similar to: [vhost:config-endian 38/39] drivers/platform/mellanox/mlxbf-tmfifo.c:1237:2: error: invalid preprocessing directive #defined; did you mean

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git config-endian head: df43c8f58f42ec36e91740f91ea7360f63213004 commit: e1e22056bc3641f340ed27012cfd1b8b05f83a0a [38/39] fixup! virtio_net: correct tags for config space fields config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget

mlxbf-tmfifo accesses config space using native types - which works for it since the legacy virtio native types. This will break if it ever needs to support modern virtio, so with new tags previously introduced for virtio net config, sparse now warns for this in drivers. Since this is a legacy only device, fix it up using virtio_legacy_is_little_endian for now. No functional changes.

On Mon, 3 Aug 2020 17:00:01 -0400 "Michael S. Tsirkin" <mst at redhat.com> wrote: > mlxbf-tmfifo accesses config space using native types - > which works for it since the legacy virtio native types. > > This will break if it ever needs to support modern virtio, > so with new tags previously introduced for virtio net config, > sparse now warns for this in

struct vring (in the uapi directory) and supporting APIs are kept around to avoid breaking old userspace builds. It's not actually part of the UAPI - it was kept in the UAPI header by mistake, and using it in kernel isn't necessary and prevents us from making changes safely. In particular, the APIs actually assume the legacy layout. Add struct vring_s (identical ATM) and supporting legacy

struct vring (in the uapi directory) and supporting APIs are kept around to avoid breaking old userspace builds. It's not actually part of the UAPI - it was kept in the UAPI header by mistake, and using it in kernel isn't necessary and prevents us from making changes safely. In particular, the APIs actually assume the legacy layout. Add struct vring_s (identical ATM) and supporting legacy

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).

OK, some patches in the series add buggy code which is then fixed by follow-up patches, but none of the bugs fixed are severe regressions on common configs (e.g. compiler warnings, lockdep/rt errors, or bugs in new drivers). So I thought it's more important to preserve the credit for the fixes. I had to pull 5 patches from git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux mlx5-next

The following changes since commit 835a6a649d0dd1b1f46759eb60fff2f63ed253a7: virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM" (2020-04-07 05:44:57 -0400) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to

The following changes since commit 835a6a649d0dd1b1f46759eb60fff2f63ed253a7: virtio-balloon: Revert "virtio-balloon: Switch back to OOM handler for VIRTIO_BALLOON_F_DEFLATE_ON_OOM" (2020-04-07 05:44:57 -0400) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to

On Fri, Feb 14, 2020 at 12:05:32PM +0800, Jason Wang wrote: > > The standard driver model is a 'bus' driver provides the HW access > > (think PCI level things), and a 'hw driver' attaches to the bus > > device, > > This is not true, kernel had already had plenty virtual bus where virtual > devices and drivers could be attached, besides mdev and virtio,

On 2020/2/14 ??12:24, Jason Gunthorpe wrote: > On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote: >> On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote: >>>> That bus is exactly what Greg KH proposed. There are other ways >>>> to solve this I guess but this bikeshedding is getting tiring. >>> This discussion was for a

Whitespace neatening... Multiline statement argument alignment. Argument wrapping. Use kmalloc_array instead of kmalloc. --- drivers/misc/mic/card/mic_virtio.c | 17 ++++--- drivers/misc/mic/card/mic_x100.c | 4 +- drivers/misc/mic/host/mic_debugfs.c | 91 ++++++++++++++++++------------------- drivers/misc/mic/host/mic_fops.c | 6 +-- drivers/misc/mic/host/mic_intr.c | 37

This patch enables the following: a) Initializes the Intel MIC X100 PCIe devices. b) Boots and shuts down the card via sysfs entries. c) Allocates and maps a device page for communication with the card driver and updates the device page address via scratchpad registers. d) Provides sysfs entries for family, stepping, state, shutdown status, kernel command line, IP address, ramdisk and log buffer

mk_pirq_info(), gsi_from_irq() and vector_from_irq() are static functions and no one is calling them. This fixed following compilation warnings : drivers/xen/events.c:134: warning: ?mk_pirq_info? defined but not used drivers/xen/events.c:180: warning: ?gsi_from_irq? defined but not used drivers/xen/events.c:190: warning: ?vector_from_irq? defined but not used Signed-off-by: Jaswinder

mk_pirq_info(), gsi_from_irq() and vector_from_irq() are static functions and no one is calling them. This fixed following compilation warnings : drivers/xen/events.c:134: warning: ?mk_pirq_info? defined but not used drivers/xen/events.c:180: warning: ?gsi_from_irq? defined but not used drivers/xen/events.c:190: warning: ?vector_from_irq? defined but not used Signed-off-by: Jaswinder

mk_pirq_info(), gsi_from_irq() and vector_from_irq() are static functions and no one is calling them. This fixed following compilation warnings : drivers/xen/events.c:134: warning: ?mk_pirq_info? defined but not used drivers/xen/events.c:180: warning: ?gsi_from_irq? defined but not used drivers/xen/events.c:190: warning: ?vector_from_irq? defined but not used Signed-off-by: Jaswinder

Pci_dev_msi_enabled() is used to check whether device MSI/MSIX enabled. Refactor this function to suuport checking only device MSI or MSIX enabled. Signed-off-by: Yijing Wang <wangyijing at huawei.com> --- arch/cris/arch-v32/drivers/pci/bios.c | 2 +- arch/frv/mb93090-mb00/pci-vdk.c | 2 +- arch/ia64/pci/pci.c | 4 ++--

On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote: > > > That bus is exactly what Greg KH proposed. There are other ways > > > to solve this I guess but this bikeshedding is getting tiring. > > > > This discussion was for a different goal, IMHO. > > Hmm couldn't find it

On Thu, Feb 13, 2020 at 10:56:00AM -0500, Michael S. Tsirkin wrote: > On Thu, Feb 13, 2020 at 11:51:54AM -0400, Jason Gunthorpe wrote: > > > That bus is exactly what Greg KH proposed. There are other ways > > > to solve this I guess but this bikeshedding is getting tiring. > > > > This discussion was for a different goal, IMHO. > > Hmm couldn't find it

> -----Original Message----- > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org] > On Behalf Of Yijing Wang > Sent: Saturday, July 26, 2014 8:39 AM > To: linux-kernel at vger.kernel.org > Cc: Xinwei Hu; Wuyun; Bjorn Helgaas; linux-pci at vger.kernel.org; > Paul.Mundt at huawei.com; James E.J. Bottomley; Marc Zyngier; linux-arm- > kernel at