linux-kernel - Re: [Patch v3 7/7] Onkey: DA9055 Onkey driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1350024404.11527.3.camel@dhruva>
Date:	Fri, 12 Oct 2012 12:16:44 +0530
From:	Ashish Jangam <ashish.jangam@...tcummins.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Liam Girdwood <lrg@...mlogic.co.uk>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	<linux-input@...r.kernel.org>,
	David Dajun Chen <dchen@...semi.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Patch v3 7/7] Onkey: DA9055 Onkey driver

On Thu, 2012-10-11 at 09:28 -0700, Dmitry Torokhov wrote:
> Hi Ashish,
> 
> On Thu, Oct 11, 2012 at 04:15:16PM +0530, Ashish Jangam wrote:
> > This is the ONKEY driver of the Dialog DA9055 PMIC and depends on the DA9055 MFD
> > core driver.
> > 
> > This patch is functionally tested on SMDK6410 board.
> > 
> > Signed-off-by: David Dajun Chen <dchen@...semi.com>
> > Signed-off-by: Ashish Jangam <ashish.jangam@...tcummins.com>
> > ---
> > changes since v3:
> > - used of module_platform_driver macro
> > - add regmap virtual irq function
> > changes since v2:
> > - add support for button release
> > - use of devm_request_threaded_irq API
> 
> This API does not make any sense for your driver as you are scheduling
> delayed work from the IRQ handler. In such cases you need _first_ free
> IRQ and _then_ cancel the work but with devm_* you do it in opposite
> order.
I miss on this, will correct it.
> 
> Also, I think I mentioned this before - this driver looks like twin
> brother for da9055_onkey.c. How many of such parts do you have (or will
> you have)? Is there way to unify them?
Well, DA9052 and DA9055 register sets are entirely different even there
bit position are different and also few of its components have slight
different behaviour.  Device components functional difference can be
managed programmatic but, to unify these two different sets of register
will be impractical. In case of DA9052 I managed to club the DA9053
functionality within it but it was not possible for DA9055.
> 
> Thanks.
> 


--
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/