All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: SHMobile Compatibility String Inconsistencies
Date: Fri, 23 Aug 2013 00:19:35 +0000	[thread overview]
Message-ID: <20130823001934.GA4331@verge.net.au> (raw)
In-Reply-To: <5813266.Bt0QjqXd25@avalon>

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?

WARNING: multiple messages have this Message-ID (diff)
From: horms@verge.net.au (Simon Horman)
To: linux-arm-kernel@lists.infradead.org
Subject: SHMobile Compatibility String Inconsistencies
Date: Fri, 23 Aug 2013 09:19:35 +0900	[thread overview]
Message-ID: <20130823001934.GA4331@verge.net.au> (raw)
In-Reply-To: <5813266.Bt0QjqXd25@avalon>

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?

  reply	other threads:[~2013-08-23  0:19 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-22  5:46 SHMobile Compatibility String Inconsistencies Simon Horman
2013-08-22  5:46 ` Simon Horman
2013-08-22 10:43 ` Laurent Pinchart
2013-08-22 10:43   ` Laurent Pinchart
2013-08-23  0:19   ` Simon Horman [this message]
2013-08-23  0:19     ` Simon Horman
2013-08-27 17:34     ` Olof Johansson
2013-08-27 17:34       ` Olof Johansson
2013-08-27 17:34       ` Olof Johansson
2013-08-23  2:11 ` David Gibson
2013-08-23  2:11   ` David Gibson
2013-08-23 11:31   ` Laurent Pinchart
2013-08-23 11:31     ` Laurent Pinchart
2013-08-24  2:13     ` Simon Horman
2013-08-24  2:13       ` Simon Horman
2013-08-26 16:08       ` Guennadi Liakhovetski
2013-08-26 16:08         ` Guennadi Liakhovetski
2013-08-26 16:08         ` Guennadi Liakhovetski
2013-08-27  6:30         ` Laurent Pinchart
2013-08-27  6:30           ` Laurent Pinchart
2013-08-27  6:30           ` Laurent Pinchart
2013-08-27  6:46           ` Guennadi Liakhovetski
2013-08-27  6:46             ` Guennadi Liakhovetski
2013-08-27  6:46             ` Guennadi Liakhovetski
2013-08-26  7:16     ` David Gibson
2013-08-26  7:16       ` David Gibson
2013-08-26  7:16       ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130823001934.GA4331@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.