SHMobile Compatibility String Inconsistencies

SHMobile Compatibility String Inconsistencies

[Simon Horman]

Hi Laurent, Hi Guennadi, Hi All,

Olof has brought to my attention that there is some inconsistency
in the way that compatibility strings for SHMobile are named and he
has asked us to clean things up for v3.12.

Looking through arch/arm/boot/dts/ I see that we have:

1. {gpio,pfc}-r8aXXXX and;
2. r8aXXXX-sdhi

The inconsistency that Olof has asked us to resolve is that we
should either use r8aXXXX- or -r8aXXXX. Not both.

It seems to me that neither option is inherently better than the other
so we should just choose the path of least resistance to make things
consistent.

Laurent, Guennadi, do you have any opinions on if it would
be easier to change the GPIO and PFC compatibility strings;
or to change the SDHI compatibility strings?

Ideally I would like you to come to some sort of consensus and send
patches.

Thanks

SHMobile Compatibility String Inconsistencies

[Simon Horman]

Hi Laurent, Hi Guennadi, Hi All,

Olof has brought to my attention that there is some inconsistency
in the way that compatibility strings for SHMobile are named and he
has asked us to clean things up for v3.12.

Looking through arch/arm/boot/dts/ I see that we have:

1. {gpio,pfc}-r8aXXXX and;
2. r8aXXXX-sdhi

The inconsistency that Olof has asked us to resolve is that we
should either use r8aXXXX- or -r8aXXXX. Not both.

It seems to me that neither option is inherently better than the other
so we should just choose the path of least resistance to make things
consistent.

Laurent, Guennadi, do you have any opinions on if it would
be easier to change the GPIO and PFC compatibility strings;
or to change the SDHI compatibility strings?

Ideally I would like you to come to some sort of consensus and send
patches.

Thanks

Re: SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi Simon,

On Thursday 22 August 2013 14:46:40 Simon Horman wrote:
> Hi Laurent, Hi Guennadi, Hi All,
> 
> Olof has brought to my attention that there is some inconsistency in the way
> that compatibility strings for SHMobile are named and he has asked us to
> clean things up for v3.12.
> 
> Looking through arch/arm/boot/dts/ I see that we have:
> 
> 1. {gpio,pfc}-r8aXXXX and;
> 2. r8aXXXX-sdhi
> 
> The inconsistency that Olof has asked us to resolve is that we should either
> use r8aXXXX- or -r8aXXXX. Not both.
> 
> It seems to me that neither option is inherently better than the other
> so we should just choose the path of least resistance to make things
> consistent.
> 
> Laurent, Guennadi, do you have any opinions on if it would be easier to
> change the GPIO and PFC compatibility strings; or to change the SDHI
> compatibility strings?

I don't think either of the options would be significantly more complex than 
the other one.

> Ideally I would like you to come to some sort of consensus and send patches.

Shouldn't the consensus be ARM-wide instead of SH-wide ? Quoting one of my 
replies to Stephen Warren from another mail thread:

> In the bindings I've seen, it's more typical for the compatible value to
> be ${vendor},${soc}-${unit} than ${vendor},${unit}-${soc}. I guess I
> don't know how common one format or the other is though.

I'm personally fine with both. However, when using a version number, the 
format is ${vendor},${unit}-${version}. As we don't have an IP core version 
number we use the SoC name instead, so ${vendor},${unit}-${soc} would make 
sense. We should probably decide on one of the two alternatives and document 
it. 

-- 
Regards,

Laurent Pinchart

SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi Simon,

On Thursday 22 August 2013 14:46:40 Simon Horman wrote:
> Hi Laurent, Hi Guennadi, Hi All,
> 
> Olof has brought to my attention that there is some inconsistency in the way
> that compatibility strings for SHMobile are named and he has asked us to
> clean things up for v3.12.
> 
> Looking through arch/arm/boot/dts/ I see that we have:
> 
> 1. {gpio,pfc}-r8aXXXX and;
> 2. r8aXXXX-sdhi
> 
> The inconsistency that Olof has asked us to resolve is that we should either
> use r8aXXXX- or -r8aXXXX. Not both.
> 
> It seems to me that neither option is inherently better than the other
> so we should just choose the path of least resistance to make things
> consistent.
> 
> Laurent, Guennadi, do you have any opinions on if it would be easier to
> change the GPIO and PFC compatibility strings; or to change the SDHI
> compatibility strings?

I don't think either of the options would be significantly more complex than 
the other one.

> Ideally I would like you to come to some sort of consensus and send patches.

Shouldn't the consensus be ARM-wide instead of SH-wide ? Quoting one of my 
replies to Stephen Warren from another mail thread:

> In the bindings I've seen, it's more typical for the compatible value to
> be ${vendor},${soc}-${unit} than ${vendor},${unit}-${soc}. I guess I
> don't know how common one format or the other is though.

I'm personally fine with both. However, when using a version number, the 
format is ${vendor},${unit}-${version}. As we don't have an IP core version 
number we use the SoC name instead, so ${vendor},${unit}-${soc} would make 
sense. We should probably decide on one of the two alternatives and document 
it. 

-- 
Regards,

Laurent Pinchart

Re: SHMobile Compatibility String Inconsistencies

[Simon Horman]

On Thu, Aug 22, 2013 at 12:43:14PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Thursday 22 August 2013 14:46:40 Simon Horman wrote:
> > Hi Laurent, Hi Guennadi, Hi All,
> > 
> > Olof has brought to my attention that there is some inconsistency in the way
> > that compatibility strings for SHMobile are named and he has asked us to
> > clean things up for v3.12.
> > 
> > Looking through arch/arm/boot/dts/ I see that we have:
> > 
> > 1. {gpio,pfc}-r8aXXXX and;
> > 2. r8aXXXX-sdhi
> > 
> > The inconsistency that Olof has asked us to resolve is that we should either
> > use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > It seems to me that neither option is inherently better than the other
> > so we should just choose the path of least resistance to make things
> > consistent.
> > 
> > Laurent, Guennadi, do you have any opinions on if it would be easier to
> > change the GPIO and PFC compatibility strings; or to change the SDHI
> > compatibility strings?
> 
> I don't think either of the options would be significantly more complex than 
> the other one.
> 
> > Ideally I would like you to come to some sort of consensus and send patches.
> 
> Shouldn't the consensus be ARM-wide instead of SH-wide ? Quoting one of my 
> replies to Stephen Warren from another mail thread:

My understanding from Olof is that it is fine to just make
an SH-mobile-wide decision.

> > In the bindings I've seen, it's more typical for the compatible value to
> > be ${vendor},${soc}-${unit} than ${vendor},${unit}-${soc}. I guess I
> > don't know how common one format or the other is though.
> 
> I'm personally fine with both. However, when using a version number, the 
> format is ${vendor},${unit}-${version}. As we don't have an IP core version 
> number we use the SoC name instead, so ${vendor},${unit}-${soc} would make 
> sense. We should probably decide on one of the two alternatives and document 
> it. 

Ok, so on the one hand ${vendor},${soc}-${unit} is more common.
But on the other hand because we use ${soc} in place of ${version} it
seems there are cases where it would make sense for use to use
${vendor},${unit}-${soc}.

I believe that the second hand trumps the first and we should go with
${vendor},${unit}-${soc} on SH-mobile as that should over all our
use-cases.

Does that sound reasonable to you?

SHMobile Compatibility String Inconsistencies

[Simon Horman]

On Thu, Aug 22, 2013 at 12:43:14PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> On Thursday 22 August 2013 14:46:40 Simon Horman wrote:
> > Hi Laurent, Hi Guennadi, Hi All,
> > 
> > Olof has brought to my attention that there is some inconsistency in the way
> > that compatibility strings for SHMobile are named and he has asked us to
> > clean things up for v3.12.
> > 
> > Looking through arch/arm/boot/dts/ I see that we have:
> > 
> > 1. {gpio,pfc}-r8aXXXX and;
> > 2. r8aXXXX-sdhi
> > 
> > The inconsistency that Olof has asked us to resolve is that we should either
> > use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > It seems to me that neither option is inherently better than the other
> > so we should just choose the path of least resistance to make things
> > consistent.
> > 
> > Laurent, Guennadi, do you have any opinions on if it would be easier to
> > change the GPIO and PFC compatibility strings; or to change the SDHI
> > compatibility strings?
> 
> I don't think either of the options would be significantly more complex than 
> the other one.
> 
> > Ideally I would like you to come to some sort of consensus and send patches.
> 
> Shouldn't the consensus be ARM-wide instead of SH-wide ? Quoting one of my 
> replies to Stephen Warren from another mail thread:

My understanding from Olof is that it is fine to just make
an SH-mobile-wide decision.

> > In the bindings I've seen, it's more typical for the compatible value to
> > be ${vendor},${soc}-${unit} than ${vendor},${unit}-${soc}. I guess I
> > don't know how common one format or the other is though.
> 
> I'm personally fine with both. However, when using a version number, the 
> format is ${vendor},${unit}-${version}. As we don't have an IP core version 
> number we use the SoC name instead, so ${vendor},${unit}-${soc} would make 
> sense. We should probably decide on one of the two alternatives and document 
> it. 

Ok, so on the one hand ${vendor},${soc}-${unit} is more common.
But on the other hand because we use ${soc} in place of ${version} it
seems there are cases where it would make sense for use to use
${vendor},${unit}-${soc}.

I believe that the second hand trumps the first and we should go with
${vendor},${unit}-${soc} on SH-mobile as that should over all our
use-cases.

Does that sound reasonable to you?

Re: SHMobile Compatibility String Inconsistencies

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]

On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> Hi Laurent, Hi Guennadi, Hi All,
> 
> Olof has brought to my attention that there is some inconsistency
> in the way that compatibility strings for SHMobile are named and he
> has asked us to clean things up for v3.12.
> 
> Looking through arch/arm/boot/dts/ I see that we have:
> 
> 1. {gpio,pfc}-r8aXXXX and;
> 2. r8aXXXX-sdhi
> 
> The inconsistency that Olof has asked us to resolve is that we
> should either use r8aXXXX- or -r8aXXXX. Not both.
> 
> It seems to me that neither option is inherently better than the other
> so we should just choose the path of least resistance to make things
> consistent.
> 
> Laurent, Guennadi, do you have any opinions on if it would
> be easier to change the GPIO and PFC compatibility strings;
> or to change the SDHI compatibility strings?
> 
> Ideally I would like you to come to some sort of consensus and send
> patches.

So, by all means clean this up in the dts.

BUT, in keeping with the recent discussions on improving the DT
process, the corresponding drivers must continue to recognize both
forms, so that old DTs will still work correctly.

It's probably also worth putting a note about the deprecated form into
the binding description, too.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

SHMobile Compatibility String Inconsistencies

[David Gibson]

On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> Hi Laurent, Hi Guennadi, Hi All,
> 
> Olof has brought to my attention that there is some inconsistency
> in the way that compatibility strings for SHMobile are named and he
> has asked us to clean things up for v3.12.
> 
> Looking through arch/arm/boot/dts/ I see that we have:
> 
> 1. {gpio,pfc}-r8aXXXX and;
> 2. r8aXXXX-sdhi
> 
> The inconsistency that Olof has asked us to resolve is that we
> should either use r8aXXXX- or -r8aXXXX. Not both.
> 
> It seems to me that neither option is inherently better than the other
> so we should just choose the path of least resistance to make things
> consistent.
> 
> Laurent, Guennadi, do you have any opinions on if it would
> be easier to change the GPIO and PFC compatibility strings;
> or to change the SDHI compatibility strings?
> 
> Ideally I would like you to come to some sort of consensus and send
> patches.

So, by all means clean this up in the dts.

BUT, in keeping with the recent discussions on improving the DT
process, the corresponding drivers must continue to recognize both
forms, so that old DTs will still work correctly.

It's probably also worth putting a note about the deprecated form into
the binding description, too.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130823/5301c2a4/attachment.sig>

Re: SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Hi David,

On Friday 23 August 2013 12:11:11 David Gibson wrote:
> On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > Hi Laurent, Hi Guennadi, Hi All,
> > 
> > Olof has brought to my attention that there is some inconsistency
> > in the way that compatibility strings for SHMobile are named and he
> > has asked us to clean things up for v3.12.
> > 
> > Looking through arch/arm/boot/dts/ I see that we have:
> > 
> > 1. {gpio,pfc}-r8aXXXX and;
> > 2. r8aXXXX-sdhi
> > 
> > The inconsistency that Olof has asked us to resolve is that we
> > should either use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > It seems to me that neither option is inherently better than the other
> > so we should just choose the path of least resistance to make things
> > consistent.
> > 
> > Laurent, Guennadi, do you have any opinions on if it would
> > be easier to change the GPIO and PFC compatibility strings;
> > or to change the SDHI compatibility strings?
> > 
> > Ideally I would like you to come to some sort of consensus and send
> > patches.
> 
> So, by all means clean this up in the dts.
> 
> BUT, in keeping with the recent discussions on improving the DT
> process, the corresponding drivers must continue to recognize both
> forms, so that old DTs will still work correctly.

Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
have no DT-based systems in the wild. The old compatibility string could in my 
opinion just be dropped.

> It's probably also worth putting a note about the deprecated form into
> the binding description, too.

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi David,

On Friday 23 August 2013 12:11:11 David Gibson wrote:
> On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > Hi Laurent, Hi Guennadi, Hi All,
> > 
> > Olof has brought to my attention that there is some inconsistency
> > in the way that compatibility strings for SHMobile are named and he
> > has asked us to clean things up for v3.12.
> > 
> > Looking through arch/arm/boot/dts/ I see that we have:
> > 
> > 1. {gpio,pfc}-r8aXXXX and;
> > 2. r8aXXXX-sdhi
> > 
> > The inconsistency that Olof has asked us to resolve is that we
> > should either use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > It seems to me that neither option is inherently better than the other
> > so we should just choose the path of least resistance to make things
> > consistent.
> > 
> > Laurent, Guennadi, do you have any opinions on if it would
> > be easier to change the GPIO and PFC compatibility strings;
> > or to change the SDHI compatibility strings?
> > 
> > Ideally I would like you to come to some sort of consensus and send
> > patches.
> 
> So, by all means clean this up in the dts.
> 
> BUT, in keeping with the recent discussions on improving the DT
> process, the corresponding drivers must continue to recognize both
> forms, so that old DTs will still work correctly.

Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
have no DT-based systems in the wild. The old compatibility string could in my 
opinion just be dropped.

> It's probably also worth putting a note about the deprecated form into
> the binding description, too.

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130823/bc3664f1/attachment.sig>

Re: SHMobile Compatibility String Inconsistencies

[Simon Horman]

On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> Hi David,
> 
> On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > Hi Laurent, Hi Guennadi, Hi All,
> > > 
> > > Olof has brought to my attention that there is some inconsistency
> > > in the way that compatibility strings for SHMobile are named and he
> > > has asked us to clean things up for v3.12.
> > > 
> > > Looking through arch/arm/boot/dts/ I see that we have:
> > > 
> > > 1. {gpio,pfc}-r8aXXXX and;
> > > 2. r8aXXXX-sdhi
> > > 
> > > The inconsistency that Olof has asked us to resolve is that we
> > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > > 
> > > It seems to me that neither option is inherently better than the other
> > > so we should just choose the path of least resistance to make things
> > > consistent.
> > > 
> > > Laurent, Guennadi, do you have any opinions on if it would
> > > be easier to change the GPIO and PFC compatibility strings;
> > > or to change the SDHI compatibility strings?
> > > 
> > > Ideally I would like you to come to some sort of consensus and send
> > > patches.
> > 
> > So, by all means clean this up in the dts.
> > 
> > BUT, in keeping with the recent discussions on improving the DT
> > process, the corresponding drivers must continue to recognize both
> > forms, so that old DTs will still work correctly.
> 
> Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> have no DT-based systems in the wild. The old compatibility string could in my 
> opinion just be dropped.

I tend to agree, though I don't mind either way.

> > It's probably also worth putting a note about the deprecated form into
> > the binding description, too.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

SHMobile Compatibility String Inconsistencies

[Simon Horman]

On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> Hi David,
> 
> On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > Hi Laurent, Hi Guennadi, Hi All,
> > > 
> > > Olof has brought to my attention that there is some inconsistency
> > > in the way that compatibility strings for SHMobile are named and he
> > > has asked us to clean things up for v3.12.
> > > 
> > > Looking through arch/arm/boot/dts/ I see that we have:
> > > 
> > > 1. {gpio,pfc}-r8aXXXX and;
> > > 2. r8aXXXX-sdhi
> > > 
> > > The inconsistency that Olof has asked us to resolve is that we
> > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > > 
> > > It seems to me that neither option is inherently better than the other
> > > so we should just choose the path of least resistance to make things
> > > consistent.
> > > 
> > > Laurent, Guennadi, do you have any opinions on if it would
> > > be easier to change the GPIO and PFC compatibility strings;
> > > or to change the SDHI compatibility strings?
> > > 
> > > Ideally I would like you to come to some sort of consensus and send
> > > patches.
> > 
> > So, by all means clean this up in the dts.
> > 
> > BUT, in keeping with the recent discussions on improving the DT
> > process, the corresponding drivers must continue to recognize both
> > forms, so that old DTs will still work correctly.
> 
> Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> have no DT-based systems in the wild. The old compatibility string could in my 
> opinion just be dropped.

I tend to agree, though I don't mind either way.

> > It's probably also worth putting a note about the deprecated form into
> > the binding description, too.
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Re: SHMobile Compatibility String Inconsistencies

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> Hi David,
> 
> On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > Hi Laurent, Hi Guennadi, Hi All,
> > > 
> > > Olof has brought to my attention that there is some inconsistency
> > > in the way that compatibility strings for SHMobile are named and he
> > > has asked us to clean things up for v3.12.
> > > 
> > > Looking through arch/arm/boot/dts/ I see that we have:
> > > 
> > > 1. {gpio,pfc}-r8aXXXX and;
> > > 2. r8aXXXX-sdhi
> > > 
> > > The inconsistency that Olof has asked us to resolve is that we
> > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > > 
> > > It seems to me that neither option is inherently better than the other
> > > so we should just choose the path of least resistance to make things
> > > consistent.
> > > 
> > > Laurent, Guennadi, do you have any opinions on if it would
> > > be easier to change the GPIO and PFC compatibility strings;
> > > or to change the SDHI compatibility strings?
> > > 
> > > Ideally I would like you to come to some sort of consensus and send
> > > patches.
> > 
> > So, by all means clean this up in the dts.
> > 
> > BUT, in keeping with the recent discussions on improving the DT
> > process, the corresponding drivers must continue to recognize both
> > forms, so that old DTs will still work correctly.
> 
> Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> have no DT-based systems in the wild. The old compatibility string could in my 
> opinion just be dropped.

Hm, well, ok.  Just remember to always err on the side of broad
compatiblity.  We've become sloppy with incompatible DT updates and
its caused us a bunch of grief.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: SHMobile Compatibility String Inconsistencies

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> Hi David,
> 
> On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > Hi Laurent, Hi Guennadi, Hi All,
> > > 
> > > Olof has brought to my attention that there is some inconsistency
> > > in the way that compatibility strings for SHMobile are named and he
> > > has asked us to clean things up for v3.12.
> > > 
> > > Looking through arch/arm/boot/dts/ I see that we have:
> > > 
> > > 1. {gpio,pfc}-r8aXXXX and;
> > > 2. r8aXXXX-sdhi
> > > 
> > > The inconsistency that Olof has asked us to resolve is that we
> > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > > 
> > > It seems to me that neither option is inherently better than the other
> > > so we should just choose the path of least resistance to make things
> > > consistent.
> > > 
> > > Laurent, Guennadi, do you have any opinions on if it would
> > > be easier to change the GPIO and PFC compatibility strings;
> > > or to change the SDHI compatibility strings?
> > > 
> > > Ideally I would like you to come to some sort of consensus and send
> > > patches.
> > 
> > So, by all means clean this up in the dts.
> > 
> > BUT, in keeping with the recent discussions on improving the DT
> > process, the corresponding drivers must continue to recognize both
> > forms, so that old DTs will still work correctly.
> 
> Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> have no DT-based systems in the wild. The old compatibility string could in my 
> opinion just be dropped.

Hm, well, ok.  Just remember to always err on the side of broad
compatiblity.  We've become sloppy with incompatible DT updates and
its caused us a bunch of grief.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

SHMobile Compatibility String Inconsistencies

[David Gibson]

On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> Hi David,
> 
> On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > Hi Laurent, Hi Guennadi, Hi All,
> > > 
> > > Olof has brought to my attention that there is some inconsistency
> > > in the way that compatibility strings for SHMobile are named and he
> > > has asked us to clean things up for v3.12.
> > > 
> > > Looking through arch/arm/boot/dts/ I see that we have:
> > > 
> > > 1. {gpio,pfc}-r8aXXXX and;
> > > 2. r8aXXXX-sdhi
> > > 
> > > The inconsistency that Olof has asked us to resolve is that we
> > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > > 
> > > It seems to me that neither option is inherently better than the other
> > > so we should just choose the path of least resistance to make things
> > > consistent.
> > > 
> > > Laurent, Guennadi, do you have any opinions on if it would
> > > be easier to change the GPIO and PFC compatibility strings;
> > > or to change the SDHI compatibility strings?
> > > 
> > > Ideally I would like you to come to some sort of consensus and send
> > > patches.
> > 
> > So, by all means clean this up in the dts.
> > 
> > BUT, in keeping with the recent discussions on improving the DT
> > process, the corresponding drivers must continue to recognize both
> > forms, so that old DTs will still work correctly.
> 
> Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> have no DT-based systems in the wild. The old compatibility string could in my 
> opinion just be dropped.

Hm, well, ok.  Just remember to always err on the side of broad
compatiblity.  We've become sloppy with incompatible DT updates and
its caused us a bunch of grief.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130826/19bc76a8/attachment.sig>

Re: SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

On Sat, 24 Aug 2013, Simon Horman wrote:

> On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > Hi David,
> > 
> > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > 
> > > > Olof has brought to my attention that there is some inconsistency
> > > > in the way that compatibility strings for SHMobile are named and he
> > > > has asked us to clean things up for v3.12.
> > > > 
> > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > 
> > > > 1. {gpio,pfc}-r8aXXXX and;

Add shdma-<soc> to the above

> > > > 2. r8aXXXX-sdhi
> > > > 
> > > > The inconsistency that Olof has asked us to resolve is that we
> > > > should either use r8aXXXX- or -r8aXXXX. Not both.

Given the 3:1 score the choice seems rather simple to me. So, if we do
have to make those consistent, let's change SDHI.

> > > > It seems to me that neither option is inherently better than the other
> > > > so we should just choose the path of least resistance to make things
> > > > consistent.
> > > > 
> > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > be easier to change the GPIO and PFC compatibility strings;
> > > > or to change the SDHI compatibility strings?
> > > > 
> > > > Ideally I would like you to come to some sort of consensus and send
> > > > patches.
> > > 
> > > So, by all means clean this up in the dts.
> > > 
> > > BUT, in keeping with the recent discussions on improving the DT
> > > process, the corresponding drivers must continue to recognize both
> > > forms, so that old DTs will still work correctly.
> > 
> > Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> > have no DT-based systems in the wild. The old compatibility string could in my 
> > opinion just be dropped.
> 
> I tend to agree, though I don't mind either way.

So, what path should we choose? I see 2 SDHI users in your current "devel" 
brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single 
patch, changing the driver and both users and push it via ARM with Chris' 
ack or shall we add new compats, switch .dtsi's, remove old compats - over 
2 kernel versions? Can we still get anything for this into 3.12 or is it 
too late? Would it be a "fix" enough for -rc2 / late -rc1?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

On Sat, 24 Aug 2013, Simon Horman wrote:

> On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > Hi David,
> > 
> > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > 
> > > > Olof has brought to my attention that there is some inconsistency
> > > > in the way that compatibility strings for SHMobile are named and he
> > > > has asked us to clean things up for v3.12.
> > > > 
> > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > 
> > > > 1. {gpio,pfc}-r8aXXXX and;

Add shdma-<soc> to the above

> > > > 2. r8aXXXX-sdhi
> > > > 
> > > > The inconsistency that Olof has asked us to resolve is that we
> > > > should either use r8aXXXX- or -r8aXXXX. Not both.

Given the 3:1 score the choice seems rather simple to me. So, if we do
have to make those consistent, let's change SDHI.

> > > > It seems to me that neither option is inherently better than the other
> > > > so we should just choose the path of least resistance to make things
> > > > consistent.
> > > > 
> > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > be easier to change the GPIO and PFC compatibility strings;
> > > > or to change the SDHI compatibility strings?
> > > > 
> > > > Ideally I would like you to come to some sort of consensus and send
> > > > patches.
> > > 
> > > So, by all means clean this up in the dts.
> > > 
> > > BUT, in keeping with the recent discussions on improving the DT
> > > process, the corresponding drivers must continue to recognize both
> > > forms, so that old DTs will still work correctly.
> > 
> > Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> > have no DT-based systems in the wild. The old compatibility string could in my 
> > opinion just be dropped.
> 
> I tend to agree, though I don't mind either way.

So, what path should we choose? I see 2 SDHI users in your current "devel" 
brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single 
patch, changing the driver and both users and push it via ARM with Chris' 
ack or shall we add new compats, switch .dtsi's, remove old compats - over 
2 kernel versions? Can we still get anything for this into 3.12 or is it 
too late? Would it be a "fix" enough for -rc2 / late -rc1?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

On Sat, 24 Aug 2013, Simon Horman wrote:

> On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > Hi David,
> > 
> > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > 
> > > > Olof has brought to my attention that there is some inconsistency
> > > > in the way that compatibility strings for SHMobile are named and he
> > > > has asked us to clean things up for v3.12.
> > > > 
> > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > 
> > > > 1. {gpio,pfc}-r8aXXXX and;

Add shdma-<soc> to the above

> > > > 2. r8aXXXX-sdhi
> > > > 
> > > > The inconsistency that Olof has asked us to resolve is that we
> > > > should either use r8aXXXX- or -r8aXXXX. Not both.

Given the 3:1 score the choice seems rather simple to me. So, if we do
have to make those consistent, let's change SDHI.

> > > > It seems to me that neither option is inherently better than the other
> > > > so we should just choose the path of least resistance to make things
> > > > consistent.
> > > > 
> > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > be easier to change the GPIO and PFC compatibility strings;
> > > > or to change the SDHI compatibility strings?
> > > > 
> > > > Ideally I would like you to come to some sort of consensus and send
> > > > patches.
> > > 
> > > So, by all means clean this up in the dts.
> > > 
> > > BUT, in keeping with the recent discussions on improving the DT
> > > process, the corresponding drivers must continue to recognize both
> > > forms, so that old DTs will still work correctly.
> > 
> > Given the early state of DT support in arm/mach-shmobile, I'm pretty sure we 
> > have no DT-based systems in the wild. The old compatibility string could in my 
> > opinion just be dropped.
> 
> I tend to agree, though I don't mind either way.

So, what path should we choose? I see 2 SDHI users in your current "devel" 
brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single 
patch, changing the driver and both users and push it via ARM with Chris' 
ack or shall we add new compats, switch .dtsi's, remove old compats - over 
2 kernel versions? Can we still get anything for this into 3.12 or is it 
too late? Would it be a "fix" enough for -rc2 / late -rc1?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi Guennadi,

On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> On Sat, 24 Aug 2013, Simon Horman wrote:
> > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > 
> > > > > Olof has brought to my attention that there is some inconsistency
> > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > has asked us to clean things up for v3.12.
> > > > > 
> > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > 
> > > > > 1. {gpio,pfc}-r8aXXXX and;
> 
> Add shdma-<soc> to the above
> 
> > > > > 2. r8aXXXX-sdhi
> > > > > 
> > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> 
> Given the 3:1 score the choice seems rather simple to me. So, if we do
> have to make those consistent, let's change SDHI.

Agreed.

> > > > > It seems to me that neither option is inherently better than the
> > > > > other so we should just choose the path of least resistance to make
> > > > > things consistent.
> > > > > 
> > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > or to change the SDHI compatibility strings?
> > > > > 
> > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > patches.
> > > > 
> > > > So, by all means clean this up in the dts.
> > > > 
> > > > BUT, in keeping with the recent discussions on improving the DT
> > > > process, the corresponding drivers must continue to recognize both
> > > > forms, so that old DTs will still work correctly.
> > > 
> > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > sure we have no DT-based systems in the wild. The old compatibility
> > > string could in my opinion just be dropped.
> > 
> > I tend to agree, though I don't mind either way.
> 
> So, what path should we choose? I see 2 SDHI users in your current "devel"
> brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> patch, changing the driver and both users and push it via ARM with Chris'
> ack or shall we add new compats, switch .dtsi's, remove old compats - over
> 2 kernel versions?

I'm fine with both, but in the latter case I don't see a need to spread it 
over two kernel versions.

> Can we still get anything for this into 3.12 or is it too late? Would it be
> a "fix" enough for -rc2 / late -rc1?

-- 
Regards,

Laurent Pinchart

Re: SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi Guennadi,

On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> On Sat, 24 Aug 2013, Simon Horman wrote:
> > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > 
> > > > > Olof has brought to my attention that there is some inconsistency
> > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > has asked us to clean things up for v3.12.
> > > > > 
> > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > 
> > > > > 1. {gpio,pfc}-r8aXXXX and;
> 
> Add shdma-<soc> to the above
> 
> > > > > 2. r8aXXXX-sdhi
> > > > > 
> > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> 
> Given the 3:1 score the choice seems rather simple to me. So, if we do
> have to make those consistent, let's change SDHI.

Agreed.

> > > > > It seems to me that neither option is inherently better than the
> > > > > other so we should just choose the path of least resistance to make
> > > > > things consistent.
> > > > > 
> > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > or to change the SDHI compatibility strings?
> > > > > 
> > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > patches.
> > > > 
> > > > So, by all means clean this up in the dts.
> > > > 
> > > > BUT, in keeping with the recent discussions on improving the DT
> > > > process, the corresponding drivers must continue to recognize both
> > > > forms, so that old DTs will still work correctly.
> > > 
> > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > sure we have no DT-based systems in the wild. The old compatibility
> > > string could in my opinion just be dropped.
> > 
> > I tend to agree, though I don't mind either way.
> 
> So, what path should we choose? I see 2 SDHI users in your current "devel"
> brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> patch, changing the driver and both users and push it via ARM with Chris'
> ack or shall we add new compats, switch .dtsi's, remove old compats - over
> 2 kernel versions?

I'm fine with both, but in the latter case I don't see a need to spread it 
over two kernel versions.

> Can we still get anything for this into 3.12 or is it too late? Would it be
> a "fix" enough for -rc2 / late -rc1?

-- 
Regards,

Laurent Pinchart

SHMobile Compatibility String Inconsistencies

[Laurent Pinchart]

Hi Guennadi,

On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> On Sat, 24 Aug 2013, Simon Horman wrote:
> > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > 
> > > > > Olof has brought to my attention that there is some inconsistency
> > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > has asked us to clean things up for v3.12.
> > > > > 
> > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > 
> > > > > 1. {gpio,pfc}-r8aXXXX and;
> 
> Add shdma-<soc> to the above
> 
> > > > > 2. r8aXXXX-sdhi
> > > > > 
> > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> 
> Given the 3:1 score the choice seems rather simple to me. So, if we do
> have to make those consistent, let's change SDHI.

Agreed.

> > > > > It seems to me that neither option is inherently better than the
> > > > > other so we should just choose the path of least resistance to make
> > > > > things consistent.
> > > > > 
> > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > or to change the SDHI compatibility strings?
> > > > > 
> > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > patches.
> > > > 
> > > > So, by all means clean this up in the dts.
> > > > 
> > > > BUT, in keeping with the recent discussions on improving the DT
> > > > process, the corresponding drivers must continue to recognize both
> > > > forms, so that old DTs will still work correctly.
> > > 
> > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > sure we have no DT-based systems in the wild. The old compatibility
> > > string could in my opinion just be dropped.
> > 
> > I tend to agree, though I don't mind either way.
> 
> So, what path should we choose? I see 2 SDHI users in your current "devel"
> brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> patch, changing the driver and both users and push it via ARM with Chris'
> ack or shall we add new compats, switch .dtsi's, remove old compats - over
> 2 kernel versions?

I'm fine with both, but in the latter case I don't see a need to spread it 
over two kernel versions.

> Can we still get anything for this into 3.12 or is it too late? Would it be
> a "fix" enough for -rc2 / late -rc1?

-- 
Regards,

Laurent Pinchart

Re: SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

Hi Laurent,

On Tue, 27 Aug 2013, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> > On Sat, 24 Aug 2013, Simon Horman wrote:
> > > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > > 
> > > > > > Olof has brought to my attention that there is some inconsistency
> > > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > > has asked us to clean things up for v3.12.
> > > > > > 
> > > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > > 
> > > > > > 1. {gpio,pfc}-r8aXXXX and;
> > 
> > Add shdma-<soc> to the above
> > 
> > > > > > 2. r8aXXXX-sdhi
> > > > > > 
> > > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > Given the 3:1 score the choice seems rather simple to me. So, if we do
> > have to make those consistent, let's change SDHI.
> 
> Agreed.
> 
> > > > > > It seems to me that neither option is inherently better than the
> > > > > > other so we should just choose the path of least resistance to make
> > > > > > things consistent.
> > > > > > 
> > > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > > or to change the SDHI compatibility strings?
> > > > > > 
> > > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > > patches.
> > > > > 
> > > > > So, by all means clean this up in the dts.
> > > > > 
> > > > > BUT, in keeping with the recent discussions on improving the DT
> > > > > process, the corresponding drivers must continue to recognize both
> > > > > forms, so that old DTs will still work correctly.
> > > > 
> > > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > > sure we have no DT-based systems in the wild. The old compatibility
> > > > string could in my opinion just be dropped.
> > > 
> > > I tend to agree, though I don't mind either way.
> > 
> > So, what path should we choose? I see 2 SDHI users in your current "devel"
> > brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> > patch, changing the driver and both users and push it via ARM with Chris'
> > ack or shall we add new compats, switch .dtsi's, remove old compats - over
> > 2 kernel versions?
> 
> I'm fine with both, but in the latter case I don't see a need to spread it 
> over two kernel versions.

The latter only makes sense if we want to push patches via separate trees, 
i.e.
DMA
ARM
DMA
and doing this within 1 kernel release would be difficult. Whereas if we 
want to push all 3 patches via 1 tree, then I'd say just doing 1 patch 
would be easier.

Thanks
Guennadi

> > Can we still get anything for this into 3.12 or is it too late? Would it be
> > a "fix" enough for -rc2 / late -rc1?
> 
> -- 
> Regards,
> 
> Laurent Pinchart

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

Hi Laurent,

On Tue, 27 Aug 2013, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> > On Sat, 24 Aug 2013, Simon Horman wrote:
> > > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > > 
> > > > > > Olof has brought to my attention that there is some inconsistency
> > > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > > has asked us to clean things up for v3.12.
> > > > > > 
> > > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > > 
> > > > > > 1. {gpio,pfc}-r8aXXXX and;
> > 
> > Add shdma-<soc> to the above
> > 
> > > > > > 2. r8aXXXX-sdhi
> > > > > > 
> > > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > Given the 3:1 score the choice seems rather simple to me. So, if we do
> > have to make those consistent, let's change SDHI.
> 
> Agreed.
> 
> > > > > > It seems to me that neither option is inherently better than the
> > > > > > other so we should just choose the path of least resistance to make
> > > > > > things consistent.
> > > > > > 
> > > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > > or to change the SDHI compatibility strings?
> > > > > > 
> > > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > > patches.
> > > > > 
> > > > > So, by all means clean this up in the dts.
> > > > > 
> > > > > BUT, in keeping with the recent discussions on improving the DT
> > > > > process, the corresponding drivers must continue to recognize both
> > > > > forms, so that old DTs will still work correctly.
> > > > 
> > > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > > sure we have no DT-based systems in the wild. The old compatibility
> > > > string could in my opinion just be dropped.
> > > 
> > > I tend to agree, though I don't mind either way.
> > 
> > So, what path should we choose? I see 2 SDHI users in your current "devel"
> > brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> > patch, changing the driver and both users and push it via ARM with Chris'
> > ack or shall we add new compats, switch .dtsi's, remove old compats - over
> > 2 kernel versions?
> 
> I'm fine with both, but in the latter case I don't see a need to spread it 
> over two kernel versions.

The latter only makes sense if we want to push patches via separate trees, 
i.e.
DMA
ARM
DMA
and doing this within 1 kernel release would be difficult. Whereas if we 
want to push all 3 patches via 1 tree, then I'd say just doing 1 patch 
would be easier.

Thanks
Guennadi

> > Can we still get anything for this into 3.12 or is it too late? Would it be
> > a "fix" enough for -rc2 / late -rc1?
> 
> -- 
> Regards,
> 
> Laurent Pinchart

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

SHMobile Compatibility String Inconsistencies

[Guennadi Liakhovetski]

Hi Laurent,

On Tue, 27 Aug 2013, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Monday 26 August 2013 18:08:52 Guennadi Liakhovetski wrote:
> > On Sat, 24 Aug 2013, Simon Horman wrote:
> > > On Fri, Aug 23, 2013 at 01:31:31PM +0200, Laurent Pinchart wrote:
> > > > On Friday 23 August 2013 12:11:11 David Gibson wrote:
> > > > > On Thu, Aug 22, 2013 at 02:46:40PM +0900, Simon Horman wrote:
> > > > > > Hi Laurent, Hi Guennadi, Hi All,
> > > > > > 
> > > > > > Olof has brought to my attention that there is some inconsistency
> > > > > > in the way that compatibility strings for SHMobile are named and he
> > > > > > has asked us to clean things up for v3.12.
> > > > > > 
> > > > > > Looking through arch/arm/boot/dts/ I see that we have:
> > > > > > 
> > > > > > 1. {gpio,pfc}-r8aXXXX and;
> > 
> > Add shdma-<soc> to the above
> > 
> > > > > > 2. r8aXXXX-sdhi
> > > > > > 
> > > > > > The inconsistency that Olof has asked us to resolve is that we
> > > > > > should either use r8aXXXX- or -r8aXXXX. Not both.
> > 
> > Given the 3:1 score the choice seems rather simple to me. So, if we do
> > have to make those consistent, let's change SDHI.
> 
> Agreed.
> 
> > > > > > It seems to me that neither option is inherently better than the
> > > > > > other so we should just choose the path of least resistance to make
> > > > > > things consistent.
> > > > > > 
> > > > > > Laurent, Guennadi, do you have any opinions on if it would
> > > > > > be easier to change the GPIO and PFC compatibility strings;
> > > > > > or to change the SDHI compatibility strings?
> > > > > > 
> > > > > > Ideally I would like you to come to some sort of consensus and send
> > > > > > patches.
> > > > > 
> > > > > So, by all means clean this up in the dts.
> > > > > 
> > > > > BUT, in keeping with the recent discussions on improving the DT
> > > > > process, the corresponding drivers must continue to recognize both
> > > > > forms, so that old DTs will still work correctly.
> > > > 
> > > > Given the early state of DT support in arm/mach-shmobile, I'm pretty
> > > > sure we have no DT-based systems in the wild. The old compatibility
> > > > string could in my opinion just be dropped.
> > > 
> > > I tend to agree, though I don't mind either way.
> > 
> > So, what path should we choose? I see 2 SDHI users in your current "devel"
> > brunch: sh73a0 (kzm9g) and r8a73a4 (ape6evm). Should we make a single
> > patch, changing the driver and both users and push it via ARM with Chris'
> > ack or shall we add new compats, switch .dtsi's, remove old compats - over
> > 2 kernel versions?
> 
> I'm fine with both, but in the latter case I don't see a need to spread it 
> over two kernel versions.

The latter only makes sense if we want to push patches via separate trees, 
i.e.
DMA
ARM
DMA
and doing this within 1 kernel release would be difficult. Whereas if we 
want to push all 3 patches via 1 tree, then I'd say just doing 1 patch 
would be easier.

Thanks
Guennadi

> > Can we still get anything for this into 3.12 or is it too late? Would it be
> > a "fix" enough for -rc2 / late -rc1?
> 
> -- 
> Regards,
> 
> Laurent Pinchart

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: SHMobile Compatibility String Inconsistencies

[Olof Johansson]

Hi,

On Thu, Aug 22, 2013 at 5:19 PM, Simon Horman <horms@verge.net.au> wrote:

> My understanding from Olof is that it is fine to just make
> an SH-mobile-wide decision.

Sorry for being vague on this -- you really should try to join in on
the same conventions as the other platforms (if one gets established).

My general opinion is aligned with Stephen Warren's in this case, but
it's up to the devicetree-maintainers to make final calls.


-Olof

Re: SHMobile Compatibility String Inconsistencies

[Olof Johansson]

Hi,

On Thu, Aug 22, 2013 at 5:19 PM, Simon Horman <horms@verge.net.au> wrote:

> My understanding from Olof is that it is fine to just make
> an SH-mobile-wide decision.

Sorry for being vague on this -- you really should try to join in on
the same conventions as the other platforms (if one gets established).

My general opinion is aligned with Stephen Warren's in this case, but
it's up to the devicetree-maintainers to make final calls.


-Olof

SHMobile Compatibility String Inconsistencies

[Olof Johansson]

Hi,

On Thu, Aug 22, 2013 at 5:19 PM, Simon Horman <horms@verge.net.au> wrote:

> My understanding from Olof is that it is fine to just make
> an SH-mobile-wide decision.

Sorry for being vague on this -- you really should try to join in on
the same conventions as the other platforms (if one gets established).

My general opinion is aligned with Stephen Warren's in this case, but
it's up to the devicetree-maintainers to make final calls.


-Olof