On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote: > > > But the point I'm making is that we are working towards *fixing* that, > > > and *not* using DT-specific code in places where we should be using the > > > generic APIs.
> > What is the plan for fixing things here? It's not obvious (at least to > > me) that we don't want to have the subsystems having knowledge of how > > they are bound to a specific firmware which is what you seem to imply > > here. > I don't know that there *is* a coherent plan here to address it all. > Certainly, we *will* need subsystems to have firmware-specific > knowledge in some cases. Take GPIO as an example; ACPI *has* a way to > describe GPIO, and properties which reference GPIO pins are intended to > work through that — while in DT, properties which reference GPIO pins > will have different contents. They'll be compatible at the driver > level, in the sense that there's a call to get a given GPIO given the > property name, but the subsystems *will* be doing different things > behind the scenes. I'd expect that to be the norm rather than the exception. > > It seems like we're going to have to refactor these bits of code when > > they get generalised anyway so I'm not sure that the additional cost > > here is that big. > That's an acceptable answer — "we're adding legacy code here but we > know it's going to be refactored anyway". If that's true, all it takes > is a note in the commit comment to that effect. That's different from > having not thought about it :) Given the above I'm not even sure it's legacy code, it's just as likely we're going to get some parallel ACPI code added to the subsystems for parsing their bindings.
signature.asc
Description: PGP signature
