From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vitor Soares <Vitor.Soares@synopsys.com>
Cc: Jose.Abreu@synopsys.com, Joao.Pinto@synopsys.com, arnd@arndb.de,
bbrezillon@kernel.org, gregkh@linuxfoundation.org,
wsa@the-dreams.de, linux-kernel@vger.kernel.org,
broonie@kernel.org, linux-i3c@lists.infradead.org
Subject: Re: [RFC v2 1/4] i3c: master: export i3c_masterdev_type
Date: Mon, 17 Feb 2020 15:59:17 +0100 [thread overview]
Message-ID: <20200217155917.592e8ded@collabora.com> (raw)
In-Reply-To: <20200217155623.13a94802@collabora.com>
On Mon, 17 Feb 2020 15:56:23 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 29 Jan 2020 13:17:32 +0100
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
>
> > Exporte i3c_masterdev_type so i3cdev module can verify if an i3c device
> > is a master.
> >
> > Signed-off-by: Vitor Soares <vitor.soares@synopsys.com>
> > ---
> > drivers/i3c/internals.h | 1 +
> > drivers/i3c/master.c | 3 ++-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
> > index 86b7b44..bc062e8 100644
> > --- a/drivers/i3c/internals.h
> > +++ b/drivers/i3c/internals.h
> > @@ -11,6 +11,7 @@
> > #include <linux/i3c/master.h>
> >
> > extern struct bus_type i3c_bus_type;
> > +extern const struct device_type i3c_masterdev_type;
> >
> > void i3c_bus_normaluse_lock(struct i3c_bus *bus);
> > void i3c_bus_normaluse_unlock(struct i3c_bus *bus);
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > index 7f8f896..8a0ba34 100644
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
> > @@ -523,9 +523,10 @@ static void i3c_masterdev_release(struct device *dev)
> > of_node_put(dev->of_node);
> > }
> >
> > -static const struct device_type i3c_masterdev_type = {
> > +const struct device_type i3c_masterdev_type = {
> > .groups = i3c_masterdev_groups,
> > };
> > +EXPORT_SYMBOL_GPL(i3c_masterdev_type);
>
> No need to export the symbol, removing the static and adding the
> definition to internal.h should work just fine (i3c.o contains
> both master.o and device.o).
Hm, my bad. Looks like i3cdev is a separate module/driver. If that's
the case, it should not have direct access to internals.h. I see 2
options here:
1/ make the i3cdev logic part of the core
2/ provide helpers to find devices by type
But maybe none of that is needed if you let userspace bind i3c devices
to the i3cdev driver.
>
> >
> > static int i3c_bus_set_mode(struct i3c_bus *i3cbus, enum i3c_bus_mode mode,
> > unsigned long max_i2c_scl_rate)
>
_______________________________________________
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Vitor Soares <Vitor.Soares@synopsys.com>
Cc: linux-kernel@vger.kernel.org, linux-i3c@lists.infradead.org,
Joao.Pinto@synopsys.com, Jose.Abreu@synopsys.com,
bbrezillon@kernel.org, gregkh@linuxfoundation.org,
wsa@the-dreams.de, arnd@arndb.de, broonie@kernel.org
Subject: Re: [RFC v2 1/4] i3c: master: export i3c_masterdev_type
Date: Mon, 17 Feb 2020 15:59:17 +0100 [thread overview]
Message-ID: <20200217155917.592e8ded@collabora.com> (raw)
In-Reply-To: <20200217155623.13a94802@collabora.com>
On Mon, 17 Feb 2020 15:56:23 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Wed, 29 Jan 2020 13:17:32 +0100
> Vitor Soares <Vitor.Soares@synopsys.com> wrote:
>
> > Exporte i3c_masterdev_type so i3cdev module can verify if an i3c device
> > is a master.
> >
> > Signed-off-by: Vitor Soares <vitor.soares@synopsys.com>
> > ---
> > drivers/i3c/internals.h | 1 +
> > drivers/i3c/master.c | 3 ++-
> > 2 files changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/i3c/internals.h b/drivers/i3c/internals.h
> > index 86b7b44..bc062e8 100644
> > --- a/drivers/i3c/internals.h
> > +++ b/drivers/i3c/internals.h
> > @@ -11,6 +11,7 @@
> > #include <linux/i3c/master.h>
> >
> > extern struct bus_type i3c_bus_type;
> > +extern const struct device_type i3c_masterdev_type;
> >
> > void i3c_bus_normaluse_lock(struct i3c_bus *bus);
> > void i3c_bus_normaluse_unlock(struct i3c_bus *bus);
> > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> > index 7f8f896..8a0ba34 100644
> > --- a/drivers/i3c/master.c
> > +++ b/drivers/i3c/master.c
> > @@ -523,9 +523,10 @@ static void i3c_masterdev_release(struct device *dev)
> > of_node_put(dev->of_node);
> > }
> >
> > -static const struct device_type i3c_masterdev_type = {
> > +const struct device_type i3c_masterdev_type = {
> > .groups = i3c_masterdev_groups,
> > };
> > +EXPORT_SYMBOL_GPL(i3c_masterdev_type);
>
> No need to export the symbol, removing the static and adding the
> definition to internal.h should work just fine (i3c.o contains
> both master.o and device.o).
Hm, my bad. Looks like i3cdev is a separate module/driver. If that's
the case, it should not have direct access to internals.h. I see 2
options here:
1/ make the i3cdev logic part of the core
2/ provide helpers to find devices by type
But maybe none of that is needed if you let userspace bind i3c devices
to the i3cdev driver.
>
> >
> > static int i3c_bus_set_mode(struct i3c_bus *i3cbus, enum i3c_bus_mode mode,
> > unsigned long max_i2c_scl_rate)
>
next prev parent reply other threads:[~2020-02-17 16:45 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-29 12:17 [RFC v2 0/4] Introduce i3c device userspace interface Vitor Soares
2020-01-29 12:17 ` Vitor Soares
2020-01-29 12:17 ` [RFC v2 1/4] i3c: master: export i3c_masterdev_type Vitor Soares
2020-01-29 12:17 ` Vitor Soares
2020-02-17 14:56 ` Boris Brezillon
2020-02-17 14:56 ` Boris Brezillon
2020-02-17 14:59 ` Boris Brezillon [this message]
2020-02-17 14:59 ` Boris Brezillon
2020-01-29 12:17 ` [RFC v2 2/4] i3c: master: export i3c_bus_type symbol Vitor Soares
2020-01-29 12:17 ` Vitor Soares
2020-01-29 12:17 ` [RFC v2 3/4] i3c: master: add i3c_for_each_dev helper Vitor Soares
2020-01-29 12:17 ` Vitor Soares
2020-01-29 12:17 ` [RFC v2 4/4] i3c: add i3cdev module to expose i3c dev in /dev Vitor Soares
2020-01-29 12:17 ` Vitor Soares
2020-01-29 14:30 ` Arnd Bergmann
2020-01-29 14:30 ` Arnd Bergmann
2020-01-29 17:00 ` Vitor Soares
2020-01-29 17:00 ` Vitor Soares
2020-01-29 19:39 ` Arnd Bergmann
2020-01-29 19:39 ` Arnd Bergmann
2020-02-04 13:19 ` Vitor Soares
2020-02-04 13:19 ` Vitor Soares
2020-02-17 15:26 ` Boris Brezillon
2020-02-17 15:26 ` Boris Brezillon
2020-02-17 14:51 ` [RFC v2 0/4] Introduce i3c device userspace interface Boris Brezillon
2020-02-17 14:51 ` Boris Brezillon
2020-02-17 15:06 ` Arnd Bergmann
2020-02-17 15:06 ` Arnd Bergmann
2020-02-17 15:36 ` Boris Brezillon
2020-02-17 15:36 ` Boris Brezillon
2020-02-17 15:55 ` Vitor Soares
2020-02-17 15:55 ` Vitor Soares
2020-02-17 16:03 ` gregkh
2020-02-17 16:03 ` gregkh
2020-02-17 16:12 ` Vitor Soares
2020-02-17 16:12 ` Vitor Soares
2020-02-17 16:23 ` Boris Brezillon
2020-02-17 16:23 ` Boris Brezillon
2020-02-17 16:31 ` Arnd Bergmann
2020-02-17 16:31 ` Arnd Bergmann
2020-02-17 17:06 ` Boris Brezillon
2020-02-17 17:06 ` Boris Brezillon
2020-02-17 16:19 ` Arnd Bergmann
2020-02-17 16:19 ` Arnd Bergmann
2020-02-17 16:34 ` Boris Brezillon
2020-02-17 16:34 ` Boris Brezillon
2020-02-17 15:32 ` Vitor Soares
2020-02-17 15:32 ` Vitor Soares
2020-02-17 15:52 ` Boris Brezillon
2020-02-17 15:52 ` Boris Brezillon
2020-02-17 17:37 ` Boris Brezillon
2020-02-17 17:37 ` 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=20200217155917.592e8ded@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=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 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.