On Tue, Jan 28, 2014 at 11:48:10AM +0100, Arnd Bergmann wrote: > I think there is another option, which does have its own pros and cons: > We could move all the power handling back into the sdio function driver > if we allow a secondary detection path using DT rather than the probing > of the SDIO bus. No thanks. What if we have a platform where things subtly change, like for instance, the wiring on the SD slot to fix a problem with UHS-1 cards, which means you don't have UHS-1 support for some platforms but do for others. What if you have a platform which uses a brcm4329 chip for Wifi, but then later in the production run switch to using a different Wifi chipset? With this information encoded into DT, the number of DT files quickly increases, and then this presents its own problem - how do users get to know which DT file should be used for their platform when all they see externally is "a product of type A"? Let's say that the board folk were kind enough to set some kind of identifing feature for the first but not the second (why would they, it's probe-able, damn it). The "we can do it in DT" approach just makes things unnecessarily more difficult from the _user_ and _hardware_ point of view. -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit". -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
