[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <61CC2BC414934749BD9F5BF3D5D940449874174D@ORSMSX112.amr.corp.intel.com>
Date: Mon, 29 Jun 2020 23:13:27 +0000
From: "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Mark Brown <broonie@...nel.org>
CC: Greg KH <gregkh@...uxfoundation.org>, Takashi Iwai <tiwai@...e.de>,
Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
"Ranjani Sridharan" <ranjani.sridharan@...ux.intel.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"nhorman@...hat.com" <nhorman@...hat.com>,
"sassmann@...hat.com" <sassmann@...hat.com>,
Fred Oh <fred.oh@...ux.intel.com>
Subject: RE: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
client
> -----Original Message-----
> From: Jason Gunthorpe <jgg@...pe.ca>
> Sent: Monday, June 29, 2020 16:00
> To: Mark Brown <broonie@...nel.org>
> Cc: Greg KH <gregkh@...uxfoundation.org>; Takashi Iwai <tiwai@...e.de>;
> Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>; Ranjani Sridharan
> <ranjani.sridharan@...ux.intel.com>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@...el.com>; davem@...emloft.net; netdev@...r.kernel.org;
> linux-rdma@...r.kernel.org; nhorman@...hat.com; sassmann@...hat.com;
> Fred Oh <fred.oh@...ux.intel.com>
> Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
> client
>
> On Mon, Jun 29, 2020 at 09:33:17PM +0100, Mark Brown wrote:
> > On Wed, May 27, 2020 at 09:17:33AM +0200, Greg KH wrote:
> >
> > > Ok, that's good to hear. But platform devices should never be
> > > showing up as a child of a PCI device. In the "near future" when we
> > > get the virtual bus code merged, we can convert any existing users
> > > like this to the new code.
> >
> > What are we supposed to do with things like PCI attached FPGAs and
> > ASICs in that case? They can have host visible devices with physical
> > resources like MMIO ranges and interrupts without those being split up
> > neatly as PCI subfunctions - the original use case for MFD was such
> > ASICs, there's a few PCI drivers in there now.
>
> Greg has been pretty clear that MFD shouldn't have been used on top of PCI
> drivers.
>
> In a sense virtual bus is pretty much MFD v2.
With the big distinction that MFD uses Platform bus/devices, which is why we could not
use MFD as a solution, and virtbus does not.
Powered by blists - more mailing lists