Re: [PATCH 2/3] dt-bindings: rockchip: Add DesignWare based PCIe controller

[Robin Murphy <robin.murphy@arm.com>]

On 2021-01-20 14:54, Heiko Stübner wrote:
> Am Mittwoch, 20. Januar 2021, 15:16:25 CET schrieb Rob Herring:
>> On Tue, Jan 19, 2021 at 12:40 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>>
>>> On 2021-01-19 15:11, Johan Jonker wrote:
>>>> Hi Simon, Heiko,
>>>>
>>>> On 1/19/21 2:14 PM, Heiko Stübner wrote:
>>>>> Hi Johan,
>>>>>
>>>>> Am Dienstag, 19. Januar 2021, 14:07:41 CET schrieb Johan Jonker:
>>>>>> Hi Simon,
>>>>>>
>>>>>> Thank you for this patch for rk3568 pcie.
>>>>>>
>>>>>> Include the Rockchip device tree maintainer and all other people/lists
>>>>>> to the CC list.
>>>>>>
>>>>>> ./scripts/checkpatch.pl --strict <patch1> <patch2>
>>>>>>
>>>>>>    ./scripts/get_maintainer.pl --noroles --norolestats --nogit-fallback
>>>>>> --nogit <patch1> <patch2>
>>>>>>
>>>>>> git send-email --suppress-cc all --dry-run --annotate --to
>>>>>> heiko@sntech.de --cc <..> <patch1> <patch2>
>>>>>>
>>>>>> This SoC has no support in mainline linux kernel yet.
>>>>>> In all the following yaml documents for rk3568 we need headers with
>>>>>> defines for clocks and power domains, etc.
>>>>>>
>>>>>> For example:
>>>>>> #include <dt-bindings/clock/rk3568-cru.h>
>>>>>> #include <dt-bindings/power/rk3568-power.h>
>>>>>>
>>>>>> Could Rockchip submit first clocks and power drivers entries and a basic
>>>>>> rk3568.dtsi + evb dts?
>>>>>> Include a patch to this serie with 3 pcie nodes added to rk3568.dtsi.
>>>>>>
>>>>>> A dtbs_check only works with a complete dtsi and evb dts.
>>>>>>
>>>>>> make ARCH=arm64 dtbs_check
>>>>>> DT_SCHEMA_FILES=Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
>>>>>>
>>>>>> On 1/18/21 10:17 AM, Simon Xue wrote:
>>>>>>> Signed-off-by: Simon Xue <xxm@rock-chips.com>
>>>>>>> ---
>>>>>>>    .../bindings/pci/rockchip-dw-pcie.yaml        | 101 ++++++++++++++++++
>>>>>>>    1 file changed, 101 insertions(+)
>>>>>>>    create mode 100644 Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
>>>>>>> new file mode 100644
>>>>>>> index 000000000000..fa664cfffb29
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
>>>>>>> @@ -0,0 +1,101 @@
>>>>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>>>>> +%YAML 1.2
>>>>>>> +---
>>>>>>> +$id: http://devicetree.org/schemas/pci/rockchip-dw-pcie.yaml#
>>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>>> +
>>>>>>> +title: DesignWare based PCIe RC controller on Rockchip SoCs
>>>>>>> +
>>>>>>
>>>>>>> +maintainers:
>>>>>>> +  - Shawn Lin <shawn.lin@rock-chips.com>
>>>>>>> +  - Simon Xue <xxm@rock-chips.com>
>>>>>>
>>>>>> maintainers:
>>>>>>     - Heiko Stuebner <heiko@sntech.de>
>>>>>>
>>>>>> Add only people with maintainer rights.
>>>>>
>>>>> I'd disagree on this ;-)
>>>>
>>>> All roads leads to Heiko... ;)
>>>>
>>>> It takes long term commitment.
>>>> Year in, year out.
>>>> Keeping yourself up to date with the latest pcei development.
>>>> Communicate in English.
>>>> Be able to submit patches without errors... ;)
>>>> Review other peoples patches.
>>>> Respond in short time.
>>>> Bug fixing.
>>>
>>> Crikey, it's only a DT binding... :/
>>>
>>>> If that's what you really want, then you must include a patch to this
>>>> serie for MAINTAINERS.
>>>
>>> I think if Bjorn and Lorenzo want a specifically named sub-maintainer
>>> for the driver itself, we can let them say so rather than presume.
>>
>> For the binding it's my call. :)
>>
>> This should be someone who cares and knows the h/w. IOW, if I want to
>> delete the binding, someone who will object.
>>
>> Of course, I'd like that someone to have all the above qualities too.
> 
> I guess that would be separate entites then ...

Yup, that's the point I was trying to clarify - binding maintainer and 
driver maintainer are technically distinct roles. Of course if someone 
is a driver maintainer then it's usual - and preferable - for them to 
maintain the relevant bindings as well, so MAINTAINERS entries for 
drivers typically also cover those for convenience and pre-schema 
historical reasons. However, someone can take responsibility for a 
binding without signing up to explicitly maintain a corresponding driver 
(I know I have), and in that case the schema makes the binding 
self-documenting already - we don't have MAINTAINERS entries that *only* 
cover bindings, other than the top-level one that says Rob's in charge 
overall :)

Robin.

> Shawn and Simon know the hardware way better, though I'm not sure if their
> work commitments will allow them to keep track of binding deletions
> 
> So maybe all 3 of us ;-)
> 
> Heiko
> 
>