Re: [resend/standalone PATCH v4] Add auxiliary bus support

[Alexandre Belloni]

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
https://bootlin.com