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

Date:	Tue, 10 Sep 2013 09:43:25 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	David Woodhouse <dwmw2@...radead.org>,
	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 09/10/2013 09:31 AM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2@...radead.org> wrote:
>>
>> In cost-sensitive products (and what *isn't* cost-sensitive these days),
>> you really don't want to have to put an extra EEPROM on the board
>> somewhere
> 
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware. That way lies madness and
> the usual firmware crazies.
> 
> 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.
> 
> But no, every SoC designer out there seems to want to make their
> hardware crap. Don't be surprised when I then call them out on the
> fact. And don't bring up totally irrelevant issues that have nothing
> to do with anything.

(Many of) the buses aren't something that ARM SoC designers invented
though; they're industry standard things like I2C, SPI, I2S, all of
which are supported by SoC manufacturers solely because there are huge
numbers of useful chips that attach to these buses, from many many
manufacturers. This is an industry issue, not some evil conspiracy by
ARM SoC vendors.

True, it'd be lovely if those standard buses were discoverable; if the
industry had ended up with more advanced buses (although again: cost, to
implement those features, even if embedded into the chip itself rather
than as an external component).

Now, there are certainly cases where everybody just does their own silly
thing in HW, such as using GPIOs from a separate GPIO controller for SD
card detect and write-protect signals, rather than having the SDHCI
controller handle those functions, and hence be standalone. So from that
perspective your point is justified. However, solving this aspect would
only solve part of the problem.

x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
LM90 thermal sensors. However, I /think/ this all gets hidden from the
OS by ACPI or other firmware mechanisms. Do you prefer firmware
abstraction over DT?
--
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/