Re: [PATCH] Input: tca6416-keypad: Change to module_init()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 23, 2011 at 12:22:05AM +0900, Magnus Damm wrote:
> On Tue, Mar 22, 2011 at 11:33 PM, Paul Mundt <lethal@xxxxxxxxxxxx> wrote:
> > On Tue, Mar 22, 2011 at 02:28:55PM +0000, Mark Brown wrote:
> >> On Tue, Mar 22, 2011 at 11:26:19PM +0900, Magnus Damm wrote:
> >>
> >> > The tca6416 driver makes use of the I2C bus for chatting
> >> > with the actual hardware device. Without this patch both
> >> > the I2C bus driver and the tca6416 driver are initialized
> >> > at the subsys_initcall() level. This may lead to problems
> >> > with the tca6416 driver being initialized before the I2C
> >> > bus driver.
> >>
> >> While this change seems reasonable I'm curious what the problems caused
> >> by out of order registration are?
> >
> > I'm also curious as to why link order isn't a sufficient gaurantee like
> > it is for everyone else?
> 
> I believe all other i2c keyboard drivers use module_init().
> 
We do not change initcall ordering around unless there is a reason to do
so, as it's assumed that a given initcall has been chosen for a reason.
You have hit upon a bug or at least something timing related causing you
a delay and so have elected to push it down a level. That is of course
fine, but none of that is anywhere in your commit text leaving us to try
and figure out what exactly the point of this exercise is.

Usually "because everyone else is doing it" and another driver is not,
there's a reason for that driver doing things differently. There are
certainly enough cases where initcall and link ordering is strongly
ordered for a reason that cosmetic/janitorial fixes are best rejected out
of hand.

You had a reason, great. Next time put it in your commit text.
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux