search for: iopoll

...p-kqueue's io_loop_handler_run -> io_loop_call_io -> ssl_step repeatedly; dtruss shows that it is repeatedly making system calls to kevent and read, the latter returning -1 with errno 57=ENOTCONN="Socket is not connected". (I also tried ./configure --with-ioloop=poll and --with-iopoll=select instead of the default best = kqueue but the results were the same; --with-iopoll=epoll didn't work because epoll is not available on this machine.) The client, initiated by the command "openssl s_client -connect SERVER:993", first responds "CONNECTED(00000003)" but...

...io/topology.c new file mode 100644 index 000000000000..4923eec618b9 --- /dev/null +++ b/drivers/iommu/virtio/topology.c @@ -0,0 +1,259 @@ +// SPDX-License-Identifier: GPL-2.0 +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + +#include <linux/io-64-nonatomic-hi-lo.h> +#include <linux/iopoll.h> +#include <linux/list.h> +#include <linux/pci.h> +#include <linux/virtio_ids.h> +#include <linux/virtio_pci.h> +#include <uapi/linux/virtio_config.h> +#include <uapi/linux/virtio_iommu.h> + +#include "topology-helpers.h" + +struct viommu_cap_confi...

...000000000000..4923eec618b9 > --- /dev/null > +++ b/drivers/iommu/virtio/topology.c > @@ -0,0 +1,259 @@ > +// SPDX-License-Identifier: GPL-2.0 > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > + > +#include <linux/io-64-nonatomic-hi-lo.h> > +#include <linux/iopoll.h> > +#include <linux/list.h> > +#include <linux/pci.h> > +#include <linux/virtio_ids.h> > +#include <linux/virtio_pci.h> > +#include <uapi/linux/virtio_config.h> > +#include <uapi/linux/virtio_iommu.h> > + > +#include "topology-he...

...#include <linux/kmemleak.h> #include <net/sock.h> #include "include/apparmor.h" --- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c +++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c @@ -25,7 +25,6 @@ #include <linux/io.h> #include <linux/iommu.h> #include <linux/iopoll.h> -#include <linux/kmemleak.h> #include <linux/list.h> #include <linux/of_address.h> #include <linux/of_iommu.h> --- lnx-416-rc1.orig/drivers/staging/rtlwifi/pci.c +++ lnx-416-rc1/drivers/staging/rtlwifi/pci.c @@ -31,7 +31,6 @@ #include "efuse.h" #include...

...#include <linux/kmemleak.h> #include <net/sock.h> #include "include/apparmor.h" --- lnx-416-rc1.orig/drivers/iommu/mtk_iommu_v1.c +++ lnx-416-rc1/drivers/iommu/mtk_iommu_v1.c @@ -25,7 +25,6 @@ #include <linux/io.h> #include <linux/iommu.h> #include <linux/iopoll.h> -#include <linux/kmemleak.h> #include <linux/list.h> #include <linux/of_address.h> #include <linux/of_iommu.h> --- lnx-416-rc1.orig/drivers/staging/rtlwifi/pci.c +++ lnx-416-rc1/drivers/staging/rtlwifi/pci.c @@ -31,7 +31,6 @@ #include "efuse.h" #include...

Add more vDPA callbacks. [s/g]et_vq_state is added in patch 1, including a new control mechanism to read data from the DPU. suspend is added in patch 2. Alvaro Karsz (2): vdpa/snet: support getting and setting VQ state vdpa/snet: support the suspend vDPA callback drivers/vdpa/solidrun/Makefile | 1 + drivers/vdpa/solidrun/snet_ctrl.c | 324 +++++++++++++++++++++++++++++

Add more vDPA callbacks. [s/g]et_vq_state is added in patch 1, including a new control mechanism to read data from the DPU. suspend is added in patch 2. Alvaro Karsz (2): vdpa/snet: support getting and setting VQ state vdpa/snet: support the suspend vDPA callback drivers/vdpa/solidrun/Makefile | 1 + drivers/vdpa/solidrun/snet_ctrl.c | 324 +++++++++++++++++++++++++++++

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

Add a topology description to the virtio-iommu driver and enable x86 platforms. Since [v2] we have made some progress on adding ACPI support for virtio-iommu, which is the preferred boot method on x86. It will be a new vendor-agnostic table describing para-virtual topologies in a minimal format. However some platforms don't use either ACPI or DT for booting (for example microvm), and will

...100644 --- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c +++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c @@ -5,6 +5,7 @@ #include <drm/drm_gem_shmem_helper.h> #include <drm/panfrost_drm.h> #include <linux/completion.h> +#include <linux/dma-buf-map.h> #include <linux/iopoll.h> #include <linux/pm_runtime.h> #include <linux/slab.h> @@ -72,6 +73,7 @@ static int panfrost_perfcnt_enable_locked(struct panfrost_device *pfdev, { struct panfrost_file_priv *user = file_priv->driver_priv; struct panfrost_perfcnt *perfcnt = pfdev->perfcnt; + struct dma...

...100644 --- a/drivers/gpu/drm/panfrost/panfrost_perfcnt.c +++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c @@ -5,6 +5,7 @@ #include <drm/drm_gem_shmem_helper.h> #include <drm/panfrost_drm.h> #include <linux/completion.h> +#include <linux/dma-buf-map.h> #include <linux/iopoll.h> #include <linux/pm_runtime.h> #include <linux/slab.h> @@ -72,6 +73,7 @@ static int panfrost_perfcnt_enable_locked(struct panfrost_device *pfdev, { struct panfrost_file_priv *user = file_priv->driver_priv; struct panfrost_perfcnt *perfcnt = pfdev->perfcnt; + struct dma...

...anfrost_perfcnt.c > +++ b/drivers/gpu/drm/panfrost/panfrost_perfcnt.c > @@ -5,6 +5,7 @@ > #include <drm/drm_gem_shmem_helper.h> > #include <drm/panfrost_drm.h> > #include <linux/completion.h> > +#include <linux/dma-buf-map.h> > #include <linux/iopoll.h> > #include <linux/pm_runtime.h> > #include <linux/slab.h> > @@ -72,6 +73,7 @@ static int panfrost_perfcnt_enable_locked(struct panfrost_device *pfdev, > { > struct panfrost_file_priv *user = file_priv->driver_priv; > struct panfrost_perfcnt *perfcn...

...lt;drm/drm_atomic_helper.h> -#include <drm/drm_crtc_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_panel.h> #include <drm/drm_of.h> +#include <drm/drm_probe_helper.h> #include <linux/clk.h> #include <linux/component.h> #include <linux/iopoll.h> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index 12ad00d01063..915cc84621ae 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -14,7 +14,7 @@ #include <drm/drmP.h> #include <drm/drm_atomic_helper...

...lt;drm/drm_atomic_helper.h> -#include <drm/drm_crtc_helper.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_panel.h> #include <drm/drm_of.h> +#include <drm/drm_probe_helper.h> #include <linux/clk.h> #include <linux/component.h> #include <linux/iopoll.h> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c index f3ef7bf80563..1fe1b5cd26c1 100644 --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c @@ -14,7 +14,7 @@ #include <drm/drmP.h> #include <drm/drm_atomic_helper...

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use