linux-kernel - RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature

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]

Date:	Tue, 18 Jun 2013 09:01:32 +0000
From:	"J, KEERTHY" <j-keerthy@...com>
To:	Mark Brown <broonie@...nel.org>
CC:	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"ldewangan@...dia.com" <ldewangan@...dia.com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"swarren@...dia.com" <swarren@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>
Subject: RE: [PATCH 1/4] MFD: Palmas: Add Interrupt feature

Hi Mark,


> -----Original Message-----
> From: Mark Brown [mailto:broonie@...nel.org]
> Sent: Tuesday, June 18, 2013 2:28 PM
> To: J, KEERTHY
> Cc: linux-omap@...r.kernel.org; ldewangan@...dia.com;
> sameo@...ux.intel.com; grant.likely@...retlab.ca; swarren@...dia.com;
> linux-kernel@...r.kernel.org; linux-doc@...r.kernel.org;
> gg@...mlogic.co.uk
> Subject: Re: [PATCH 1/4] MFD: Palmas: Add Interrupt feature
> 
> On Tue, Jun 18, 2013 at 05:15:03AM +0000, J, KEERTHY wrote:
> 
> > I understand your point. The IRQ is passed from device tree node.
> > Say if the chip for some reason is not connected to any valid IRQ
> line
> > the driver might end up requesting for a wrong IRQ line.
> 
> > So should I be validating the irq entry populated from  device tree?
> 
> Yes, you should be checking that there's actually an interrupt there -
> the number will be zero if there isn't.
> 
> > Explicitly checking on chip ID helps to avoid wrongly populated
> Device
> > tree data.
> 
> Right, but on the other hand it ought to be possible to handle chips
> that could but aren't configured to do interrupts and if the driver can
> do that then this becomes redundant.

I understood. I am now implementing this in the driver making use
Of the of_parse_phandle and check if the interrupts property is
Populated and only then request for irq else skip that. Hope this
Approach is fine. I will send v2 in a while.

Regards,
Keerthy
--
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/