mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@cam.org>
To: David Brownell <david-b@pacbell.net>
Cc: Richard Purdie <rpurdie@rpsys.net>,
	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, 08 Jun 2006 22:34:15 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0606082217590.19403@localhost.localdomain> (raw)
In-Reply-To: <200606081903.07203.david-b@pacbell.net>

On Thu, 8 Jun 2006, David Brownell wrote:

> On Thursday 08 June 2006 6:25 pm, Nicolas Pitre wrote:
> > He replied to your assertion where you said: "if the kernel doesn't have 
> > that driver configured, that's another reason not to bother registering 
> > its device" to which he disagreed, and I disagree too.
> 
> I see your point.  Yes, this is arguable ... there are multiple principles
> that can be traded off against each other.
> 
> For example, "by default, make design choices that save memory" (what I was
> using) versus:
> 
> > The _device_ should indeed be registered based on _hardware_ config, not 
> > _driver_ config.
> 
> For a kernel without CONFIG_MODULES, that's pure wasted space.  Why bother?
> Those are devices that "can't be present", so that's one of the cases where
> that "ignore the driver config" policy will indeed register such devices.

But constrained hardware designs for which memory usage is important 
that have the device available are likely to make use of that device 
anyway.  So in those cases it is pretty unlikely that the kernel config 
won't include the corresponding driver.

The case where the hardware does support a device but someone decided 
not to use it may have its kernel config exclude the corresponding 
driver.  But since this is most probably not the common case I don't 
think we should go as far as uglifying the code with conditional device 
registrations based on #if !defined(CONFIG_MODULE) && !defined(CONFIG_FOO)
just for the sake of saving as many bytes as possible.  That someone may 
as well comment out that device registration in his own source tree 
himself.

It is more likely that some hardware design that is not 
expected to use a particular device will simply not register that device 
in the first place and its default kernel config won't have the driver 
selected either.  In that sense I think Richard's patch is all that is 
needed for mainline.


Nicolas

  reply	other threads:[~2006-06-09  2:34 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
2006-06-09  1:25                               ` Nicolas Pitre
2006-06-09  2:03                                 ` David Brownell
2006-06-09  2:34                                   ` Nicolas Pitre [this message]
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=Pine.LNX.4.64.0606082217590.19403@localhost.localdomain \
    --to=nico@cam.org \
    --cc=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

all inboxes | Powered by JetHome®