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

Groups > linux.kernel > #1512509 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Geert Uytterhoeven <geert+renesas@glider.be> - 2016-10-31 12:40 +0100
    [PATCH v2 2/7] base: soc: Introduce soc_device_match() interface Geert Uytterhoeven <geert+renesas@glider.be> - 2016-10-31 12:40 +0100
    Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Geert Uytterhoeven <geert@linux-m68k.org> - 2016-11-07 10:40 +0100
      Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Krzysztof Kozlowski <krzk@kernel.org> - 2016-11-07 19:40 +0100
      Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Geert Uytterhoeven <geert@linux-m68k.org> - 2016-11-09 14:40 +0100
        Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Arnd Bergmann <arnd@arndb.de> - 2016-11-09 18:00 +0100
          Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Geert Uytterhoeven <geert@linux-m68k.org> - 2016-11-09 18:20 +0100
            Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus Arnd Bergmann <arnd@arndb.de> - 2016-11-09 22:20 +0100
              Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Geert Uytterhoeven <geert@linux-m68k.org> - 2016-11-10 10:30 +0100
                Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Ulf Hansson <ulf.hansson@linaro.org> - 2016-11-10 12:00 +0100
                Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the  SoC bus Geert Uytterhoeven <geert@linux-m68k.org> - 2016-11-10 12:00 +0100

#1512509 — [PATCH v2 0/7] 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), and behavior
(errate and quirks).  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 7 patches:
  - Patches 1-4 provide soc_device_match(), with some related fixes,
  - Patches 5-7 implement identification of Renesas SoCs and
    registration with the SoC bus,

Changes compared to v1:
  - Add Acked-by,
  - New patches:
      - "[4/7] base: soc: Provide a dummy implementation of
	       soc_device_match()",
      - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
      - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
        (more similar patches available, I'm not yet spamming you all
	 with them),
  - Drop SoC families and family names; use fixed "Renesas" instead,
  - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
    devices with other SoCs,
  - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
    M1A: not accessible from the ARM core?),
  - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
    for SoCs that provide a chip ID register,
  - Build renesas-soc only if SOC_BUS is enabled,
  - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
    available, else fall back to hardcoded addresses for compatibility
    with existing DTBs,
  - Remove verification of product IDs; just print the ID instead,
  - Don't register the SoC bus if the chip ID register is missing,
  - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
    both).

Merge strategy:
  - In theory, patches 1-4 should go through Greg's driver core tree.
    But it's a hard dependency for all users.
    If people agree, I can provide an immutable branch in my
    renesas-drivers repository, to be merged by all interested parties.
    So far I'm aware of Freescale/NXP, and Renesas.
  - Patches 5-7 obviously have to go through Simon's Renesas tree (after
    merging the soc_device_match() core), and arm-soc.

Tested on (machine, soc_id, optional revision):
    EMEV2 KZM9D Board, emev2
    Genmai, r7s72100
    APE6EVM, r8a73a4, ES1.0
    armadillo 800 eva, r8a7740, ES2.0
    bockw, r8a7778
    marzen, r8a7779, ES1.0
    Lager, r8a7790, ES1.0
    Koelsch, r8a7791, ES1.0
    Porter, r8a7791, ES3.0
    Blanche, r8a7792, ES1.1
    Gose, r8a7793, ES1.0
    Alt, r8a7794, ES1.0
    Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
    Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
    Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
    KZM-A9-GT, sh73a0, ES2.0

For your convenience, this series (incl. more DT updates to add device
nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
repository at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Its first user is support for R-Car H3 ES2.0 in branch
topic/r8a7795-es2-v1-rebased2.

Thanks for your comments!

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

Geert Uytterhoeven (6):
  base: soc: Early register bus when needed
  base: soc: Check for NULL SoC device attributes
  base: soc: Provide a dummy implementation of soc_device_match()
  ARM: shmobile: Document DT bindings for CCCR and PRR
  arm64: dts: r8a7795: Add device node for PRR
  soc: renesas: Identify SoC and register with the SoC bus

 Documentation/devicetree/bindings/arm/shmobile.txt |  26 +++++
 arch/arm/mach-shmobile/Kconfig                     |   3 +
 arch/arm64/Kconfig.platforms                       |   1 +
 arch/arm64/boot/dts/renesas/r8a7795.dtsi           |   5 +
 drivers/base/Kconfig                               |   1 +
 drivers/base/soc.c                                 |  79 +++++++++++++
 drivers/soc/renesas/Makefile                       |   2 +
 drivers/soc/renesas/renesas-soc.c                  | 130 +++++++++++++++++++++
 include/linux/sys_soc.h                            |   9 ++
 9 files changed, 256 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]

#1512510 — [PATCH v2 2/7] base: soc: Introduce soc_device_match() interface

From: Arnd Bergmann <arnd@arndb.de>

We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version register that is
not part of the device itself but that belongs to a global register area
of the chip.

Common reasons for doing this include:

- A machine is not using devicetree or similar for passing data about
  on-chip devices, but just announces their presence using boot-time
  platform devices, and the machine code itself does not care about the
  revision.

- There is existing firmware or boot loaders with existing DT binaries
  with generic compatible strings that do not identify the particular
  revision of each device, but the driver knows which SoC revisions
  include which part.

- A prerelease version of a chip has some quirks and we are using the same
  version of the bootloader and the DT blob on both the prerelease and the
  final version. An update of the DT binding seems inappropriate because
  that would involve maintaining multiple copies of the dts and/or
  bootloader.

This patch introduces the soc_device_match() interface that is meant to
work like of_match_node() but instead of identifying the version of a
device, it identifies the SoC itself using a vendor-agnostic interface.

Unlike of_match_node(), we do not do an exact string compare but instead
use glob_match() to allow wildcards in strings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
v2:
  - Add Acked-by.
---
 drivers/base/Kconfig    |  1 +
 drivers/base/soc.c      | 66 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/sys_soc.h |  3 +++
 3 files changed, 70 insertions(+)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d02e7c0f5bfdff1c..2abea876c0a0c2c2 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -237,6 +237,7 @@ config GENERIC_CPU_AUTOPROBE
 
 config SOC_BUS
 	bool
+	select GLOB
 
 source "drivers/base/regmap/Kconfig"
 
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index 028cef377fd49959..04ee597fc3a3fda0 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -13,6 +13,7 @@
 #include <linux/spinlock.h>
 #include <linux/sys_soc.h>
 #include <linux/err.h>
+#include <linux/glob.h>
 
 static DEFINE_IDA(soc_ida);
 
@@ -168,3 +169,68 @@ static int __init soc_bus_register(void)
 	return bus_register(&soc_bus_type);
 }
 core_initcall(soc_bus_register);
+
+static int soc_device_match_one(struct device *dev, void *arg)
+{
+	struct soc_device *soc_dev = container_of(dev, struct soc_device, dev);
+	const struct soc_device_attribute *match = arg;
+
+	if (match->machine &&
+	    !glob_match(match->machine, soc_dev->attr->machine))
+		return 0;
+
+	if (match->family &&
+	    !glob_match(match->family, soc_dev->attr->family))
+		return 0;
+
+	if (match->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))
+		return 0;
+
+	return 1;
+}
+
+/*
+ * soc_device_match - identify the SoC in the machine
+ * @matches: zero-terminated array of possible matches
+ *
+ * returns the first matching entry of the argument array, or NULL
+ * if none of them match.
+ *
+ * This function is meant as a helper in place of of_match_node()
+ * in cases where either no device tree is available or the information
+ * in a device node is insufficient to identify a particular variant
+ * by its compatible strings or other properties. For new devices,
+ * the DT binding should always provide unique compatible strings
+ * that allow the use of of_match_node() instead.
+ *
+ * The calling function can use the .data entry of the
+ * soc_device_attribute to pass a structure or function pointer for
+ * each entry.
+ */
+const struct soc_device_attribute *soc_device_match(
+	const struct soc_device_attribute *matches)
+{
+	int ret = 0;
+
+	if (!matches)
+		return NULL;
+
+	while (!ret) {
+		if (!(matches->machine || matches->family ||
+		      matches->revision || matches->soc_id))
+			break;
+		ret = bus_for_each_dev(&soc_bus_type, NULL, (void *)matches,
+				       soc_device_match_one);
+		if (!ret)
+			matches++;
+		else
+			return matches;
+	}
+	return NULL;
+}
+EXPORT_SYMBOL_GPL(soc_device_match);
diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
index 2739ccb69571e444..9f5eb06f9fd87565 100644
--- a/include/linux/sys_soc.h
+++ b/include/linux/sys_soc.h
@@ -13,6 +13,7 @@ struct soc_device_attribute {
 	const char *family;
 	const char *revision;
 	const char *soc_id;
+	const void *data;
 };
 
 /**
@@ -34,4 +35,6 @@ struct soc_device *soc_device_register(
  */
 struct device *soc_device_to_device(struct soc_device *soc);
 
+const struct soc_device_attribute *soc_device_match(
+	const struct soc_device_attribute *matches);
 #endif /* __SOC_BUS_H */
-- 
1.9.1

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

#1515946 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
<geert+renesas@glider.be> wrote:
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks).  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 7 patches:
>   - Patches 1-4 provide soc_device_match(), with some related fixes,
>   - Patches 5-7 implement identification of Renesas SoCs and
>     registration with the SoC bus,
>
> Changes compared to v1:
>   - Add Acked-by,
>   - New patches:
>       - "[4/7] base: soc: Provide a dummy implementation of
>                soc_device_match()",
>       - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>       - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>         (more similar patches available, I'm not yet spamming you all
>          with them),
>   - Drop SoC families and family names; use fixed "Renesas" instead,
>   - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>     devices with other SoCs,
>   - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>     M1A: not accessible from the ARM core?),
>   - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>     for SoCs that provide a chip ID register,
>   - Build renesas-soc only if SOC_BUS is enabled,
>   - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>     available, else fall back to hardcoded addresses for compatibility
>     with existing DTBs,
>   - Remove verification of product IDs; just print the ID instead,
>   - Don't register the SoC bus if the chip ID register is missing,
>   - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>     both).
>
> Merge strategy:
>   - In theory, patches 1-4 should go through Greg's driver core tree.
>     But it's a hard dependency for all users.
>     If people agree, I can provide an immutable branch in my
>     renesas-drivers repository, to be merged by all interested parties.
>     So far I'm aware of Freescale/NXP, and Renesas.

And Samsung.
Shall I create the immutable branch now?

Thanks!

>   - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>     merging the soc_device_match() core), and arm-soc.
>
> Tested on (machine, soc_id, optional revision):
>     EMEV2 KZM9D Board, emev2
>     Genmai, r7s72100
>     APE6EVM, r8a73a4, ES1.0
>     armadillo 800 eva, r8a7740, ES2.0
>     bockw, r8a7778
>     marzen, r8a7779, ES1.0
>     Lager, r8a7790, ES1.0
>     Koelsch, r8a7791, ES1.0
>     Porter, r8a7791, ES3.0
>     Blanche, r8a7792, ES1.1
>     Gose, r8a7793, ES1.0
>     Alt, r8a7794, ES1.0
>     Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>     Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>     Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>     KZM-A9-GT, sh73a0, ES2.0
>
> For your convenience, this series (incl. more DT updates to add device
> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> Its first user is support for R-Car H3 ES2.0 in branch
> topic/r8a7795-es2-v1-rebased2.
>
> Thanks for your comments!
>
> Arnd Bergmann (1):
>   base: soc: Introduce soc_device_match() interface
>
> Geert Uytterhoeven (6):
>   base: soc: Early register bus when needed
>   base: soc: Check for NULL SoC device attributes
>   base: soc: Provide a dummy implementation of soc_device_match()
>   ARM: shmobile: Document DT bindings for CCCR and PRR
>   arm64: dts: r8a7795: Add device node for PRR
>   soc: renesas: Identify SoC and register with the SoC bus
>
>  Documentation/devicetree/bindings/arm/shmobile.txt |  26 +++++
>  arch/arm/mach-shmobile/Kconfig                     |   3 +
>  arch/arm64/Kconfig.platforms                       |   1 +
>  arch/arm64/boot/dts/renesas/r8a7795.dtsi           |   5 +
>  drivers/base/Kconfig                               |   1 +
>  drivers/base/soc.c                                 |  79 +++++++++++++
>  drivers/soc/renesas/Makefile                       |   2 +
>  drivers/soc/renesas/renesas-soc.c                  | 130 +++++++++++++++++++++
>  include/linux/sys_soc.h                            |   9 ++
>  9 files changed, 256 insertions(+)
>  create mode 100644 drivers/soc/renesas/renesas-soc.c

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] | [prev] | [next] | [standalone]

#1516452 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On Mon, Nov 07, 2016 at 10:35:31AM +0100, Geert Uytterhoeven wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
> > Some Renesas SoCs may exist in different revisions, providing slightly
> > different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> > (errate and quirks).  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 7 patches:
> >   - Patches 1-4 provide soc_device_match(), with some related fixes,
> >   - Patches 5-7 implement identification of Renesas SoCs and
> >     registration with the SoC bus,
> >
> > Changes compared to v1:
> >   - Add Acked-by,
> >   - New patches:
> >       - "[4/7] base: soc: Provide a dummy implementation of
> >                soc_device_match()",
> >       - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
> >       - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
> >         (more similar patches available, I'm not yet spamming you all
> >          with them),
> >   - Drop SoC families and family names; use fixed "Renesas" instead,
> >   - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
> >     devices with other SoCs,
> >   - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
> >     M1A: not accessible from the ARM core?),
> >   - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
> >     for SoCs that provide a chip ID register,
> >   - Build renesas-soc only if SOC_BUS is enabled,
> >   - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >     available, else fall back to hardcoded addresses for compatibility
> >     with existing DTBs,
> >   - Remove verification of product IDs; just print the ID instead,
> >   - Don't register the SoC bus if the chip ID register is missing,
> >   - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
> >     both).
> >
> > Merge strategy:
> >   - In theory, patches 1-4 should go through Greg's driver core tree.
> >     But it's a hard dependency for all users.
> >     If people agree, I can provide an immutable branch in my
> >     renesas-drivers repository, to be merged by all interested parties.
> >     So far I'm aware of Freescale/NXP, and Renesas.
> 
> And Samsung.

Yes, I would need it as well.

> Shall I create the immutable branch now?

...or the applying person could provide one.

Best regards,
Krzysztof

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

#1518174 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd,

On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>> Some Renesas SoCs may exist in different revisions, providing slightly
>> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
>> (errate and quirks).  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 7 patches:
>>   - Patches 1-4 provide soc_device_match(), with some related fixes,
>>   - Patches 5-7 implement identification of Renesas SoCs and
>>     registration with the SoC bus,
>>
>> Changes compared to v1:
>>   - Add Acked-by,
>>   - New patches:
>>       - "[4/7] base: soc: Provide a dummy implementation of
>>                soc_device_match()",
>>       - "[5/7] ARM: shmobile: Document DT bindings for CCCR and PRR",
>>       - "[6/7] arm64: dts: r8a7795: Add device node for PRR"
>>         (more similar patches available, I'm not yet spamming you all
>>          with them),
>>   - Drop SoC families and family names; use fixed "Renesas" instead,
>>   - Drop EMEV2, which doesn't have a chip ID register, and doesn't share
>>     devices with other SoCs,
>>   - Drop RZ/A1H and R-CAR M1A, which don't have chip ID registers (for
>>     M1A: not accessible from the ARM core?),
>>   - On arm, move "select SOC_BUS" from ARCH_RENESAS to Kconfig symbols
>>     for SoCs that provide a chip ID register,
>>   - Build renesas-soc only if SOC_BUS is enabled,
>>   - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>>     available, else fall back to hardcoded addresses for compatibility
>>     with existing DTBs,
>>   - Remove verification of product IDs; just print the ID instead,
>>   - Don't register the SoC bus if the chip ID register is missing,
>>   - Change R-Mobile APE6 fallback to use PRR instead of CCCR (it has
>>     both).
>>
>> Merge strategy:
>>   - In theory, patches 1-4 should go through Greg's driver core tree.
>>     But it's a hard dependency for all users.
>>     If people agree, I can provide an immutable branch in my
>>     renesas-drivers repository, to be merged by all interested parties.
>>     So far I'm aware of Freescale/NXP, and Renesas.
>
> And Samsung.
> Shall I create the immutable branch now?

Arnd: are you happy with the new patches and changes?

Thanks again!

>>   - Patches 5-7 obviously have to go through Simon's Renesas tree (after
>>     merging the soc_device_match() core), and arm-soc.
>>
>> Tested on (machine, soc_id, optional revision):
>>     EMEV2 KZM9D Board, emev2
>>     Genmai, r7s72100
>>     APE6EVM, r8a73a4, ES1.0
>>     armadillo 800 eva, r8a7740, ES2.0
>>     bockw, r8a7778
>>     marzen, r8a7779, ES1.0
>>     Lager, r8a7790, ES1.0
>>     Koelsch, r8a7791, ES1.0
>>     Porter, r8a7791, ES3.0
>>     Blanche, r8a7792, ES1.1
>>     Gose, r8a7793, ES1.0
>>     Alt, r8a7794, ES1.0
>>     Renesas Salvator-X board based on r8a7795, r8a7795, ES1.0
>>     Renesas Salvator-X board based on r8a7795, r8a7795, ES1.1
>>     Renesas Salvator-X board based on r8a7796, r8a7796, ES1.0
>>     KZM-A9-GT, sh73a0, ES2.0
>>
>> For your convenience, this series (incl. more DT updates to add device
>> nodes for CCCR and PRR to all other Renesas ARM SoCs) is also available
>> in the topic/renesas-soc-id-v2 branch of my renesas-drivers git
>> repository at
>> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>> Its first user is support for R-Car H3 ES2.0 in branch
>> topic/r8a7795-es2-v1-rebased2.
>>
>> Thanks for your comments!
>>
>> Arnd Bergmann (1):
>>   base: soc: Introduce soc_device_match() interface
>>
>> Geert Uytterhoeven (6):
>>   base: soc: Early register bus when needed
>>   base: soc: Check for NULL SoC device attributes
>>   base: soc: Provide a dummy implementation of soc_device_match()
>>   ARM: shmobile: Document DT bindings for CCCR and PRR
>>   arm64: dts: r8a7795: Add device node for PRR
>>   soc: renesas: Identify SoC and register with the SoC bus

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] | [prev] | [next] | [standalone]

#1518309

On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >
> > And Samsung.
> > Shall I create the immutable branch now?
> 
> Arnd: are you happy with the new patches and changes?

I still had some comments for patch 7, but that shouldn't stop
you from creating a branch for the first three so everyone can
build on top of that.

	Arnd

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

#1518324 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd,

On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> > And Samsung.
>> > Shall I create the immutable branch now?
>>
>> Arnd: are you happy with the new patches and changes?
>
> I still had some comments for patch 7, but that shouldn't stop
> you from creating a branch for the first three so everyone can
> build on top of that.

Thanks!

What about patch [4/7]?
Haven't you received it? Your address was in the To-line for all 7 patches.

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] | [prev] | [next] | [standalone]

#1518485

On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
> >> > And Samsung.
> >> > Shall I create the immutable branch now?
> >>
> >> Arnd: are you happy with the new patches and changes?
> >
> > I still had some comments for patch 7, but that shouldn't stop
> > you from creating a branch for the first three so everyone can
> > build on top of that.
> 
> Thanks!
> 
> What about patch [4/7]?
> Haven't you received it? Your address was in the To-line for all 7 patches.

Ok, I see it now, looks good. That should be included as well then.

	Arnd

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

#1518787 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Ulf,

On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>> >> > And Samsung.
>> >> > Shall I create the immutable branch now?
>> >>
>> >> Arnd: are you happy with the new patches and changes?
>> >
>> > I still had some comments for patch 7, but that shouldn't stop
>> > you from creating a branch for the first three so everyone can
>> > build on top of that.
>>
>> Thanks!
>>
>> What about patch [4/7]?
>> Haven't you received it? Your address was in the To-line for all 7 patches.
>
> Ok, I see it now, looks good. That should be included as well then.

Thanks, I've created the branch/tag :

    git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
    branch soc-device-match
    signed tag soc-device-match-tag1

In the mean time, Ulf has applied the first two patches to mmc/next, on top
of lots of MMC work :-(

Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
but also for Samsung and Renesas, would it still be possible to replace these
two commits

    8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
    6fa350172b098f0f base: soc: Check for NULL SoC device attributes

by a merge of soc-device-match-tag1?

You can find more info in the full thread at
https://www.spinics.net/lists/devicetree/msg148558.html

Thanks!

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] | [prev] | [next] | [standalone]

#1518854 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
>     git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>     branch soc-device-match
>     signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(

No worries! :-)

>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
>     8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
>     6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?

Yes, I will take care of it during the day.

Kind regards
Uffe

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

#1518857 — Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
>     git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
>     branch soc-device-match
>     signed tag soc-device-match-tag1

Tested by kbuild test robot:

    https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
 soc-device-match
    da65a1589dacc7ec44ea0557a14d70a39d991f32  base: soc: Provide a
dummy implementation of soc_device_match()
    elapsed time: 101m
    configs tested: 85

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] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web