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

[Ard Biesheuvel]

On 13 November 2017 at 15:40, Andreas Färber  wrote:
> Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
>> On 6 November 2017 at 06:58, Andreas Färber  wrote:
>>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>> [...]

 Again, I am not the one who is ranting here. You hit a nerve by
 accusing me of 'rebelling against linux.git' while this is quite the
 opposite of what I am doing.
>>>
>>> Actually you did confirm that point by starting an argument about not
>>> needing a central repository and you not liking Linux as the location.
>>> That was exactly what I meant with my original comment.
>>>
>>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>>> a year after the board went to market - there's Linaro contributions
>>> from Mani that I'm thankful for.
>>>
>>> Whereas patches keep falling into a dark hole when there's already other
>>> work for a certain vendor, such as Marvell and now Socionext, with no
>>> one feeling responsible for either taking them or saying, "hey, we're
>>> not going to submit any conflicting DT bindings for SynQuacer because we
>>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>>
>>> Don't complain about me ranting if you belittle my volunteer work that I
>>> believe Linaro and its partners should've done in the first place: If I
>>> can get an initial mainline PoC done as an individual on a few
>>> evenings/weekends, then the same should be super-easy for an
>>> organization with lots of engineers and paying member companies.
>>
>> The only person doing the ranting, rebelling and belittling in this
>> thread is you. I have never commented on the nature of your work, let
>> alone belittle it.
>
> You have stated your opinion that Device Trees don't belong in a central
> repository and that Linux was the wrong place for them.

Not as strongly as that, but ok.

> My contributions
> to Linux have been mainly such Device Trees and bindings, such as this
> patch series here.

Again, I don't have a clue what it is you work on, although I just
found out (from the other thread you started) that it involves a
Fujitsu not-quite-96board that shares IP with the SynQuacer SoC? It
was my understanding (from information I received from Socionext) that
any upstreaming efforts involving that SoC had been discarded. I guess
the Socionext and Fujitsu engineers are not talking to each other
either.

> Quod erat demonstrandum.

Mathematical proof usually involves inferring new facts from existing
facts. You have done nothing of the kind, and I am not sure what you
are so angry about, but I think it would be better to leave the
emotions out of it, and try to remain factual. Especially when it
comes to representing other people's statements.

-- 
Ard.

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

[Ard Biesheuvel]

On 13 November 2017 at 15:40, Andreas Färber  wrote:
> Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
>> On 6 November 2017 at 06:58, Andreas Färber  wrote:
>>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>> [...]

 Again, I am not the one who is ranting here. You hit a nerve by
 accusing me of 'rebelling against linux.git' while this is quite the
 opposite of what I am doing.
>>>
>>> Actually you did confirm that point by starting an argument about not
>>> needing a central repository and you not liking Linux as the location.
>>> That was exactly what I meant with my original comment.
>>>
>>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>>> a year after the board went to market - there's Linaro contributions
>>> from Mani that I'm thankful for.
>>>
>>> Whereas patches keep falling into a dark hole when there's already other
>>> work for a certain vendor, such as Marvell and now Socionext, with no
>>> one feeling responsible for either taking them or saying, "hey, we're
>>> not going to submit any conflicting DT bindings for SynQuacer because we
>>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>>
>>> Don't complain about me ranting if you belittle my volunteer work that I
>>> believe Linaro and its partners should've done in the first place: If I
>>> can get an initial mainline PoC done as an individual on a few
>>> evenings/weekends, then the same should be super-easy for an
>>> organization with lots of engineers and paying member companies.
>>
>> The only person doing the ranting, rebelling and belittling in this
>> thread is you. I have never commented on the nature of your work, let
>> alone belittle it.
>
> You have stated your opinion that Device Trees don't belong in a central
> repository and that Linux was the wrong place for them.

Not as strongly as that, but ok.

> My contributions
> to Linux have been mainly such Device Trees and bindings, such as this
> patch series here.

Again, I don't have a clue what it is you work on, although I just
found out (from the other thread you started) that it involves a
Fujitsu not-quite-96board that shares IP with the SynQuacer SoC? It
was my understanding (from information I received from Socionext) that
any upstreaming efforts involving that SoC had been discarded. I guess
the Socionext and Fujitsu engineers are not talking to each other
either.

> Quod erat demonstrandum.

Mathematical proof usually involves inferring new facts from existing
facts. You have done nothing of the kind, and I am not sure what you
are so angry about, but I think it would be better to leave the
emotions out of it, and try to remain factual. Especially when it
comes to representing other people's statements.

-- 
Ard.

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

[Andreas Färber]

Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
> On 6 November 2017 at 06:58, Andreas Färber  wrote:
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> [...]
>>>
>>> Again, I am not the one who is ranting here. You hit a nerve by
>>> accusing me of 'rebelling against linux.git' while this is quite the
>>> opposite of what I am doing.
>>
>> Actually you did confirm that point by starting an argument about not
>> needing a central repository and you not liking Linux as the location.
>> That was exactly what I meant with my original comment.
>>
>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>> a year after the board went to market - there's Linaro contributions
>> from Mani that I'm thankful for.
>>
>> Whereas patches keep falling into a dark hole when there's already other
>> work for a certain vendor, such as Marvell and now Socionext, with no
>> one feeling responsible for either taking them or saying, "hey, we're
>> not going to submit any conflicting DT bindings for SynQuacer because we
>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>
>> Don't complain about me ranting if you belittle my volunteer work that I
>> believe Linaro and its partners should've done in the first place: If I
>> can get an initial mainline PoC done as an individual on a few
>> evenings/weekends, then the same should be super-easy for an
>> organization with lots of engineers and paying member companies.
> 
> The only person doing the ranting, rebelling and belittling in this
> thread is you. I have never commented on the nature of your work, let
> alone belittle it.

You have stated your opinion that Device Trees don't belong in a central
repository and that Linux was the wrong place for them. My contributions
to Linux have been mainly such Device Trees and bindings, such as this
patch series here. Quod erat demonstrandum.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

[Andreas Färber]

Am 06.11.2017 um 12:28 schrieb Ard Biesheuvel:
> On 6 November 2017 at 06:58, Andreas Färber  wrote:
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> [...]
>>>
>>> Again, I am not the one who is ranting here. You hit a nerve by
>>> accusing me of 'rebelling against linux.git' while this is quite the
>>> opposite of what I am doing.
>>
>> Actually you did confirm that point by starting an argument about not
>> needing a central repository and you not liking Linux as the location.
>> That was exactly what I meant with my original comment.
>>
>> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
>> a year after the board went to market - there's Linaro contributions
>> from Mani that I'm thankful for.
>>
>> Whereas patches keep falling into a dark hole when there's already other
>> work for a certain vendor, such as Marvell and now Socionext, with no
>> one feeling responsible for either taking them or saying, "hey, we're
>> not going to submit any conflicting DT bindings for SynQuacer because we
>> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>>
>> Don't complain about me ranting if you belittle my volunteer work that I
>> believe Linaro and its partners should've done in the first place: If I
>> can get an initial mainline PoC done as an individual on a few
>> evenings/weekends, then the same should be super-easy for an
>> organization with lots of engineers and paying member companies.
> 
> The only person doing the ranting, rebelling and belittling in this
> thread is you. I have never commented on the nature of your work, let
> alone belittle it.

You have stated your opinion that Device Trees don't belong in a central
repository and that Linux was the wrong place for them. My contributions
to Linux have been mainly such Device Trees and bindings, such as this
patch series here. Quod erat demonstrandum.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

[Ard Biesheuvel]

On 6 November 2017 at 06:58, Andreas Färber  wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
>
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
>
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.
>
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place: If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

The only person doing the ranting, rebelling and belittling in this
thread is you. I have never commented on the nature of your work, let
alone belittle it.

I understand you are frustrated with how some of the upstreaming of
96boards is handled. I don't have anything to do with that. The only
96boards i have in my drawer (and never use) is an original HiKey.

I work for the enterprise group, not the 96boards team, and I make a
point of not working with vendor trees at all. The only reason I
submitted some patches to the upcoming release of the ERP is so that
we have an installer that works out of the box, but all the patches I
did contribute were already queued for v4.15 at that point.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

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

[Ard Biesheuvel]

On 6 November 2017 at 06:58, Andreas Färber  wrote:
> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
[...]
>>
>> Again, I am not the one who is ranting here. You hit a nerve by
>> accusing me of 'rebelling against linux.git' while this is quite the
>> opposite of what I am doing.
>
> Actually you did confirm that point by starting an argument about not
> needing a central repository and you not liking Linux as the location.
> That was exactly what I meant with my original comment.
>
> Adding Actions Semi was somewhat easy as a new vendor and now - roughly
> a year after the board went to market - there's Linaro contributions
> from Mani that I'm thankful for.
>
> Whereas patches keep falling into a dark hole when there's already other
> work for a certain vendor, such as Marvell and now Socionext, with no
> one feeling responsible for either taking them or saying, "hey, we're
> not going to submit any conflicting DT bindings for SynQuacer because we
> use ACPI, so please go ahead with proposal X, thanks for your efforts".
>
> Don't complain about me ranting if you belittle my volunteer work that I
> believe Linaro and its partners should've done in the first place: If I
> can get an initial mainline PoC done as an individual on a few
> evenings/weekends, then the same should be super-easy for an
> organization with lots of engineers and paying member companies.

The only person doing the ranting, rebelling and belittling in this
thread is you. I have never commented on the nature of your work, let
alone belittle it.

I understand you are frustrated with how some of the upstreaming of
96boards is handled. I don't have anything to do with that. The only
96boards i have in my drawer (and never use) is an original HiKey.

I work for the enterprise group, not the 96boards team, and I make a
point of not working with vendor trees at all. The only reason I
submitted some patches to the upcoming release of the ERP is so that
we have an installer that works out of the box, but all the patches I
did contribute were already queued for v4.15 at that point.

> As I've pointed out, an ever-increasing frustration builds over Linaro
> continuing to announce new boards (such as SynQuacer) that will be the
> best since sliced bread, while neglecting the 96boards that are already
> on the market and equally are promoted under the "96Boards" brand.
> The Linaro CEO has been promoting the Orange Pi i96 in keynotes, so
> management is aware of that hardware, and yet not a single patch came
> from Xunlong, RDA Micro or Linaro. No patch review from RDA either. And
> my patches got stuck on the bindings not including interrupts property
> for the UART yet, since I still do not have their custom interrupt
> controller working... So the context here is that not just my 4.14+
> pulls got stuck but three other 96Boards patch series, too.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

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

[Yang Zhang]

> On 6 Nov 2017, at 06:58, Andreas Färber  wrote:
> 
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 20:06, Andreas Färber  wrote:
 Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>> 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 

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

[Yang Zhang]

> On 6 Nov 2017, at 06:58, Andreas Färber  wrote:
> 
>> Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 20:06, Andreas Färber  wrote:
 Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>> 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.
>>> 

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

[Andreas Färber]

Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 20:06, Andreas Färber  wrote:
>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 15:30, Andreas Färber  wrote:
 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 

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

[Andreas Färber]

Am 05.11.2017 um 04:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 20:06, Andreas Färber  wrote:
>> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>>> On 4 November 2017 at 15:30, Andreas Färber  wrote:
 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 

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

[Ard Biesheuvel]

On 4 November 2017 at 20:06, Andreas Färber  wrote:
> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>>> 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
> 

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

[Ard Biesheuvel]

On 4 November 2017 at 20:06, Andreas Färber  wrote:
> Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
>> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>>> 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?
>>>
>>> 

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

[Andreas Färber]

Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>> 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, 

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

[Andreas Färber]

Am 04.11.2017 um 23:39 schrieb Ard Biesheuvel:
> On 4 November 2017 at 15:30, Andreas Färber  wrote:
>> 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 

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

[Ard Biesheuvel]

On 4 November 2017 at 15:30, Andreas Färber  wrote:
> 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 

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

[Ard Biesheuvel]

On 4 November 2017 at 15:30, Andreas Färber  wrote:
> 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.
>

OK, so where did we deviate from this in your opinion?

> U-Boot only allows import of new .dts 

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

[Andreas Färber]

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 

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

[Andreas Färber]

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.

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  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?


> 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 

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  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?


> 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 

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

[Andreas Färber]

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.

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)

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

[Andreas Färber]

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.

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)

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

[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.


> 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.  :-)



-- 
Best Regards
Masahiro Yamada

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

[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.


> 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.  :-)



-- 
Best Regards
Masahiro Yamada

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

[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.

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
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.

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.)

Best regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

[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.

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
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.

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.)

Best regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

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

[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/.





-- 
Best Regards
Masahiro Yamada

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

[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/.





-- 
Best Regards
Masahiro Yamada

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

[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 

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

[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