From: Neil Armstrong <narmstrong@baylibre.com> To: "Andreas Färber" <afaerber@suse.de>, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org> Cc: "Geert Uytterhoeven" <geert+renesas@glider.be>, linux-realtek-soc@lists.infradead.org, "Tony Lindgren" <tony@atomide.com>, "Linus Walleij" <linus.walleij@linaro.org>, "Bjorn Andersson" <bjorn.andersson@linaro.org>, "Thierry Reding" <thierry.reding@gmail.com>, "Lee Jones" <lee.jones@linaro.org>, "Rob Herring" <robh@kernel.org>, "Kevin Hilman" <khilman@baylibre.com>, "Rafael J. Wysocki" <rafael@kernel.org>, "Michal Simek" <michal.simek@xilinx.com>, "Jonathan Hunter" <jonathanh@nvidia.com>, "NXP Linux Team" <linux-imx@nxp.com>, "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>, boot-architecture@lists.linaro.org, "Sascha Hauer" <s.hauer@pengutronix.de>, "Fabio Estevam" <festevam@gmail.com>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org, "Alexander Sverdlin" <alexander.sverdlin@gmail.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Hartley Sweeten" <hsweeten@visionengravers.com>, "Pengutronix Kernel Team" <kernel@pengutronix.de>, "Shawn Guo" <shawnguo@kernel.org> Subject: Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Date: Fri, 15 Nov 2019 09:52:25 +0100 Message-ID: <c8572f70-5550-8cee-4381-fd7de7ae5af0@baylibre.com> (raw) In-Reply-To: <aff81b8e-f041-73a5-6a95-d308fa07842c@suse.de> On 12/11/2019 11:47, Andreas Färber wrote: > Am 12.11.19 um 08:29 schrieb Uwe Kleine-König: >> On Tue, Nov 12, 2019 at 06:23:47AM +0100, Greg Kroah-Hartman wrote: >>> On Mon, Nov 11, 2019 at 09:10:41PM +0100, Andreas Färber wrote: >>>> Am 11.11.19 um 07:40 schrieb Greg Kroah-Hartman: >>>>> On Mon, Nov 11, 2019 at 06:42:05AM +0100, Andreas Färber wrote: >>>>>> Am 11.11.19 um 06:27 schrieb Greg Kroah-Hartman: >>>>>>> On Mon, Nov 11, 2019 at 05:56:09AM +0100, Andreas Färber wrote: >>>>>>>> Use of soc_device_to_device() in driver modules causes a build failure. >>>>>>>> Given that the helper is nicely documented in include/linux/sys_soc.h, >>>>>>>> let's export it as GPL symbol. >>>>>>> >>>>>>> I thought we were fixing the soc drivers to not need this. What >>>>>>> happened to that effort? I thought I had patches in my tree (or >>>>>>> someone's tree) that did some of this work already, such that this >>>>>>> symbol isn't needed anymore. >>>>>> >>>>>> I do still see this function used in next-20191108 in drivers/soc/. >>>>>> >>>>>> I'll be happy to adjust my RFC driver if someone points me to how! >>>>> >>>>> Look at c31e73121f4c ("base: soc: Handle custom soc information sysfs >>>>> entries") for how you can just use the default attributes for the soc to >>>>> create the needed sysfs files, instead of having to do it "by hand" >>>>> which is racy and incorrect. >>>> >>>> Unrelated. >>>> >>>>>> Given the current struct layout, a type cast might work (but ugly). >>>>>> Or if we stay with my current RFC driver design, we could use the >>>>>> platform_device instead of the soc_device (which would clutter the >>>>>> screen more than "soc soc0:") or resort to pr_info() w/o device. >>>>> >>>>> Ick, no, don't cast blindly. What do you need the pointer for? Is this >>>>> for in-tree code? >>>> >>>> No, an RFC patchset: https://patchwork.kernel.org/cover/11224261/ >>>> >>>> As I indicated above, I used it for a dev_info(), which I can easily >>>> avoid by using pr_info() instead: >>>> >>>> diff --git a/drivers/soc/realtek/chip.c b/drivers/soc/realtek/chip.c >>>> index e5078c6731fd..f9380e831659 100644 >>>> --- a/drivers/soc/realtek/chip.c >>>> +++ b/drivers/soc/realtek/chip.c >>>> @@ -178,8 +178,7 @@ static int rtd_soc_probe(struct platform_device *pdev) >>>> >>>> platform_set_drvdata(pdev, soc_dev); >>>> >>>> - dev_info(soc_device_to_device(soc_dev), >>>> - "%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> + pr_info("%s %s (0x%08x) rev %s (0x%08x) detected\n", >>>> soc_dev_attr->family, soc_dev_attr->soc_id, chip_id, >>>> soc_dev_attr->revision, chip_rev); >>> >>> First off, the driver should not be spitting out noise for when all goes >>> well like this :) >> >> I didn't follow the discussion closely, but I think I want to object >> here a bit. While I agree that each driver emitting some stuff to the >> log buffer is hardly helpful, seeing the exact SoC details is indeed >> useful at times. With my Debian kernel team member hat on, I'd say >> keep this information. This way the SoC details make it into kernel bug >> reports without effort on our side. > > Seconded. For example, RTD1295 will support LSADC only from revision B00 > on (and it's not the first time I'm seeing such things in the industry). > So if a user complains, it will be helpful to see that information. > > Referencing your Amlogic review, with all due respect for its authors, > the common framework here just lets that information evaporate into the > deeps of sysfs. Hopefully we never had the case where needed to use the soc info in drivers, but now we have one and having such infrastructure already in-place will help. Renesas platforms makes a extensive usage of the soc info infrastructure to figure out plenty of HW parameters at runtime and lower their DT changes. Neil > People who know can check /sys/bus/soc/devices/soc0, but > ordinary users will at most upload dmesg output to a Bugzilla ticket. > > And it was precisely info-level boot output from the Amlogic GX driver > that made me aware of this common framework and inspired me to later > contribute such a driver elsewhere myself. That's not a bad effect. ;) > > So if anything, we should standardize that output and move it into > soc_device_register(): "<family> <soc_id> [rev <revision>] detected" > with suitable NULL checks? (what I did above for Realtek, minus hex) > > The info level seems correct to me - it allows people to use a different > log_level if they only care about warnings or errors on the console; > it's not debug info for that driver, except in my case the accompanying > hex numbers that I'd be happy to drop in favor of standardization. > > Another aspect here is that the overall amount of soc_device_register() > users is just an estimated one third above the analysis shared before. > In particular server platforms, be it arm64 or x86_64, that potentially > have more than one SoC integrated in a multi-socket configuration, don't > feed into this soc bus at all! Therefore my comment that > dev_info()-printed "soc soc0:" is kind of useless if there's only one > SoC on those boards. I'm not aware of any tool or a more common file > aggregating this information, certainly not /proc/cpuinfo and I'm not > aware of any special "lssoc" tool either. And if there's no ACPI/DMI > driver feeding support-relevant information into this framework to be > generally useful, I don't expect the big distros to spend time on > improving its usability. > > So if we move info output into base/soc.c, we could continue using > dev_info() with "soc"-grep'able prefix in the hopes that someday we'll > have more than one soc device on the bus and will need to distinguish; > otherwise yes, pr_info() would change the output format for Amlogic (and > so would a harmonization of the text), but does anyone really care in > practice? Tools shouldn't be relying on its output format, and humans > will understand equally either way. > > Finally, arch/arm seems unique in that it has the machine_desc mechanism > that allows individual SoCs to force creating their soc_device early and > using it as parent for further DT-created platform_devices. With arm64 > we've lost that ability, and nios2 is not using it either. > A bad side effect (with SUSE hat on) is that this parent design pattern > does not allow to build such drivers as modules, which means that distro > configs using arm's multi-platform, e.g., CONFIG_ARCH_MULTI_V7 will get > unnecessary code creep as new platforms get added over time (beyond the > basic clk, pinctrl, tty and maybe timer). > Even if it were possible to call into a driver module that early, using > it as parent would seem to imply that all the references by its children > would not allow to unload the module, which I'd consider a flawed design > for such an "optional" read-once driver. If we want the device hierarchy > to have a soc root then most DT based platforms will have a /soc DT node > anyway (although no device_type = "soc") that we probably could have a > device registered for in common code rather than each SoC platform > handling that differently? That might then make soc_register_device() > not the creator of the device (if pre-existent) but the supplier of data > to that core device, which should then allow to unload the data provider > with just the sysfs data disappearing until re-inserted (speeding up the > develop-and-test cycle on say not-so-resource-constrained platforms). > > On the other hand, one might argue that such information should just be > parsed by EBBR-conformant bootloaders and be passed to the kernel via > standard UEFI interfaces and DMI tables. But I'm not aware of Barebox > having implemented any of that yet, and even for U-Boot (e.g., Realtek > based consumer devices...) not everyone has the GPL sources or tools to > update their bootloader. So, having the kernel we control gather > information relevant to kernel developers does make some sense to me. > > Thoughts? > > Regards, > Andreas > > P.S. Sorry that a seemingly trivial one-line 0-day fix derailed into > this fundamental use case discussion. > > arch/arm/mach-ep93xx/core.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-imx/cpu.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-mvebu/mvebu-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > arch/arm/mach-mxs/mach-mxs.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-omap2/id.c: soc_dev = soc_device_register(soc_dev_attr); > arch/arm/mach-tegra/tegra.c: struct device *parent = > tegra_soc_device_register(); > arch/arm/mach-zynq/common.c: soc_dev = soc_device_register(soc_dev_attr); > arch/nios2/platform/platform.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-gx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/amlogic/meson-mx-socinfo.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/atmel/soc.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/bcm/brcmstb/common.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/fsl/guts.c: soc_dev = soc_device_register(&soc_dev_attr); > drivers/soc/imx/soc-imx-scu.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/imx/soc-imx8.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/qcom/socinfo.c: qs->soc_dev = > soc_device_register(&qs->attr); > drivers/soc/realtek/chip.c: soc_dev = soc_device_register(soc_dev_attr); > drivers/soc/renesas/renesas-soc.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/samsung/exynos-chipid.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/tegra/fuse/fuse-tegra.c: dev = soc_device_register(attr); > drivers/soc/ux500/ux500-soc-id.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-integrator.c: soc_dev = > soc_device_register(soc_dev_attr); > drivers/soc/versatile/soc-realview.c: soc_dev = > soc_device_register(soc_dev_attr); >
next prev parent reply index Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-03 1:36 [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber 2019-11-03 1:36 ` [RFC 01/11] dt-bindings: soc: Add Realtek RTD1195 chip info binding Andreas Färber 2019-11-06 4:41 ` Rob Herring 2019-11-03 1:36 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 Andreas Färber 2019-11-03 1:45 ` Andreas Färber 2019-11-11 4:56 ` [PATCH] base: soc: Export soc_device_to_device() helper Andreas Färber 2019-11-11 5:27 ` Greg Kroah-Hartman 2019-11-11 5:42 ` Andreas Färber 2019-11-11 6:40 ` Greg Kroah-Hartman 2019-11-11 20:10 ` Andreas Färber 2019-11-12 0:29 ` Andreas Färber 2019-11-12 5:23 ` Greg Kroah-Hartman 2019-11-12 7:29 ` Uwe Kleine-König 2019-11-12 10:47 ` Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper) Andreas Färber 2019-11-14 22:09 ` Rob Herring 2019-11-15 11:15 ` Andreas Färber 2019-11-15 11:49 ` Andreas Färber 2019-11-15 8:52 ` Neil Armstrong [this message] 2019-11-15 8:58 ` Geert Uytterhoeven 2019-11-15 12:00 ` Andreas Färber 2019-11-15 12:34 ` Geert Uytterhoeven 2019-11-18 15:55 ` Tony Lindgren 2019-11-12 10:48 ` [PATCH] base: soc: Export soc_device_to_device() helper Lee Jones 2020-01-02 14:29 ` [RFC 02/11] soc: Add Realtek chip info driver for RTD1195 and RTD1295 James Tai 2020-01-02 14:39 ` Andreas Färber 2020-01-02 15:02 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2019-11-03 1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber 2020-01-02 14:32 ` James Tai 2020-01-03 5:07 ` Stanley Chang[昌育德] 2020-01-02 14:33 ` James Tai 2020-01-02 14:34 ` James Tai 2019-11-03 1:36 ` [RFC 04/11] ARM: dts: rtd1195: " Andreas Färber 2019-11-03 1:36 ` [RFC 05/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg property Andreas Färber 2019-11-06 4:46 ` Rob Herring 2019-11-06 8:42 ` Andreas Färber 2019-11-03 1:36 ` [RFC 06/11] soc: realtek: chip: Detect RTD1296 Andreas Färber 2020-01-02 14:35 ` James Tai 2019-11-03 1:36 ` [RFC 07/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with CHIP_INFO1 Andreas Färber 2019-11-03 1:36 ` [RFC 08/11] soc: realtek: chip: Detect RTD1293 Andreas Färber 2019-11-03 1:36 ` [RFC 09/11] dt-bindings: soc: realtek: rtd1195-chip: Extend reg node again Andreas Färber 2019-11-03 1:36 ` [RFC 10/11] soc: realtek: chip: Detect RTD1294 Andreas Färber 2019-11-03 1:36 ` [RFC 11/11] arm64: dts: realtek: rtd129x: Extend chip-info reg with efuse Andreas Färber 2019-11-07 7:16 ` [RFC 00/11] ARM: Realtek RTD1195/RTD1295 SoC info Andreas Färber
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c8572f70-5550-8cee-4381-fd7de7ae5af0@baylibre.com \ --to=narmstrong@baylibre.com \ --cc=afaerber@suse.de \ --cc=alexander.sverdlin@gmail.com \ --cc=bjorn.andersson@linaro.org \ --cc=boot-architecture@lists.linaro.org \ --cc=festevam@gmail.com \ --cc=geert+renesas@glider.be \ --cc=gregkh@linuxfoundation.org \ --cc=hsweeten@visionengravers.com \ --cc=jonathanh@nvidia.com \ --cc=kernel@pengutronix.de \ --cc=khilman@baylibre.com \ --cc=lee.jones@linaro.org \ --cc=linus.walleij@linaro.org \ --cc=linux-amlogic@lists.infradead.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=linux-realtek-soc@lists.infradead.org \ --cc=linux-tegra@vger.kernel.org \ --cc=michal.simek@xilinx.com \ --cc=rafael@kernel.org \ --cc=robh@kernel.org \ --cc=s.hauer@pengutronix.de \ --cc=shawnguo@kernel.org \ --cc=thierry.reding@gmail.com \ --cc=tony@atomide.com \ --cc=u.kleine-koenig@pengutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ linux-kernel@vger.kernel.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git