From: Alexander Usyskin <[email protected]>
pm_runtime_autosuspend can take synchronous or asynchronous
paths, Because we are calling pm_runtime_mark_last_busy just before
this most of the cases it takes the asynchronous way. However,
when the FW or driver resets during already running runtime suspend,
the call will result in calling to the driver's rpm callback and results
in a deadlock on device_lock.
The simplest fix is to replace pm_runtime_autosuspend with
asynchronous pm_request_autosuspend.
Cc: <[email protected]> # 4.4+
Signed-off-by: Alexander Usyskin <[email protected]>
Signed-off-by: Tomas Winkler <[email protected]>
---
drivers/misc/mei/client.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 9635b14b6011..391936c1aa04 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -691,7 +691,7 @@ void mei_host_client_init(struct mei_device *dev)
pm_runtime_mark_last_busy(dev->dev);
dev_dbg(dev->dev, "rpm: autosuspend\n");
- pm_runtime_autosuspend(dev->dev);
+ pm_request_autosuspend(dev->dev);
}
/**
--
2.7.4
>
> From: Alexander Usyskin <[email protected]>
>
> pm_runtime_autosuspend can take synchronous or asynchronous paths,
> Because we are calling pm_runtime_mark_last_busy just before this most of
> the cases it takes the asynchronous way. However, when the FW or driver
> resets during already running runtime suspend, the call will result in calling to
> the driver's rpm callback and results in a deadlock on device_lock.
> The simplest fix is to replace pm_runtime_autosuspend with asynchronous
> pm_request_autosuspend.
>
> Cc: <[email protected]> # 4.4+
Looks like git send-email is not able to parse this address correctly though this is suggested format by Documentation/stable_kernel_rules.txt.
Create wrong address If git parsers is used : '[email protected]#4.4+'
Something like s/#.*$// is needed before parsing Cc:
Thanks
Tomas
On Thu, Nov 24, 2016 at 04:10:49PM +0000, Winkler, Tomas wrote:
> > Cc: <[email protected]> # 4.4+
>
> Looks like git send-email is not able to parse this address correctly
> though this is suggested format by Documentation/stable_kernel_rules.txt.
> Create wrong address If git parsers is used : '[email protected]#4.4+'
>
> Something like s/#.*$// is needed before parsing Cc:
This should be fixed by e3fdbcc8e (parse_mailboxes: accept extra text
after <...> address, 2016-10-13), which will be released next week as
part of v2.11. As a workaround, you can also install the Mail::Address
perl module. See [1] for the gory details.
-Peff
[1] http://public-inbox.org/git/[email protected]/
>
> On Thu, Nov 24, 2016 at 04:10:49PM +0000, Winkler, Tomas wrote:
>
> > > Cc: <[email protected]> # 4.4+
> >
> > Looks like git send-email is not able to parse this address correctly
> > though this is suggested format by Documentation/stable_kernel_rules.txt.
> > Create wrong address If git parsers is used : '[email protected]#4.4+'
> >
> > Something like s/#.*$// is needed before parsing Cc:
>
> This should be fixed by e3fdbcc8e (parse_mailboxes: accept extra text after
> <...> address, 2016-10-13), which will be released next week as part of v2.11. As
> a workaround, you can also install the Mail::Address perl module. See [1] for
> the gory details.
Thanks for update, I failed to understand from the thread though what decision was actually applied, I will look at the patch itself.
I've tried to install Mail::Address and it fixes the actual address, but it appends the # 4.4+ suffix into the name
as also mentioned in the thread, which doesn't fit the stable rules doc.
So far I've fixed the particular issue with the simple substitute above, till the real fix is released.
Maybe the stable kernel maintainers should also be pulled into the conversation.
Thanks
Tomas
On Thu, Nov 24, 2016 at 10:37:14PM +0000, Winkler, Tomas wrote:
> > > > Cc: <[email protected]> # 4.4+
> > >
> > > Looks like git send-email is not able to parse this address correctly
> > > though this is suggested format by Documentation/stable_kernel_rules.txt.
> > > Create wrong address If git parsers is used : '[email protected]#4.4+'
> > >
> > > Something like s/#.*$// is needed before parsing Cc:
> >
> > This should be fixed by e3fdbcc8e (parse_mailboxes: accept extra text after
> > <...> address, 2016-10-13), which will be released next week as part of v2.11. As
> > a workaround, you can also install the Mail::Address perl module. See [1] for
> > the gory details.
>
> Thanks for update, I failed to understand from the thread though what
> decision was actually applied, I will look at the patch itself. I've
> tried to install Mail::Address and it fixes the actual address, but it
> appends the # 4.4+ suffix into the name as also mentioned in the
> thread, which doesn't fit the stable rules doc.
The patch just brings parity to the Mail::Address behavior and git's
fallback parser, so that you don't end up with the broken
[email protected]#4.4+ address. Instead, that content goes into the
name part of the address.
It sounds like you want the "# 4.4+" to be dropped entirely in the
rfc822 header. It looks like send-email used to do that, but stopped in
b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc,
2015-06-30).
So perhaps there are further fixes required, but it's hard to know. The
input isn't a valid rfc822 header, so it's not entirely clear what the
output is supposed to be. I can buy either "drop it completely" or
"stick it in the name field of the cc header" as reasonable.
-Peff
W dniu 25.11.2016 o 04:14, Jeff King pisze:
> On Thu, Nov 24, 2016 at 10:37:14PM +0000, Winkler, Tomas wrote:
>
>>>>> Cc: <[email protected]> # 4.4+
>>>>
>>>> Looks like git send-email is not able to parse this address correctly
>>>> though this is suggested format by Documentation/stable_kernel_rules.txt.
>>>> Create wrong address If git parsers is used : '[email protected]#4.4+'
[...]
> The patch just brings parity to the Mail::Address behavior and git's
> fallback parser, so that you don't end up with the broken
> [email protected]#4.4+ address. Instead, that content goes into the
> name part of the address.
>
> It sounds like you want the "# 4.4+" to be dropped entirely in the
> rfc822 header. It looks like send-email used to do that, but stopped in
> b1c8a11c8 (send-email: allow multiple emails using --cc, --to and --bcc,
> 2015-06-30).
>
> So perhaps there are further fixes required, but it's hard to know. The
> input isn't a valid rfc822 header, so it's not entirely clear what the
> output is supposed to be. I can buy either "drop it completely" or
> "stick it in the name field of the cc header" as reasonable.
Well, we could always convert it to email address comment, converting
for example the following trailer:
Cc: John Doe <[email protected]> # comment
to the following address:
John Doe <[email protected]> (comment)
Just FYI. Though I'm not sure how well this would work...
Best,
--
Jakub Narębski
>
> W dniu 25.11.2016 o 04:14, Jeff King pisze:
> > On Thu, Nov 24, 2016 at 10:37:14PM +0000, Winkler, Tomas wrote:
> >
> >>>>> Cc: <[email protected]> # 4.4+
> >>>>
> >>>> Looks like git send-email is not able to parse this address
> >>>> correctly though this is suggested format by
> Documentation/stable_kernel_rules.txt.
> >>>> Create wrong address If git parsers is used : '[email protected]#4.4+'
> [...]
>
> > The patch just brings parity to the Mail::Address behavior and git's
> > fallback parser, so that you don't end up with the broken
> > [email protected]#4.4+ address. Instead, that content goes into
> > the name part of the address.
> >
> > It sounds like you want the "# 4.4+" to be dropped entirely in the
> > rfc822 header. It looks like send-email used to do that, but stopped
> > in
> > b1c8a11c8 (send-email: allow multiple emails using --cc, --to and
> > --bcc, 2015-06-30).
> >
> > So perhaps there are further fixes required, but it's hard to know.
> > The input isn't a valid rfc822 header, so it's not entirely clear what
> > the output is supposed to be. I can buy either "drop it completely" or
> > "stick it in the name field of the cc header" as reasonable.
>
> Well, we could always convert it to email address comment, converting for
> example the following trailer:
>
> Cc: John Doe <[email protected]> # comment
>
> to the following address:
>
> John Doe <[email protected]> (comment)
>
> Just FYI. Though I'm not sure how well this would work...
>
Yep, it actually looks as right place to put this kind of info,
though I'm not on the receiving side.
I'm not sure if and how is this used by stable maintainers.
Thanks
Tomas