On 02/22/2013 02:55 PM, Rhyland Klein wrote:On 2/22/2013 2:49 PM, Stephen Warren wrote:For other resource types, this is handled by the (phandle -> whatever)On 02/21/2013 04:11 PM, Rhyland Klein wrote:The main problem I ran into when I was essentially trying to do this,With the growing support for dt, it make sense to try to make use ofWhen parsing the DT, you can convert from phandle (or struct device_node
dt features to make the general code cleaner. This patch is an
attempt to commonize how chargers and their supplies are linked.
Following common dt convention, the "supplied-to" char** list is
replaced with phandle lists defined in the supplies which contain
phandles of their suppliers.
This has the effect however of introducing an inversion in the internal
mechanics of how this information is stored. In the case of non-dt,
the char** list of supplies is stored in the charger. In the dt case,
a device_node * list is stored in the supplies of their chargers,
however this seems to be the only way to support this.
*) to the name of the referenced supply by simple lookup. So, you could
store supply names rather than device_node *. Can't you then also fill
in the referenced supply's existing char** list of supplies?
Of course, making this interact-with/use -EPROBE_DEFERRED might be
challenging, since this would be operating in the inverse order to other
producer/consumer relationships, which might cause loops.
was that the list of names that
are used to match the power_supplies are the strings set as "name" in
the power_supply structs. This
doesn't get set automatically based on their nodes, and it is currently
up to each driver to define their
For example, the sbs-battery driver uses the name "sbs-XXX" where XX is
its dev_name. Other drivers
use "%s-$%d" as i2c_device_id->name, + instance number. Then the only
solution I see is to require a new
property that defines the power-supply's name in the devicetree.
This solution with device_nodes, while not ideal, seems the be the best
bet from what I see. Maybe
someone else has a better idea.
conversion process actually being a function call on the referenced
object, so that the driver code for it can look up the data in the
actual device/... object etc. See the various .of_xlate functions that
exist in the kernel.