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  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]
Date:   Fri, 18 Dec 2020 18:15:34 +0100
From:   Alexandre Belloni <>
To:     Jason Gunthorpe <>
Cc:     Mark Brown <>,
        Greg KH <>,
        Dan Williams <>,
        Pierre-Louis Bossart <>,, Kiran Patil <>,
        linux-rdma <>,
        Shiraz Saleem <>,
        Martin Habets <>,
        Liam Girdwood <>,
        Ranjani Sridharan <>,
        Fred Oh <>,
        Dave Ertman <>,
        Jakub Kicinski <>,
        Netdev <>,
        Leon Romanovsky <>,
        David Miller <>,
        Linux Kernel Mailing List <>,
        Parav Pandit <>,
Subject: Re: [resend/standalone PATCH v4] Add auxiliary bus support

On 18/12/2020 12:28:17-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 03:52:04PM +0000, Mark Brown wrote:
> > On Fri, Dec 18, 2020 at 10:08:54AM -0400, Jason Gunthorpe wrote:
> > > On Fri, Dec 18, 2020 at 01:17:09PM +0000, Mark Brown wrote:
> > 
> > > > As previously discussed this will need the auxilliary bus extending to
> > > > support at least interrupts and possibly also general resources.
> > 
> > > I thought the recent LWN article summed it up nicely, auxillary bus is
> > > for gluing to subsystems together using a driver specific software API
> > > to connect to the HW, MFD is for splitting a physical HW into disjoint
> > > regions of HW.
> > 
> > This conflicts with the statements from Greg about not using the
> > platform bus for things that aren't memory mapped or "direct firmware",
> > a large proportion of MFD subfunctions are neither at least in so far as
> > I can understand what direct firmware means.
> I assume MFD will keep existing and it will somehow stop using
> platform device for the children it builds.
> That doesn't mean MFD must use aux device, so I don't see what you
> mean by conflicts?
> If someone has a PCI device and they want to split it up, they should
> choose between aux device and MFD (assuming MFD gets fixed, as Greg
> has basically blanket NAK'd adding more of them to MFD as is)

I have an SoC with for example, a designware SPI controller (handled by
drivers/spi/spi-dw-mmio.c), a designware I2C controller (handled by
So, those are MMIO and described using device tree. On this particular
SoC, I can disable the CPU and connect it to another SoC using PCIe. In
that case it will expose one BAR, with all the HW IPs.

The question here is why would I use something different from platform
devices to register the SPI and I2C controllers? It seems that by using
auxiliary devices, I would have to reinvent parsing device property and
children/clients description. This isn't great from a code reuse

Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering

Powered by blists - more mailing lists