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]
Message-ID: <391ae107-8c10-b14e-c1ad-0fac74951432@marcan.st>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ