From: "Ertman, David M" <david.m.ertman@intel.com> To: Leon Romanovsky <leon@kernel.org> Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>, "parav@mellanox.com" <parav@mellanox.com>, "tiwai@suse.de" <tiwai@suse.de>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "ranjani.sridharan@linux.intel.com" <ranjani.sridharan@linux.intel.com>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, "fred.oh@linux.intel.com" <fred.oh@linux.intel.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "dledford@redhat.com" <dledford@redhat.com>, "broonie@kernel.org" <broonie@kernel.org>, "jgg@nvidia.com" <jgg@nvidia.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "kuba@kernel.org" <kuba@kernel.org>, "Williams, Dan J" <dan.j.williams@intel.com>, "Saleem, Shiraz" <shiraz.saleem@intel.com>, "davem@davemloft.net" <davem@davemloft.net>, "Patil, Kiran" <kiran.patil@intel.com> Subject: RE: [PATCH v2 1/6] Add ancillary bus support Date: Wed, 7 Oct 2020 19:53:40 +0000 [thread overview] Message-ID: <DM6PR11MB2841EBB5C27A947789F9DB73DD0A0@DM6PR11MB2841.namprd11.prod.outlook.com> (raw) In-Reply-To: <20201007192610.GD3964015@unreal> > -----Original Message----- > From: Alsa-devel <alsa-devel-bounces@alsa-project.org> On Behalf Of Leon > Romanovsky > Sent: Wednesday, October 7, 2020 12:26 PM > To: Ertman, David M <david.m.ertman@intel.com> > Cc: alsa-devel@alsa-project.org; parav@mellanox.com; tiwai@suse.de; > netdev@vger.kernel.org; ranjani.sridharan@linux.intel.com; Pierre-Louis > Bossart <pierre-louis.bossart@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; Williams, > Dan J <dan.j.williams@intel.com>; Saleem, Shiraz > <shiraz.saleem@intel.com>; davem@davemloft.net; Patil, Kiran > <kiran.patil@intel.com> > Subject: Re: [PATCH v2 1/6] Add ancillary bus support > > On Wed, Oct 07, 2020 at 06:06:30PM +0000, Ertman, David M wrote: > > > -----Original Message----- > > > From: Leon Romanovsky <leon@kernel.org> > > > Sent: Tuesday, October 6, 2020 10:03 AM > > > To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > > > Cc: Ertman, David M <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; > Williams, > > > Dan J <dan.j.williams@intel.com>; Saleem, Shiraz > > > <shiraz.saleem@intel.com>; davem@davemloft.net; Patil, Kiran > > > <kiran.patil@intel.com> > > > Subject: Re: [PATCH v2 1/6] Add ancillary bus support > > > > > > 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? > > > > > > > The pushback Pierre is referring to was during our mid-tier internal review. > It was > > primarily a concern of Parav as I recall, so he can speak to his reasoning. > > > > What we originally had was a single API call (ancillary_device_register) that > started > > with a call to device_initialize(), and every error path out of the function > performed > > a put_device(). > > > > Is this the model you have in mind? > > I don't like this flow: > ancillary_device_initialize() > if (ancillary_ancillary_device_add()) { > put_device(....) > ancillary_device_unregister() > return err; > } > > And prefer this flow: > ancillary_device_initialize() > if (ancillary_device_add()) { > ancillary_device_unregister() > return err; > } > > In this way, the ancillary users won't need to do non-intuitive put_device(); Isn't there a problem calling device_unregister() if device_add() fails? device_unregister() does a device_del() and if the device_add() failed there is nothing to delete? -DaveE > > Thanks
WARNING: multiple messages have this Message-ID (diff)
From: "Ertman, David M" <david.m.ertman@intel.com> To: Leon Romanovsky <leon@kernel.org> Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>, "parav@mellanox.com" <parav@mellanox.com>, "tiwai@suse.de" <tiwai@suse.de>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>, "ranjani.sridharan@linux.intel.com" <ranjani.sridharan@linux.intel.com>, "fred.oh@linux.intel.com" <fred.oh@linux.intel.com>, "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>, "dledford@redhat.com" <dledford@redhat.com>, "broonie@kernel.org" <broonie@kernel.org>, "jgg@nvidia.com" <jgg@nvidia.com>, "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>, "kuba@kernel.org" <kuba@kernel.org>, "Williams, Dan J" <dan.j.williams@intel.com>, "Saleem, Shiraz" <shiraz.saleem@intel.com>, "davem@davemloft.net" <davem@davemloft.net>, "Patil, Kiran" <kiran.patil@intel.com> Subject: RE: [PATCH v2 1/6] Add ancillary bus support Date: Wed, 7 Oct 2020 19:53:40 +0000 [thread overview] Message-ID: <DM6PR11MB2841EBB5C27A947789F9DB73DD0A0@DM6PR11MB2841.namprd11.prod.outlook.com> (raw) In-Reply-To: <20201007192610.GD3964015@unreal> > -----Original Message----- > From: Alsa-devel <alsa-devel-bounces@alsa-project.org> On Behalf Of Leon > Romanovsky > Sent: Wednesday, October 7, 2020 12:26 PM > To: Ertman, David M <david.m.ertman@intel.com> > Cc: alsa-devel@alsa-project.org; parav@mellanox.com; tiwai@suse.de; > netdev@vger.kernel.org; ranjani.sridharan@linux.intel.com; Pierre-Louis > Bossart <pierre-louis.bossart@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; Williams, > Dan J <dan.j.williams@intel.com>; Saleem, Shiraz > <shiraz.saleem@intel.com>; davem@davemloft.net; Patil, Kiran > <kiran.patil@intel.com> > Subject: Re: [PATCH v2 1/6] Add ancillary bus support > > On Wed, Oct 07, 2020 at 06:06:30PM +0000, Ertman, David M wrote: > > > -----Original Message----- > > > From: Leon Romanovsky <leon@kernel.org> > > > Sent: Tuesday, October 6, 2020 10:03 AM > > > To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > > > Cc: Ertman, David M <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; > Williams, > > > Dan J <dan.j.williams@intel.com>; Saleem, Shiraz > > > <shiraz.saleem@intel.com>; davem@davemloft.net; Patil, Kiran > > > <kiran.patil@intel.com> > > > Subject: Re: [PATCH v2 1/6] Add ancillary bus support > > > > > > 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? > > > > > > > The pushback Pierre is referring to was during our mid-tier internal review. > It was > > primarily a concern of Parav as I recall, so he can speak to his reasoning. > > > > What we originally had was a single API call (ancillary_device_register) that > started > > with a call to device_initialize(), and every error path out of the function > performed > > a put_device(). > > > > Is this the model you have in mind? > > I don't like this flow: > ancillary_device_initialize() > if (ancillary_ancillary_device_add()) { > put_device(....) > ancillary_device_unregister() > return err; > } > > And prefer this flow: > ancillary_device_initialize() > if (ancillary_device_add()) { > ancillary_device_unregister() > return err; > } > > In this way, the ancillary users won't need to do non-intuitive put_device(); Isn't there a problem calling device_unregister() if device_add() fails? device_unregister() does a device_del() and if the device_add() failed there is nothing to delete? -DaveE > > Thanks
next prev parent reply other threads:[~2020-10-07 20:19 UTC|newest] Thread overview: 140+ 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 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 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 [this message] 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 20:59 ` Pierre-Louis Bossart 2020-10-07 21:22 ` Ertman, David M 2020-10-07 21:22 ` Ertman, David M 2020-10-07 21:49 ` Pierre-Louis Bossart 2020-10-07 21:49 ` Pierre-Louis Bossart 2020-10-08 4:56 ` Parav Pandit 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-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 16:54 ` Ertman, David M 2020-10-08 17:35 ` Parav Pandit 2020-10-08 17:35 ` Parav Pandit 2020-10-08 18:13 ` Ertman, David M 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:30 ` Ertman, David M 2020-10-07 20:18 ` 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 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-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=DM6PR11MB2841EBB5C27A947789F9DB73DD0A0@DM6PR11MB2841.namprd11.prod.outlook.com \ --to=david.m.ertman@intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=broonie@kernel.org \ --cc=dan.j.williams@intel.com \ --cc=davem@davemloft.net \ --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=leon@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: linkBe 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.