search for: virtio_to_cpu

...return __cpu_to_virtio64(virtio_is_little_endian(vdev), val); } -/* - * Only the checker differentiates between __virtioXX and __uXX types. But we - * try to share as much code as we can with the regular GCC build. - */ -#if !defined(CONFIG_CC_IS_GCC) && !defined(__CHECKER__) +#define virtio_to_cpu(vdev, x) \ + _Generic((x), \ + __u8: (x), \ + __virtio16: virtio16_to_cpu((vdev), (x)), \ + __virtio32: virtio32_to_cpu((vdev), (x)), \ + __virtio64: virtio64_to_cpu((vdev), (x)), \ + /* + * Why define a default? checker can distinguish between + * e.g. __u16, __le16 and __virtio16, but GC...

...sparse reports warnings if I use virtio_cread() > for virtio-crypto device. I suspect that's because you are doing cread into an le32 variable. > Furthermore, it means the warnings exist for all VIRTIO_1 devices because > they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. > > > PS: I googled a discussion about this topic for virtio-input device, pls see: > http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver > > Regards, > -Gonglei Looks like we changed the macros since - at least ATM virtio_console_conf...

...sparse reports warnings if I use virtio_cread() > for virtio-crypto device. I suspect that's because you are doing cread into an le32 variable. > Furthermore, it means the warnings exist for all VIRTIO_1 devices because > they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. > > > PS: I googled a discussion about this topic for virtio-input device, pls see: > http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver > > Regards, > -Gonglei Looks like we changed the macros since - at least ATM virtio_console_conf...

On Tue, Nov 22, 2016 at 04:10:22PM +0800, Gonglei wrote: > Virtio modern devices are always little edian, let's introduce > the LE functions for read/write configuration space for > virtio modern devices, which avoid complaint by Sparse when > we use the virtio_creaed/virtio_cwrite in VIRTIO_1 devices. > > Signed-off-by: Gonglei <arei.gonglei at huawei.com> > ---

On Tue, Nov 22, 2016 at 04:10:22PM +0800, Gonglei wrote: > Virtio modern devices are always little edian, let's introduce > the LE functions for read/write configuration space for > virtio modern devices, which avoid complaint by Sparse when > we use the virtio_creaed/virtio_cwrite in VIRTIO_1 devices. > > Signed-off-by: Gonglei <arei.gonglei at huawei.com> > ---

...s. For virtio-crypto device, I used __le32/64 directly in struct virtio_crypto_config. The sparse reports warnings if I use virtio_cread() for virtio-crypto device. Furthermore, it means the warnings exist for all VIRTIO_1 devices because they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. PS: I googled a discussion about this topic for virtio-input device, pls see: http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver Regards, -Gonglei > If you want it in LE format, swap it! > > > > > -- > > 1.8.3.1 > > >...

..._cread() > > for virtio-crypto device. > > I suspect that's because you are doing cread into an le32 variable. > > > > > Furthermore, it means the warnings exist for all VIRTIO_1 devices because > > they are definitely LE, which it's not necessary to use virtio_to_cpu/cpu_to_virtio. > > > > > > PS: I googled a discussion about this topic for virtio-input device, pls see: > > http://linux.kernel.narkive.com/3argfbWz/patch-1-1-add-virtio-input-driver > > > > Regards, > > -Gonglei > > Looks like we changed the ma...

Config space endian-ness is currently a mess: fields are not tagged with the correct endian-ness so it's easy to make mistakes like instanciating config space in native endian-ness. The following patches adding sparse tagging are currently in my tree. Lightly tested. As a follow-up, I plan to add new APIs that handle modern config space in a more efficient way (bypassing the version check).