RE: [char-misc-next] mei: request async autosuspend at the end of enumeration

RE: [char-misc-next] mei: request async autosuspend at the end of enumeration

[Winkler, Tomas]

> 
> From: Alexander Usyskin <alexander.usyskin@intel.com>
> 
> 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: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#4.4+' 

Something like s/#.*$// is needed before parsing Cc: 

Thanks
Tomas 

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

[Jeff King]

On Thu, Nov 24, 2016 at 04:10:49PM +0000, Winkler, Tomas wrote:

> > Cc: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#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/41164484-309b-bfff-ddbb-55153495d41a@lwfinger.net/

RE: [char-misc-next] mei: request async autosuspend at the end of enumeration

[Winkler, Tomas]

> 
> On Thu, Nov 24, 2016 at 04:10:49PM +0000, Winkler, Tomas wrote:
> 
> > > Cc: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#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 

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

[Jeff King]

On Thu, Nov 24, 2016 at 10:37:14PM +0000, Winkler, Tomas wrote:

> > > > Cc: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#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
stable@vger.kernel.org#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

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

[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: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#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
> stable@vger.kernel.org#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 <john@example.com> # comment

to the following address:

  John Doe <john@example.com> (comment)

Just FYI.  Though I'm not sure how well this would work...

Best,
-- 
Jakub Narębski

RE: [char-misc-next] mei: request async autosuspend at the end of enumeration

[Winkler, Tomas]

> 
> 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: <stable@vger.kernel.org> # 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 : 'stable@vger.kernel.org#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
> > stable@vger.kernel.org#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 <john@example.com> # comment
> 
> to the following address:
> 
>   John Doe <john@example.com> (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