From: Josh Triplett <josh@joshtriplett.org>
To: Greg KH <greg@kroah.com>
Cc: "G, Manjunath Kondaiah" <manjugk@ti.com>,
linux-arm-kernel@lists.infradead.org,
Grant Likely <grant.likely@secretlab.ca>,
linux-omap@vger.kernel.org, linux-mmc@vger.kernel.org,
linux-kernel@vger.kernel.org, Dilan Lee <dilee@nvidia.com>,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Manjunath@jasper.es
Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Date: Fri, 7 Oct 2011 21:03:51 -0700 [thread overview]
Message-ID: <20111008040351.GA7694@leaf> (raw)
In-Reply-To: <20111007212326.GA29003@kroah.com>
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > +config PROBE_DEFER
> > > > + bool "Deferred Driver Probe"
> > > > + default y
> > > > + help
> > > > + This option provides deferring driver probe if it has dependency on
> > > > + other driver. Without this feature, initcall ordering should be done
> > > > + manually to resolve driver dependencies. This feature completely side
> > > > + steps the issues by allowing driver registration to occur in any
> > > > + order, and any driver can request to be retried after a few more other
> > > > + drivers get probed.
> > >
> > > Why is this even an option? Why would you ever want it disabled? Why
> > > does it need to be selected?
> > >
> > > If you are going to default something to 'y' then just make it so it
> > > can't be turned off any other way by just not making it an option at
> > > all.
> >
> > Given that the drivers which use this mechanism will not necessarily get
> > built into the kernel, I'd suggest that it should remain optional and
> > default to n. Those drivers can then add a dependency on PROBE_DEFER.
> > Let's try to avoid adding more infrastructure to the kernel that takes
> > up space even when unused; certainly embedded will appreciate not having
> > this feature unless a driver needs it.
>
> How much extra space is this "feature" really?
Just checked: 776 bytes, 640 of text and 136 of data. We have kconfig
options for comparable amounts.
> I don't see it being
> anything larger than the amount of memory increase that just happened as
> I typed this email as part of the ongoing memory density changes.
I don't know about the changes you mean, but in any case I'd like to
prevent mandatory size increases wherever possible. I'd love to see the
size of "allnoconfig" getting *smaller* over time, not larger.
- Josh Triplett
WARNING: multiple messages have this Message-ID (diff)
From: josh@joshtriplett.org (Josh Triplett)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
Date: Fri, 7 Oct 2011 21:03:51 -0700 [thread overview]
Message-ID: <20111008040351.GA7694@leaf> (raw)
In-Reply-To: <20111007212326.GA29003@kroah.com>
On Fri, Oct 07, 2011 at 02:23:26PM -0700, Greg KH wrote:
> On Fri, Oct 07, 2011 at 01:57:15PM -0700, Josh Triplett wrote:
> > On Thu, Oct 06, 2011 at 11:49:28PM -0700, Greg KH wrote:
> > > On Fri, Oct 07, 2011 at 10:33:07AM +0500, G, Manjunath Kondaiah wrote:
> > > > +config PROBE_DEFER
> > > > + bool "Deferred Driver Probe"
> > > > + default y
> > > > + help
> > > > + This option provides deferring driver probe if it has dependency on
> > > > + other driver. Without this feature, initcall ordering should be done
> > > > + manually to resolve driver dependencies. This feature completely side
> > > > + steps the issues by allowing driver registration to occur in any
> > > > + order, and any driver can request to be retried after a few more other
> > > > + drivers get probed.
> > >
> > > Why is this even an option? Why would you ever want it disabled? Why
> > > does it need to be selected?
> > >
> > > If you are going to default something to 'y' then just make it so it
> > > can't be turned off any other way by just not making it an option at
> > > all.
> >
> > Given that the drivers which use this mechanism will not necessarily get
> > built into the kernel, I'd suggest that it should remain optional and
> > default to n. Those drivers can then add a dependency on PROBE_DEFER.
> > Let's try to avoid adding more infrastructure to the kernel that takes
> > up space even when unused; certainly embedded will appreciate not having
> > this feature unless a driver needs it.
>
> How much extra space is this "feature" really?
Just checked: 776 bytes, 640 of text and 136 of data. We have kconfig
options for comparable amounts.
> I don't see it being
> anything larger than the amount of memory increase that just happened as
> I typed this email as part of the ongoing memory density changes.
I don't know about the changes you mean, but in any case I'd like to
prevent mandatory size increases wherever possible. I'd love to see the
size of "allnoconfig" getting *smaller* over time, not larger.
- Josh Triplett
next prev parent reply other threads:[~2011-10-08 4:04 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-07 5:33 [PATCH 0/5] Driver Probe Deferral Mechanism G, Manjunath Kondaiah
2011-10-07 5:33 ` [PATCH 1/5] drivercore: add new error value for deferred probe G, Manjunath Kondaiah
2011-10-07 6:43 ` Greg KH
2011-10-07 6:43 ` Greg KH
2011-10-07 10:00 ` Mark Brown
2011-10-07 10:00 ` Mark Brown
2011-10-07 22:12 ` Grant Likely
2011-10-07 22:12 ` Grant Likely
2011-10-07 23:28 ` Valdis.Kletnieks
2011-10-07 23:28 ` Valdis.Kletnieks
2011-10-07 23:28 ` Valdis.Kletnieks at vt.edu
2011-10-08 0:12 ` Greg KH
2011-10-08 0:12 ` Greg KH
2011-10-09 22:59 ` Grant Likely
2011-10-09 22:59 ` Grant Likely
2011-10-09 22:59 ` Grant Likely
2011-10-10 1:06 ` Greg KH
2011-10-10 1:06 ` Greg KH
2011-10-10 1:06 ` Greg KH
2011-10-12 6:18 ` G, Manjunath Kondaiah
2011-10-12 6:18 ` G, Manjunath Kondaiah
2011-10-13 4:10 ` Grant Likely
2011-10-13 4:10 ` Grant Likely
2011-10-07 5:33 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah
2011-10-07 6:49 ` Greg KH
2011-10-07 6:49 ` Greg KH
2011-10-07 20:57 ` Josh Triplett
2011-10-07 20:57 ` Josh Triplett
2011-10-07 21:23 ` Greg KH
2011-10-07 21:23 ` Greg KH
2011-10-08 4:03 ` Josh Triplett [this message]
2011-10-08 4:03 ` Josh Triplett
2011-10-08 15:55 ` Greg KH
2011-10-08 15:55 ` Greg KH
2011-10-08 18:18 ` Josh Triplett
2011-10-08 18:18 ` Josh Triplett
2011-10-10 17:37 ` Andrei Warkentin
2011-10-10 17:37 ` Andrei Warkentin
2011-10-11 12:29 ` Ming Lei
2011-10-11 12:29 ` Ming Lei
2011-10-13 4:09 ` Grant Likely
2011-10-13 4:09 ` Grant Likely
2011-10-13 14:18 ` Ming Lei
2011-10-13 14:18 ` Ming Lei
2011-10-13 14:31 ` Alan Stern
2011-10-13 14:31 ` Alan Stern
2011-10-13 14:31 ` Alan Stern
2011-10-13 15:21 ` Ming Lei
2011-10-13 15:21 ` Ming Lei
2011-10-13 16:04 ` Alan Stern
2011-10-13 16:04 ` Alan Stern
2011-10-13 16:04 ` Alan Stern
2011-10-14 0:13 ` Ming Lei
2011-10-14 0:13 ` Ming Lei
2011-10-13 17:15 ` Grant Likely
2011-10-13 17:15 ` Grant Likely
2011-10-13 18:16 ` Alan Stern
2011-10-13 18:16 ` Alan Stern
2011-10-13 18:16 ` Alan Stern
2011-10-13 18:28 ` Grant Likely
2011-10-13 18:28 ` Grant Likely
2011-10-14 15:39 ` Alan Stern
2011-10-14 15:39 ` Alan Stern
2011-10-14 15:39 ` Alan Stern
2011-10-14 16:17 ` Grant Likely
2011-10-14 16:17 ` Grant Likely
2011-10-14 16:33 ` Alan Stern
2011-10-14 16:33 ` Alan Stern
2011-10-14 16:33 ` Alan Stern
2011-10-14 17:20 ` Grant Likely
2011-10-14 17:20 ` Grant Likely
2011-10-14 17:33 ` Alan Stern
2011-10-14 17:33 ` Alan Stern
2011-10-14 17:33 ` Alan Stern
2011-10-14 18:25 ` Grant Likely
2011-10-14 18:25 ` Grant Likely
2011-10-14 18:39 ` Alan Stern
2011-10-14 18:39 ` Alan Stern
2011-10-14 18:39 ` Alan Stern
2011-10-14 19:07 ` Grant Likely
2011-10-14 19:07 ` Grant Likely
2011-10-14 18:56 ` David Daney
2011-10-14 18:56 ` David Daney
2011-10-14 19:03 ` Grant Likely
2011-10-14 19:03 ` Grant Likely
2011-10-14 19:03 ` Grant Likely
2011-10-14 19:09 ` David Daney
2011-10-14 19:09 ` David Daney
2011-10-14 15:37 ` Alan Stern
2011-10-14 15:37 ` Alan Stern
2011-10-14 15:37 ` Alan Stern
2011-10-12 7:04 ` G, Manjunath Kondaiah
2011-10-12 7:04 ` G, Manjunath Kondaiah
2011-10-07 21:28 ` Grant Likely
2011-10-07 21:28 ` Grant Likely
2011-10-07 21:28 ` Grant Likely
2011-10-07 5:33 ` [PATCH 3/5] regulator: Support driver probe deferral G, Manjunath Kondaiah
2011-10-07 5:33 ` [PATCH 4/5] gpiolib: handle deferral probe error G, Manjunath Kondaiah
2011-10-07 10:06 ` Alan Cox
2011-10-07 10:06 ` Alan Cox
2011-10-07 10:06 ` Alan Cox
2011-10-07 22:09 ` Grant Likely
2011-10-07 22:09 ` Grant Likely
2011-10-12 6:14 ` G, Manjunath Kondaiah
2011-10-12 6:14 ` G, Manjunath Kondaiah
2011-10-12 6:14 ` G, Manjunath Kondaiah
2011-10-13 4:12 ` Grant Likely
2011-10-13 4:12 ` Grant Likely
2011-10-07 5:33 ` [PATCH 5/5] omap: hsmmc: use platform_driver_register G, Manjunath Kondaiah
2011-10-07 6:50 ` [PATCH 0/5] Driver Probe Deferral Mechanism Greg KH
2011-10-07 6:50 ` Greg KH
2011-10-07 6:50 ` Greg KH
2011-10-07 7:37 ` G, Manjunath Kondaiah
2011-10-07 7:37 ` G, Manjunath Kondaiah
2011-10-07 7:37 ` G, Manjunath Kondaiah
-- strict thread matches above, loose matches on Subject: below --
2011-10-07 5:05 G, Manjunath Kondaiah
2011-10-07 5:05 ` [PATCH 2/5] drivercore: Add driver probe deferral mechanism G, Manjunath Kondaiah
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=20111008040351.GA7694@leaf \
--to=josh@joshtriplett.org \
--cc=Manjunath@jasper.es \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=dilee@nvidia.com \
--cc=grant.likely@secretlab.ca \
--cc=greg@kroah.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=manjugk@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.