From: Leon Romanovsky <leon@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, kuba@kernel.org, parav@mellanox.com,
tiwai@suse.de, netdev@vger.kernel.org,
ranjani.sridharan@linux.intel.com, fred.oh@linux.intel.com,
linux-rdma@vger.kernel.org, dledford@redhat.com,
broonie@kernel.org, jgg@nvidia.com, gregkh@linuxfoundation.org,
Dave Ertman <david.m.ertman@intel.com>,
dan.j.williams@intel.com, shiraz.saleem@intel.com,
davem@davemloft.net, kiran.patil@intel.com
Subject: Re: [PATCH v2 1/6] Add ancillary bus support
Date: Tue, 6 Oct 2020 20:02:41 +0300 [thread overview]
Message-ID: <20201006170241.GM1874917@unreal> (raw)
In-Reply-To: <b4f6b5d1-2cf4-ae7a-3e57-b66230a58453@linux.intel.com>
On Tue, Oct 06, 2020 at 10:18:07AM -0500, Pierre-Louis Bossart wrote:
> Thanks for the review Leon.
>
> > > Add support for the Ancillary Bus, ancillary_device and ancillary_driver.
> > > It enables drivers to create an ancillary_device and bind an
> > > ancillary_driver to it.
> >
> > I was under impression that this name is going to be changed.
>
> It's part of the opens stated in the cover letter.
ok, so what are the variants?
system bus (sysbus), sbsystem bus (subbus), crossbus ?
>
> [...]
>
> > > + const struct my_driver my_drv = {
> > > + .ancillary_drv = {
> > > + .driver = {
> > > + .name = "myancillarydrv",
> >
> > Why do we need to give control over driver name to the driver authors?
> > It can be problematic if author puts name that already exists.
>
> Good point. When I used the ancillary_devices for my own SoundWire test, the
> driver name didn't seem specifically meaningful but needed to be set to
> something, what mattered was the id_table. Just thinking aloud, maybe we can
> add prefixing with KMOD_BUILD, as we've done already to avoid collisions
> between device names?
IMHO, it shouldn't be controlled by the drivers at all and need to have
kernel module name hardwired. Users will use it later for various
bind/unbind/autoprobe tricks and it will give predictability for them.
>
> [...]
>
> > > +int __ancillary_device_add(struct ancillary_device *ancildev, const char *modname)
> > > +{
> > > + struct device *dev = &ancildev->dev;
> > > + int ret;
> > > +
> > > + if (!modname) {
> > > + pr_err("ancillary device modname is NULL\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = dev_set_name(dev, "%s.%s.%d", modname, ancildev->name, ancildev->id);
> > > + if (ret) {
> > > + pr_err("ancillary device dev_set_name failed: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = device_add(dev);
> > > + if (ret)
> > > + dev_err(dev, "adding ancillary device failed!: %d\n", ret);
> > > +
> > > + return ret;
> > > +}
> >
> > Sorry, but this is very strange API that requires users to put
> > internal call to "dev" that is buried inside "struct ancillary_device".
> >
> > For example in your next patch, you write this "put_device(&cdev->ancildev.dev);"
> >
> > I'm pretty sure that the amount of bugs in error unwind will be
> > astonishing, so if you are doing wrappers over core code, better do not
> > pass complexity to the users.
>
> In initial reviews, there was pushback on adding wrappers that don't do
> anything except for a pointer indirection.
>
> Others had concerns that the API wasn't balanced and blurring layers.
Are you talking about internal review or public?
If it is public, can I get a link to it?
>
> Both points have merits IMHO. Do we want wrappers for everything and
> completely hide the low-level device?
This API is partially obscures low level driver-core code and needs to
provide clear and proper abstractions without need to remember about
put_device. There is already _add() interface why don't you do
put_device() in it?
>
> >
> > > +EXPORT_SYMBOL_GPL(__ancillary_device_add);
> > > +
> > > +static int ancillary_probe_driver(struct device *dev)
> > > +{
> > > + struct ancillary_driver *ancildrv = to_ancillary_drv(dev->driver);
> > > + struct ancillary_device *ancildev = to_ancillary_dev(dev);
> > > + int ret;
> > > +
> > > + ret = dev_pm_domain_attach(dev, true);
> > > + if (ret) {
> > > + dev_warn(dev, "Failed to attach to PM Domain : %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = ancildrv->probe(ancildev, ancillary_match_id(ancildrv->id_table, ancildev));
> >
> > I don't think that you need to call ->probe() if ancillary_match_id()
> > returned NULL and probably that check should be done before
> > dev_pm_domain_attach().
>
> we'll look into this.
>
> >
> > > + if (ret)
> > > + dev_pm_domain_detach(dev, true);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int ancillary_remove_driver(struct device *dev)
> > > +{
> > > + struct ancillary_driver *ancildrv = to_ancillary_drv(dev->driver);
> > > + struct ancillary_device *ancildev = to_ancillary_dev(dev);
> > > + int ret;
> > > +
> > > + ret = ancildrv->remove(ancildev);
> > > + dev_pm_domain_detach(dev, true);
> > > +
> > > + return ret;
> >
> > You returned an error to user and detached from PM, what will user do
> > with this information? Should user ignore it? retry?
>
> That comment was also provided in earlier reviews. In practice the error is
> typically ignored so there was a suggestion to move the return type to void,
> that could be done if this was desired by the majority.
+1 from me.
>
> [...]
>
> > > diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> > > index 5b08a473cdba..7d596dc30833 100644
> > > --- a/include/linux/mod_devicetable.h
> > > +++ b/include/linux/mod_devicetable.h
> > > @@ -838,4 +838,12 @@ struct mhi_device_id {
> > > kernel_ulong_t driver_data;
> > > };
> > >
> > > +#define ANCILLARY_NAME_SIZE 32
> > > +#define ANCILLARY_MODULE_PREFIX "ancillary:"
> > > +
> > > +struct ancillary_device_id {
> > > + char name[ANCILLARY_NAME_SIZE];
> >
> > I hope that this be enough.
>
> Are you suggesting a different value to allow for a longer string?
I have no idea, but worried that there were no checks at all if name is
more than 32. Maybe compiler warn about it?
Thanks
WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Dave Ertman <david.m.ertman@intel.com>,
alsa-devel@alsa-project.org, parav@mellanox.com, tiwai@suse.de,
netdev@vger.kernel.org, ranjani.sridharan@linux.intel.com,
fred.oh@linux.intel.com, linux-rdma@vger.kernel.org,
dledford@redhat.com, broonie@kernel.org, jgg@nvidia.com,
gregkh@linuxfoundation.org, kuba@kernel.org,
dan.j.williams@intel.com, shiraz.saleem@intel.com,
davem@davemloft.net, kiran.patil@intel.com
Subject: Re: [PATCH v2 1/6] Add ancillary bus support
Date: Tue, 6 Oct 2020 20:02:41 +0300 [thread overview]
Message-ID: <20201006170241.GM1874917@unreal> (raw)
In-Reply-To: <b4f6b5d1-2cf4-ae7a-3e57-b66230a58453@linux.intel.com>
On Tue, Oct 06, 2020 at 10:18:07AM -0500, Pierre-Louis Bossart wrote:
> Thanks for the review Leon.
>
> > > Add support for the Ancillary Bus, ancillary_device and ancillary_driver.
> > > It enables drivers to create an ancillary_device and bind an
> > > ancillary_driver to it.
> >
> > I was under impression that this name is going to be changed.
>
> It's part of the opens stated in the cover letter.
ok, so what are the variants?
system bus (sysbus), sbsystem bus (subbus), crossbus ?
>
> [...]
>
> > > + const struct my_driver my_drv = {
> > > + .ancillary_drv = {
> > > + .driver = {
> > > + .name = "myancillarydrv",
> >
> > Why do we need to give control over driver name to the driver authors?
> > It can be problematic if author puts name that already exists.
>
> Good point. When I used the ancillary_devices for my own SoundWire test, the
> driver name didn't seem specifically meaningful but needed to be set to
> something, what mattered was the id_table. Just thinking aloud, maybe we can
> add prefixing with KMOD_BUILD, as we've done already to avoid collisions
> between device names?
IMHO, it shouldn't be controlled by the drivers at all and need to have
kernel module name hardwired. Users will use it later for various
bind/unbind/autoprobe tricks and it will give predictability for them.
>
> [...]
>
> > > +int __ancillary_device_add(struct ancillary_device *ancildev, const char *modname)
> > > +{
> > > + struct device *dev = &ancildev->dev;
> > > + int ret;
> > > +
> > > + if (!modname) {
> > > + pr_err("ancillary device modname is NULL\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = dev_set_name(dev, "%s.%s.%d", modname, ancildev->name, ancildev->id);
> > > + if (ret) {
> > > + pr_err("ancillary device dev_set_name failed: %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = device_add(dev);
> > > + if (ret)
> > > + dev_err(dev, "adding ancillary device failed!: %d\n", ret);
> > > +
> > > + return ret;
> > > +}
> >
> > Sorry, but this is very strange API that requires users to put
> > internal call to "dev" that is buried inside "struct ancillary_device".
> >
> > For example in your next patch, you write this "put_device(&cdev->ancildev.dev);"
> >
> > I'm pretty sure that the amount of bugs in error unwind will be
> > astonishing, so if you are doing wrappers over core code, better do not
> > pass complexity to the users.
>
> In initial reviews, there was pushback on adding wrappers that don't do
> anything except for a pointer indirection.
>
> Others had concerns that the API wasn't balanced and blurring layers.
Are you talking about internal review or public?
If it is public, can I get a link to it?
>
> Both points have merits IMHO. Do we want wrappers for everything and
> completely hide the low-level device?
This API is partially obscures low level driver-core code and needs to
provide clear and proper abstractions without need to remember about
put_device. There is already _add() interface why don't you do
put_device() in it?
>
> >
> > > +EXPORT_SYMBOL_GPL(__ancillary_device_add);
> > > +
> > > +static int ancillary_probe_driver(struct device *dev)
> > > +{
> > > + struct ancillary_driver *ancildrv = to_ancillary_drv(dev->driver);
> > > + struct ancillary_device *ancildev = to_ancillary_dev(dev);
> > > + int ret;
> > > +
> > > + ret = dev_pm_domain_attach(dev, true);
> > > + if (ret) {
> > > + dev_warn(dev, "Failed to attach to PM Domain : %d\n", ret);
> > > + return ret;
> > > + }
> > > +
> > > + ret = ancildrv->probe(ancildev, ancillary_match_id(ancildrv->id_table, ancildev));
> >
> > I don't think that you need to call ->probe() if ancillary_match_id()
> > returned NULL and probably that check should be done before
> > dev_pm_domain_attach().
>
> we'll look into this.
>
> >
> > > + if (ret)
> > > + dev_pm_domain_detach(dev, true);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int ancillary_remove_driver(struct device *dev)
> > > +{
> > > + struct ancillary_driver *ancildrv = to_ancillary_drv(dev->driver);
> > > + struct ancillary_device *ancildev = to_ancillary_dev(dev);
> > > + int ret;
> > > +
> > > + ret = ancildrv->remove(ancildev);
> > > + dev_pm_domain_detach(dev, true);
> > > +
> > > + return ret;
> >
> > You returned an error to user and detached from PM, what will user do
> > with this information? Should user ignore it? retry?
>
> That comment was also provided in earlier reviews. In practice the error is
> typically ignored so there was a suggestion to move the return type to void,
> that could be done if this was desired by the majority.
+1 from me.
>
> [...]
>
> > > diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> > > index 5b08a473cdba..7d596dc30833 100644
> > > --- a/include/linux/mod_devicetable.h
> > > +++ b/include/linux/mod_devicetable.h
> > > @@ -838,4 +838,12 @@ struct mhi_device_id {
> > > kernel_ulong_t driver_data;
> > > };
> > >
> > > +#define ANCILLARY_NAME_SIZE 32
> > > +#define ANCILLARY_MODULE_PREFIX "ancillary:"
> > > +
> > > +struct ancillary_device_id {
> > > + char name[ANCILLARY_NAME_SIZE];
> >
> > I hope that this be enough.
>
> Are you suggesting a different value to allow for a longer string?
I have no idea, but worried that there were no checks at all if name is
more than 32. Maybe compiler warn about it?
Thanks
next prev parent reply other threads:[~2020-10-06 17:03 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 18:24 [PATCH v2 0/6] Ancillary bus implementation and SOF multi-client support Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-05 18:24 ` [PATCH v2 1/6] Add ancillary bus support Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-06 7:18 ` Leon Romanovsky
2020-10-06 7:18 ` Leon Romanovsky
2020-10-06 15:18 ` Pierre-Louis Bossart
2020-10-06 17:02 ` Leon Romanovsky [this message]
2020-10-06 17:02 ` Leon Romanovsky
2020-10-06 17:09 ` Parav Pandit
2020-10-06 17:09 ` Parav Pandit
2020-10-06 17:26 ` Leon Romanovsky
2020-10-06 17:26 ` Leon Romanovsky
2020-10-06 17:41 ` Saleem, Shiraz
2020-10-06 17:41 ` Saleem, Shiraz
2020-10-06 19:20 ` Leon Romanovsky
2020-10-06 19:20 ` Leon Romanovsky
2020-10-07 2:49 ` Dan Williams
2020-10-07 2:49 ` Dan Williams
2020-10-07 13:09 ` Saleem, Shiraz
2020-10-07 13:09 ` Saleem, Shiraz
2020-10-07 13:36 ` Leon Romanovsky
2020-10-07 13:36 ` Leon Romanovsky
2020-10-07 18:55 ` Dan Williams
2020-10-07 18:55 ` Dan Williams
2020-10-07 20:01 ` Ertman, David M
2020-10-07 20:01 ` Ertman, David M
2020-10-06 18:35 ` Ranjani Sridharan
2020-10-06 18:35 ` Ranjani Sridharan
2020-10-06 17:50 ` Saleem, Shiraz
2020-10-06 17:50 ` Saleem, Shiraz
2020-10-07 18:06 ` Ertman, David M
2020-10-07 19:26 ` Leon Romanovsky
2020-10-07 19:26 ` Leon Romanovsky
2020-10-07 19:53 ` Ertman, David M
2020-10-07 19:53 ` Ertman, David M
2020-10-07 19:57 ` Ertman, David M
2020-10-07 19:57 ` Ertman, David M
2020-10-07 20:17 ` Parav Pandit
2020-10-07 20:17 ` Parav Pandit
2020-10-07 20:46 ` Ertman, David M
2020-10-07 20:46 ` Ertman, David M
2020-10-07 20:59 ` Pierre-Louis Bossart
2020-10-07 21:22 ` Ertman, David M
2020-10-07 21:49 ` Pierre-Louis Bossart
2020-10-08 4:56 ` Parav Pandit
2020-10-08 5:26 ` Leon Romanovsky
2020-10-08 5:26 ` Leon Romanovsky
2020-10-08 7:14 ` Parav Pandit
2020-10-08 7:14 ` Parav Pandit
2020-10-08 7:45 ` Leon Romanovsky
2020-10-08 7:45 ` Leon Romanovsky
2020-10-08 9:45 ` Parav Pandit
2020-10-08 9:45 ` Parav Pandit
2020-10-08 10:17 ` Leon Romanovsky
2020-10-08 10:17 ` Leon Romanovsky
2020-10-08 13:29 ` Pierre-Louis Bossart
2020-10-09 11:40 ` Leon Romanovsky
2020-10-09 11:40 ` Leon Romanovsky
2020-10-08 16:54 ` Ertman, David M
2020-10-08 17:35 ` Parav Pandit
2020-10-08 18:13 ` Ertman, David M
2020-10-08 5:21 ` Leon Romanovsky
2020-10-08 5:21 ` Leon Romanovsky
2020-10-08 6:32 ` Dan Williams
2020-10-08 6:32 ` Dan Williams
2020-10-08 7:00 ` Leon Romanovsky
2020-10-08 7:00 ` Leon Romanovsky
2020-10-08 7:38 ` Dan Williams
2020-10-08 7:38 ` Dan Williams
2020-10-08 7:50 ` gregkh
2020-10-08 7:50 ` gregkh
2020-10-08 11:10 ` Parav Pandit
2020-10-08 11:10 ` Parav Pandit
2020-10-08 16:39 ` Ertman, David M
2020-10-08 16:39 ` Ertman, David M
2020-10-08 8:00 ` Leon Romanovsky
2020-10-08 8:00 ` Leon Romanovsky
2020-10-08 8:09 ` Dan Williams
2020-10-08 8:09 ` Dan Williams
2020-10-08 16:42 ` Ertman, David M
2020-10-08 16:42 ` Ertman, David M
2020-10-08 17:21 ` Leon Romanovsky
2020-10-08 17:21 ` Leon Romanovsky
2020-10-08 18:25 ` Ertman, David M
2020-10-08 18:25 ` Ertman, David M
2020-10-07 20:30 ` Ertman, David M
2020-10-07 20:18 ` Ertman, David M
2020-10-06 17:23 ` Leon Romanovsky
2020-10-06 17:23 ` Leon Romanovsky
2020-10-06 17:45 ` Saleem, Shiraz
2020-10-06 17:45 ` Saleem, Shiraz
2020-10-08 22:04 ` Ertman, David M
2020-10-08 22:04 ` Ertman, David M
2020-10-08 22:41 ` Dan Williams
2020-10-08 22:41 ` Dan Williams
2020-10-09 14:26 ` Pierre-Louis Bossart
2020-10-09 19:22 ` Dan Williams
2020-10-09 19:22 ` Dan Williams
2020-10-09 19:39 ` Pierre-Louis Bossart
2020-10-09 19:39 ` Pierre-Louis Bossart
2020-10-12 18:34 ` Ertman, David M
2020-10-08 17:20 ` Leon Romanovsky
2020-10-08 17:20 ` Leon Romanovsky
2020-10-08 17:28 ` Ertman, David M
2020-10-08 17:28 ` Ertman, David M
2020-10-05 18:24 ` [PATCH v2 2/6] ASoC: SOF: Introduce descriptors for SOF client Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-13 1:05 ` Randy Dunlap
2020-10-13 1:05 ` Randy Dunlap
2020-10-13 1:31 ` Pierre-Louis Bossart
2020-10-13 1:31 ` Pierre-Louis Bossart
2020-10-13 1:55 ` Randy Dunlap
2020-10-13 1:55 ` Randy Dunlap
2020-10-13 1:56 ` Randy Dunlap
2020-10-13 1:56 ` Randy Dunlap
2020-10-13 15:08 ` Pierre-Louis Bossart
2020-10-13 19:35 ` Randy Dunlap
2020-10-13 19:57 ` Pierre-Louis Bossart
2020-10-05 18:24 ` [PATCH v2 3/6] ASoC: SOF: Create client driver for IPC test Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-05 18:24 ` [PATCH v2 4/6] ASoC: SOF: ops: Add ops for client registration Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-05 18:24 ` [PATCH v2 5/6] ASoC: SOF: Intel: Define " Dave Ertman
2020-10-05 18:24 ` Dave Ertman
2020-10-05 18:24 ` [PATCH v2 6/6] ASoC: SOF: debug: Remove IPC flood test support in SOF core Dave Ertman
2020-10-05 18:24 ` Dave Ertman
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=20201006170241.GM1874917@unreal \
--to=leon@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=david.m.ertman@intel.com \
--cc=dledford@redhat.com \
--cc=fred.oh@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=kiran.patil@intel.com \
--cc=kuba@kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=parav@mellanox.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=shiraz.saleem@intel.com \
--cc=tiwai@suse.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.