linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stepan Moskovchenko <stepanm@codeaurora.org>
To: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <robherring2@gmail.com>,
	devicetree-discuss@lists.ozlabs.org,
	David Brown <davidb@codeaurora.org>,
	Daniel Walker <dwalker@fifo99.com>,
	Bryan Huntsman <bryanh@codeaurora.org>,
	Russell King <linux@arm.linux.org.uk>,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] dt/platform: Use cell-index for device naming if available
Date: Mon, 12 Nov 2012 18:48:43 -0800	[thread overview]
Message-ID: <50A1B50B.4020509@codeaurora.org> (raw)
In-Reply-To: <554191d69bc21a4b133fb876df84ff89.squirrel@www.codeaurora.org>

On 11/11/2012 5:45 PM, Stepan Moskovchenko wrote:
>
>> On Sun, Nov 11, 2012 at 2:32 AM, Rob Herring <robherring2@gmail.com>
>> wrote:
>>> On 11/09/2012 06:48 PM, Stepan Moskovchenko wrote:
>>>> Use the cell-index property to construct names for platform
>>>> devices, falling back on the existing scheme of using the
>>>> device register address if cell-index is not specified.
>>>>
>>>> The cell-index property is a more useful device identifier,
>>>> especially in systems containing several numbered instances
>>>> of a particular hardware block, since it more easily
>>>> illustrates how devices relate to each other.
>>>>
>>>> Additionally, userspace software may rely on the classic
>>>> <name>.<id> naming scheme to access device attributes in
>>>> sysfs, without having to know the physical addresses of
>>>> that device on every platform the userspace software may
>>>> support. Using cell-index for device naming allows the
>>>> device addresses to be hidden from userspace and to be
>>>> exposed by logical device number without having to rely on
>>>> auxdata to perform name overrides. This allows userspace to
>>>> make assumptions about which sysfs nodes map to which
>>>> logical instance of a specific hardware block.
>>>>
>>>> Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
>>>> ---
>>>> I had also considered using something like the linux,label property to
>>>> allow
>>>> custom names for platform devices without resorting to auxdata, but the
>>>> cell-index approach seems more in line with what cell-index was
>>>> intended for
>>>> and with what the pre-DT platform device naming scheme used to be.
>>>> Please let
>>>> me know if you think there is a better way to accomplish this.
>>>>
>>>> This is just being sent out as an RFC for now. If there are no
>>>> objections, I
>>>> will send this out as an official patch, along with (or combined with)
>>>> a patch
>>>> to fix up the device names in things like clock tables of any affected
>>>> platforms.
>>>
>>> cell-index is basically deprecated. This has been discussed multiple
>>> times in the past. You can use auxdata if you really need to have the
>>> old name.
>>
>> Actually, I think it would be fine to use an /aliases entry to set the
>> device name. That's the place to put global namespace information.
>>
>> g.
>>
>
> Ah, thank you. I would prefer to stay away from auxdata, since it involves
> placing more platform-specific data into the kernel, and it is my
> understanding that auxdata is intended as a temporary measure. The
> /aliases approach looks interesting, and I'll see what I can do with it -
> hopefully I can have an RFC / patch soon. It looks like we would want an
> "inverse" alias lookup- that is, we would need to know which alias
> corresponds to a given node. Is it possible for a node to have multiple
> aliases? If so, which shall we use to create the device name? Anyway, I
> will further look into how these aliases work.
>
> Steve

Hi Grant,

Looking through the alias code, I see that the stem and the alias ID are 
stored and parsed separately. For the current way of using aliases, this 
makes sense. However, can you please clarify what you meant by using an 
/aliases entry to set the device name?

The first and most straightforward approach would be to use the entire 
alias name as the device name, making no distinction between the alias 
stem and ID. However, since it is possible to have multiple aliases to 
the same device, which of the aliases shall we use to construct the 
device name? Additionally, this may cause possible problems for legacy 
software that expects names in the format of <name>.<ID>, since '.' is 
not a valid character for alias names as defined by the DT spec, 
although strictly speaking this approach would successfully solve the 
problem of giving devices predictable and controllable names.

Another way an /aliases entry could be used to set the device name is to 
have a <name>.<ID> naming scheme, where the name comes from node->name 
(as is done in of_device_make_bus_id) and the ID gets queried using 
of_alias_get_id(). We would need to create a new alias stem for this 
purpose, and suppose that something like "platform" would work. The 
name-setting code would then roughly look as follows:

+	alias_id = of_alias_get_id(node, "platform");
+	if (alias_id != -ENODEV) {
+		dev_set_name(dev, "%s.%d", node->name, alias_id);
+		return;
+	}

The downside to this approach is that it imposes the restriction that 
device ID numbers now have to be unique throughout the system, whereas 
before only the <name>.<ID> combinations had to be unique. This is the 
result of only the ID number being present in the alias table, with each 
such ID number having the "platform" stem, and the restriction that node 
properties shall have unique names.

A third possible solution is to use an alias stem prefix for defining 
the device name. That is, the alias to set the device name would have 
some prefix (such as "platform-" for example) and the aliases would look 
something like platform-<name><ID>. The code to assign device names 
would find the matching alias containing the "platform-" prefix, strip 
the prefix, and use the resulting name and ID to construct the device 
name. This approach would make it more obvious as to which of several 
aliases is used to set the device name, but it imposes additional 
structure on the stem names and causes any aliases starting with 
"platform-" to become magical, which bothers me slightly.

Do any of these describe what you intended when you suggested using the 
/aliases node to set device names, or is there another approach that I 
have missed? Can you please elaborate further?

Thank you
Steve


-- 
  The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
  hosted by The Linux Foundation

  reply	other threads:[~2012-11-13  2:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-10  0:48 [RFC] dt/platform: Use cell-index for device naming if available Stepan Moskovchenko
2012-11-11  2:32 ` Rob Herring
2012-11-11 17:49   ` Grant Likely
2012-11-12  1:45     ` Stepan Moskovchenko
2012-11-13  2:48       ` Stepan Moskovchenko [this message]
2012-11-15 16:10         ` Grant Likely
2012-11-16  2:46           ` Stepan Moskovchenko
2012-11-17  3:29           ` Stepan Moskovchenko
2012-11-20 16:19             ` Grant Likely
2012-12-05  2:34               ` Stepan Moskovchenko

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=50A1B50B.4020509@codeaurora.org \
    --to=stepanm@codeaurora.org \
    --cc=bryanh@codeaurora.org \
    --cc=davidb@codeaurora.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dwalker@fifo99.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robherring2@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).