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. 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) -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
