On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote: > On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> > See version 2 of the series[1] which did that. It became obvious that > > was pointless because the call paths ended up looking like this: > > Generic subsystem code -> DT look-up code -> fwnode_probe_device -> > > of_probe_device > You link to a thread which says that "AT LEAST CURRENTLY, the calling > locations [the 'DT look-up code' you mention above] are DT specific > functions anyway. > 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. That seems like it's going to fall down since the different firmware interfaces do have quite different ideas about how things fit together at a system level and different compatibility needs which do suggest that just trying to do a direct mapping from DT into ACPI may well not make people happy but it sounds like that's the intention. When it gets to drivers the situation is much more clear since it's normally just simple properties, it's generally a bit more worrying if drivers are needing to directly interact with cross-device linkage. This is all subsystem level code though. > None of that really negates that fact that we are *working* on cleaning > these code paths up to be firmware-agnostic, and the fact that we > haven't got to this one *yet* isn't necessarily a good reason to make > it *worse* by adding new firmware-specificity to it. 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.
signature.asc
Description: PGP signature
