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
