Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue

[Ard Biesheuvel]

On 4 November 2017 at 13:44, Andreas FÃrber <afaerber@xxxxxxx> wrote:
> Hi everyone,
>
> The non-building clk driver has been removed for 4.14, but this patchset
> seems stuck on matters of naming and maintenance...
>
> Am 30.06.2017 um 01:18 schrieb Masahiro Yamada:
>> Hi Andreas,
>>
>> 2017-06-29 21:53 GMT+09:00 Andreas FÃrber <afaerber@xxxxxxx>:
>>> Hi Masahiro-san,
>>>
>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@xxxxxxxxxx>:
>>>>> On Sun, Jun 25, 2017 at 07:00:18PM +0200, Andreas FÃrber wrote:
>>>>>> For consistency with existing SoC bindings, use "fujitsu,mb86s71" but
>>>>>> socionext.txt.
>>>>>>
>>>>>> Signed-off-by: Andreas FÃrber <afaerber@xxxxxxx>
>>>>>> ---
>>>>>>  Documentation/devicetree/bindings/arm/socionext.txt | 17 +++++++++++++++++
>>>>>>  1 file changed, 17 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/arm/socionext.txt
>>>>>
>>>>> Acked-by: Rob Herring <robh@xxxxxxxxxx>
>>>>> --
>>>>
>>>> I do not mind this, but
>>>> please note there are multiple product lines in Socionext
>>>> because Socionext merged LSI divisions from Panasonic and Fujitsu.
>>>>
>>>> I maintain documents for Socionext UniPhier SoC family
>>>> (which inherits SoC architecture of Panasonic)
>>>> in Documentation/devicetree/bindings/arm/uniphier/.
>>>
>>> Actually you seemed to be lacking bindings beyond the cache controller
>>> for Uniphier:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/arm/uniphier
>>>
>>> The SoC compatible, e.g. "socionext,uniphier-ld11", needs to be defined
>>> somewhere too, as done here. A git-grep for that particular compatible
>>> only finds derived clk and reset bindings.
>>
>> I can care to send a patch later, but it is off-topic here.
>
> [The relevance was that had there been any bindings precedence from
> UniPhier, it would've influenced my naming choices.]
>
>>> Using socionext.txt allows you to add those bindings to a shared file;
>>> if you prefer to host them separately below uniphier/ or as uniphier.txt
>>
>> I was thinking of this way.
>>
>> For example, TI has omap/, keystone/, davinci.txt, etc.
>> in this directory level.
>>
>>
>>> do you have a better name suggestion for this one? I was trying to keep
>>> our options open to later add SC2A11 in socionext.txt, and I also saw
>>> some mb8ac300 or so (MB86S7x predecessor?) in downstream sources, so I
>>> don't know a good common name for the non-Panasonic parts. And if we
>>> take fujitsu.txt for MB86S7x to match the vendor prefix then we will
>>> need a separate file for the new SC2A11 IIUC.
>>
>> I have no idea.
>> Actually, I am not familiar with those SoCs.
>>
>> I am not sure if there exists a common name for those Fujitsu-derived SoCs.
>> I think a SoC family name will be helpful to avoid proliferating
>> arch/arm/mach-{mb86s7x,mb8ac300, ...}.
>>
>> I see some Socionext guys CC'ed in this mail,
>> somebody might have information about this.
>>
>> As I said before, I do not mind adding socionext.txt
>> and it seems reasonable enough
>> if there is no common name for those SoCs.
>>
>>
>>
>>> Also if you can tell us where the cut between Fujitsu and Socionext
>>> should be done, we can certainly adapt. NXP is still adding all their
>>> new SoCs in fsl.txt, it seems.
>>> (A similar naming issue exists for my not-yet-submitted FM4 patches,
>>> where it changed owners from Fujitsu to Spansion and then to Cypress.)
>>>
>>
>> Right, vendor names are not future-proof in some cases.
>>
>> We use "uniphier" because it is convenient to
>> make a group of SoCs with similar architecture,
>> and it will work even if UniPhier product lines are sold again in the
>> future.  :-)
>
> Summarizing: Masahiro-san only wants to maintain the UniPhier family of
> Socionext SoCs, not this MB86S71. No one from Socionext or Linaro has
> volunteered as maintainer for these F-Cue MB86S71 patches - that seems
> to indicate I'll again have to set up a new repository and start
> maintaining it myself.
>
> Naming it linux-socionext.git wouldn't quite be right due to UniPhier
> also being Socionext.
>
> It's also unclear whether and by whom there may be SC2A11 patches - I
> hear for now Linaro are maintaining a SynQuacer DT in EDK2, rebelling
> against linux.git.
>

Eh, wait, what? "Rebelling against linux.git"? What is that supposed
to mean exactly?


> So... what about naming it linux-fujitsu.git? Then we could keep the
> "fujitsu," vendor prefix and document compatibles in a fujitsu.txt for
> consistency (instead of this v1's socionext.txt), and I could later add
> non-Socionext FM4 (Spansion/Cypress) to the same tree and bindings file.
>
> That still leaves conflict potential with the upcoming Fujitsu Post-K
> chip, but we could still worry about that if it ever results in DT
> bindings patches rather than just ACPI tables.
>
> Objections, suggestions?
>
> Thanks,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 NÃrnberg, Germany
> GF: Felix ImendÃrffer, Jane Smithard, Graham Norton
> HRB 21284 (AG NÃrnberg)
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel