Received: by 10.223.164.197 with SMTP id h5csp186687wrb; Sat, 4 Nov 2017 08:32:04 -0700 (PDT) X-Google-Smtp-Source: ABhQp+TloD9o+GDjdRBcBg3/KVGwLt33cBIefjDklOHJXtnHYN8+FM6L3YfmJoHRy/P5Wdz7CkXs X-Received: by 10.159.255.70 with SMTP id u6mr9995823pls.41.1509809524239; Sat, 04 Nov 2017 08:32:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509809524; cv=none; d=google.com; s=arc-20160816; b=bfn9Q5xCtDx1djBW+yqEK2dQQos7ITxq8vycIWWvxVwMVfpnUqhaXTTuRMguolNmb8 BRMRmuBvT/L/g9pF/QUO+88hdhfrSXc8f0CBbIQQCOy5hjoNFvgmaM6dUSt0VFe+mQkK XspqWTlhc+Ju/LnJ+QqJ6Di4MQeerUaERTnclewqOtbwsePit3v2ynX3Xs9OFwJlUp8A 8P+pjulW6WHtOfmLJcjWsw1ts4GPbFSu96rB1sjNNtkU9IevxTAgsucobsHCLdw8nsQE uo1c7et481KUG968WGJduY7AkPNuf7bnvYSsGZQ808F5u5Sm+PAd1RhiStYcgJ8rDtVB SBBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=Ik1tjl0OTEaGxsoBswp6mMXklQJnGJt4907KYMYxdw8=; b=yS0Qedi/MdTD1EiHV3mt8ZFrRJgflZfYFdaJnY47gWgMFrK4HlpJfu7BAcB0iYD0cT RMyb/e43cH3AqA5N+NbMoT0hMge6TQSHLMi7HDvD7dd+Q/uirxFm2LJ0q8eDhXjf9c6Q SUFB+D9wo0fYjgb0hUkph2HCtQTCEiGb4q7nAyi06W7y3PH5TeaDLammjUIPRy6E/I6T uqxS4gkdoRjT8qZohAJwhKOmRcdUX0pKfhddbYzK7gPGxY+QqJLbuQnJ0no5dRZpgSZf mG1bHxZ9bPgbGW+6rklrCTX8Jn5SLRLrtL19UsH+AEa06udJ9yaV+eSPuIF/GG9keGmC t5Cg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c2si7514177plk.427.2017.11.04.08.31.50; Sat, 04 Nov 2017 08:32:04 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932938AbdKDPbL (ORCPT + 92 others); Sat, 4 Nov 2017 11:31:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:49026 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751710AbdKDPbK (ORCPT ); Sat, 4 Nov 2017 11:31:10 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1CF37ABFA; Sat, 4 Nov 2017 15:31:07 +0000 (UTC) Subject: Re: [PATCH 3/5] dt-bindings: arm: Document Socionext MB86S71 and Fujitsu F-Cue To: Ard Biesheuvel Cc: Leif Lindholm , Grant Likely , Masahiro Yamada , Satoru OKAMOTO , Arnd Bergmann , Olof Johansson , Mark Rutland , Rob Herring , "devicetree@vger.kernel.org" , Linux Kernel Mailing List , Amit Kucheria , linux-arm-kernel References: <20170625170020.11791-1-afaerber@suse.de> <20170625170020.11791-4-afaerber@suse.de> <20170628164605.2gnvrv4g7jluzyrm@rob-hp-laptop> <51221840-b08e-45f1-5601-937fb15f3947@suse.de> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Organization: SUSE Linux GmbH Message-ID: <3327258c-b222-248b-9550-7620a57328f5@suse.de> Date: Sat, 4 Nov 2017 23:30:59 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 04.11.2017 um 22:57 schrieb Ard Biesheuvel: > On 4 November 2017 at 13:44, Andreas Färber 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 : >>>> Hi Masahiro-san, >>>> >>>> Am 29.06.2017 um 14:18 schrieb Masahiro Yamada: >>>>> 2017-06-29 1:46 GMT+09:00 Rob Herring : >>>>>> 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 >>>>>>> --- >>>>>>> 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 >>>>>> -- >>>>> >>>>> 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? Bindings must be submitted to the devicetree mailing list, acked by Rob and merged into the Linux tree before compatible strings may be used in Linux drivers or in-tree .dts[i] files. checkpatch.pl checks for that. U-Boot only allows import of new .dts files from Linux, too. So Linus' linux.git is the location to merge any vendor prefixes and device tree bindings, as well as the central location for device trees. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts If you're unfamiliar with that, talk to your Linaro colleagues please! Regards, Andreas > > >> 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 -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) From 1583147986045941326@xxx Sat Nov 04 14:59:33 +0000 2017 X-GM-THRID: 1571196999491588298 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread