On Mon, Aug 29, 2016 at 5:44 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Saturday, August 27, 2016 12:56:10 PM CEST Florian Fainelli wrote: >> >> Finally, Arnd's suggestions of using "dma-ranges" is fine, but I do not >> think we quite need this here because we really need to advertise the >> right set of capabilities based on the generation/version of the >> controller deployed in specific chips. > > To be more specific here, I think that without the dma-ranges property > you should never be able to set a dma-mask larger than the 32-bit > mask, so if you have machines that are capable of high DMA, you > should definitely add the property in the bus, even if that is > currently ignored. > > I've suggested a patch before, but I believe both ARM and MIPS ignore > this at the moment, and just allow drivers to set arbitrary masks > even when the bus does not have a dma-ranges property, and that > is a bug. I think there's some confusion over the core issue so let be summarize. The SDHCI host controller CAPABILITIES register bit 28 indicates if the host controller hardware can support 64 bit addresses using the larger 96 bit DMA descriptors. We currently don't have any SoCs that have this support, even our current 64bit ARM SoCs don't support this, though there are future ARM SoCs that will have this support. The bug is that a few MIPS based SoCs had this bit incorrectly set even though the hardware did not support it and this caused the driver to use the larger DMA descriptors which crashed the driver. All we're trying to fix here is a simple SDHCI host controller hardware bug where a CAPs bit is a 1 where it should be a 0. Our future 64 ARM chips that do support 64bit addressing should be the only chips with this bit set. Al -- 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
