Re: [RFC v2 2/3] power: power_supply: Add core support for supplied_nodes

[Rhyland Klein]

On 2/22/2013 4:58 PM, Rhyland Klein wrote:
> On 2/22/2013 3:09 PM, Stephen Warren wrote:
> > On 02/21/2013 04:11 PM, Rhyland Klein wrote:
> > > With the growing support for dt, it make sense to try to make use of
> > > 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.
> > grep over the whole kernel tree for supplied_to doesn't yield /too/ many
> > hits, although I didn't look at the complexity of most of them. Would it
> > be possible to invert all the current in-kernel uses to represent a
> > supplied_from/by model instead? That would mean the proposed DT binding
> > would then represent the same relationship ordering as the kernel code,
> > which would be easier to handle.
> I think it is surely possible to change all the existing drivers to the
> inverse logic as
> you suggested. That might make a good follow patchset.
>
> -rhyland

Anton, David, would you be adverse to the changing of supplied_to from 
being a
list of batteries stored in a charger to being a list of chargers stored 
in batteries?

(I only use terms charger and batteries as it is much clearer for me to 
read in place
of terms like supplier and supply which are more accurate but much more 
confusing
when used together).

-rhyland

--
nvpublic

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/