linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Jiri Kosina <jkosina@suse.cz>
Cc: linux-input@vger.kernel.org
Subject: HID device names
Date: Mon, 12 Oct 2009 15:02:29 +0200	[thread overview]
Message-ID: <20091012150229.78d8df88@hyperion.delvare> (raw)

Hi Jiri,

Looking at hid-core.c, I see the following:

	dev_set_name(&hdev->dev, "%04X:%04X:%04X.%04X", hdev->bus,
	             hdev->vendor, hdev->product, atomic_inc_return(&id));

This looks plain wrong to me. The vendor and product IDs can be
attributes of the devices, but they should not be part of the device
name aka bus_id. The bus_id is about the address of the device, not
what the device is. Just look at how the PCI or USB subsystems do, or
virtually any other kernel subsystem, as I don't think any other
subsystem does what HID is doing right now.

On top of this, using an auto-incrementing device ID in the bus_id
looks wrong too. For one thing, it will cycle after 65536 requests, so
the above does not guarantee uniqueness over time. If anything, you
should used an idr instead. But even that would probably be wrong,
because this scheme itself doesn't guarantee stability of the bus_id
over disconnect/reconnect, reboot, etc. While I agree it's not always
possible to guarantee stability especially for externally pluggable
devices, we should try to keep names as stable as we can.

The above makes me wonder if handling hid as a bus is really the right
thing to do, as apparently your devices do not have an address you can
use to generate a good-looking bus_id. Shouldn't hid devices be class
devices instead?

-- 
Jean Delvare

             reply	other threads:[~2009-10-12 13:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-12 13:02 Jean Delvare [this message]
2009-10-12 14:01 ` HID device names Jiri Kosina
2009-10-12 14:49   ` Jean Delvare

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=20091012150229.78d8df88@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.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 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).