On 7/10/2015 9:50 PM, scottwood at freescale.com (Scott Wood) wrote: > On Fri, 2015-07-10 at 13:29 -0500, Pledge Roy-R01356 wrote: >>> return in_be32((void *)bm + offset); >>>> ^ >>>> [...]/drivers/soc/fsl/qbman/bman.c: In function ‘__bm_out’: >>>> [...]/drivers/soc/fsl/qbman/bman.c:172:2: error: implicit declaration >>>> of function ‘out_be32’ [-Werror=implicit-function-declaration] >>>> out_be32((void *)bm + offset, val); >>> >>> These PPCisms will need to be fixed. LS1043A is an ARM chip with DPAA >>> 1.0. >> >> LS1043 (ARM, Little Endian) support is still work in progress. The patches >> for that are being tested now but are based on the SDK version of the >> driver and will need to be massaged in order to get them applied here. Our >> plan of record is to add upstream support for this at a later time. > > If you're already reworking this for upstream acceptance, why not fix the > more obvious PPCisms now?
Other drivers are facing similar problems wrt. I/O accessors. How should the problem be solved? For caam driver (drivers/crypto/caam) we have the following combinations: ARCH CORE CAAM SoC, options PPC BIG BIG P4080 etc. PPC BIG LITTLE N/A PPC LITTLE BIG P4080 + CONFIG_CPU_LITTLE_ENDIAN PPC LITTLE LITTLE N/A ARM LITTLE LITTLE LS1021A, LS2085A etc. ARM LITTLE BIG LS1043A ARM BIG LITTLE LS1021A + CONFIG_CPU_BIG_ENDIAN ARM BIG BIG LS1043A + CONFIG_CPU_BIG_ENDIAN Not all need to be supported, but for e.g. we are being requested to run on ARM in BE mode. Existing MMIO accessors have one of the following drawbacks: -readl/writel: on ARM do swapping (cpu <--> le), while on PPC are bus-specific (for PCI) -have weak semantics (no barriers / sequence points etc.), like __raw_* Thus, it looks like drivers have to define their own MMIO accessors, taking into account: -core endianness (which is independent of arch) -device endianness -already-defined MMIO accessors availability, depending on arch -semantics will have to match Unfortunately, the code will look terrible. In each driver. Thanks, Horia P.S. Sorry if the To/Cc list is screwed up, I've taken the message from the archive. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
