From: Boris Brezillon <boris.brezillon@collabora.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Vitor Soares <Vitor.Soares@synopsys.com>,
Jose Abreu <Jose.Abreu@synopsys.com>,
"corbet@lwn.net" <corbet@lwn.net>,
Joao Pinto <Joao.Pinto@synopsys.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"wsa@the-dreams.de" <wsa@the-dreams.de>,
"bbrezillon@kernel.org" <bbrezillon@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"broonie@kernel.org" <broonie@kernel.org>,
"linux-i3c@lists.infradead.org" <linux-i3c@lists.infradead.org>
Subject: Re: [PATCH v3 3/5] i3c: master: add i3c_for_each_dev helper
Date: Sat, 22 Feb 2020 09:38:44 +0100 [thread overview]
Message-ID: <20200222093844.2f5ed538@collabora.com> (raw)
In-Reply-To: <20200221174428.77696ab6@collabora.com>
On Fri, 21 Feb 2020 17:44:28 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Fri, 21 Feb 2020 13:59:11 +0100
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > On Fri, 21 Feb 2020 12:52:29 +0100
> > Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > > On Fri, Feb 21, 2020 at 11:47:22AM +0000, Vitor Soares wrote:
> > > > Hi Greg,
> > > >
> > > > From: Greg KH <gregkh@linuxfoundation.org>
> > > > Date: Wed, Feb 19, 2020 at 07:35:48
> > > >
> > > > > On Wed, Feb 19, 2020 at 01:20:41AM +0100, Vitor Soares wrote:
> > > > > > Introduce i3c_for_each_dev(), an i3c device iterator for use by i3cdev.
> > > > > >
> > > > > > Signed-off-by: Vitor Soares <vitor.soares@synopsys.com>
> > > > > > ---
> > > > > > drivers/i3c/internals.h | 1 +
> > > > > > drivers/i3c/master.c | 12 ++++++++++++
> > > > > > 2 files changed, 13 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
> > > > > > index bc062e8..a6deedf 100644
> > > > > > --- a/drivers/i3c/internals.h
> > > > > > +++ b/drivers/i3c/internals.h
> > > > > > @@ -24,4 +24,5 @@ int i3c_dev_enable_ibi_locked(struct i3c_dev_desc *dev);
> > > > > > int i3c_dev_request_ibi_locked(struct i3c_dev_desc *dev,
> > > > > > const struct i3c_ibi_setup *req);
> > > > > > void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev);
> > > > > > +int i3c_for_each_dev(void *data, int (*fn)(struct device *, void *));
> > > > > > #endif /* I3C_INTERNAL_H */
> > > > > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > > > > > index 21c4372..8e22da2 100644
> > > > > > --- a/drivers/i3c/master.c
> > > > > > +++ b/drivers/i3c/master.c
> > > > > > @@ -2640,6 +2640,18 @@ void i3c_dev_free_ibi_locked(struct i3c_dev_desc *dev)
> > > > > > dev->ibi = NULL;
> > > > > > }
> > > > > >
> > > > > > +int i3c_for_each_dev(void *data, int (*fn)(struct device *, void *))
> > > > > > +{
> > > > > > + int res;
> > > > > > +
> > > > > > + mutex_lock(&i3c_core_lock);
> > > > > > + res = bus_for_each_dev(&i3c_bus_type, NULL, data, fn);
> > > > > > + mutex_unlock(&i3c_core_lock);
> > > > >
> > > > > Ick, why the lock? Are you _sure_ you need that? The core should
> > > > > handle any list locking issues here, right?
> > > >
> > > > I want to make sure that no new devices (eg: Hot-Join capable device) are
> > > > added during this iteration and after this call, each new device will
> > > > release a bus notification.
> > > >
> > > > >
> > > > > I don't see bus-specific-locks around other subsystem functions that do
> > > > > this (like usb_for_each_dev).
> > > >
> > > > I based in I2C use case.
> > >
> > > Check to see if this is really needed, for some reason I doubt it...
> >
> > Can we please try the spidev approach before fixing those problems. None
> > of that would be needed if we declare the i3cdev driver as a regular
> > i3c_device_driver and let user space bind devices it wants to expose
> > through the sysfs interface. As I said earlier, we even have all the
> > pieces we need to automate that using a udev rule, and the resulting
> > patchset would be 'less invasive'/simpler for pretty much the same
> > result.
>
> So, I went ahead and implemented it the way I suggest. The diffstat is
> not representative here (though it's still in favor of this new version)
> since I also changed the way we expose/handle SDR transfers. What's
> most important IMO is the fact that
>
> * we no longer need to access the internal I3C API
> * we no longer need to care about transitions between i3cdev and
> other drivers (the core guarantees that a device is always bound to at
> most one driver)
> * the registration/unregistration procedure is simplified
Looks like I was wrong, there's no way to disable auto-binding and keep
manual binding possible (they both use the bus->match() hook to know if
a dev can be attached to a driver, and the type of binding is not
specified here). There are of course other options to do this:
* add a i3c_driver->match() hook and expose driver-specific sysfs knobs
to explicitly add devices to attach to this driver
* make the i3cdev module register one driver per-device, each time with
its own i3c_device_id table and add sysfs knobs to trigger this
registration
but none of these option sounds reasonable to me, so let's pursue with
your approach.
next prev parent reply other threads:[~2020-02-22 8:38 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 0:20 [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19 0:20 ` [PATCH v3 1/5] i3c: master: export i3c_masterdev_type Vitor Soares
2020-02-19 0:20 ` [PATCH v3 2/5] i3c: master: export i3c_bus_type symbol Vitor Soares
2020-02-19 0:20 ` [PATCH v3 3/5] i3c: master: add i3c_for_each_dev helper Vitor Soares
2020-02-19 7:35 ` Greg KH
2020-02-21 11:47 ` Vitor Soares
2020-02-21 11:52 ` Greg KH
2020-02-21 12:59 ` Boris Brezillon
2020-02-21 16:44 ` Boris Brezillon
2020-02-21 16:45 ` Boris Brezillon
2020-02-21 17:19 ` Vitor Soares
2020-02-22 8:38 ` Boris Brezillon [this message]
2020-02-19 0:20 ` [PATCH v3 4/5] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares
2020-02-19 7:37 ` Greg KH
2020-02-19 8:45 ` Vitor Soares
2020-02-19 7:39 ` Greg KH
2020-02-21 11:50 ` Vitor Soares
2020-02-19 8:42 ` Greg KH
2020-02-21 22:32 ` Boris Brezillon
2020-02-24 11:04 ` Vitor Soares
2020-02-24 11:22 ` Boris Brezillon
2020-02-19 0:20 ` [PATCH v3 5/5] add i3cdev documentation Vitor Soares
2020-02-19 0:46 ` Vitor Soares
2020-02-19 4:34 ` Randy Dunlap
2020-02-21 10:31 ` Vitor Soares
2020-02-21 15:36 ` Randy Dunlap
2020-02-19 0:39 ` [PATCH v3 0/5] Introduce i3c device userspace interface Vitor Soares
2020-02-19 8:16 ` Boris Brezillon
2020-02-21 17:08 ` Vitor Soares
2020-02-21 17:41 ` Boris Brezillon
2020-02-24 10:53 ` Vitor Soares
2020-02-24 11:24 ` Boris Brezillon
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=20200222093844.2f5ed538@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Joao.Pinto@synopsys.com \
--cc=Jose.Abreu@synopsys.com \
--cc=Vitor.Soares@synopsys.com \
--cc=arnd@arndb.de \
--cc=bbrezillon@kernel.org \
--cc=broonie@kernel.org \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-i3c@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wsa@the-dreams.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