| Message ID | 878ulzx6hr.wl%kuninori.morimoto.gx@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 >
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
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.
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
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?
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?
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.
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 --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