From: David Brownell <david-b@pacbell.net>
To: Richard Purdie <rpurdie@rpsys.net>
Cc: linux-usb-devel@lists.sourceforge.net,
Pavel Machek <pavel@suse.cz>,
Russell King <rmk+lkml@arm.linux.org.uk>,
lenz@cs.wisc.edu, David Liontooth <liontooth@cogweb.net>,
Oliver Neukum <oliver@neukum.org>,
kernel list <linux-kernel@vger.kernel.org>
Subject: Re: [linux-usb-devel] [PATCH] limit power budget on spitz
Date: Thu, 8 Jun 2006 16:44:45 -0700 [thread overview]
Message-ID: <200606081644.47288.david-b@pacbell.net> (raw)
In-Reply-To: <1149803365.11412.28.camel@localhost.localdomain>
On Thursday 08 June 2006 2:49 pm, Richard Purdie wrote:
>
> > > The easiest solution might be to move the ohci device registration into
> > > pxa_set_ohci_info (in pxa27x.c). I gave in and appended a patch (compile
> > > tested only so far).
> >
> > Looked OK to me.
> >
> > That's the kind of approach now used with OMAP and AT91, and which IMO
> > would be appropriate to use for most platform devices ... that is, don't
> > register devices that the board doesn't have. One additional nuance: if
> > the kernel doesn't have that driver configured, that's another reason not
> > to bother registering its device.
>
> This is where you start to add ugly ifdefs and generally start making
> the code look horrible. The device model separated the drivers and the
> devices to deal with this issue as I see it.
Enumeration is a separate issue. You wouldn't argue that every potential
PCI or USB device must get registered, right? Only the ones that are
actually _present_ get registered.
But here you argue that platform bus should not work that same way ... it
should register devices that can't be present. If nothing else, that's
an inconsistent aproach.
Plus, consider the common situation that a given pin could potentially
be used with several different devices. On a given board, only one of
those devices will be wired up. It's counterproductive to register any
of the others ... error prone, waste-of-kernel-address-space, etc.
> Generally I'd say its
> cleaner just to let the device register, then if a module comes along at
> some later point, the device is there for it.
Whether the device is there or not is a hardware issue. Board schematics
will show which devices are relevant ... registering any others is just
wastage. "Clean" is somewhat in the eye of the beholder; in mine, wasting
system resources is not clean.
- Dave
next prev parent reply other threads:[~2006-06-08 23:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-01 9:18 USB devices fail unnecessarily on unpowered hubs David Liontooth
2006-05-30 20:01 ` Pavel Machek
2006-06-03 9:29 ` Oliver Neukum
2006-06-05 14:32 ` [linux-usb-devel] " David Brownell
2006-06-06 7:43 ` Oliver Neukum
2006-06-08 7:01 ` Pavel Machek
2006-06-08 8:34 ` [PATCH] limit power budget on spitz Pavel Machek
2006-06-08 8:50 ` Richard Purdie
2006-06-08 9:02 ` Pavel Machek
2006-06-08 9:22 ` Richard Purdie
2006-06-08 17:09 ` Russell King
2006-06-08 18:26 ` David Brownell
2006-06-08 20:06 ` Richard Purdie
2006-06-08 20:38 ` [linux-usb-devel] " David Brownell
2006-06-08 21:22 ` Richard Purdie
2006-06-08 21:40 ` David Brownell
2006-06-08 21:49 ` Richard Purdie
2006-06-08 23:44 ` David Brownell [this message]
2006-06-09 1:25 ` Nicolas Pitre
2006-06-09 2:03 ` David Brownell
2006-06-09 2:34 ` Nicolas Pitre
2006-06-01 10:01 ` USB devices fail unnecessarily on unpowered hubs Andrew Morton
2006-06-01 11:42 ` Daniel Drake
2006-06-01 14:58 ` Alan Stern
2006-06-01 15:09 ` linux-os (Dick Johnson)
2006-06-01 15:23 ` Lennart Sorensen
2006-06-01 21:39 ` Dagfinn Ilmari Mannsåker
2006-06-01 15:53 ` Oliver Neukum
2006-06-01 17:24 ` linux-os (Dick Johnson)
2006-06-01 16:57 ` Alan Stern
2006-06-01 16:43 ` [linux-usb-devel] " Greg KH
2006-06-02 0:03 ` David Liontooth
2006-06-02 1:53 ` [linux-usb-devel] " David Brownell
2006-06-02 7:12 ` Oliver Neukum
2006-06-02 15:11 ` Alan Stern
2006-06-02 19:49 ` David Liontooth
2006-06-01 16:59 ` Andrew Morton
2006-06-01 17:08 ` Alan Stern
2006-06-01 17:34 ` Mark Lord
2006-06-01 17:47 ` Alan Stern
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=200606081644.47288.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=lenz@cs.wisc.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=liontooth@cogweb.net \
--cc=oliver@neukum.org \
--cc=pavel@suse.cz \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=rpurdie@rpsys.net \
/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