linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Ian Campbell <ijc@hellion.org.uk>,
	devicetree@vger.kernel.org, linux-input@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
	Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	linux ARM <linux-arm-kernel@lists.infradead.org>,
	tbm@cyrius.com
Subject: Re: [PATCH] ARM: Kirkwood: Add DT description of QNAP 419
Date: Sat, 11 Jan 2014 22:04:43 +0100	[thread overview]
Message-ID: <20140111210443.GT9681@lunn.ch> (raw)
In-Reply-To: <1389174517.12612.87.camel@kazak.uk.xensource.com>

On Wed, Jan 08, 2014 at 09:48:37AM +0000, Ian Campbell wrote:
> On Mon, 2014-01-06 at 23:49 +0100, Andrew Lunn wrote:

Hi Ian

I added in the devicetree list and the input list and added my
thoughts below.
 
> The other issue I spotted is
> that /dev/input/by-path/platform-gpio-keys-event has
> become /dev/input/by-path/platform-gpio_keys.3-event. Is it considered
> valid for a by-path name to change? In particular the 3 here is
> apparently the node depth in the DTB, which doesn't make much logical
> sense as a "path" in this context I don't think (I expect it to be some
> sort of path through the hardware buses, perhaps my expectation is
> wrong?).

The ts41x-setup.c board file creates the gpio keys platform device
using the following structure:

static struct platform_device qnap_ts41x_button_device = {
        .name           = "gpio-keys",
        .id             = -1,
        .num_resources  = 0,
        .dev            = {
                .platform_data  = &qnap_ts41x_button_data,
        }
};

The id of -1 causes platform_device_add() to set the device name to
plain "gpio-keys".

When using DT, the device name is created by the function
of_device_make_bus_id(). It has the following comment:

 * This routine will first try using either the dcr-reg or the reg property
 * value to derive a unique name.  As a last resort it will use the node
 * name followed by a unique number.

Since the gpio_keys node does not have a reg properties, it gets a
unique number appended to it. We end up with the device name
"gpio_keys.3"

So as it stands, it does not appear i can make the DT system use the
same device name as a board system.

But i'm also a little bit concerned by the "unique number" and this
ending up in /dev/input/by-path/platform-gpio_keys.3-event. Is this
path supposed to be stable? This unique number is not stable. An
unwitting change to the DT could cause its value to change. Do we need
to make it stable?

   Andrew

       reply	other threads:[~2014-01-11 21:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1389048557-16364-1-git-send-email-andrew@lunn.ch>
     [not found] ` <1389174517.12612.87.camel@kazak.uk.xensource.com>
2014-01-11 21:04   ` Andrew Lunn [this message]
2014-01-15 16:36     ` [PATCH] ARM: Kirkwood: Add DT description of QNAP 419 Arnd Bergmann
2014-01-15 17:45       ` Andrew Lunn
2014-01-15 18:20         ` Arnd Bergmann

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=20140111210443.GT9681@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=ijc@hellion.org.uk \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=sebastian.hesselbarth@googlemail.com \
    --cc=tbm@cyrius.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).