On Fri, Nov 11, 2022 at 11:16:11AM +0000, Charles Keepax wrote: > On Fri, Nov 11, 2022 at 08:00:10AM +0000, Marc Zyngier wrote: > > > > ACPI gets to be a lot of fun here, it's just not idiomatic to describe > > > the internals of these devices in firmware there and a lot of the > > > systems shipping this stuff are targeted at other OSs and system > > > integrators are therefore not in the least worried about Linux > > > preferences. > I would echo Mark's statement that going the way of moving this > into DT/ACPI will actually likely necessitate the addition of a > lot of "board file" stuff in the future. If the part gets used in > any ACPI systems (granted support is not in yet but this is not a > super unlikely addition in the future for cs48l32) we will need to > support the laptops containing the part in Linux and the vendors are > extremely unlikely to put internal CODEC IRQs into the ACPI tables. It's a bit of a stronger issue than that in that it's not how ACPI is usually expected to work (it draws more from the PCI model where you just get a top level ID from the device and have to figure the rest out yourself). > An alternative approach would be to actually represent the MFD in > device tree, I think this would allow things to work and look > something like (totally not tested just for discussion): That's what Marc's pushing for - there is an idea to do that which works well enough for cases (like this irqchip for the most part, modulo how to handle the top level interrupts for the chip) where the way Linux wants to model the device maps clearly onto the hardware but like I was mentioning with the audio/clocking split it gets tricky where things are more up in the air and potentially changable since it's much harder to define a suitable ABI.
Attachment:
signature.asc
Description: PGP signature
