linux-kernel - Re: [PATCH 01/11] MFD: DA9052 MFD core module v8

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: <20111204155912.GB16287@opensource.wolfsonmicro.com>
Date:	Sun, 4 Dec 2011 15:59:12 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ashish Jangam <Ashish.Jangam@...tcummins.com>
Cc:	"arnd@...db.de" <arnd@...db.de>,
	"sameo@...nedhand.com" <sameo@...nedhand.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Dajun <dajun.chen@...semi.com>,
	"linaro-dev@...ts.linaro.org" <linaro-dev@...ts.linaro.org>
Subject: Re: [PATCH 01/11] MFD: DA9052 MFD core module v8

On Sun, Dec 04, 2011 at 11:50:02AM +0000, Ashish Jangam wrote:

You should fix your mailer to word wrap at less than 80 columns, I've
reflowed your text for legibility.

> > > regmap-irq has a opaque struct regmap_irq_chip_data which has a member
> > > irq_base and this is required for non-primary irqs registration
> > > and also the clean-up function regmap_del_irq_chip() requires it.
> > > So as of now I will keep the current irq implementation as it is.

> > I'm not sure how this is relevant to my above comment?  The struct is of
> > course opaque since it is only used by the implementation.

> No issues on that but it has got irq_base as its member which gets
> initialize in the function regmap_add_irq_chip() and since this member
> value is not available to the user how can the mfd dependent modules
> like touch, battery etc can register for interrupt because during irq
> registration we add irq_base to the irq nmber for e.g. irq_base +
> battery_irq  

There's several straightforward solutions to that - for example, we can
add an accessor to retrieve the information, we can use resources to
pass the interrupt ranges to the MFD children or we can have the core
remember the interrupt base it's passing on to the children.

Whichever one we choose we can certainly solve the problem without
replicating the entire interrupt controller implementation.
--
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/