[GIT PULL] efm32 for 3.17-rc1

[GIT PULL] efm32 for 3.17-rc1

[Uwe Kleine-König]

Hello,

The following changes since commit 7171511eaec5bf23fb06078f59784a3a0626b38f:

  Linux 3.16-rc1 (2014-06-15 17:45:28 -1000)

are available in the git repository at:

  git://git.pengutronix.de/git/ukl/linux.git tags/efm32-for-armsoc

for you to fetch changes up to f89056edb765268fe6880ab8caaee9331c3f5618:

  ARM: efm32: switch to vendor,device compatible strings (2014-06-30 17:11:53 +0200)

----------------------------------------------------------------
Just two follow-up changes for cleanups that went into v3.15-rc2.

----------------------------------------------------------------
These two patches were not sent to the list yet, but I will send them as
reply to this mail. If you prefer to pick them up by hand instead of
pulling, feel free to do so. I didn't put them into my for-next branch.

Best regards
Uwe

Uwe Kleine-K?nig (2):
      ARM: efm32: switch to properly namespaced location property
      ARM: efm32: switch to vendor,device compatible strings

 arch/arm/boot/dts/efm32gg-dk3750.dts |  6 +++---
 arch/arm/boot/dts/efm32gg.dtsi       | 32 ++++++++++++++++----------------
 2 files changed, 19 insertions(+), 19 deletions(-)


-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Uwe Kleine-König]

Now that both spi and serial driver support these (commits f2bb31057a42
(spi: efm32: properly namespace location property) and
74be65a3cff5 (serial: efm32: properly namespace location property)) use
the better names.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/dts/efm32gg-dk3750.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
index b4031fa4a567..d5dd2a2a7970 100644
--- a/arch/arm/boot/dts/efm32gg-dk3750.dts
+++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
@@ -43,7 +43,7 @@
 
 		spi0: spi at 4000c000 { /* USART0 */
 			cs-gpios = <&gpio 68 1>; // E4
-			location = <1>;
+			efm32,location = <1>;
 			status = "ok";
 
 			microsd at 0 {
@@ -57,7 +57,7 @@
 
 		spi1: spi at 4000c400 { /* USART1 */
 			cs-gpios = <&gpio 51 1>; // D3
-			location = <1>;
+			efm32,location = <1>;
 			status = "ok";
 
 			ks8851 at 0 {
@@ -70,7 +70,7 @@
 		};
 
 		uart4: uart at 4000e400 { /* UART1 */
-			location = <2>;
+			efm32,location = <2>;
 			status = "ok";
 		};
 
-- 
2.0.0

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Olof Johansson]

Hi,

On Mon, Jun 30, 2014 at 8:41 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Now that both spi and serial driver support these (commits f2bb31057a42
> (spi: efm32: properly namespace location property) and
> 74be65a3cff5 (serial: efm32: properly namespace location property)) use
> the better names.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> ---
>  arch/arm/boot/dts/efm32gg-dk3750.dts | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
> index b4031fa4a567..d5dd2a2a7970 100644
> --- a/arch/arm/boot/dts/efm32gg-dk3750.dts
> +++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
> @@ -43,7 +43,7 @@
>
>                 spi0: spi at 4000c000 { /* USART0 */
>                         cs-gpios = <&gpio 68 1>; // E4
> -                       location = <1>;
> +                       efm32,location = <1>;

Hrm, the prefix is normally the vendor, not the platform. I see that
the bindings have already been merged though. Sorry, I completely
missed that the first time around. :(

Probably not a whole lot to do about it in this case. It's not the end
of the world anyway, efm32 is a sufficiently unique string as it is.


-Olof

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Uwe Kleine-König]

Hi Olof,

On Mon, Jul 07, 2014 at 10:46:52PM -0700, Olof Johansson wrote:
> On Mon, Jun 30, 2014 at 8:41 AM, Uwe Kleine-K?nig
> <u.kleine-koenig@pengutronix.de> wrote:
> > Now that both spi and serial driver support these (commits f2bb31057a42
> > (spi: efm32: properly namespace location property) and
> > 74be65a3cff5 (serial: efm32: properly namespace location property)) use
> > the better names.
> >
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > ---
> >  arch/arm/boot/dts/efm32gg-dk3750.dts | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
> > index b4031fa4a567..d5dd2a2a7970 100644
> > --- a/arch/arm/boot/dts/efm32gg-dk3750.dts
> > +++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
> > @@ -43,7 +43,7 @@
> >
> >                 spi0: spi at 4000c000 { /* USART0 */
> >                         cs-gpios = <&gpio 68 1>; // E4
> > -                       location = <1>;
> > +                       efm32,location = <1>;
> 
> Hrm, the prefix is normally the vendor, not the platform. I see that
Don't considering what it used normally (and I didn't do it wrong on
purpose) I consider a string identifying the platform to be more
sensible here. For one thing because the vendor can change (as it did with
efm32). Another reason is that the vendor can create another platform
that also needs some devices with a location property that has a
completely different semantic but would get the same name.
(Ok, if the semantic on the different platform is similar
$vendor,location would be more appropriate. Probably the decision on
what name to pick should be considered case by case.)

Just my 0.02 ?,
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Olof Johansson]

On Mon, Jul 7, 2014 at 11:41 PM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hi Olof,
>
> On Mon, Jul 07, 2014 at 10:46:52PM -0700, Olof Johansson wrote:
>> On Mon, Jun 30, 2014 at 8:41 AM, Uwe Kleine-K?nig
>> <u.kleine-koenig@pengutronix.de> wrote:
>> > Now that both spi and serial driver support these (commits f2bb31057a42
>> > (spi: efm32: properly namespace location property) and
>> > 74be65a3cff5 (serial: efm32: properly namespace location property)) use
>> > the better names.
>> >
>> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>> > ---
>> >  arch/arm/boot/dts/efm32gg-dk3750.dts | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/efm32gg-dk3750.dts b/arch/arm/boot/dts/efm32gg-dk3750.dts
>> > index b4031fa4a567..d5dd2a2a7970 100644
>> > --- a/arch/arm/boot/dts/efm32gg-dk3750.dts
>> > +++ b/arch/arm/boot/dts/efm32gg-dk3750.dts
>> > @@ -43,7 +43,7 @@
>> >
>> >                 spi0: spi at 4000c000 { /* USART0 */
>> >                         cs-gpios = <&gpio 68 1>; // E4
>> > -                       location = <1>;
>> > +                       efm32,location = <1>;
>>
>> Hrm, the prefix is normally the vendor, not the platform. I see that
> Don't considering what it used normally (and I didn't do it wrong on
> purpose) I consider a string identifying the platform to be more
> sensible here.

It's long-standing practice (20 years or so) to always use the vendor
as prefix, not the platform.

> For one thing because the vendor can change (as it did with
> efm32).

Then we keep the previous vendor, that's a long-standing practice too.
Sun didn't switch from SUNW to JAVA as prefix just because their stock
ticker was renamed.

> Another reason is that the vendor can create another platform
> that also needs some devices with a location property that has a
> completely different semantic but would get the same name.

Then the new binding will use a different name, or they will be
managed in some compatible way. The same argument could be said in the
other way: the same vendor might introduce a new platform that uses
the same binding but isn't called efm32. That's equally wrong (and
it's actually a quite common situation these days).

> (Ok, if the semantic on the different platform is similar
> $vendor,location would be more appropriate. Probably the decision on
> what name to pick should be considered case by case.)

I really don't want a hodge-podge of whatever someone felt like
picking as a name at the time. It makes it really hard for newcomers
to find a good best practices to follow, and over time will result in
total chaos.

What's this binding for anyway? It looks a lot like an ad-hoc pinctrl
binding for configuring pinout, is that accurate?


-Olof

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Uwe Kleine-König]

Hi Olof,

On Tue, Jul 08, 2014 at 09:06:13AM -0700, Olof Johansson wrote:
> I really don't want a hodge-podge of whatever someone felt like
> picking as a name at the time. It makes it really hard for newcomers
> to find a good best practices to follow, and over time will result in
> total chaos.
That's right. I did it in good faith. If you think it would be worth to
switch to say "energymicro,location" I think it wouldn't be that hard,
because I think there are no boards in the wild that use a device tree
and don't use the BSP I'm providing where switching is a no brainer.
> 
> What's this binding for anyway? It looks a lot like an ad-hoc pinctrl
> binding for configuring pinout, is that accurate?
Well, it has to do with pinctrl, but it was agreed that managing it with
a single pinctrl device would complicate things considerably and in the
end the device tree wouldn't describe how the hardware looks like but
would result in a lot of complexity just to fit into the Linux pinctrl
model.

See the thread around
http://marc.info/?l=linux-spi&m=137485291802157&w=2 for the glory
details.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 1/2] ARM: efm32: switch to properly namespaced location property

[Olof Johansson]

On Tue, Jul 8, 2014 at 11:26 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Hi Olof,
>
> On Tue, Jul 08, 2014 at 09:06:13AM -0700, Olof Johansson wrote:
>> I really don't want a hodge-podge of whatever someone felt like
>> picking as a name at the time. It makes it really hard for newcomers
>> to find a good best practices to follow, and over time will result in
>> total chaos.
> That's right. I did it in good faith. If you think it would be worth to
> switch to say "energymicro,location" I think it wouldn't be that hard,
> because I think there are no boards in the wild that use a device tree
> and don't use the BSP I'm providing where switching is a no brainer.

Yeah, let's do it now before there are users, if that's OK with you.

>> What's this binding for anyway? It looks a lot like an ad-hoc pinctrl
>> binding for configuring pinout, is that accurate?
> Well, it has to do with pinctrl, but it was agreed that managing it with
> a single pinctrl device would complicate things considerably and in the
> end the device tree wouldn't describe how the hardware looks like but
> would result in a lot of complexity just to fit into the Linux pinctrl
> model.
>
> See the thread around
> http://marc.info/?l=linux-spi&m=137485291802157&w=2 for the glory
> details.

OK, thanks for the background.


-Olof

[PATCH] serial: efm32: correct namespacing of location property

[Uwe Kleine-König]

Olof Johansson pointed out that usually the company name is picked as
namespace prefix to specific properties. So expect "energymicro,location"
but fall back to the previously introduced name "efm32,location".

Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 Documentation/devicetree/bindings/serial/efm32-uart.txt | 4 ++--
 drivers/tty/serial/efm32-uart.c                         | 8 +++++++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt
index 3ca01336b837..8adbab268ca3 100644
--- a/Documentation/devicetree/bindings/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt
@@ -6,7 +6,7 @@ Required properties:
 - interrupts : Should contain uart interrupt
 
 Optional properties:
-- efm32,location : Decides the location of the USART I/O pins.
+- energymicro,location : Decides the location of the USART I/O pins.
   Allowed range : [0 .. 5]
   Default: 0
 
@@ -16,5 +16,5 @@ uart at 0x4000c400 {
 	compatible = "energymicro,efm32-uart";
 	reg = <0x4000c400 0x400>;
 	interrupts = <15>;
-	efm32,location = <0>;
+	energymicro,location = <0>;
 };
diff --git a/drivers/tty/serial/efm32-uart.c b/drivers/tty/serial/efm32-uart.c
index 3b0ee9afd76f..cb007a4f4d15 100644
--- a/drivers/tty/serial/efm32-uart.c
+++ b/drivers/tty/serial/efm32-uart.c
@@ -671,10 +671,16 @@ static int efm32_uart_probe_dt(struct platform_device *pdev,
 	if (!np)
 		return 1;
 
-	ret = of_property_read_u32(np, "efm32,location", &location);
+	ret = of_property_read_u32(np, "energymicro,location", &location);
+
+	if (ret)
+		/* fall back to wrongly namespaced property */
+		ret = of_property_read_u32(np, "efm32,location", &location);
+
 	if (ret)
 		/* fall back to old and (wrongly) generic property "location" */
 		ret = of_property_read_u32(np, "location", &location);
+
 	if (!ret) {
 		if (location > 5) {
 			dev_err(&pdev->dev, "invalid location\n");
-- 
2.0.0

[PATCH] spi: efm32: correct namespacing of location property

[Uwe Kleine-König]

Olof Johansson pointed out that usually the company name is picked as
namespace prefix to specific properties. So expect "energymicro,location"
but fall back to the previously introduced name "efm32,location".

Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 Documentation/devicetree/bindings/spi/efm32-spi.txt | 13 +++++++------
 drivers/spi/spi-efm32.c                             |  8 +++++++-
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt
index 130cd17e3680..750e29aff9bc 100644
--- a/Documentation/devicetree/bindings/spi/efm32-spi.txt
+++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt
@@ -10,11 +10,12 @@ Required properties:
 - cs-gpios: see spi-bus.txt
 
 Recommended properties :
-- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to
-                  configure the pinmux for the device, see datasheet for values.
-                  If "efm32,location" property is not provided, keeping what is
-                  already configured in the hardware, so its either the reset
-                  default 0 or whatever the bootloader did.
+- energymicro,location: Value to write to the ROUTE register's LOCATION
+                        bitfield to configure the pinmux for the device, see
+                        datasheet for values.
+                        If this property is not provided, keeping what is
+                        already configured in the hardware, so its either the
+                        reset default 0 or whatever the bootloader did.
 
 Example:
 
@@ -26,7 +27,7 @@ spi1: spi at 0x4000c400 { /* USART1 */
 	interrupts = <15 16>;
 	clocks = <&cmu 20>;
 	cs-gpios = <&gpio 51 1>; // D3
-	efm32,location = <1>;
+	energymicro,location = <1>;
 	status = "ok";
 
 	ks8851 at 0 {
diff --git a/drivers/spi/spi-efm32.c b/drivers/spi/spi-efm32.c
index be44a3eeb5e8..6caeb1cac0f3 100644
--- a/drivers/spi/spi-efm32.c
+++ b/drivers/spi/spi-efm32.c
@@ -294,10 +294,16 @@ static void efm32_spi_probe_dt(struct platform_device *pdev,
 	u32 location;
 	int ret;
 
-	ret = of_property_read_u32(np, "efm32,location", &location);
+	ret = of_property_read_u32(np, "energymicro,location", &location);
+
+	if (ret)
+		/* fall back to wrongly namespaced property */
+		ret = of_property_read_u32(np, "efm32,location", &location);
+
 	if (ret)
 		/* fall back to old and (wrongly) generic property "location" */
 		ret = of_property_read_u32(np, "location", &location);
+
 	if (!ret) {
 		dev_dbg(&pdev->dev, "using location %u\n", location);
 	} else {
-- 
2.0.0

[PATCH] spi: efm32: correct namespacing of location property

[Mark Brown]

On Fri, Jul 11, 2014 at 10:17:57AM +0200, Uwe Kleine-K?nig wrote:
> Olof Johansson pointed out that usually the company name is picked as
> namespace prefix to specific properties. So expect "energymicro,location"
> but fall back to the previously introduced name "efm32,location".

Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140711/a622b1d9/attachment-0001.sig>

[PATCH] i2c: efm32: correct namespacing of location property

[Uwe Kleine-König]

Olof Johansson pointed out that usually the company name is picked as
namespace prefix to specific properties. So expect "energymicro,location"
but fall back to the previously introduced name "efm32,location".

Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 Documentation/devicetree/bindings/i2c/i2c-efm32.txt | 4 ++--
 drivers/i2c/busses/i2c-efm32.c                      | 8 +++++++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
index fc15ac519437..50b25c3da186 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
@@ -10,7 +10,7 @@ Required properties :
 Recommended properties :
 
  - clock-frequency : maximal I2C bus clock frequency in Hz.
- - efm32,location : Decides the location of the USART I/O pins.
+ - energymicro,location : Decides the location of the USART I/O pins.
    Allowed range : [0 .. 6]
 
 Example:
@@ -23,7 +23,7 @@ Example:
 		clocks = <&cmu clk_HFPERCLKI2C0>;
 		clock-frequency = <100000>;
 		status = "ok";
-		efm32,location = <3>;
+		energymicro,location = <3>;
 
 		eeprom at 50 {
 			compatible = "microchip,24c02";
diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
index f7eccd682de9..5c4cf94527e3 100644
--- a/drivers/i2c/busses/i2c-efm32.c
+++ b/drivers/i2c/busses/i2c-efm32.c
@@ -370,7 +370,13 @@ static int efm32_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ret = of_property_read_u32(np, "efm32,location", &location);
+
+	ret = of_property_read_u32(np, "energymicro,location", &location);
+
+	if (!ret)
+		/* fall back to wrongly namespaced property */
+		ret = of_property_read_u32(np, "efm32,location", &location);
+
 	if (!ret) {
 		dev_dbg(&pdev->dev, "using location %u\n", location);
 	} else {
-- 
2.0.0

[PATCH] i2c: efm32: correct namespacing of location property

[Uwe Kleine-König]

Hi Wolfram,

> diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
> index f7eccd682de9..5c4cf94527e3 100644
> --- a/drivers/i2c/busses/i2c-efm32.c
> +++ b/drivers/i2c/busses/i2c-efm32.c
> @@ -370,7 +370,13 @@ static int efm32_i2c_probe(struct platform_device *pdev)
>  		return ret;
>  	}
>  
> -	ret = of_property_read_u32(np, "efm32,location", &location);
> +
> +	ret = of_property_read_u32(np, "energymicro,location", &location);
> +
> +	if (!ret)
This must be "if (ret)". I noticed during testing but obviously forgot
to fixup before sending out. Should I resend?

Best regards
Uwe
> +		/* fall back to wrongly namespaced property */
> +		ret = of_property_read_u32(np, "efm32,location", &location);
> +
>  	if (!ret) {
>  		dev_dbg(&pdev->dev, "using location %u\n", location);
>  	} else {

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] i2c: efm32: correct namespacing of location property

[Wolfram Sang]

> > +	if (!ret)
> This must be "if (ret)". I noticed during testing but obviously forgot
> to fixup before sending out. Should I resend?

Yup.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140711/a5410753/attachment.sig>

[PATCH v2] i2c: efm32: correct namespacing of location property

[Uwe Kleine-König]

Olof Johansson pointed out that usually the company name is picked as
namespace prefix to specific properties. So expect "energymicro,location"
but fall back to the previously introduced name "efm32,location".

Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
Changes since (implicit) v1:
 - fix a wrong if condtion

 Documentation/devicetree/bindings/i2c/i2c-efm32.txt | 4 ++--
 drivers/i2c/busses/i2c-efm32.c                      | 8 +++++++-
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
index fc15ac519437..50b25c3da186 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt
@@ -10,7 +10,7 @@ Required properties :
 Recommended properties :
 
  - clock-frequency : maximal I2C bus clock frequency in Hz.
- - efm32,location : Decides the location of the USART I/O pins.
+ - energymicro,location : Decides the location of the USART I/O pins.
    Allowed range : [0 .. 6]
 
 Example:
@@ -23,7 +23,7 @@ Example:
 		clocks = <&cmu clk_HFPERCLKI2C0>;
 		clock-frequency = <100000>;
 		status = "ok";
-		efm32,location = <3>;
+		energymicro,location = <3>;
 
 		eeprom at 50 {
 			compatible = "microchip,24c02";
diff --git a/drivers/i2c/busses/i2c-efm32.c b/drivers/i2c/busses/i2c-efm32.c
index f7eccd682de9..10b8323b08d4 100644
--- a/drivers/i2c/busses/i2c-efm32.c
+++ b/drivers/i2c/busses/i2c-efm32.c
@@ -370,7 +370,13 @@ static int efm32_i2c_probe(struct platform_device *pdev)
 		return ret;
 	}
 
-	ret = of_property_read_u32(np, "efm32,location", &location);
+
+	ret = of_property_read_u32(np, "energymicro,location", &location);
+
+	if (ret)
+		/* fall back to wrongly namespaced property */
+		ret = of_property_read_u32(np, "efm32,location", &location);
+
 	if (!ret) {
 		dev_dbg(&pdev->dev, "using location %u\n", location);
 	} else {
-- 
2.0.0

[PATCH v2] i2c: efm32: correct namespacing of location property

[Wolfram Sang]

On Fri, Jul 11, 2014 at 10:50:14AM +0200, Uwe Kleine-K?nig wrote:
> Olof Johansson pointed out that usually the company name is picked as
> namespace prefix to specific properties. So expect "energymicro,location"
> but fall back to the previously introduced name "efm32,location".
> 
> Cc: Olof Johansson <olof@lixom.net>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>

Applied to for-next, thanks! If you think this is better suited in
for-current, let me know.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140717/8d55127a/attachment.sig>

[PATCH v2] i2c: efm32: correct namespacing of location property

[Uwe Kleine-König]

On Thu, Jul 17, 2014 at 03:40:00PM +0200, Wolfram Sang wrote:
> On Fri, Jul 11, 2014 at 10:50:14AM +0200, Uwe Kleine-K?nig wrote:
> > Olof Johansson pointed out that usually the company name is picked as
> > namespace prefix to specific properties. So expect "energymicro,location"
> > but fall back to the previously introduced name "efm32,location".
> > 
> > Cc: Olof Johansson <olof@lixom.net>
> > Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> 
> Applied to for-next, thanks! If you think this is better suited in
> for-current, let me know.
I'm not in a hurry. If you take it it's fine for me.

(BTW, I'm not sure i fI understand your branch naming. for-next means
"targeting the next merge window" and for-current means "targeting the
next release"? So for-next currently means 3.17-rc1?)

Thanks
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH 2/2] ARM: efm32: switch to vendor,device compatible strings

[Uwe Kleine-König]

The mainline drivers were fixed in commits

 - 4ea8dafd2475 (serial: efm32: use $vendor,$device scheme for
   compatible string)
 - 12f6dd860cf8 (spi: efm32: use $vendor,$device scheme for compatible
   string)
 - 63cc122381bd (clocksource: efm32: use $vendor,$device scheme for
   compatible string)

to also support these compatible strings.

For the other affected peripherals (adc and gpio) there are no drivers in
mainline yet.

Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
---
 arch/arm/boot/dts/efm32gg.dtsi | 32 ++++++++++++++++----------------
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/boot/dts/efm32gg.dtsi b/arch/arm/boot/dts/efm32gg.dtsi
index 106d505c5d3d..c747983771c7 100644
--- a/arch/arm/boot/dts/efm32gg.dtsi
+++ b/arch/arm/boot/dts/efm32gg.dtsi
@@ -23,7 +23,7 @@
 
 	soc {
 		adc: adc at 40002000 {
-			compatible = "efm32,adc";
+			compatible = "energymicro,efm32-adc";
 			reg = <0x40002000 0x400>;
 			interrupts = <7>;
 			clocks = <&cmu clk_HFPERCLKADC0>;
@@ -31,7 +31,7 @@
 		};
 
 		gpio: gpio at 40006000 {
-			compatible = "efm32,gpio";
+			compatible = "energymicro,efm32-gpio";
 			reg = <0x40006000 0x1000>;
 			interrupts = <1 11>;
 			gpio-controller;
@@ -45,7 +45,7 @@
 		i2c0: i2c at 4000a000 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "efm32,i2c";
+			compatible = "energymicro,efm32-i2c";
 			reg = <0x4000a000 0x400>;
 			interrupts = <9>;
 			clocks = <&cmu clk_HFPERCLKI2C0>;
@@ -56,7 +56,7 @@
 		i2c1: i2c at 4000a400 {
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "efm32,i2c";
+			compatible = "energymicro,efm32-i2c";
 			reg = <0x4000a400 0x400>;
 			interrupts = <10>;
 			clocks = <&cmu clk_HFPERCLKI2C1>;
@@ -67,7 +67,7 @@
 		spi0: spi at 4000c000 { /* USART0 */
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "efm32,spi";
+			compatible = "energymicro,efm32-spi";
 			reg = <0x4000c000 0x400>;
 			interrupts = <3 4>;
 			clocks = <&cmu clk_HFPERCLKUSART0>;
@@ -77,7 +77,7 @@
 		spi1: spi at 4000c400 { /* USART1 */
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "efm32,spi";
+			compatible = "energymicro,efm32-spi";
 			reg = <0x4000c400 0x400>;
 			interrupts = <15 16>;
 			clocks = <&cmu clk_HFPERCLKUSART1>;
@@ -87,7 +87,7 @@
 		spi2: spi at 4000c800 { /* USART2 */
 			#address-cells = <1>;
 			#size-cells = <0>;
-			compatible = "efm32,spi";
+			compatible = "energymicro,efm32-spi";
 			reg = <0x4000c800 0x400>;
 			interrupts = <18 19>;
 			clocks = <&cmu clk_HFPERCLKUSART2>;
@@ -95,7 +95,7 @@
 		};
 
 		uart0: uart at 4000c000 { /* USART0 */
-			compatible = "efm32,uart";
+			compatible = "energymicro,efm32-uart";
 			reg = <0x4000c000 0x400>;
 			interrupts = <3 4>;
 			clocks = <&cmu clk_HFPERCLKUSART0>;
@@ -103,7 +103,7 @@
 		};
 
 		uart1: uart at 4000c400 { /* USART1 */
-			compatible = "efm32,uart";
+			compatible = "energymicro,efm32-uart";
 			reg = <0x4000c400 0x400>;
 			interrupts = <15 16>;
 			clocks = <&cmu clk_HFPERCLKUSART1>;
@@ -111,7 +111,7 @@
 		};
 
 		uart2: uart at 4000c800 { /* USART2 */
-			compatible = "efm32,uart";
+			compatible = "energymicro,efm32-uart";
 			reg = <0x4000c800 0x400>;
 			interrupts = <18 19>;
 			clocks = <&cmu clk_HFPERCLKUSART2>;
@@ -119,7 +119,7 @@
 		};
 
 		uart3: uart at 4000e000 { /* UART0 */
-			compatible = "efm32,uart";
+			compatible = "energymicro,efm32-uart";
 			reg = <0x4000e000 0x400>;
 			interrupts = <20 21>;
 			clocks = <&cmu clk_HFPERCLKUART0>;
@@ -127,7 +127,7 @@
 		};
 
 		uart4: uart at 4000e400 { /* UART1 */
-			compatible = "efm32,uart";
+			compatible = "energymicro,efm32-uart";
 			reg = <0x4000e400 0x400>;
 			interrupts = <22 23>;
 			clocks = <&cmu clk_HFPERCLKUART1>;
@@ -135,28 +135,28 @@
 		};
 
 		timer0: timer at 40010000 {
-			compatible = "efm32,timer";
+			compatible = "energymicro,efm32-timer";
 			reg = <0x40010000 0x400>;
 			interrupts = <2>;
 			clocks = <&cmu clk_HFPERCLKTIMER0>;
 		};
 
 		timer1: timer at 40010400 {
-			compatible = "efm32,timer";
+			compatible = "energymicro,efm32-timer";
 			reg = <0x40010400 0x400>;
 			interrupts = <12>;
 			clocks = <&cmu clk_HFPERCLKTIMER1>;
 		};
 
 		timer2: timer at 40010800 {
-			compatible = "efm32,timer";
+			compatible = "energymicro,efm32-timer";
 			reg = <0x40010800 0x400>;
 			interrupts = <13>;
 			clocks = <&cmu clk_HFPERCLKTIMER2>;
 		};
 
 		timer3: timer at 40010c00 {
-			compatible = "efm32,timer";
+			compatible = "energymicro,efm32-timer";
 			reg = <0x40010c00 0x400>;
 			interrupts = <14>;
 			clocks = <&cmu clk_HFPERCLKTIMER3>;
-- 
2.0.0