| Message ID | 3a8e2822e1351c0ef8f9dd1c3e81cd5bfeb319e5.1424931398.git.horms+renesas@verge.net.au (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 3a8e2822e1351c0ef8f9dd1c3e81cd5bfeb319e5 |
| Headers | show |
On Thursday 26 February 2015 15:22:44 Simon Horman wrote: > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > This provides information through SOC_BUS to sysfs. > And this moves all on-SoC devices from /sys/devices/platform to > /sys/devices/socX/. > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > --- > arch/arm/mach-shmobile/Kconfig | 1 + > arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++---- > 2 files changed, 35 insertions(+), 4 deletions(-) I think this would be better done as a standalone driver in drivers/soc, to avoid having to add the init_machine callbacks in patch 3. > void __init rcar_gen2_init_machine(void) > { > - system_rev = rcar_gen2_get_cut(); > + struct soc_device_attribute *soc_dev_attr; > + struct soc_device *soc_dev; > + struct device *parent = NULL; > + u32 prr; > + > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); > + if (!soc_dev_attr) > + goto out; > + > + prr = rcar_gen2_get_prr(); > + system_rev = (prr & 0xFF) + 0x10; > + > + soc_dev_attr->machine = of_flat_dt_get_machine_name(); I would not duplicate that information here. Can you find out the SoC name from registers and put it here? ARnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote: > On Thursday 26 February 2015 15:22:44 Simon Horman wrote: > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > > > This provides information through SOC_BUS to sysfs. > > And this moves all on-SoC devices from /sys/devices/platform to > > /sys/devices/socX/. > > > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > --- > > arch/arm/mach-shmobile/Kconfig | 1 + > > arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++---- > > 2 files changed, 35 insertions(+), 4 deletions(-) > > I think this would be better done as a standalone driver in drivers/soc, > to avoid having to add the init_machine callbacks in patch 3. Could we handle this as follow-up work? > > void __init rcar_gen2_init_machine(void) > > { > > - system_rev = rcar_gen2_get_cut(); > > + struct soc_device_attribute *soc_dev_attr; > > + struct soc_device *soc_dev; > > + struct device *parent = NULL; > > + u32 prr; > > + > > + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); > > + if (!soc_dev_attr) > > + goto out; > > + > > + prr = rcar_gen2_get_prr(); > > + system_rev = (prr & 0xFF) + 0x10; > > + > > + soc_dev_attr->machine = of_flat_dt_get_machine_name(); > > I would not duplicate that information here. Can you find out the SoC > name from registers and put it here? > > ARnd > -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 27 February 2015 09:52:23 Simon Horman wrote: > > On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote: > > On Thursday 26 February 2015 15:22:44 Simon Horman wrote: > > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > > > > > This provides information through SOC_BUS to sysfs. > > > And this moves all on-SoC devices from /sys/devices/platform to > > > /sys/devices/socX/. > > > > > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > > --- > > > arch/arm/mach-shmobile/Kconfig | 1 + > > > arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++---- > > > 2 files changed, 35 insertions(+), 4 deletions(-) > > > > I think this would be better done as a standalone driver in drivers/soc, > > to avoid having to add the init_machine callbacks in patch 3. > > Could we handle this as follow-up work? That was my first idea when I looked at patch 3, but then I had the other comment below: > I would not duplicate that information here. Can you find out the SoC > name from registers and put it here? We must not introduce the user interface in one kernel and then change it in the next one, so I'm cautious about taking the pull request in the current form. Once we have agreed on what the contents of the sysfs files should be, I can take the patches, and then we are free to move the implementation later. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Arnd, On Fri, Feb 27, 2015 at 10:00 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Friday 27 February 2015 09:52:23 Simon Horman wrote: >> >> On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote: >> > On Thursday 26 February 2015 15:22:44 Simon Horman wrote: >> > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> >> > > >> > > This provides information through SOC_BUS to sysfs. >> > > And this moves all on-SoC devices from /sys/devices/platform to >> > > /sys/devices/socX/. >> > > >> > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> >> > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> >> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> >> > > --- >> > > arch/arm/mach-shmobile/Kconfig | 1 + >> > > arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++---- >> > > 2 files changed, 35 insertions(+), 4 deletions(-) >> > >> > I think this would be better done as a standalone driver in drivers/soc, >> > to avoid having to add the init_machine callbacks in patch 3. >> >> Could we handle this as follow-up work? > > That was my first idea when I looked at patch 3, but then I had the other > comment below: > >> > > + soc_dev_attr->machine = of_flat_dt_get_machine_name(); >> I would not duplicate that information here. Can you find out the SoC >> name from registers and put it here? > > We must not introduce the user interface in one kernel and then change > it in the next one, so I'm cautious about taking the pull request in > the current form. Once we have agreed on what the contents of the sysfs > files should be, I can take the patches, and then we are free to move > the implementation later. Currently machine contains e.g. "Koelsch", which is the name of the board, not of the SoC. We can derive the SoC name from soc_id, e.g. 0x47 = "R-Car M2-W". 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 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 27 February 2015 11:41:04 Geert Uytterhoeven wrote: > > We must not introduce the user interface in one kernel and then change > > it in the next one, so I'm cautious about taking the pull request in > > the current form. Once we have agreed on what the contents of the sysfs > > files should be, I can take the patches, and then we are free to move > > the implementation later. > > Currently machine contains e.g. "Koelsch", which is the name of the board, > not of the SoC. > > We can derive the SoC name from soc_id, e.g. 0x47 = "R-Car M2-W". > Yes, I think that would be best. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Feb 27, 2015 at 10:00:04AM +0100, Arnd Bergmann wrote: > On Friday 27 February 2015 09:52:23 Simon Horman wrote: > > > > On Thu, Feb 26, 2015 at 04:53:39PM +0100, Arnd Bergmann wrote: > > > On Thursday 26 February 2015 15:22:44 Simon Horman wrote: > > > > From: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > > > > > > > This provides information through SOC_BUS to sysfs. > > > > And this moves all on-SoC devices from /sys/devices/platform to > > > > /sys/devices/socX/. > > > > > > > > Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> > > > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> > > > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > > > --- > > > > arch/arm/mach-shmobile/Kconfig | 1 + > > > > arch/arm/mach-shmobile/setup-rcar-gen2.c | 38 ++++++++++++++++++++++++++++---- > > > > 2 files changed, 35 insertions(+), 4 deletions(-) > > > > > > I think this would be better done as a standalone driver in drivers/soc, > > > to avoid having to add the init_machine callbacks in patch 3. > > > > Could we handle this as follow-up work? > > That was my first idea when I looked at patch 3, but then I had the other > comment below: > > > I would not duplicate that information here. Can you find out the SoC > > name from registers and put it here? > > We must not introduce the user interface in one kernel and then change > it in the next one, so I'm cautious about taking the pull request in > the current form. Once we have agreed on what the contents of the sysfs > files should be, I can take the patches, and then we are free to move > the implementation later. Thanks for the clarification. Accordingly I'd like to withdraw this pull request: I will drop these patches. -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 2f36c85..a7f5ab5 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -19,6 +19,7 @@ config ARCH_RCAR_GEN2 bool select PM_RCAR if PM || SMP select RENESAS_IRQC + select SOC_BUS select SYS_SUPPORTS_SH_CMT select PCI_DOMAINS if PCI diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c b/arch/arm/mach-shmobile/setup-rcar-gen2.c index 6f290a8..9cc2a90 100644 --- a/arch/arm/mach-shmobile/setup-rcar-gen2.c +++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c @@ -26,6 +26,8 @@ #include <linux/of.h> #include <linux/of_fdt.h> #include <linux/of_platform.h> +#include <linux/slab.h> +#include <linux/sys_soc.h> #include <asm/system_info.h> #include <asm/mach/arch.h> #include "common.h" @@ -206,19 +208,47 @@ void __init rcar_gen2_reserve(void) } #define PRR 0xFF000044 -static unsigned int __init rcar_gen2_get_cut(void) +static u32 __init rcar_gen2_get_prr(void) { void __iomem *addr = ioremap_nocache(PRR, 4); u32 data = ioread32(addr); iounmap(addr); - return (data & 0xFF) + 0x10; + return data; } void __init rcar_gen2_init_machine(void) { - system_rev = rcar_gen2_get_cut(); + struct soc_device_attribute *soc_dev_attr; + struct soc_device *soc_dev; + struct device *parent = NULL; + u32 prr; + + soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL); + if (!soc_dev_attr) + goto out; + + prr = rcar_gen2_get_prr(); + system_rev = (prr & 0xFF) + 0x10; + + soc_dev_attr->machine = of_flat_dt_get_machine_name(); + soc_dev_attr->family = kasprintf(GFP_KERNEL, "Renesas R-Car Gen2"); + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "%u.%u", + system_rev >> 4, system_rev & 0xF); + soc_dev_attr->soc_id = kasprintf(GFP_KERNEL, "%04x", + (prr & 0x7F00) >> 8); + + soc_dev = soc_device_register(soc_dev_attr); + if (IS_ERR(soc_dev)) { + kfree(soc_dev_attr->family); + kfree(soc_dev_attr->revision); + kfree(soc_dev_attr->soc_id); + kfree(soc_dev_attr); + goto out; + } - of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); + parent = soc_device_to_device(soc_dev); +out: + of_platform_populate(NULL, of_default_bus_match_table, NULL, parent); }