From: Hector Martin <[email protected]>
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 <[email protected]>
---
This trivial dt-bindings update should be merged through the asahi-soc
tree to ensure validation of the Apple M2 (t8112) devicetrees in this
series.
---
Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
index 94d369eb85de..59a6af735a21 100644
--- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
+++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
@@ -32,6 +32,7 @@ properties:
items:
- enum:
- apple,t8103-pmgr-pwrstate
+ - apple,t8112-pmgr-pwrstate
- apple,t6000-pmgr-pwrstate
- const: apple,pmgr-pwrstate
--
2.39.1
On 12/02/2023 16:41, Janne Grunau wrote:
> From: Hector Martin <[email protected]>
>
> 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 <[email protected]>
>
Missing SoB.
Best regards,
Krzysztof
On 13/02/2023 20.09, Krzysztof Kozlowski wrote:
> On 12/02/2023 16:41, Janne Grunau wrote:
>> From: Hector Martin <[email protected]>
>>
>> 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 <[email protected]>
>>
>
> Missing SoB.
>
I'd rather get an r-b, since this is going back into my tree ;)
- Hector
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 <[email protected]>
>>>
>>> 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 <[email protected]>
>>>
>>
>> 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.
Best regards,
Krzysztof
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 <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>>
>>>
>>> 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
On 2023-02-12 16:41:11 +0100, Janne Grunau wrote:
> From: Hector Martin <[email protected]>
>
> 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 <[email protected]>
>
> ---
> This trivial dt-bindings update should be merged through the asahi-soc
> tree to ensure validation of the Apple M2 (t8112) devicetrees in this
> series.
> ---
> Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
> index 94d369eb85de..59a6af735a21 100644
> --- a/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
> +++ b/Documentation/devicetree/bindings/power/apple,pmgr-pwrstate.yaml
> @@ -32,6 +32,7 @@ properties:
> items:
> - enum:
> - apple,t8103-pmgr-pwrstate
> + - apple,t8112-pmgr-pwrstate
> - apple,t6000-pmgr-pwrstate
> - const: apple,pmgr-pwrstate
Reviewed-by: Janne Grunau <[email protected]>
Janne
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 <[email protected]>
>>>>>
>>>>> 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 <[email protected]>
>>>>>
>>>>
>>>> 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. She might
have rebased it or not. The chain expects that anyone touching the patch
must leave SoB. I am not providing my reviewes for patches breaking the
process we have clearly described. 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.
Best regards,
Krzysztof
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 <[email protected]>
>>>>>>
>>>>>> 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 <[email protected]>
>>>>>>
>>>>>
>>>>> 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