linux-kernel - Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <14122609.M29raBct1E@wuerfel>
Date:	Wed, 08 Jan 2014 21:09:17 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Thierry Reding <thierry.reding@...il.com>
Cc:	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
	Paul Walmsley <paul@...an.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>, linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...aro.org>,
	linux-omap@...r.kernel.org
Subject: Re: [PATCH] driver-core: platform: Resolve DT interrupt references late

On Wednesday 08 January 2014 20:59:10 Thierry Reding wrote:
> On Wed, Jan 08, 2014 at 05:25:17PM +0100, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014, Thierry Reding wrote:
> > > On Wed, Jan 08, 2014 at 04:11:08PM +0100, Arnd Bergmann wrote:
> > The more I think about the iommu case, the more I am convinced that it
> > does belong into the core, in whatever form we can find. As far as I
> > can tell from the little reliable information I have on the topic, I
> > would assume that we can keep it in the DT probing code, as there won't
> > be a need for multiple arbitrary IOMMUs with ACPI or with board files.
> 
> I think part of the problem is that we don't have any DT probing code
> yet. of_platform_probe() would have been that code. Perhaps if you weigh
> in Grant and Greg will reconsider.

For all I know, we don't even have a binding proposal, but I may
have missed that.

> > Good point, I forgot about the special case for i2c_client->irq.
> > I looked now and noticed that very few i2c devices actually use this
> > field, but larger number uses platform_data, which has a similar
> > problem.
> 
> Yeah. It's kind of messy. The more I think about it, the more I begin to
> like the lookup table option. One big advantage of that is that we could
> actually unify much of the lookup code, much like we do for other types
> of resources. It's a pattern that has worked fairly well in a number of
> cases, so it seems natural to use it for interrupts as well.
> 
> An even more extreme option would be to go all the way and introduce
> struct irq, along the same lines of the new struct gpiod. That would
> allow nice things such as storing trigger types and such within the IRQ
> handle and propagate them automatically.

We already have struct irq_desc, and I believe everybody who works
with interrupts supports migrating from irq number interfaces to
irq descriptors as soon as we can find someone willing to do that
work.
 
> > No trivial solution that I can see. I think we can deal with the case
> > where platform code uses platform_device->resources, and everything else
> > comes down to having multiple code branches in the driver, as we already
> > have to deal with platform_data and DT properties describing stuff that
> > doesn't fit in the resources.
> 
> That would be another argument in favour of the lookup table. It would
> provide a unified mechanism to define static interrupts if no firmware
> interface is available *independent* of the device type. You could have
> something like:
> 
> 	static const struct irq_lookup board_irq_lookup[] = {
> 		IRQ_LOOKUP("gpio", 0, "0-0040", NULL), /* I2C client via GPIO expander */
> 		IRQ_LOOKUP("intc", 0, "ehci.1", NULL), /* platform device via INTC */
> 	};
> 
> Along with:
> 
> 	struct irq *irq_get(struct device *dev, const char *con_id);
> 
> To look it up via DT, ACPI, lookup table. That obviously means a more or
> less complete change in how interrupts are handled in the kernel, and it
> may not be worth it in the end.

It would certainly need a long migration period, and a plan for how to
get there without breaking things in the meantime. Rather than a lookup
table like the kind we have for clocks, I'd prefer a general way to
attach named properties to devices. My feeling is that building upon
devres would be a good plan, since it already provides a way to attach
arbitrary data to a device.

	Arnd

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