Re: [PATCH 0/4] Current ad7879 patches

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

On Wed, Jun 30, 2010 at 09:40:54AM +0100, Hennerich, Michael wrote:
> Dmitry Torokhov wrote on 2010-06-30:
> > On Tue, Jun 29, 2010 at 01:10:38PM +0100, Hennerich, Michael wrote:
> >> Dmitry Torokhov wrote on 2010-06-25:
> >>> Mike, Michael,
> >>>
> >>> I was looking through outstanding patches to ad7879 and here they are.
> >>> Since I made some changes to the patches you wrote and there also some
> >>> new code and I do not have the hardware I'd appreciate if you could
> >>> try them out so they can be applied.
> >>>
> >>> Thank you.
> >>>
> >>
> >> Hi Dmitry,
> >>
> >> I tested your ad7879 patch set -
> >> A few issues see patch below.
> >>
> >> -Fix ad7879_probe() parameter passing. -Add missing input_set_drvdata()
> >> -Avoid unbalanced irq enable warning: disable_irq() after request. -Fix
> >> sysfs disable hook logic: the file is called disable so don't treat it
> >> as enable.
> >>
> >
> > Thanks for catching all the mistakes Michael. Regardgin disable_irq()
> > - do you think it would be even better to call __ad7879_disable()
> > there to make sure the chip is in low power mode?
> 
> Right - __ad7879_disable() is a good option here.
> 
> > And I guess we need
> > to add matching enable_irq() in error handlig path and in
> > ad7879_remove() in case we reload the driver...
> 
> I don't see a problem here. free_irq() will take care and unconditional
> disable the irq for us. Both the error return as well as the module
> remove path will call free_irq().

free_irq() will disable the irq in the chip and will set desc->action to
NULL but will not alter desc->depth as far as I can see.

I guess we can rely on the fact that request_irq resets desc->depth for
non-shared IRQs...

-- 
Dmitry