linux-kernel - Re: SPARC and OF

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: <20121130.114651.461648561907776096.davem@davemloft.net>
Date:	Fri, 30 Nov 2012 11:46:51 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	grant.likely@...retlab.ca
Cc:	thierry.reding@...onic-design.de, sparclinux@...r.kernel.org,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org
Subject: Re: SPARC and OF_GPIO

From: Grant Likely <grant.likely@...retlab.ca>
Date: Fri, 30 Nov 2012 09:35:20 +0000

> On non-sparc I've actually been moving in the direction of resolving
> resources at .probe time to make it easier to handle deferred probing.
> So if, for example, a device irq line is routed to a GPIO instead of the
> core interrupt controller, then the irq number won't be known until
> after the gpio driver .probe occurs. For addresses, this situation is
> unlikely, but for all the other kinds of resources (gpios, regs, clocks, irqs,
> etc) it is a problem that we're actually seeing.

Every interrupt in the device tree is resolvable with, at worst, very
small bus drivers, and that's what we pack into the generic sparc OF
device creation layer.

Actually much of it is generic and not bus type specific at all, and
is a simply mask and match into an interrupt routing table property.
--
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/