diff mbox

[resend] of: Add vendor 2nd prefix for Asahi Kasei Corp

Message ID 878ulzx6hr.wl%kuninori.morimoto.gx@gmail.com (mailing list archive)
State Awaiting Upstream
Headers show

Commit Message

Kuninori Morimoto Sept. 4, 2014, 6:08 a.m. UTC
From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

Current vendor-prefixes.txt already has
"ak" prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)

But, almost all Asahi Kasei chip driver is
using "asahi-kasei" prefix today.

This patch adds "asahi-kasei" to vendor-prefixes.txt.
checkpatch.pl will report WARNING without this patch.
(DT compatible string vendor "asahi-kasei" appears un-documented)

OTOH, Asahi Kasei is usually referred to as "AKM",
but this patch doesn't care about it.
Because no DT is using it today.

Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
 .../devicetree/bindings/vendor-prefixes.txt        |    1 +
 1 file changed, 1 insertion(+)

Comments

Mark Rutland Sept. 22, 2014, 1 p.m. UTC | #1
On Thu, Sep 04, 2014 at 07:08:37AM +0100, Kuninori Morimoto wrote:
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> 
> Current vendor-prefixes.txt already has
> "ak" prefix for Asahi Kasei Corp by
> ae8c4209af2cec065fef15d200a42a04130799f7
> (of: Add vendor prefix for Asahi Kasei Corp.)
> 
> But, almost all Asahi Kasei chip driver is
> using "asahi-kasei" prefix today.
> 
> This patch adds "asahi-kasei" to vendor-prefixes.txt.
> checkpatch.pl will report WARNING without this patch.
> (DT compatible string vendor "asahi-kasei" appears un-documented)

If we're adding a new string, we should figure out what's happening with
the old one. We want some consistency here.

From a quick grep, it looks like the only use of "ak" is "ak,ak8975" in
arch/arm/boot/dts/tegra20-seaboard.dts. There are instances of
"asahi-kasei,ak8975" in other dts files.

Olof added "asahi-kasei,ak8975" to the ak8975 driver in February 2012
(see 54461c3067b2), and the "asahi-kasei" prefix is currently far more
common. This was only documented in May 2013 (see f4b7f751c6fd).

Stephen added the "ak" vendor-refix was added later in November 2012
(see ae8c4209af2c), and the only instance seems to work due to the i2c
subsystem doing something dehind the scenes with the compatible string.
So I think we made a mistake there.

Given all that, I think we should get rid of the "ak" prefix entirely,
fix up the seaboard dts, and leave the legacy matching for "ak,ak8975"
up to the i2c framework. However, that would imply deleting from
vendor-prefixes.txt (if we want people to be warned on use of "ak"), and
that's not a good precedent to set.

Thoughts?

Mark.

> OTOH, Asahi Kasei is usually referred to as "AKM",
> but this patch doesn't care about it.
> Because no DT is using it today.
> 
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
> ---
>  .../devicetree/bindings/vendor-prefixes.txt        |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index abc3080..7e4bb83 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -17,6 +17,7 @@ amstaos	AMS-Taos Inc.
>  apm	Applied Micro Circuits Corporation (APM)
>  arm	ARM Ltd.
>  armadeus	ARMadeus Systems SARL
> +asahi-kasei	Asahi Kasei Corp.
>  atmel	Atmel Corporation
>  auo	AU Optronics Corporation
>  avago	Avago Technologies
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Geert Uytterhoeven Sept. 22, 2014, 1:24 p.m. UTC | #2
Hi Mark,

On Mon, Sep 22, 2014 at 3:00 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> Given all that, I think we should get rid of the "ak" prefix entirely,
> fix up the seaboard dts, and leave the legacy matching for "ak,ak8975"
> up to the i2c framework. However, that would imply deleting from
> vendor-prefixes.txt (if we want people to be warned on use of "ak"), and
> that's not a good precedent to set.

Instead of deleting, we can deprecate, like was done for powervr:

powervr PowerVR (deprecated, use img)

Still missing is an update for checkpatch to warn when a deprecated
vendor prefix is used.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Rutland Sept. 22, 2014, 1:27 p.m. UTC | #3
On Mon, Sep 22, 2014 at 02:24:24PM +0100, Geert Uytterhoeven wrote:
> Hi Mark,

Hi Geert,

> On Mon, Sep 22, 2014 at 3:00 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > Given all that, I think we should get rid of the "ak" prefix entirely,
> > fix up the seaboard dts, and leave the legacy matching for "ak,ak8975"
> > up to the i2c framework. However, that would imply deleting from
> > vendor-prefixes.txt (if we want people to be warned on use of "ak"), and
> > that's not a good precedent to set.
> 
> Instead of deleting, we can deprecate, like was done for powervr:
> 
> powervr PowerVR (deprecated, use img)

Ah. I tried to see if we had any deprecated bindings, but I somehow
failed to search correctly and missed powervr.

> Still missing is an update for checkpatch to warn when a deprecated
> vendor prefix is used.

Marking it deprecated and warning with checkpatch is certainly
preferable.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kuninori Morimoto Nov. 13, 2014, 2:18 a.m. UTC | #4
Hi Mark, Geert

Sorry for my super late response about this

> > > Given all that, I think we should get rid of the "ak" prefix entirely,
> > > fix up the seaboard dts, and leave the legacy matching for "ak,ak8975"
> > > up to the i2c framework. However, that would imply deleting from
> > > vendor-prefixes.txt (if we want people to be warned on use of "ak"), and
> > > that's not a good precedent to set.
> > 
> > Instead of deleting, we can deprecate, like was done for powervr:
> > 
> > powervr PowerVR (deprecated, use img)
> 
> Ah. I tried to see if we had any deprecated bindings, but I somehow
> failed to search correctly and missed powervr.
> 
> > Still missing is an update for checkpatch to warn when a deprecated
> > vendor prefix is used.
> 
> Marking it deprecated and warning with checkpatch is certainly
> preferable.

I guess removing "ak" line from vendor-prefixes.txt is very enough
for warn for a deprecated vendor prefix on checkpatch ?

  ...
- ak	Asahi Kasei Corp.
  ...
+ asahi-kasei	Asahi Kasei Corp.

Best regards
---
Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Joe Perches Nov. 13, 2014, 2:21 a.m. UTC | #5
On Thu, 2014-11-13 at 02:18 +0000, Kuninori Morimoto wrote:
> > > Still missing is an update for checkpatch to warn when a deprecated
> > > vendor prefix is used.
> > 
> > Marking it deprecated and warning with checkpatch is certainly
> > preferable.
> 
> I guess removing "ak" line from vendor-prefixes.txt is very enough
> for warn for a deprecated vendor prefix on checkpatch ?

Huh?  No idea what you mean.
What are you suggesting about checkpatch?


--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman Nov. 13, 2014, 2:51 a.m. UTC | #6
On Wed, Nov 12, 2014 at 06:21:49PM -0800, Joe Perches wrote:
> On Thu, 2014-11-13 at 02:18 +0000, Kuninori Morimoto wrote:
> > > > Still missing is an update for checkpatch to warn when a deprecated
> > > > vendor prefix is used.
> > > 
> > > Marking it deprecated and warning with checkpatch is certainly
> > > preferable.
> > 
> > I guess removing "ak" line from vendor-prefixes.txt is very enough
> > for warn for a deprecated vendor prefix on checkpatch ?
> 
> Huh?  No idea what you mean.
> What are you suggesting about checkpatch?

Hi Joe,

I think that what Morimoto-san wanted to say was something like this:

  I guess that removing the "ak" line from vendor-prefixes.txt would
  be sufficient to cause checkpatch to generate a warning about
  using the deprecated "ak" vendor prefix. Is that a good approach?
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kuninori Morimoto Nov. 13, 2014, 3:33 a.m. UTC | #7
Hi Joe, Simon

> > > I guess removing "ak" line from vendor-prefixes.txt is very enough
> > > for warn for a deprecated vendor prefix on checkpatch ?
> > 
> > Huh?  No idea what you mean.
> > What are you suggesting about checkpatch?
> 
> Hi Joe,
> 
> I think that what Morimoto-san wanted to say was something like this:
> 
>   I guess that removing the "ak" line from vendor-prefixes.txt would
>   be sufficient to cause checkpatch to generate a warning about
>   using the deprecated "ak" vendor prefix. Is that a good approach?

Yes, this is.
Thank you Simon, Sorry Joe.

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Brown Nov. 13, 2014, 11:07 a.m. UTC | #8
On Thu, Nov 13, 2014 at 03:33:38AM +0000, Kuninori Morimoto wrote:

> > I think that what Morimoto-san wanted to say was something like this:

> >   I guess that removing the "ak" line from vendor-prefixes.txt would
> >   be sufficient to cause checkpatch to generate a warning about
> >   using the deprecated "ak" vendor prefix. Is that a good approach?

> Yes, this is.
> Thank you Simon, Sorry Joe.

It'd be a bit nicer to be able to leave it there with a note saying it
was legacy (if only so people don't try to add it back) but I don't mind
too much.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index abc3080..7e4bb83 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -17,6 +17,7 @@  amstaos	AMS-Taos Inc.
 apm	Applied Micro Circuits Corporation (APM)
 arm	ARM Ltd.
 armadeus	ARMadeus Systems SARL
+asahi-kasei	Asahi Kasei Corp.
 atmel	Atmel Corporation
 auo	AU Optronics Corporation
 avago	Avago Technologies