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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 30 Jun 2020 15:16:04 +0100
From:   Mark Brown <>
To:     Jason Gunthorpe <>
Cc:     Greg KH <>, Takashi Iwai <>,
        Pierre-Louis Bossart <>,
        Ranjani Sridharan <>,
        Jeff Kirsher <>,,,,,, Fred Oh <>,
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF

On Tue, Jun 30, 2020 at 08:32:45AM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 30, 2020 at 11:31:41AM +0100, Mark Brown wrote:
> > On Mon, Jun 29, 2020 at 07:59:59PM -0300, Jason Gunthorpe wrote:

> > > > 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.

> Resource handling is only useful if the HW has a hard distinction
> between it's functional blocks. This scheme is intended for devices
> where that doesn't exist. The driver that attaches to the PCI device
> and creates the virtual devices is supposed to provide SW abstractions
> for the other drivers to sit on.

> I'm not sure why we are calling it virtual bus.

The abstraction that the PCI based MFDs (and FPGAs will be similar,
they're just dynamic MFDs to a good approximation) need is to pass
through MMIO regions, interrupts and so on which is exactly what the
platform bus offers.  The hardware is basically someone taking a bunch
of IPs and shoving them behind the MMIO/interrupt regions of a PCI

> > 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.

> Maybe Greg will explain why he didn't like the earlier version of that
> stuff that used MFD

AFAICT Greg is mostly concerned about the MFDs that aren't memory
mapped, though some of them do use the resource API to pass interrupts

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

Powered by blists - more mailing lists