LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Rob Herring <robh@kernel.org>
To: "Andreas Färber" <afaerber@suse.de>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"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>,
	"Fabio Estevam" <festevam@gmail.com>,
	"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>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"open list:ARM/Amlogic Meson..."
	<linux-amlogic@lists.infradead.org>,
	"Lee Jones" <lee.jones@linaro.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	"Alexander Sverdlin" <alexander.sverdlin@gmail.com>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Hartley Sweeten" <hsweeten@visionengravers.com>,
	"Pengutronix Kernel Team" <kernel@pengutronix.de>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Architecture Mailman List" <boot-architecture@lists.linaro.org>
Subject: Re: Sense of soc bus? (was: [PATCH] base: soc: Export soc_device_to_device() helper)
Date: Thu, 14 Nov 2019 16:09:28 -0600
Message-ID: <CAL_JsqLr=fw6zxa=69rtgZ4oxzdw=cVDr3km5ya0pRGsNT1xLw@mail.gmail.com> (raw)
In-Reply-To: <aff81b8e-f041-73a5-6a95-d308fa07842c@suse.de>

On Tue, Nov 12, 2019 at 4:47 AM Andreas Färber <afaerber@suse.de> 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. 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.

lshw? That works with info from DT, sysfs, and DMI. It did have some
endian bugs (written for sparc/power) last time I looked at it 5+
years ago.

> 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).

I for one would like to for this to be consistent. Either we always
have an SoC device parent or never. I wouldn't decide based on having
a DT node or not either. Generally, we should always have MMIO devices
under a bus node and perhaps more than one, but that doesn't always
happen. I think building the drivers as modules is a good reason to do
away with the parent device.

It would also allow getting rid of remaining
of_platform_default_populate calls in arm platforms except for auxdata
cases. Pretty much that's the ones you list below in arch/arm/.

> 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.

UEFI and DMI are orthogonal, right. You can't expect DMI on a UEFI+DT system.

Rob

>
> 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);
>
> --
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer
> HRB 36809 (AG Nürnberg)

  reply index

Thread overview: 35+ 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 [this message]
2019-11-15 11:15                     ` Andreas Färber
2019-11-15 11:49                     ` Andreas Färber
2019-11-15  8:52                   ` Neil Armstrong
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
2019-11-03  1:36 ` [RFC 03/11] arm64: dts: realtek: rtd129x: Add chip info node Andreas Färber
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
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 publically 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='CAL_JsqLr=fw6zxa=69rtgZ4oxzdw=cVDr3km5ya0pRGsNT1xLw@mail.gmail.com' \
    --to=robh@kernel.org \
    --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=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

	# 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