Re: [PATCH 1/2] Input: DaVinci Keypad Driver

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Wed, Sep 23, 2009 at 04:05:43PM -0700, David Brownell wrote:
> On Wednesday 23 September 2009, Dmitry Torokhov wrote:
> > This is one possible design... however you are not talking about the
> > current Linux kernel but some other OS.
> 
> What other OS might it be then, which has carried around
> that exit section scrubbing mechanism for quite a few years
> now, and is distributed through www.kernel.org with labels
> such as "Linux 2.6.31" ???
> 

It can't be it since it does not exibit the behavior you are describing.

> 
> > > And thus, if any code is presuming that *every* driver
> > > can be unbound, it's wrong.
> > > 
> > > As I said:  bug in other code.
> > 
> > Not an implementation bug, the system behaves as designed.
> 
> Yes, absolutely an implementation bug.
> 
> At best you can say that there are two "designs" that
> are in conflict with each other.  And argue, for some
> reason, that the relatively-recently-introduced oops
> (OK, mid-2005, so it's been lurking for quite a while)
> is "more intended" than the previous safe-no-oops one
> (predating mid-2005 by many years).

Driver model was introduced what, 7 years ago? And since then at no
point remove methods() could be __devexit.

> 
> 
> > > Looking at this a bit more, it seems like there will need
> > > to be some "can this bus remove this driver" check, since
> > > the struct device.remove method is now managed at the bus
> > > level.  Easy enough to do instead of the null check that
> > > I mentioned below.  Provide it for platform bus, and the
> > > main potential trouble spots will be resolved.
> > 
> > 		... deletia ...
> > 
> 
> > I am talking about current design of the Linux driver code, as it is
> > present in mainline and in this particular instance probe() and remove()
> > do not do what you think they do. 
> 
> You're arguing about what it "should" do, and ignoring
> all the evidence I've provided.  So I guess "talking"
> is right, not "listening" or better yet "discussing".
>

Ok, then let me tell this once again since you snipped it off:

Until driver model is fixed so that using unbind sysfs attribute does not
cause trouble if devices discard their remove methods I will not accept
or ack drivers that mark their remove() methods as __exit.

-- 
Dmitry