From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Rhyland Klein <rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: Anton Vorontsov <cbou-JGs/UdohzUI@public.gmane.org>,
David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
Grant Likely
<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org"
<devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [RFC v2 2/3] power: power_supply: Add core support for supplied_nodes
Date: Fri, 22 Feb 2013 16:01:09 -0700 [thread overview]
Message-ID: <5127F8B5.10002@wwwdotorg.org> (raw)
In-Reply-To: <5127E95E.4010500-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 02/22/2013 02:55 PM, Rhyland Klein wrote:
> On 2/22/2013 2:49 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.
>> When parsing the DT, you can convert from phandle (or struct device_node
>> *) 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.
> The main problem I ran into when I was essentially trying to do this,
> 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
> own name.
>
> 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.
For other resource types, this is handled by the (phandle -> whatever)
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.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Rhyland Klein <rklein@nvidia.com>
Cc: Anton Vorontsov <cbou@mail.ru>,
David Woodhouse <dwmw2@infradead.org>,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v2 2/3] power: power_supply: Add core support for supplied_nodes
Date: Fri, 22 Feb 2013 16:01:09 -0700 [thread overview]
Message-ID: <5127F8B5.10002@wwwdotorg.org> (raw)
In-Reply-To: <5127E95E.4010500@nvidia.com>
On 02/22/2013 02:55 PM, Rhyland Klein wrote:
> On 2/22/2013 2:49 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.
>> When parsing the DT, you can convert from phandle (or struct device_node
>> *) 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.
> The main problem I ran into when I was essentially trying to do this,
> 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
> own name.
>
> 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.
For other resource types, this is handled by the (phandle -> whatever)
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.
next prev parent reply other threads:[~2013-02-22 23:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-21 23:11 [RFC v2 0/3] Add DT Binding for Power-Supply power-supply property Rhyland Klein
2013-02-21 23:11 ` Rhyland Klein
[not found] ` <1361488272-21010-1-git-send-email-rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-21 23:11 ` [RFC v2 1/3] power_supply: Define Binding for supplied-nodes Rhyland Klein
2013-02-21 23:11 ` Rhyland Klein
2013-02-22 19:46 ` Stephen Warren
[not found] ` <5127CAF9.1030506-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-22 22:05 ` Rhyland Klein
2013-02-22 22:05 ` Rhyland Klein
2013-02-21 23:11 ` [RFC v2 2/3] power: power_supply: Add core support for supplied_nodes Rhyland Klein
2013-02-21 23:11 ` Rhyland Klein
[not found] ` <1361488272-21010-3-git-send-email-rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-22 19:49 ` Stephen Warren
2013-02-22 19:49 ` Stephen Warren
[not found] ` <5127CBD9.9050501-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-22 21:55 ` Rhyland Klein
2013-02-22 21:55 ` Rhyland Klein
[not found] ` <5127E95E.4010500-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-02-22 23:01 ` Stephen Warren [this message]
2013-02-22 23:01 ` Stephen Warren
[not found] ` <5127F8B5.10002-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-28 19:54 ` Rhyland Klein
2013-02-28 19:54 ` Rhyland Klein
2013-02-22 20:09 ` Stephen Warren
2013-02-22 20:09 ` Stephen Warren
[not found] ` <5127D083.6020308-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-02-22 21:58 ` Rhyland Klein
2013-02-22 21:58 ` Rhyland Klein
2013-02-28 19:48 ` Rhyland Klein
[not found] ` <512FB473.8060309-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-02 22:48 ` Anton Vorontsov
2013-03-02 22:48 ` Anton Vorontsov
[not found] ` <20130302224832.GA16720-SAfYLu58TvsKrcn4e17nTyIbA2bwYUBrKwcig+XE9tjR7s880joybQ@public.gmane.org>
2013-03-04 17:32 ` Rhyland Klein
2013-03-04 17:32 ` Rhyland Klein
[not found] ` <5134DAB3.5000604-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-03-04 17:47 ` Anton Vorontsov
2013-03-04 17:47 ` Anton Vorontsov
2013-02-21 23:11 ` [RFC v2 3/3] power: power_supply: add support for getting supplied-nodes from dt Rhyland Klein
2013-02-21 23:11 ` Rhyland Klein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5127F8B5.10002@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=cbou-JGs/UdohzUI@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rklein-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.