On Fri, Nov 11, 2022 at 11:49:25AM +0000, Mark Brown wrote:
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).
Hmm... yes ok true ACPI isn't going to put the elements of the MFD in either so we would then need something to bind all those in as well.
Thanks, Charles