Re: [PATCH] Input: drivers/joystick: use parallel port device model

[Sudip Mukherjee]

On Tue, Aug 04, 2015 at 11:41:28AM -0700, Dmitry Torokhov wrote:
> On Mon, Aug 03, 2015 at 08:32:20PM +0530, Sudip Mukherjee wrote:
> > On Fri, Jul 31, 2015 at 01:43:06PM -0700, Dmitry Torokhov wrote:
> > > > 
> > > > Converting to the "new" api is the end goal here, no need to keep the
> > > > old one around anymore.
> > > 
> > > OK, then I guess we can do the conversion right (dropping db9_base
> > > module-global) and see if anyone screams at us.
> > Hi Dmitry,
<snip>	
> > NULL, but the code will get unnecessary complicated. And these are not
> > just hypothetical situtation I got them while testing.
> > I am ready to make the changes, just want your confirmation if it is
> > worth complicatng the code and taking risk just for removing one global
> > variable.
> 
> Hmm, it is quite unexpected that detach() is called even if attach() did
> not actually attach anything.
But that is the way original parallel port used to work. And this adding
the device model code was mainly done keeping the original behaviour of
the code. In the original code the register_driver did:
list_for_each_entry(port, &portlist, list)
	drv->attach(port);
list_add(&drv->list, &drivers);

And the unregister_driver did:
list_for_each_entry(port, &portlist, list)
	drv->detach(port);

So, the original code never checked if attach succeded or not, and used
to call detach whenever driver used to unregister even if attach failed.
It was on the driver to check for and maintain the status.

> Maybe it is not too late if attach() would return a pointer to:
But that will change the way the parallel port client drivers used to
work. Maybe, for now we should stick to the old existing behaviour until
all the conversion is complete (hopefully without any regression). And
after we have fully converted to device model then we can plan to improve
it.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/