search for: __le

...9 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -336,7 +336,7 @@ static void virtio_vsock_reset_sock(struct sock *sk) static void virtio_vsock_update_guest_cid(struct virtio_vsock *vsock) { struct virtio_device *vdev = vsock->vdev; - u64 guest_cid; + __le64 guest_cid; vdev->config->get(vdev, offsetof(struct virtio_vsock_config, guest_cid), &guest_cid, sizeof(guest_cid)); -- MST

...accessors for handling virtio in modern little endian and in + * compatibility big endian format. */ + +#define __DEFINE_VIRTIO_XX_TO_CPU(bits) \ +static inline u##bits __virtio##bits##_to_cpu(bool little_endian, __virtio##bits val) \ +{ \ + if (little_endian) \ + return le##bits##_to_cpu((__force __le##bits)val); \ + else \ + return (__force u##bits)val; \ +} \ +static inline __virtio##bits __cpu_to_virtio##bits(bool little_endian, u##bits val) \ +{ \ + if (little_endian) \ + return (__force __virtio##bits)cpu_to_le##bits(val); \ + else \ + return val; \ +} + +__DEFINE_VIRTIO_XX_TO_CPU(16) +_...

...accessors for handling virtio in modern little endian and in + * compatibility big endian format. */ + +#define __DEFINE_VIRTIO_XX_TO_CPU(bits) \ +static inline u##bits __virtio##bits##_to_cpu(bool little_endian, __virtio##bits val) \ +{ \ + if (little_endian) \ + return le##bits##_to_cpu((__force __le##bits)val); \ + else \ + return (__force u##bits)val; \ +} \ +static inline __virtio##bits __cpu_to_virtio##bits(bool little_endian, u##bits val) \ +{ \ + if (little_endian) \ + return (__force __virtio##bits)cpu_to_le##bits(val); \ + else \ + return val; \ +} + +__DEFINE_VIRTIO_XX_TO_CPU(16) +_...

...PCI device using single order-2 page buffer. > >>> > >>> Do you mean a legacy virtio device? I don't see why > >>> you would want to support pre-1.0 mode. > >>> If you drop that, you can drop all cpu_to_virtio things > >>> and just use __le accessors. > >> > >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > > > Unless kvmtools wants to be left behind it has to go 1.0. > > And it also has to go ACPI. Is there any reason, apart from kvmtool, to > make a completely new virti...

...PCI device using single order-2 page buffer. > >>> > >>> Do you mean a legacy virtio device? I don't see why > >>> you would want to support pre-1.0 mode. > >>> If you drop that, you can drop all cpu_to_virtio things > >>> and just use __le accessors. > >> > >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > > > Unless kvmtools wants to be left behind it has to go 1.0. > > And it also has to go ACPI. Is there any reason, apart from kvmtool, to > make a completely new virti...

...t;mst at redhat.com> wrote: > > On Sun, Mar 01, 2020 at 01:07:30PM +0200, Yuri Benditovich wrote: > > This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, > > VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. > > > > Changes from v1: > > __virtio -> __le > > maximal -> maximum > > minor style fixes > > > Looks good to me - sent a bit of consmetics. > > But as any virtio UAPI change, please CC virtio-dev as virtio TC maintains the > interface. Thanks! Probably 'virtio-dev' should be added to maintainers file...

...an and in > + * compatibility big endian format. */ s/big/native/ > + > +#define __DEFINE_VIRTIO_XX_TO_CPU(bits) \ > +static inline u##bits __virtio##bits##_to_cpu(bool little_endian, __virtio##bits val) \ > +{ \ > + if (little_endian) \ > + return le##bits##_to_cpu((__force __le##bits)val); \ > + else \ > + return (__force u##bits)val; \ > +} \ > +static inline __virtio##bits __cpu_to_virtio##bits(bool little_endian, u##bits val) \ > +{ \ > + if (little_endian) \ > + return (__force __virtio##bits)cpu_to_le##bits(val); \ > + else \ > + return...

...gt; > > > It supports legacy PCI device using single order-2 page buffer. > > > > Do you mean a legacy virtio device? I don't see why > > you would want to support pre-1.0 mode. > > If you drop that, you can drop all cpu_to_virtio things > > and just use __le accessors. > > I was thinking about the kvmtools which lacks 1.0 support AFAIK. Unless kvmtools wants to be left behind it has to go 1.0. > But > I think it'd be better to always use __le type anyway. Will change. > > > > > > > It uses > > > two...

...gt; > > > It supports legacy PCI device using single order-2 page buffer. > > > > Do you mean a legacy virtio device? I don't see why > > you would want to support pre-1.0 mode. > > If you drop that, you can drop all cpu_to_virtio things > > and just use __le accessors. > > I was thinking about the kvmtools which lacks 1.0 support AFAIK. Unless kvmtools wants to be left behind it has to go 1.0. > But > I think it'd be better to always use __le type anyway. Will change. > > > > > > > It uses > > > two...

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v1: __virtio -> __le maximal -> maximum minor style fixes Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 90 +++++++++++++++++++++++++++++++-- 1 file changed, 86 i...

This series introduce virtio-net features VIRTIO_NET_F_RSC_EXT, VIRTIO_NET_F_RSS and VIRTIO_NET_F_HASH_REPORT. Changes from v1: __virtio -> __le maximal -> maximum minor style fixes Yuri Benditovich (3): virtio-net: Introduce extended RSC feature virtio-net: Introduce RSS receive steering feature virtio-net: Introduce hash report feature include/uapi/linux/virtio_net.h | 90 +++++++++++++++++++++++++++++++-- 1 file changed, 86 i...

This patch fixes below sparse warning related to __virtio type in virtio pmem driver. This is reported by Intel test bot on linux-next tree. nd_virtio.c:56:28: warning: incorrect type in assignment (different base types) nd_virtio.c:56:28: expected unsigned int [unsigned] [usertype] type nd_virtio.c:56:28: got restricted __virtio32 nd_virtio.c:93:59: warning: incorrect type in argument

This patch fixes below sparse warning related to __virtio type in virtio pmem driver. This is reported by Intel test bot on linux-next tree. nd_virtio.c:56:28: warning: incorrect type in assignment (different base types) nd_virtio.c:56:28: expected unsigned int [unsigned] [usertype] type nd_virtio.c:56:28: got restricted __virtio32 nd_virtio.c:93:59: warning: incorrect type in argument

...type] val nd_virtio.c:93:59: got unsigned int [unsigned] [usertype] ret Reported-by: kbuild test robot <lkp at intel.com> Signed-off-by: Pankaj Gupta <pagupta at redhat.com> --- This fixes a warning, so submitting it as a separate patch on top of virtio pmem series. v2-> v3 Use __le for req/resp fields - Michael drivers/nvdimm/nd_virtio.c | 4 ++-- include/uapi/linux/virtio_pmem.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c index 8645275c08c2..10351d5b49fa 100644 --- a/drivers/nvdimm/n...

...type] val nd_virtio.c:93:59: got unsigned int [unsigned] [usertype] ret Reported-by: kbuild test robot <lkp at intel.com> Signed-off-by: Pankaj Gupta <pagupta at redhat.com> --- This fixes a warning, so submitting it as a separate patch on top of virtio pmem series. v2-> v3 Use __le for req/resp fields - Michael drivers/nvdimm/nd_virtio.c | 4 ++-- include/uapi/linux/virtio_pmem.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/nvdimm/nd_virtio.c b/drivers/nvdimm/nd_virtio.c index 8645275c08c2..10351d5b49fa 100644 --- a/drivers/nvdimm/n...

...ike ftrace dump) later. > > > > It supports legacy PCI device using single order-2 page buffer. > > Do you mean a legacy virtio device? I don't see why > you would want to support pre-1.0 mode. > If you drop that, you can drop all cpu_to_virtio things > and just use __le accessors. I was thinking about the kvmtools which lacks 1.0 support AFAIK. But I think it'd be better to always use __le type anyway. Will change. > > > It uses > > two virtqueues - one for (sync) read and another for (async) write. > > Since it cannot wait for write...

...;> It supports legacy PCI device using single order-2 page buffer. >>> >>> Do you mean a legacy virtio device? I don't see why >>> you would want to support pre-1.0 mode. >>> If you drop that, you can drop all cpu_to_virtio things >>> and just use __le accessors. >> >> I was thinking about the kvmtools which lacks 1.0 support AFAIK. > > Unless kvmtools wants to be left behind it has to go 1.0. And it also has to go ACPI. Is there any reason, apart from kvmtool, to make a completely new virtio device, with no support in existi...

...t to have other > information (like ftrace dump) later. > > It supports legacy PCI device using single order-2 page buffer. Do you mean a legacy virtio device? I don't see why you would want to support pre-1.0 mode. If you drop that, you can drop all cpu_to_virtio things and just use __le accessors. > It uses > two virtqueues - one for (sync) read and another for (async) write. > Since it cannot wait for write finished, it supports up to 128 > concurrent IO. The buffer size is configurable now. > > Cc: Paolo Bonzini <pbonzini at redhat.com> > Cc: Radim...

...t to have other > information (like ftrace dump) later. > > It supports legacy PCI device using single order-2 page buffer. Do you mean a legacy virtio device? I don't see why you would want to support pre-1.0 mode. If you drop that, you can drop all cpu_to_virtio things and just use __le accessors. > It uses > two virtqueues - one for (sync) read and another for (async) write. > Since it cannot wait for write finished, it supports up to 128 > concurrent IO. The buffer size is configurable now. > > Cc: Paolo Bonzini <pbonzini at redhat.com> > Cc: Radim...

...g single order-2 page buffer. >>>>> >>>>> Do you mean a legacy virtio device? I don't see why >>>>> you would want to support pre-1.0 mode. >>>>> If you drop that, you can drop all cpu_to_virtio things >>>>> and just use __le accessors. >>>> >>>> I was thinking about the kvmtools which lacks 1.0 support AFAIK. >>> >>> Unless kvmtools wants to be left behind it has to go 1.0. >> >> And it also has to go ACPI. Is there any reason, apart from kvmtool, to >> make...