Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1495311 > unrolled thread

[PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven <geert+renesas@glider.be> - 2016-10-04 11:20 +0200
    [PATCH 1/4] base: soc: Early register bus when needed Geert Uytterhoeven <geert+renesas@glider.be> - 2016-10-04 11:20 +0200
      Re: [PATCH 1/4] base: soc: Early register bus when needed Arnd Bergmann <arnd@arndb.de> - 2016-10-10 16:20 +0200
    [PATCH 3/4] base: soc: Check for NULL SoC device attributes Geert Uytterhoeven <geert+renesas@glider.be> - 2016-10-04 11:20 +0200
      Re: [PATCH 3/4] base: soc: Check for NULL SoC device attributes Arnd Bergmann <arnd@arndb.de> - 2016-10-10 16:20 +0200
    Re: [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus Arnd Bergmann <arnd@arndb.de> - 2016-10-10 16:30 +0200

#1495311 — [PATCH 0/4] soc: renesas: Identify SoC and register with the SoC bus

	Hi all,

Some Renesas SoCs may exist in different revisions, providing slightly
different functionalities (e.g. R-Car H3 ES1.x and ES2.0). This needs to
be catered for by drivers and/or platform code.  The recently proposed
soc_device_match() API seems like a good fit to handle this.

This patch series implements the core infrastructure to provide SoC and
revision information through the SoC bus for Renesas ARM SoCs. It
consists of 4 patches:
  - Patch 1 avoids a crash when SoC revision information is needed and
    provided early,
  - Patch 2 (from Arnd) introduces the soc_device_match() API.
    I don't know if, when, and through which channel this patch is
    planned to go upstream,
  - Patch 3 fixes a bug in soc_device_match(), causing a crash when
    trying to match on an SoC attribute that is not provided (seen on
    EMEV2, RZ/A, and R-Car M1A, which lack revision information),
  - Patch 4 identifies Renesas SoCs and registers them with the SoC bus.

Tested on (family, machine, soc_id, optional revision):

    Emma Mobile EV2, EMEV2 KZM9D Board, emev2
    RZ/A, Genmai, r7s72100
    R-Mobile, APE6EVM, r8a73a4, ES1.0
    R-Mobile, armadillo 800 eva, r8a7740, ES2.0
    R-Car Gen1, bockw, r8a7778
    R-Car Gen1, marzen, r8a7779, ES1.0
    R-Car Gen2, Lager, r8a7790, ES1.0
    R-Car Gen2, Koelsch, r8a7791, ES1.0
    R-Car Gen2, Gose, r8a7793, ES1.0
    R-Car Gen2, Alt, r8a7794, ES1.0
    R-Car Gen3, Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
    R-Car Gen3, Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
    SH-Mobile, KZM-A9-GT, sh73a0, ES2.0

For your convenience, this series is also available in the
topic/renesas-soc-id-v1 branch of my renesas-drivers git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git

Thanks for your comments!

Arnd Bergmann (1):
  base: soc: Introduce soc_device_match() interface

Geert Uytterhoeven (3):
  base: soc: Early register bus when needed
  base: soc: Check for NULL SoC device attributes
  [RFC] soc: renesas: Identify SoC and register with the SoC bus

 arch/arm/mach-shmobile/Kconfig    |   1 +
 arch/arm64/Kconfig.platforms      |   1 +
 drivers/base/Kconfig              |   1 +
 drivers/base/soc.c                |  79 +++++++++++
 drivers/soc/renesas/Makefile      |   2 +
 drivers/soc/renesas/renesas-soc.c | 266 ++++++++++++++++++++++++++++++++++++++
 include/linux/sys_soc.h           |   3 +
 7 files changed, 353 insertions(+)
 create mode 100644 drivers/soc/renesas/renesas-soc.c

-- 
1.9.1

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

[toc] | [next] | [standalone]

#1495312 — [PATCH 1/4] base: soc: Early register bus when needed

If soc_device_register() is called before soc_bus_register(), it crashes
with a NULL pointer dereference.

soc_bus_register() is already a core_initcall(), but drivers/base/ is
entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
are several subsystems that may need to know SoC revision information,
while it's not so easy to initialize the SoC bus even earlier using an
initcall.

To fix this, let soc_device_register() register the bus early if that
hasn't happened yet.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/base/soc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 75b98aad6fafd171..f612715d24754d27 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -114,6 +114,12 @@ struct soc_device *soc_device_register(struct soc_device_attribute *soc_dev_attr
 	struct soc_device *soc_dev;
 	int ret;
 
+	if (!soc_bus_type.p) {
+		ret = bus_register(&soc_bus_type);
+		if (ret)
+			goto out1;
+	}
+
 	soc_dev = kzalloc(sizeof(*soc_dev), GFP_KERNEL);
 	if (!soc_dev) {
 		ret = -ENOMEM;
@@ -157,6 +163,9 @@ void soc_device_unregister(struct soc_device *soc_dev)
 
 static int __init soc_bus_register(void)
 {
+	if (soc_bus_type.p)
+		return 0;
+
 	return bus_register(&soc_bus_type);
 }
 core_initcall(soc_bus_register);
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1498352 — Re: [PATCH 1/4] base: soc: Early register bus when needed

On Tuesday, October 4, 2016 11:09:24 AM CEST Geert Uytterhoeven wrote:
> If soc_device_register() is called before soc_bus_register(), it crashes
> with a NULL pointer dereference.
> 
> soc_bus_register() is already a core_initcall(), but drivers/base/ is
> entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
> are several subsystems that may need to know SoC revision information,
> while it's not so easy to initialize the SoC bus even earlier using an
> initcall.
> 
> To fix this, let soc_device_register() register the bus early if that
> hasn't happened yet.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 

Not nice, but I can't think of a better alternative, so

Acked-by: Arnd Bergmann <arnd@arndb.de>

[toc] | [prev] | [next] | [standalone]

#1495313 — [PATCH 3/4] base: soc: Check for NULL SoC device attributes

If soc_device_match() is used to check the value of a specific
attribute that is not present for the current SoC, the kernel crashes
with a NULL pointer dereference.

Fix this by explicitly checking for the absence of a needed property,
and considering this a non-match.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
 drivers/base/soc.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 37c087096b1c5675..545cc9cf2789fe07 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -185,19 +185,23 @@ static int soc_device_match_one(struct device *dev, void *arg)
 	const struct soc_device_attribute *match = arg;
 
 	if (match->machine &&
-	    !glob_match(match->machine, soc_dev->attr->machine))
+	    (!soc_dev->attr->machine ||
+	     !glob_match(match->machine, soc_dev->attr->machine)))
 		return 0;
 
 	if (match->family &&
-	    !glob_match(match->family, soc_dev->attr->family))
+	    (!soc_dev->attr->family ||
+	     !glob_match(match->family, soc_dev->attr->family)))
 		return 0;
 
 	if (match->revision &&
-	    !glob_match(match->revision, soc_dev->attr->revision))
+	    (!soc_dev->attr->revision ||
+	     !glob_match(match->revision, soc_dev->attr->revision)))
 		return 0;
 
 	if (match->soc_id &&
-	    !glob_match(match->soc_id, soc_dev->attr->soc_id))
+	    (!soc_dev->attr->soc_id ||
+	     !glob_match(match->soc_id, soc_dev->attr->soc_id)))
 		return 0;
 
 	return 1;
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1498353 — Re: [PATCH 3/4] base: soc: Check for NULL SoC device attributes

On Tuesday, October 4, 2016 11:09:26 AM CEST Geert Uytterhoeven wrote:
> If soc_device_match() is used to check the value of a specific
> attribute that is not present for the current SoC, the kernel crashes
> with a NULL pointer dereference.
> 
> Fix this by explicitly checking for the absence of a needed property,
> and considering this a non-match.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 

Acked-by: Arnd Bergmann <arnd@arndb.de>

[toc] | [prev] | [next] | [standalone]

#1498357

On Tuesday, October 4, 2016 11:09:23 AM CEST Geert Uytterhoeven wrote:
> 	Hi all,
> 
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0). This needs to
> be catered for by drivers and/or platform code.  The recently proposed
> soc_device_match() API seems like a good fit to handle this.
> 
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs. It
> consists of 4 patches:
>   - Patch 1 avoids a crash when SoC revision information is needed and
>     provided early,
>   - Patch 2 (from Arnd) introduces the soc_device_match() API.
>     I don't know if, when, and through which channel this patch is
>     planned to go upstream,
>   - Patch 3 fixes a bug in soc_device_match(), causing a crash when
>     trying to match on an SoC attribute that is not provided (seen on
>     EMEV2, RZ/A, and R-Car M1A, which lack revision information),
>   - Patch 4 identifies Renesas SoCs and registers them with the SoC bus.
> 
> Tested on (family, machine, soc_id, optional revision):
> 
>     Emma Mobile EV2, EMEV2 KZM9D Board, emev2
>     RZ/A, Genmai, r7s72100
>     R-Mobile, APE6EVM, r8a73a4, ES1.0
>     R-Mobile, armadillo 800 eva, r8a7740, ES2.0
>     R-Car Gen1, bockw, r8a7778
>     R-Car Gen1, marzen, r8a7779, ES1.0
>     R-Car Gen2, Lager, r8a7790, ES1.0
>     R-Car Gen2, Koelsch, r8a7791, ES1.0
>     R-Car Gen2, Gose, r8a7793, ES1.0
>     R-Car Gen2, Alt, r8a7794, ES1.0
>     R-Car Gen3, Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>     R-Car Gen3, Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>     SH-Mobile, KZM-A9-GT, sh73a0, ES2.0

As mentioned in the comment for the driver patch, I think this makes
a lot of sense for the machines that have a revision register, in
particular when the interpretation of that register is always done
the same way, but I'm a bit skeptical about doing it in the same driver
for machines that don't have the register.

Matching by a device rather than the SoC platform also has the advantage
that there is no need to maintain a list of compatible numbers in the
driver.

	Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web