/openbmc/linux/arch/mips/include/asm/mach-ip30/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
/openbmc/linux/arch/mips/include/asm/mach-generic/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
/openbmc/linux/arch/mips/include/asm/mach-ip32/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
/openbmc/linux/arch/mips/include/asm/mach-ip27/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
/openbmc/linux/arch/mips/include/asm/mach-tx49xx/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|
/openbmc/linux/arch/mips/include/asm/mach-cavium-octeon/ |
H A D | mangle-port.h | 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h
MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting.
We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> 7b5f9694 Sat Jun 20 04:34:51 CDT 2020 Alexander Lobakin <alobakin@pm.me> MIPS: io: fix sparse flood on asm/io.h MIPS MMIO macros for byteswapping from/to hardware endianness are a bit tricky because they use cpu_to_le{16,32,64}() in both directions. This generates a lot of questions from sparse as __le{16,32,64} types are 'restricted' and direct cast is forbidden in order to prevent messing up the byteorder. As MMIO ops are used in almost every single driver, this leads to console flooding and complicates bug hunting. We could fix it in a more proper way, i.e. separate from device / to device byteswap macros and expand __BUILD_MEMORY_*(), but this seems redundant and will produce code duplication. Instead, just expand the existing *ioswab*() macros with forced typecasting to stop floods. Signed-off-by: Alexander Lobakin <alobakin@pm.me> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
|