On 14/02/2023 18.39, Krzysztof Kozlowski wrote: > On 14/02/2023 09:43, Hector Martin wrote: >> 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@xxxxxxxxx> >>>>>> >>>>>> 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@xxxxxxxxx> >>>>>> >>>>> >>>>> 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. > > Listen, I have no clue whether Janne changed the patch or not. I do, which is why I asked for an r-b and not an SoB. > She might > have rebased it or not. The patch is identical to what is in my asahi tree already. > The chain expects that anyone touching the patch > must leave SoB. And clearly it wasn't touched here. > I am not providing my reviewes for patches breaking the > process we have clearly described. Good thing we don't need your review for simple compatible additions then! > I also do not see any problem in > following the process we have - adding SoB whenever you play with a > patch and send it. Entire discussion is silly indeed, instead of just > following the process. Or you could just stop nitpicking and doubling down on things that don't even concern you, since it is *my* tree and *my* job to worry about the signoffs being kosher, not yours, as *I* am upstream in the submission path and you are not. - Hector
