linux-next: Fixes tags need some work in the pinctrl tree

linux-next: Fixes tags need some work in the pinctrl tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

Hi all,

In commit

  6548c9dc711d ("pinctrl/rockchip: support deferring other gpio params")

Fixes tags

  Fixes: e7165b1d ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
  Fixes: 59dd178e ("gpio/rockchip: fetch deferred output settings on probe")

have these problem(s):

  - SHA1 should be at least 12 digits long
    This can be fixed for the future by setting core.abbrev to 12 (or
    more) or (for git v2.11 or later) just making sure it is not set
    (or set to "auto").

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Fixes tags need some work in the pinctrl tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

Hi all,

On Thu, 21 Apr 2022 09:10:55 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> In commit
> 
>   6548c9dc711d ("pinctrl/rockchip: support deferring other gpio params")
> 
> Fixes tags
> 
>   Fixes: e7165b1d ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
>   Fixes: 59dd178e ("gpio/rockchip: fetch deferred output settings on probe")
> 
> have these problem(s):
> 
>   - SHA1 should be at least 12 digits long
>     This can be fixed for the future by setting core.abbrev to 12 (or
>     more) or (for git v2.11 or later) just making sure it is not set
>     (or set to "auto").

This is now commit aa696c2e8f33.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: Fixes tags need some work in the pinctrl tree

[Linus Walleij]

On Thu, Apr 21, 2022 at 1:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> In commit
>
>   6548c9dc711d ("pinctrl/rockchip: support deferring other gpio params")
>
> Fixes tags
>
>   Fixes: e7165b1d ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
>   Fixes: 59dd178e ("gpio/rockchip: fetch deferred output settings on probe")
>
> have these problem(s):
>
>   - SHA1 should be at least 12 digits long
>     This can be fixed for the future by setting core.abbrev to 12 (or
>     more) or (for git v2.11 or later) just making sure it is not set
>     (or set to "auto").

Fixed it up by rebasing, thanks!

Yours,
Linus Walleij

Re: linux-next: Fixes tags need some work in the pinctrl tree

[Caleb Connolly]

Hi both,

Apologies, I made a silly mistake when submitting this series.

Patch 2 
(https://lore.kernel.org/linux-rockchip/20220328005005.72492-3-kc@postmarketos.org/), 
contains a fix which should have been squashed into patch one - the first hunk 
of the diff, the bug is a bitwise compare to an enum which isn't bitwise:

if (param == (PIN_CONFIG_OUTPUT | PIN_CONFIG_INPUT_ENABLE))

In hindsight, I think it was a mistake the add a Fixes tag to the first patch, 
it doesn't fix a "bug" it just adds behaviour which arguably should have been 
implemented in the patch it fixes.

The patch shouldn't be backported to stable as it will introduce a bug if ported 
without the second patch (and as above, I don't think this series should be 
backported at all). Could you let me know how to get this dropped from backporting?

Again, sorry for the hassle this has caused.

Kind regards,
Caleb

On 22/04/2022 21:57, Linus Walleij wrote:
> On Thu, Apr 21, 2022 at 1:11 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
>> In commit
>>
>>    6548c9dc711d ("pinctrl/rockchip: support deferring other gpio params")
>>
>> Fixes tags
>>
>>    Fixes: e7165b1d ("pinctrl/rockchip: add a queue for deferred pin output settings on probe")
>>    Fixes: 59dd178e ("gpio/rockchip: fetch deferred output settings on probe")
>>
>> have these problem(s):
>>
>>    - SHA1 should be at least 12 digits long
>>      This can be fixed for the future by setting core.abbrev to 12 (or
>>      more) or (for git v2.11 or later) just making sure it is not set
>>      (or set to "auto").
> 
> Fixed it up by rebasing, thanks!
> 
> Yours,
> Linus Walleij

Re: linux-next: Fixes tags need some work in the pinctrl tree

[Linus Walleij]

On Mon, Apr 25, 2022 at 2:27 PM Caleb Connolly <kc@postmarketos.org> wrote:

> The patch shouldn't be backported to stable as it will introduce a bug if ported
> without the second patch (and as above, I don't think this series should be
> backported at all). Could you let me know how to get this dropped from backporting?

If Greg or Sasha etc propose the patch for stable (which will not happen
automatically unless you explicitly add Cc: stable@vger.kernel.org)
they send out a proposal "I will add this patch to stable", with CC to the
author, and then you can say you don't want it backported.

Many Fixes:-tagged patches do not get picked up for stable, it is not
what the tag means, if you want things to be picked for stable, the
rule is Cc: stable@, it's just that sometimes the stable maintainers
(and an AI!) pick some Fixes: patches anyways.

Yours,
Linus Walleij

Re: linux-next: Fixes tags need some work in the pinctrl tree

[Caleb Connolly]

On 25/04/2022 14:33, Linus Walleij wrote:
> On Mon, Apr 25, 2022 at 2:27 PM Caleb Connolly <kc@postmarketos.org> wrote:
> 
>> The patch shouldn't be backported to stable as it will introduce a bug if ported
>> without the second patch (and as above, I don't think this series should be
>> backported at all). Could you let me know how to get this dropped from backporting?
> 
> If Greg or Sasha etc propose the patch for stable (which will not happen
> automatically unless you explicitly add Cc: stable@vger.kernel.org)
> they send out a proposal "I will add this patch to stable", with CC to the
> author, and then you can say you don't want it backported.
> 
> Many Fixes:-tagged patches do not get picked up for stable, it is not
> what the tag means, if you want things to be picked for stable, the
> rule is Cc: stable@, it's just that sometimes the stable maintainers
> (and an AI!) pick some Fixes: patches anyways.
Ah ok, that's a relief. Thanks for the explanation!
> 
> Yours,
> Linus Walleij