netdev - Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200630103141.GA5272@sirena.org.uk>
Date:   Tue, 30 Jun 2020 11:31:41 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Jason Gunthorpe <jgg@...pe.ca>
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>,
        Jeff Kirsher <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>,
        lee.jones@...aro.org
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF
 client

On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:
> 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.

The proposed bus lacks resource handling, an equivalent of
platform_get_resource() and friends for example, which would be needed
for use with physical devices.  Both that and the name suggest that it's
for virtual devices.

> In a sense virtual bus is pretty much MFD v2.

Copying in Lee since I'm not sure he's aware of this, it's quite a
recent thing...  MFD is a layer above AFAICT, it's not a bus but rather
a combination of helpers for registering subdevices and a place for
drivers for core functionality of devices which have multiple features.

The reason the MFDs use platform devices is that they end up having to
have all the features of platform devices - originally people were
making virtual buses for them but the code duplication is real so
everyone (including Greg) decided to just use what was there already.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)