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. My plan, such as it is, is to go through the leaf-node drivers which almost definitely *should* be firmware-agnostic, and convert those. And then take stock of what we have left, and work out what, if anything, still needs to be done. > 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 :) -- dwmw2
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
