[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1227188008.22263.9.camel@ted>
Date: Thu, 20 Nov 2008 13:33:28 +0000
From: Richard Purdie <rpurdie@...ux.intel.com>
To: me@...ipebalbi.com
Cc: linux-kernel@...r.kernel.org,
Felipe Balbi <felipe.balbi@...ia.com>,
Anton Vorontsov <cbou@...l.ru>,
David Woodhouse <dwmw2@...radead.org>,
Greg KH <greg@...ah.com>, Pierre Ossman <drzeus@...eus.cx>
Subject: Re: [PATCH] led: simplify led_trigger_register_simple
On Thu, 2008-11-13 at 21:10 +0200, Felipe Balbi wrote:
> On Thu, Nov 13, 2008 at 08:14:16PM +0200, Felipe Balbi wrote:
> > On Thu, Nov 13, 2008 at 12:38:32PM +0000, Richard Purdie wrote:
> > > The simple triggers were designed to cause minimum interference to the
> > > usually external subsystem code they were added into. As an example this
> > > meant things like errors were just handled gracefully with a printk
> > > warning and did not take down the whole subsystem. I therefore don't
> > > regard this patch as a simplification, more a complication.
> >
> > That's a matter of changing the return ERR_PTR(err); back to a printk.
>
> And here you are. I still think we should at least kfree(trigger) in
> case of error, though.
This patch now just changes the calling convention of the function which
doesn't seem to serve much purpose.
In answer to your question about kfree, I agree it needs to be called
upon error. The callers should just be calling
led_trigger_unregister_simple() in their failure paths though which
should take care of all problems? I know we used to register the simple
triggers late in paths so no error handling was needed to keep the code
simple and minimise the LED triggers impact on those systems.
Cheers,
Richard
--
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