linux-kernel - Re: [PATCH 01/17] dt-bindings: power: apple,pmgr-pwrstate: Add t8112 compatible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 14 Feb 2023 17:43:40 +0900
From:   Hector Martin <marcan@...can.st>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Janne Grunau <j@...nau.net>, Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Mark Kettenis <kettenis@...nbsd.org>
Cc:     asahi@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/17] dt-bindings: power: apple,pmgr-pwrstate: Add t8112
 compatible

On 14/02/2023 16.50, Krzysztof Kozlowski wrote:
> On 14/02/2023 03:24, Hector Martin wrote:
>> On 13/02/2023 20.09, Krzysztof Kozlowski wrote:
>>> On 12/02/2023 16:41, Janne Grunau wrote:
>>>> From: Hector Martin <marcan@...can.st>
>>>>
>>>> Add the apple,t8112-pmgr-pwrstate compatible for the Apple M2 SoC.
>>>>
>>>> This goes after t8103. The sort order logic here is having SoC numeric
>>>> code families in release order, and SoCs within each family in release
>>>> order:
>>>>
>>>> - t8xxx (Apple HxxP/G series, "phone"/"tablet" chips)
>>>>   - t8103 (Apple H13G/M1)
>>>>   - t8112 (Apple H14G/M2)
>>>> - t6xxx (Apple HxxJ series, "desktop" chips)
>>>>   - t6000 (Apple H13J(S)/M1 Pro)
>>>>   - t6001 (Apple H13J(C)/M1 Max)
>>>>   - t6002 (Apple H13J(D)/M1 Ultra)
>>>>
>>>> Note that t600[0-2] share the t6000 compatible where the hardware is
>>>> 100% compatible, which is usually the case in this highly related set
>>>> of SoCs.
>>>>
>>>> Signed-off-by: Hector Martin <marcan@...can.st>
>>>>
>>>
>>> Missing SoB.
>>>
>>
>> I'd rather get an r-b, since this is going back into my tree ;)
> 
> Please follow Linux process which requires SoB chain.

A SoB is not an r-b. I do not upstream patches that are unreviewed. I
wrote the patch. Someone needs to review it.

The extra SoB is redundant because this is going back into my tree, I
wrote it, and I will be the committer when I apply it. It's a one-liner
patch. I know what I wrote. Sure we could record Janne's SoB as a
technicality, but it feels silly. What matters more is that the patch
gets reviewed, not that on a patch series technicality it ended up being
Janne who sent it to the list. I could just pull the patch from my own
branch and then it didn't go through Janne so it doesn't need his SoB.
But it does need someone's review (because I absolutely refuse to merge
my own patches without review, although not every maintainer has that
policy unfortunately, which means there's lots of unreviewed code in the
kernel).

Please. Let's cut down on the silliness. Please. We're trying to get
stuff done here. I'm tired of having to explain every little thing over
and over and over again. I really am.

- Hector