Messages in this thread | | | Subject | Re: [PATCH] x86/calgary: fix bitcast type warnings | From | Mukesh Ojha <> | Date | Sat, 30 Mar 2019 15:54:23 +0530 |
| |
On 3/30/2019 3:15 AM, Jann Horn wrote: > On Fri, Mar 29, 2019 at 9:19 AM Mukesh Ojha <mojha@codeaurora.org> wrote: >> On 3/29/2019 4:29 AM, Jann Horn wrote: >>> The sparse checker attempts to ensure that all conversions between >>> fixed-endianness numbers and numbers with native endianness are explicit. >>> However, the calgary code reads and writes big-endian numbers from/to IO >>> memory using {read,write}{l,q}(), which return native-endian numbers. >>> >>> This could be addressed by putting __force casts all over the place, but >>> that would kind of defeat the point of the warning. Instead, create new >>> helpers {read,write}{l,q}_be() for big-endian IO that convert from/to >>> native endianness. >>> >>> Most of this patch is a straightforward conversion; the following parts >>> aren't just mechanical replacement: >>> >>> - ->tar_val is now a native-endian number instead of big-endian >>> - calioc2_handle_quirks() did `cpu_to_be32(readl(target))` when it >>> intended to do `be32_to_cpu(readl(target))` (but that has no actual >>> effects outside of type warnings) >>> >>> This gets rid of 108 lines of sparse warnings. >>> >>> Signed-off-by: Jann Horn <jannh@google.com> >>> --- >>> compile-tested only >>> >>> arch/x86/kernel/pci-calgary_64.c | 108 ++++++++++++++++++------------- >>> 1 file changed, 64 insertions(+), 44 deletions(-) >>> >>> diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c >>> index c70720f61a34..36cd66d940fb 100644 >>> --- a/arch/x86/kernel/pci-calgary_64.c >>> +++ b/arch/x86/kernel/pci-calgary_64.c >>> @@ -534,6 +534,26 @@ static inline int is_cal_pci_dev(unsigned short device) >>> return (is_calgary(device) || is_calioc2(device)); >>> } >> >> Can the existing api's not be used here like iowrite64be/ioread64be/ or >> similar variant in "include/asm-generic/io.h" > Given what Logan said, I think it probably makes sense to keep the patch as-is?
Sure go ahead, will have a look at this patch one more time.
| |