From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Richard Gong <richard.gong@linux.intel.com>,
Johan Hovold <johan@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
Romain Izard <romain.izard.pro@gmail.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mans Rullgard <mans@mansr.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH 01/12 v2] Platform: add a dev_groups pointer to struct platform_driver
Date: Thu, 25 Jul 2019 22:13:26 +0300 [thread overview]
Message-ID: <20190725191326.GA884@penguin> (raw)
In-Reply-To: <20190725190443.GA8877@kroah.com>
On Thu, Jul 25, 2019 at 09:04:43PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 25, 2019 at 02:02:03PM -0500, Richard Gong wrote:
> > Hi Greg,
> >
> > On 7/25/19 8:44 AM, Greg Kroah-Hartman wrote:
> > > On Sat, Jul 20, 2019 at 07:38:57AM +0300, Dmitry Torokhov wrote:
> > > > On Fri, Jul 19, 2019 at 08:52:20PM +0900, Greg Kroah-Hartman wrote:
> > > > > On Sat, Jul 06, 2019 at 10:39:38AM -0700, Dmitry Torokhov wrote:
> > > > > > On Sat, Jul 6, 2019 at 10:19 AM Greg Kroah-Hartman
> > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > >
> > > > > > > On Sat, Jul 06, 2019 at 10:04:39AM -0700, Dmitry Torokhov wrote:
> > > > > > > > Hi Greg,
> > > > > > > >
> > > > > > > > On Sat, Jul 6, 2019 at 1:32 AM Greg Kroah-Hartman
> > > > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Jul 04, 2019 at 02:17:22PM -0700, Dmitry Torokhov wrote:
> > > > > > > > > > Hi Greg,
> > > > > > > > > >
> > > > > > > > > > On Thu, Jul 4, 2019 at 5:15 AM Greg Kroah-Hartman
> > > > > > > > > > <gregkh@linuxfoundation.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Platform drivers like to add sysfs groups to their device, but right now
> > > > > > > > > > > they have to do it "by hand". The driver core should handle this for
> > > > > > > > > > > them, but there is no way to get to the bus-default attribute groups as
> > > > > > > > > > > all platform devices are "special and unique" one-off drivers/devices.
> > > > > > > > > > >
> > > > > > > > > > > To combat this, add a dev_groups pointer to platform_driver which allows
> > > > > > > > > > > a platform driver to set up a list of default attributes that will be
> > > > > > > > > > > properly created and removed by the platform driver core when a probe()
> > > > > > > > > > > function is successful and removed right before the device is unbound.
> > > > > > > > > >
> > > > > > > > > > Why is this limited to platform bus? Drivers for other buses also
> > > > > > > > > > often want to augment list of their attributes during probe(). I'd
> > > > > > > > > > move it to generic probe handling.
> > > > > > > > >
> > > > > > > > > This is not limited to the platform at all, the driver core supports
> > > > > > > > > this for any bus type today, but it's then up to the bus-specific code
> > > > > > > > > to pass that on to the driver core. That's usually set for the
> > > > > > > > > bus-specific attributes that they want exposed for all devices of that
> > > > > > > > > bus type (see the bus_groups, dev_groups, and drv_groups pointers in
> > > > > > > > > struct bus_type).
> > > > > > > > >
> > > > > > > > > For the platform devices, the problem is that this is something that the
> > > > > > > > > individual drivers want after they bind to the device. And as all
> > > > > > > > > platform devices are "different" they can't be a "common" set of
> > > > > > > > > attributes, so they need to be created after the device is bound to the
> > > > > > > > > driver.
> > > > > > > >
> > > > > > > > I believe that your assertion that only platform devices want to
> > > > > > > > install custom attributes is incorrect.
> > > > > > >
> > > > > > > Sorry, I didn't mean to imply that only platform drivers want to do
> > > > > > > this, as you say, many other drivers do as well.
> > > > > > >
> > > > > > > > Drivers for devices attached
> > > > > > > > to serio, i2c, USB, spi, etc, etc, all have additional attributes:
> > > > > > > >
> > > > > > > > dtor@dtor-ws:~/kernel/work (master *)$ grep -l '\(i2c\|usb\|spi\)'
> > > > > > > > `git grep -l '\(device_add_group\|sysfs_create_group\)' -- drivers` |
> > > > > > > > wc -l
> > > > > > > > 170
> > > > > > > >
> > > > > > > > I am pretty sure some of this count is false positives, but majority
> > > > > > > > is actually proper hits.
> > > > > > >
> > > > > > > Yeah, I know, we need to add this type of functionality to those busses
> > > > > > > as well. I don't see a way of doing it other than this bus-by-bus
> > > > > > > conversion, do you?
> > > > > >
> > > > > > Can't you push the **dev_groups from platform driver down to the
> > > > > > generic driver structure and handle them in driver_sysfs_add()?
> > > > >
> > > > > Sorry for the delay, got busy with the merge window...
> > > > >
> > > > > Anyway, no, we can't call this then, because driver_sysfs_add() is
> > > > > called before probe() is called. So if probe() fails, we don't bind the
> > > > > device to the driver. We also should not be creating sysfs files for a
> > > > > driver that has not had probe() called yet, as internal structures will
> > > > > not be set up at that time.
> > > >
> > > > Ah, yes, I got confused by the fact that driver_sysfs_remove is called
> > > > early. Anyway, I think you want something like this:
> > >
> > > Ah, nice, this looks good. Let me try this and see how it goes...
> > >
> >
> > I tried Dmitry's patch on Intel Stratix10 platform and it works.
> >
> > I added one minor change on the top of Dmitry's patch, since I think we need
> > add one additional check prior to device_add_groups(). To align with
> > Dmitry's patch, I also change my code to use the new dev_groups pointer in
> > the struct of device_driver.
>
> Thanks for testing!
>
> > My changes are below,
>
> <snip>
>
> > --- a/drivers/firmware/stratix10-rsu.c
> > +++ b/drivers/firmware/stratix10-rsu.c
> > @@ -391,9 +391,9 @@ static int stratix10_rsu_remove(struct platform_device
> > *pdev)
> > static struct platform_driver stratix10_rsu_driver = {
> > .probe = stratix10_rsu_probe,
> > .remove = stratix10_rsu_remove,
> > .driver = {
> > .name = "stratix10-rsu",
> > + .dev_groups = rsu_groups,
>
> I'd prefer to leave the dev_groups in the platform driver code, as no
> one should have to do this crazy "sub structure definition" that
> platform drivers seem to love to do.
Heh.
dtor@penguin:~/kernel/work $ git grep -A15 "static struct spi_driver" --
drivers/ | grep "\.driver.*=" | wc -l
272
You will find the similar counts for i2c, and other buses, mostly
because we need to specify driver name, OF/ACPI match tables, and
pointer to PM ops.
So please just keep it in the generic driver structure.
Thanks.
--
Dmitry
next prev parent reply other threads:[~2019-07-25 19:13 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-04 8:46 [PATCH 00/11] Platform drivers, provide a way to add sysfs groups easily Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 01/11] Platform: add a dev_groups pointer to struct platform_driver Greg Kroah-Hartman
2019-07-04 9:32 ` Johan Hovold
2019-07-04 10:43 ` Greg Kroah-Hartman
2019-07-04 12:11 ` [PATCH 01/12 v2] " Greg Kroah-Hartman
2019-07-04 21:17 ` Dmitry Torokhov
2019-07-06 8:32 ` Greg Kroah-Hartman
2019-07-06 17:04 ` Dmitry Torokhov
2019-07-06 17:19 ` Greg Kroah-Hartman
2019-07-06 17:39 ` Dmitry Torokhov
2019-07-19 11:52 ` Greg Kroah-Hartman
2019-07-20 4:38 ` Dmitry Torokhov
2019-07-25 13:44 ` Greg Kroah-Hartman
2019-07-25 19:02 ` Richard Gong
2019-07-25 19:04 ` Greg Kroah-Hartman
2019-07-25 19:13 ` Dmitry Torokhov [this message]
2019-07-25 19:18 ` Dmitry Torokhov
2019-07-04 8:46 ` [PATCH 02/11] uio: uio_fsl_elbc_gpcm: convert platform driver to use dev_groups Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 03/11] serial: sh-sci: use driver core functions, not sysfs ones Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 04/11] firmware: arm_scpi: convert platform driver to use dev_groups Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 9:10 ` Sudeep Holla
2019-07-04 9:10 ` Sudeep Holla
2019-07-31 12:28 ` Greg Kroah-Hartman
2019-07-31 12:28 ` Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 05/11] olpc: x01: " Greg Kroah-Hartman
2019-07-04 13:28 ` Andy Shevchenko
2019-07-04 8:46 ` [PATCH 06/11] platform: x86: hp-wmi: " Greg Kroah-Hartman
2019-07-04 13:29 ` Andy Shevchenko
2019-07-04 8:46 ` [PATCH 07/11] video: fbdev: wm8505fb: " Greg Kroah-Hartman
2019-07-04 13:29 ` Andy Shevchenko
2019-07-04 14:25 ` Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 08/11] video: fbdev: w100fb: " Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-04 8:46 ` [PATCH 09/11] video: fbdev: sm501fb: " Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:01 ` Bartlomiej Zolnierkiewicz
2019-07-04 8:46 ` [PATCH 10/11] input: keyboard: gpio_keys: " Greg Kroah-Hartman
2019-07-04 8:46 ` Greg Kroah-Hartman
2019-07-04 8:46 ` [PATCH 11/11] input: axp20x-pek: " Greg Kroah-Hartman
2019-07-04 14:26 ` [PATCH 07/11] video: fbdev: wm8505fb: " Greg Kroah-Hartman
2019-07-04 14:26 ` Greg Kroah-Hartman
2019-07-04 14:26 ` Greg Kroah-Hartman
2019-07-05 15:00 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:00 ` Bartlomiej Zolnierkiewicz
2019-07-05 15:00 ` Bartlomiej Zolnierkiewicz
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=20190725191326.GA884@penguin \
--to=dmitry.torokhov@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mans@mansr.com \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=richard.gong@linux.intel.com \
--cc=romain.izard.pro@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.