[...] > > What I had in mind is replacing in_be32() with a esdhc_ops->readl() in this function. And the esdhc_ops->readl() would be assigned at the beginning according endian. > > static u32 esdhc_readl(struct sdhci_host *host, int reg) > { > u32 ret; > > ret = in_be32(host->ioaddr + reg); > /* > * The bit of ADMA flag in eSDHC is not compatible with standard > * SDHC register, so set fake flag SDHCI_CAN_DO_ADMA2 when ADMA is > * supported by eSDHC. > * And for many FSL eSDHC controller, the reset value of field > * SDHCI_CAN_DO_ADMA1 is one, but some of them can't support ADMA, > * only these vendor version is greater than 2.2/0x12 support ADMA. > * For FSL eSDHC, must aligned 4-byte, so use 0xFC to read the > * the verdor version number, oxFE is SDHCI_HOST_VERSION. > */ > if ((reg == SDHCI_CAPABILITIES) && (ret & SDHCI_CAN_DO_ADMA1)) { > u32 tmp = in_be32(host->ioaddr + SDHCI_SLOT_INT_STATUS); > tmp = (tmp & SDHCI_VENDOR_VER_MASK) >> SDHCI_VENDOR_VER_SHIFT; > if (tmp > VENDOR_V_22) > ret |= SDHCI_CAN_DO_ADMA2; > } > > return ret; > } > > The LE and BE accessors could be defined in sdhci-esdhc.h for esdhc_ops->readl() as below. > static u32 esdhc_be32bs_readl(struct sdhci_host *host, int reg) > { > return ioread32be(host->ioaddr + reg); > } > > static u32 esdhc_le32bs_readl(struct sdhci_host *host, int reg) > { > return ioread32(host->ioaddr + reg); > } > > Do you think it is ok for you? It becomes a bit "hacky", but currently I can't think of a better solution. > > > Or Maybe there is another method, use conditional compilation. The previous method would delete the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER to use accessors defined in sdhci-esdhc.h, and add dependency of ARM. This method could use 'select <accessors> if <ARCH>' to compile LE or BE accessors according ARCH. I don't really follow your suggestion. Isn't the problem that you need the MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER for configurations and for some you don't? More precisely, for those where you don't you would rather just use the regulator ioread* functions since those will internally deal with the endianess in runtime? If you can make these decisions at compile time an depending of the ARCH - I believe I would be fine with that as well. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html