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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 19 Dec 2020 01:22:08 +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 19:36:08-0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 10:16:58PM +0100, Alexandre Belloni wrote:
> > But then again, what about non-enumerable devices on the PCI device? I
> > feel this would exactly fit MFD. This is a collection of IPs that exist
> > as standalone but in this case are grouped in a single device.
> So, if mfd had a mfd_device and a mfd bus_type then drivers would need
> to have both a mfd_driver and a platform_driver to bind. Look at
> something like drivers/char/tpm/tpm_tis.c to see how a multi-probe
> driver is structured
> See Mark's remarks about the old of_platform_device, to explain why we
> don't have a 'dt_device' today

So, what would that mfd_driver have that the platform_driver doesn't
already provide?

> > Note that I then have another issue because the kernel doesn't support
> > irq controllers on PCI and this is exactly what my SoC has. But for now,
> > I can just duplicate the irqchip driver in the MFD driver.
> I think Thomas fixed that recently on x86 at least.. 
> Having to put dummy irq chip drivers in MFD anything sounds scary :|

This isn't a dummy driver it is a real irqchip, what issue is there to
register an irqchip from MFD ?

> > Let me point to drivers/net/ethernet/cadence/macb_pci.c which is a
> > fairly recent example. It does exactly that and I'm not sure you could
> > do it otherwise while still not having to duplicate most of macb_probe.
> Creating a platform_device to avoid restructuring the driver's probe
> and device logic to be generic is a *really* horrible reason to use a
> platform device.

Definitively but it made it in and seemed reasonable at the time it
seems. I stumbled upon that a while ago because I wanted to remove
platform_data support from the macb driver and this is the last user. I
never got the time to tackle that.

Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering

Powered by blists - more mailing lists