[PATCH v3 3/7] dt-bindings: mfd: add binding for Apple Mac System Management Controller

[Hector Martin]

On 10/11/2022 07.17, Rob Herring wrote:
> On Tue, Nov 08, 2022 at 10:22:31PM +0000, Russell King (Oracle) wrote:
>> On Tue, Nov 08, 2022 at 09:55:58PM +0100, Krzysztof Kozlowski wrote:
>>> On 08/11/2022 17:33, Russell King (Oracle) wrote:
>>>> Add a DT binding for the Apple Mac System Management Controller.
>>>
>>> Drop the second, redundant "binding" from subject. It's already in prefix.
>>
>> Yet another thing that's been there from the start... how many more
>> things are you going to pick up in subsequent versions of the patch?
>> When does this stop?
>>
>> In any case, taking your comment literally,
>>
>> "dt-bindings: mfd: add for Apple Mac System Management Controller"
>>
>> makes no sense, so presumably you want something more than that.
>>
>> In any case, I see several recent cases already merged which follow
>> the pattern that I've used and that you've reviewed.
>>
>>>> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
>>>> ---
>>>>  .../devicetree/bindings/mfd/apple,smc.yaml    | 67 +++++++++++++++++++
>>>>  1 file changed, 67 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/mfd/apple,smc.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/apple,smc.yaml b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
>>>> new file mode 100644
>>>> index 000000000000..014eba5a1bbc
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/mfd/apple,smc.yaml
>>>> @@ -0,0 +1,67 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/mfd/apple,smc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Apple Mac System Management Controller
>>>> +
>>>> +maintainers:
>>>> +  - Hector Martin <marcan at marcan.st>
>>>> +
>>>> +description:
>>>> +  Apple Mac System Management Controller implements various functions
>>>> +  such as GPIO, RTC, power, reboot.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    items:
>>>> +      - enum:
>>>> +          - apple,t6000-smc
>>>> +          - apple,t8103-smc
>>>> +          - apple,t8112-smc
>>>> +      - const: apple,smc
>>>> +
>>>> +  reg:
>>>> +    items:
>>>> +      - description: SMC area
>>>> +      - description: SRAM area
>>>> +
>>>> +  reg-names:
>>>> +    items:
>>>> +      - const: smc
>>>> +      - const: sram
>>>> +
>>>> +  mboxes:
>>>> +    maxItems: 1
>>>> +
>>>> +  gpio:
>>>> +    $ref: /schemas/gpio/gpio-macsmc.yaml
>>>
>>> So this depends on other patch, so:
>>> 1. You need mention the dependency in cover letter (nothing there),
>>> 2. Re-order patches.
>>>
>>> The GPIO cannot go separate tree and this must be explicitly communicated.
>>
>> Sigh, getting an order that is sensible is really bloody difficult.
> 
> It's not. Sub-devices before the MFD. The only time that doesn't work is 
> when the sub-devices put the parent MFD in their example. The solution 
> there is don't do that. Just 1 complete example in the MFD schema and no 
> examples in the sub-devices.
> 
>> I'm quite sure Lee is only going to want to apply the mfd bits. 
> 
> Indeed. I can't seem to make Lee care... All the schemas should really 
> be applied together.
> 
>> Then
>> what do we do with the other bits? GPIO stuff via the GPIO tree, then
>> wait a cycle before the rest can be merged. Or what?
> 
> The schemas must be picked up in the same cycle. I don't care so much 
> if subsystem maintainers' trees have warnings if they don't care, but I 
> do care for linux-next. If the subsystem bits aren't picked up, then 
> I'll pick them up if it comes to that.
> 

We can take all the schemas and DT changes via asahi-soc if that works
for you. This also lets us move forward with more related DT changes
that would apply on top of things already in that branch. Then Lee only
has to take the mfd core bits (and possibly the RTKit platform part, or
we can figure something else out for that).


- Hector