public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: Kyle Moffett <mrmacman_g4@mac.com>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] driver core: Separate platform device name from platform device number
Date: Fri, 25 Mar 2005 22:56:03 +0200	[thread overview]
Message-ID: <20050325205603.GD4192@linux-sh.org> (raw)
In-Reply-To: <20050325202508.A12715@flint.arm.linux.org.uk>

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

On Fri, Mar 25, 2005 at 08:25:08PM +0000, Russell King wrote:
> Eh?  How do you end up with "/sys/devices/platform/foobar0.0" for the
> former case?  It has an ID of "-1", and not zero.  Your idea doesn't
> make any sense.
> 
Yes, I missed the -1 part, so Kyle is correct.

It would be trivial to treat them both as foobar0 and have the
registration succeed for whoever gets it first, but I could see that this
would be problematic in the serial8250 case. On the other hand, this is
then serial8250's problem.

> > The first case is a corner case, and really shouldn't happen that much in
> > practice outside of broken drivers.
> 
> It does happen today.  Firstly, the 8250 driver registers a device of
> "serial8250" with id = -1 for the backwards-compatible devices.
> Platforms can then register a platform device called "serial8250"
> with zero or positive id numbers.
> 
That's fine, but that still doesn't make it any less of a corner case.

> > We don't go around changing /dev semantics everytime someone decides to
> > call their device something silly, I don't see why platform devices
> > should be treated differently, better to just fix the broken drivers..
> 
> It's not about something being called something silly.  It's about
> the original concept of how to generate the path being down right
> stupid.
> 
<dev><id> is a fairly common thing, if you have a problem with this,
maybe you would like to audit /dev while you are at it. I don't disagree
with you that this is useful for the devices that do end with numbers in
their names, but breaking everything else as a result of this makes no
sense either.

What would you do if you needed to register a character device using the
name of the device (which may end in a number, and there was a range of
them)? This likely doesn't happen enough in practice for anyone to
actually care, but you would have the same problem there otherwise.

This should arguably be the problem of the corner case driver, it
certainly shouldn't change convention for everyone else. While the
original concept of how to generate the path may have been "down right
stupid", it works for /dev, and I don't see how adding a superfluous . in
the paths of devices that just don't care and subsequently breaking
existing expectations of behaviour is any more inspired..

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2005-03-25 20:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-10  0:34 [BK PATCH] Driver core and kobject updates for 2.6.11 Greg KH
2005-03-10  0:34 ` [PATCH] Kobject: remove some unneeded exports Greg KH
2005-03-10  0:34   ` [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Greg KH
2005-03-10  0:34     ` [PATCH] cpufreq 2.4 interface removal schedule Greg KH
2005-03-10  0:34       ` [PATCH] driver core: Separate platform device name from platform device number Greg KH
2005-03-10  0:34         ` [PATCH] class core: export MAJOR/MINOR to the hotplug env Greg KH
2005-03-10  0:34           ` [PATCH] block " Greg KH
2005-03-10  0:34             ` [PATCH] class_simple: pass dev_t to the class core Greg KH
2005-03-10  0:34               ` [PATCH] usb: class driver " Greg KH
2005-03-10  0:34                 ` [PATCH] i2c: " Greg KH
2005-03-10  0:34                   ` [PATCH] videodev: " Greg KH
2005-03-10  0:34                     ` [PATCH] driver core: clean driver unload Greg KH
2005-03-10  0:34                       ` [PATCH] Driver core: add "bus" symlink to class/block devices Greg KH
2005-03-10  0:34                         ` [PATCH] floppy.c: pass physical device to device registration Greg KH
2005-03-10  0:34                           ` [PATCH] kset: make ksets have a spinlock, and use that to lock their lists Greg KH
2005-03-10  0:34                             ` [PATCH] sysdev: make system_subsys static as no one else needs access to it Greg KH
2005-03-10  0:34                               ` [PATCH] kref: make kref_put return if this was the last put call Greg KH
2005-03-10  0:34                                 ` [PATCH] USB: move usb core to use class_simple instead of it's own class functions Greg KH
2005-03-10  0:34                                   ` [PATCH] kmap: remove usage of rwsem from kobj_map Greg KH
2005-03-10  0:34                                     ` [PATCH] sysdev: fix the name of the list of drivers to be a sane name Greg KH
2005-03-10  0:34                                       ` [PATCH] sysdev: remove the rwsem usage from this subsystem Greg KH
2005-03-10  0:34                                         ` [PATCH] class: add a semaphore to struct class, and use that instead of the subsystem rwsem Greg KH
2005-03-25 18:01         ` [PATCH] driver core: Separate platform device name from platform device number Paul Mundt
2005-03-25 18:10           ` Greg KH
2005-03-25 18:35             ` Paul Mundt
2005-03-25 19:38               ` Kyle Moffett
2005-03-25 19:58                 ` Paul Mundt
2005-03-25 20:17                   ` Kyle Moffett
2005-03-25 20:25                   ` Russell King
2005-03-25 20:56                     ` Paul Mundt [this message]
2005-03-25 21:03                       ` Russell King
2005-03-25 22:15                         ` Paul Mundt
2005-03-10  2:23     ` [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Dave Jones
2005-03-10  4:56     ` Dominik Brodowski

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=20050325205603.GD4192@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.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