lkml.org 
[lkml]   [2017]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue
    On 4 November 2017 at 13:44, Andreas Färber <afaerber@suse.de> 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@suse.de>:
    >>> Hi Masahiro-san,
    >>>
    >>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada:
    >>>> 2017-06-29 1:46 GMT+09:00 Rob Herring <robh@kernel.org>:
    >>>>> 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@suse.de>
    >>>>>> ---
    >>>>>> 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@kernel.org>
    >>>>> --
    >>>>
    >>>> 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@lists.infradead.org
    > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

    \
     
     \ /
      Last update: 2017-11-04 15:57    [W:3.709 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site