[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150408134857.GA5585@kroah.com>
Date: Wed, 8 Apr 2015 15:48:57 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc: Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
dan.carpenter@...cle.com
Subject: Re: [PATCH v2 1/2] parport: return of attach and
parport_register_driver
On Wed, Apr 08, 2015 at 07:00:16PM +0530, Sudip Mukherjee wrote:
> as of now, we are not checking if attach or parport_register_driver
> has succeeded or failed. But attach can fail in the places where they
> have been used. Lets create an attach_ret where we will check the
> return of attach, and if attach fails then parport_register_driver
> should also fail. We can have multiple parallel port, like parport0,
> parport1 and one driver may decide to only use parport0. so we mark
> attach as failed only if it has never returned a 0.
>
> Signed-off-by: Sudip Mukherjee <sudip@...torindia.org>
> ---
> drivers/parport/share.c | 27 ++++++++++++++++++++++-----
> include/linux/parport.h | 1 +
> 2 files changed, 23 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/parport/share.c b/drivers/parport/share.c
> index 3fa6624..4aab733 100644
> --- a/drivers/parport/share.c
> +++ b/drivers/parport/share.c
> @@ -143,28 +143,45 @@ static void get_lowlevel_driver (void)
> * pointer it must call parport_get_port() to do so. Calling
> * parport_register_device() on that port will do this for you.
> *
> + * The attach_ret() function will check for the return value.
> + *
> * The driver's detach() function may block. The port that
> * detach() is given will be valid for the duration of the
> * callback, but if the driver wants to take a copy of the
> * pointer it must call parport_get_port() to do so.
> *
> - * Returns 0 on success. Currently it always succeeds.
> + * Returns 0 on success.
> **/
>
> int parport_register_driver (struct parport_driver *drv)
> {
> struct parport *port;
> + bool attached = false;
> + int err, ret = 0;
>
> if (list_empty(&portlist))
> get_lowlevel_driver ();
>
> mutex_lock(®istration_lock);
> - list_for_each_entry(port, &portlist, list)
> - drv->attach(port);
> - list_add(&drv->list, &drivers);
> + list_for_each_entry(port, &portlist, list) {
> + if (drv->attach_ret) {
> + err = drv->attach_ret(port);
> + } else {
> + drv->attach(port);
> + err = 0;
> + }
> + if (err == 0)
> + attached = true;
> + else
> + ret = err;
> + }
> + if (attached) {
> + list_add(&drv->list, &drivers);
> + ret = 0;
> + }
> mutex_unlock(®istration_lock);
>
> - return 0;
> + return ret;
> }
What really needs to happen is for the parport subsystem to move to the
driver model, which I don't think ever happened way back during the 2.5
development cycle. When that happens, then you will not have code like
this, and the drivers will work "properly"...
That's a much larger task, especially trying to do it without breaking
anything along the way, but it's the "correct" thing to do.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists