On 09/10/2013 09:31 AM, Linus Torvalds wrote: > On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
