"ak" vs "asahi-kasei" (was: Re: [PATCH 3/3 v3] ARM: shmobile: lager: add sound support on DT)

[Geert Uytterhoeven]

Hi Morimoto-san,

CC devicetree, alsa-devel

On Wed, Jun 11, 2014 at 9:40 AM, Kuninori Morimoto

On Wed, Jun 11, 2014 at 8:54 AM, Kuninori Morimoto

+ compatible = "asahi-kasei,ak4643";

As Sergei already commented,
Documentation/devicetree/bindings/vendor-prefixes.txt
says
ak Asahi Kasei Corp.

I know, but,
grep asahi-kasei sound/soc/codecs/*
sound/soc/codecs/ak4104.c: { .compatible = "asahi-kasei,ak4104", },
sound/soc/codecs/ak4554.c: { .compatible = "asahi-kasei,ak4554" },
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4642", .data = &ak4642_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4643", .data = &ak4643_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4648", .data = &ak4648_drvdata},
sound/soc/codecs/ak5386.c: { .compatible = "asahi-kasei,ak5386", },
ak4642 driver can't probe by "ak";

That's bad. And all but one of these match entries have been added
_after_ the addition of "ak" to vendor-prefixes.txt...

Outside sound, there's also "asahi-kasei,ak8975" vs. "ak,ak8975".

My code is based on "code", not "document"

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kuninori Morimoto]

Hi Geert

Post by Geert Uytterhoeven

grep asahi-kasei sound/soc/codecs/*
sound/soc/codecs/ak4104.c: { .compatible = "asahi-kasei,ak4104", },
sound/soc/codecs/ak4554.c: { .compatible = "asahi-kasei,ak4554" },
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4642", .data = &ak4642_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4643", .data = &ak4643_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4648", .data = &ak4648_drvdata},
sound/soc/codecs/ak5386.c: { .compatible = "asahi-kasei,ak5386", },
ak4642 driver can't probe by "ak";

That's bad. And all but one of these match entries have been added
_after_ the addition of "ak" to vendor-prefixes.txt...
Outside sound, there's also "asahi-kasei,ak8975" vs. "ak,ak8975".

In my quick check,
The driver which is supporting "ak" is only ak8975.
Other Asahi-Kasei driver is using "asahi-kasei".

Very interesting is that the document of ak8975
./Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
said it should be "asahi-kasei"

what is the policy of Documentation/devicetree/bindings/vendor-prefixes.txt ?

-----------------------------------------------
grep compatible `find | grep ".*/ak"`
./arch/arm/boot/dts/aks-cdu.dts: compatible = "gpio-leds";
./drivers/iio/magnetometer/ak8975.c: { .compatible = "asahi-kasei,ak8975", },
./drivers/iio/magnetometer/ak8975.c: { .compatible = "ak8975", },
./sound/soc/codecs/ak4104.c: { .compatible = "asahi-kasei,ak4104", },
./sound/soc/codecs/ak5386.c: { .compatible = "asahi-kasei,ak5386", },
./sound/soc/codecs/ak4554.c: { .compatible = "asahi-kasei,ak4554" },
./sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4642", .data = &ak4642_drvdata},
./sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4643", .data = &ak4643_drvdata},
./sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4648", .data = &ak4648_drvdata},
./Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt: - compatible : should be "asahi-kasei,ak8975"
./Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt: compatible = "asahi-kasei,ak8975";
./Documentation/devicetree/bindings/sound/ak4642.txt: - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or "asahi-kasei,ak4648"
./Documentation/devicetree/bindings/sound/ak4642.txt: compatible = "asahi-kasei,ak4642";
./Documentation/devicetree/bindings/sound/ak5386.txt: - compatible : "asahi-kasei,ak5386"
./Documentation/devicetree/bindings/sound/ak5386.txt: compatible = "asahi-kasei,ak5386";
./Documentation/devicetree/bindings/sound/ak4104.txt: - compatible : "asahi-kasei,ak4104"
./Documentation/devicetree/bindings/sound/ak4104.txt: compatible = "asahi-kasei,ak4104";
./Documentation/devicetree/bindings/sound/ak4554.c: - compatible : "asahi-kasei,ak4554"
./Documentation/devicetree/bindings/sound/ak4554.c: compatible = "asahi-kasei,ak4554";
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Ben Dooks]

Post by Kuninori Morimoto
Hi Geert

grep asahi-kasei sound/soc/codecs/*
sound/soc/codecs/ak4104.c: { .compatible = "asahi-kasei,ak4104", },
sound/soc/codecs/ak4554.c: { .compatible = "asahi-kasei,ak4554" },
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4642", .data = &ak4642_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4643", .data = &ak4643_drvdata},
sound/soc/codecs/ak4642.c: { .compatible = "asahi-kasei,ak4648", .data = &ak4648_drvdata},
sound/soc/codecs/ak5386.c: { .compatible = "asahi-kasei,ak5386", },
ak4642 driver can't probe by "ak";

Should we add ak, as well?

[Mark Brown]

Post by Ben Dooks

ak4642 driver can't probe by "ak";

Should we add ak, as well?

They're usually referred to as AKM when abbreviated and their web site
is http://www.akm.com/ - don't know what the stock ticker symbol is. In
any case there's no real cost to adding both abbreviated and
non-abbreviated forms if we want to transition.

[Geert Uytterhoeven]

Post by Mark Brown

Post by Ben Dooks

ak4642 driver can't probe by "ak";

Should we add ak, as well?

They're usually referred to as AKM when abbreviated and their web site
is http://www.akm.com/ - don't know what the stock ticker symbol is. In
any case there's no real cost to adding both abbreviated and
non-abbreviated forms if we want to transition.

commit ae8c4209af2cec065fef15d200a42a04130799f7
Author: Stephen Warren <***@nvidia.com>
Date: Mon Nov 19 15:34:43 2012 -0700

of: Add vendor prefix for Asahi Kasei Corp.

Their stock ticker is 3407.T which wouldn't make a good DT vendor
prefix. Use the company name initials instead.

Signed-off-by: Stephen Warren <***@nvidia.com>
Signed-off-by: Rob Herring <***@calxeda.com>

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ***@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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mark Brown]

Post by Geert Uytterhoeven

Post by Mark Brown
They're usually referred to as AKM when abbreviated and their web site
is http://www.akm.com/ - don't know what the stock ticker symbol is. In
any case there's no real cost to adding both abbreviated and
non-abbreviated forms if we want to transition.

of: Add vendor prefix for Asahi Kasei Corp.
Their stock ticker is 3407.T which wouldn't make a good DT vendor
prefix. Use the company name initials instead.

Sounds like akm, is a better bet then, especially as ak, has no real
adoption.

I think the bikeshed would be much better painted pink with yellow spots :)

[Geert Uytterhoeven]

Post by Mark Brown

Post by Geert Uytterhoeven

They're usually referred to as AKM when abbreviated and their web =

site

Post by Mark Brown

Post by Geert Uytterhoeven

is http://www.akm.com/ - don't know what the stock ticker symbol i=

s. In

Post by Mark Brown

Post by Geert Uytterhoeven

any case there's no real cost to adding both abbreviated and
non-abbreviated forms if we want to transition.

of: Add vendor prefix for Asahi Kasei Corp.
Their stock ticker is 3407.T which wouldn't make a good DT vendo=

r

Post by Mark Brown

Post by Geert Uytterhoeven
prefix. Use the company name initials instead.

Sounds like akm, is a better bet then, especially as ak, has no real
adoption.

Except for =D0=90=D0=B2=D1=82=D0=BE=D0=BC=D0=B0=D1=82 =D0=9A=D0=B0=D0=BB=
=D0=B0=D1=88=D0=BD=D0=B8=D0=BA=D0=BE=D0=B2=D0=B0...

Post by Mark Brown
I think the bikeshed would be much better painted pink with yellow sp=

ots :)

Definitely.

Gr{oetje,eeting}s,

Geert

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

In personal conversations with technical people, I call myself a hacker=
=2E But
when I'm talking to journalists I just say "programmer" or something li=
ke that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Stephen Warren]

Post by Mark Brown

Post by Geert Uytterhoeven

Post by Mark Brown
They're usually referred to as AKM when abbreviated and their web site
is http://www.akm.com/ - don't know what the stock ticker symbol is. In
any case there's no real cost to adding both abbreviated and
non-abbreviated forms if we want to transition.

of: Add vendor prefix for Asahi Kasei Corp.
Their stock ticker is 3407.T which wouldn't make a good DT vendor
prefix. Use the company name initials instead.

Sounds like akm, is a better bet then, especially as ak, has no real
adoption.
I think the bikeshed would be much better painted pink with yellow spots :)

Sorry to jump in on this late, but what on earth is wrong with "ak". It
went through the appropriate review process, and is already in use.
Admittedly only in a single ARM DT file, but it's still in use. We'll
have to allow the ak prefix forever given that DT is an ABI, so rather
than introducing more random variations, we should just stick with what
we have.

[Mark Brown]

Post by Stephen Warren

Post by Mark Brown
I think the bikeshed would be much better painted pink with yellow spots :)

Sorry to jump in on this late, but what on earth is wrong with "ak". It
went through the appropriate review process, and is already in use.
Admittedly only in a single ARM DT file, but it's still in use. We'll
have to allow the ak prefix forever given that DT is an ABI, so rather
than introducing more random variations, we should just stick with what
we have.

Well, the issue is that in reality the bulk of the drivers are using
asahi-kasei, we're going to have to churn at least something anyway. We
seem to have one in tree user of ak in a DTS file and two DTSs using
asahi-kasei with seven drivers.

[Stephen Warren]

Post by Mark Brown

Post by Stephen Warren

Post by Mark Brown
I think the bikeshed would be much better painted pink with yellow spots :)

Sorry to jump in on this late, but what on earth is wrong with "ak". It
went through the appropriate review process, and is already in use.
Admittedly only in a single ARM DT file, but it's still in use. We'll
have to allow the ak prefix forever given that DT is an ABI, so rather
than introducing more random variations, we should just stick with what
we have.

Well, the issue is that in reality the bulk of the drivers are using
asahi-kasei, we're going to have to churn at least something anyway. We
seem to have one in tree user of ak in a DTS file and two DTSs using
asahi-kasei with seven drivers.

As far as DTs go, there are only 2 users of asahi-kasei, and they were
both added well after the prefix was documented, so those seem like
plain old bugs.

But due to ABIness, perhaps we have to support both ak and asahi-kasei.
I don't think fixing this implies we should introduce a third option akm
though. No DT is using that today.

[Kuninori Morimoto]

From: Kuninori Morimoto <***@renesas.com>

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

It went through the appropriate review process,
and is already in use.
But, almost all Asahi Kasei chip driver is
using "asahi-kasei" prefix today.

Due to ABIness, 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 as "AKM",
but this patch doesn't care about it.
Because no DT is using it today.

Cc: Stephen Warren <***@wwwdotorg.org>
Cc: Mark Brown <***@kernel.org>
Cc: Geert Uytterhoeven <***@linux-m68k.org>,
Signed-off-by: Kuninori Morimoto <***@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

[Simon Horman]

Post by Kuninori Morimoto
Current vendor-prefixes.txt already has
"ak" prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process,
and is already in use.
But, almost all Asahi Kasei chip driver is
using "asahi-kasei" prefix today.
Due to ABIness, 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 as "AKM",
but this patch doesn't care about it.
Because no DT is using it today.
---
.../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 linux-sh" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Stephen Warren]

Post by Kuninori Morimoto
Current vendor-prefixes.txt already has
"ak" prefix for Asahi Kasei Corp by
ae8c4209af2cec065fef15d200a42a04130799f7
(of: Add vendor prefix for Asahi Kasei Corp.)
It went through the appropriate review process,
and is already in use.
But, almost all Asahi Kasei chip driver is
using "asahi-kasei" prefix today.

I'm fine with this patch, but just wanted to comment on this part of the
commit description:

What is in the drivers isn't relevant; that's not what drives the ABI.
The issue is that some *DTs* use ak and some use asahi-kasei, so both
those need to be supported.

That said, we should document which one of the two prefixes is
preferred, and use this for any new AK binding.

It would also be nice to ensure the preferred prefix is in all drivers'
of_match_tables, and remove the deprecated prefix from all drivers'
of_match_tables *except* where there's already a DT file that references
the deprecated vendor prefix.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kuninori Morimoto]

From: Kuninori Morimoto <***@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 <***@wwwdotorg.org>
Cc: Mark Brown <***@kernel.org>
Cc: Geert Uytterhoeven <***@linux-m68k.org>,
Acked-by: Simon Horman <horms+***@verge.net.au>
Signed-off-by: Kuninori Morimoto <***@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

[Mark Rutland]

Post by Kuninori Morimoto
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.

Post by Kuninori Morimoto
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.

Post by Kuninori Morimoto
OTOH, Asahi Kasei is usually referred to as "AKM",
but this patch doesn't care about it.
Because no DT is using it today.
---
.../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
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Geert Uytterhoeven]

Hi Mark,

Post by Mark Rutland
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-***@public.gmane.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 devicetree" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mark Rutland]

Post by Geert Uytterhoeven
Hi Mark,

Hi Geert,

Post by Geert Uytterhoeven

Post by Mark Rutland
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.

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.

Post by Geert Uytterhoeven
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mark Brown]

Post by Stephen Warren
As far as DTs go, there are only 2 users of asahi-kasei, and they were
both added well after the prefix was documented, so those seem like
plain old bugs.
But due to ABIness, perhaps we have to support both ak and asahi-kasei.
I don't think fixing this implies we should introduce a third option akm
though. No DT is using that today.

See my prior comments about how fetching pink with yellow spots would be :)