From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: "Andreas Färber" <afaerber@suse.de>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"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>,
"open list:ARM/Amlogic Meson..."
<linux-amlogic@lists.infradead.org>,
"open list:TI ETHERNET SWITCH DRIVER (CPSW)"
<linux-omap@vger.kernel.org>,
"Alexander Sverdlin" <alexander.sverdlin@gmail.com>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
"Linux Kernel Mailing List" <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:58:18 +0100 [thread overview]
Message-ID: <CAMuHMdWOWWQoJh5=07VMRhtrFR_Gc_qNhjTV4tCsvwvMn0kYfA@mail.gmail.com> (raw)
In-Reply-To: <c8572f70-5550-8cee-4381-fd7de7ae5af0@baylibre.com>
Hi Neil,
On Fri, Nov 15, 2019 at 9:52 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
> 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.
We do our best to use it solely for detecting quirks in early SoC revisions.
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
next prev parent reply other threads:[~2019-11-15 8:58 UTC|newest]
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
2019-11-15 8:58 ` Geert Uytterhoeven [this message]
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='CAMuHMdWOWWQoJh5=07VMRhtrFR_Gc_qNhjTV4tCsvwvMn0kYfA@mail.gmail.com' \
--to=geert@linux-m68k.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=narmstrong@baylibre.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).