linux-kernel - Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12

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: <1378828847.2627.347.camel@shinybook.infradead.org>
Date:	Tue, 10 Sep 2013 17:00:47 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Kevin Hilman <khilman@...aro.org>, ARM SoC <arm@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12

On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
> 
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware. 

But if I've got device <foo> attached to pin 15 of a GPIO controller
<bar>, surely that has to be programmed separately from the synthesis of
the two components <foo> and <bar>?

Yeah, if they really are all soft IP and we're *really* doing a whole
system on a single chip, we can do it all at the same time. But it isn't
always like that.

> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.

Setting aside the inter-component connections that are used to describe
a *board* rather than just a bag full of components, that's still far
from trivial to get right.

Let's assume you can take the same information we have in the
device-tree, and put it in the device itself to be accessed via
'configuration cycles'. Yes, you can certainly avoid having physically
separate EEPROMs for it.

But look at the abortion we've made ourselves of defining the 'bindings'
— the schemas which this extra information needs to conform to, in order
to support the full range of devices of a given type. That's where the
pain has *actually* been, and I suspect that's what's responsible for
the merge issues you were dealing with. Would that really be improved by
trying to force the various vendors of soft-IP peripherals do it
instead? Getting *them* to play along would be like herding cats... and
then they'd have to get their *customers*, who use their designs, to do
it right too in order for it to really work.

It's all very well saying "put it on the device and access it through
configuration cycles", but that doesn't actually address the part of the
problem that's been *most* problematic. If anything, I suspect it would
make it orders of magnitude worse.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5745 bytes)