-off-by: Kevin Paul Reddy Janagari
---
Documentation/gpu/drm-kms.rst | 2 ++
Documentation/gpu/drm-uapi.rst | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index abfe220764e1..da865ba1c014 100644
--- a/Documentation/gpu/drm
bug of Sphinx >=3.1, first reported by Mauro in September 2020
Link: https://github.com/sphinx-doc/sphinx/issues/8241
Signed-off-by: Kevin Paul Reddy Janagari
---
Documentation/gpu/drm-kms.rst | 4
Documentation/gpu/drm-uapi.rst | 2 ++
2 files changed, 6 insertions(+)
diff --gi
Switch to panel timings based on datasheet for the AUO G101EVN01.0
LVDS panel. Default timings were tested on the panel.
Previous mode-based timings resulted in horizontal display shift.
Signed-off-by: Kevin Baker
Fixes: 4fb86404a977 ("drm/panel: simple: Add AUO G101EVN010 panel su
Switch to panel timings based on datasheet for the AUO G101EVN01.0
LVDS panel. Default timings were tested on the panel.
Previous mode-based timings resulted in horizontal display shift.
Signed-off-by: Kevin Baker
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file
warning: Incorrect use of kernel-doc format:
* @DC_HDCP_LC_ENABLE_SW_FALLBACK If set, upon HDCP Locality Check FW
Signed-off-by: Kevin Paul Reddy Janagari
---
drivers/gpu/drm/amd/include/amd_shared.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/include
On 17.08.24 10:42, Greg KH wrote:
On Tue, Jul 30, 2024 at 08:53:39PM +0200, Kevin Holm wrote:
From: Wayne Lin
[ Upstream commit fa57924c76d995e87ca3533ec60d1d5e55769a27 ]
[Why]
dm_dp_mst_is_port_support_mode() is a bit not following the original design
rule and cause
light up issue with
pixel encoding for mst mode
validation")
Link:
https://lore.kernel.org/stable/d74a7768e957e6ce88c27a5bece0c64dff132...@holm.dev/T/#u
Signed-off-by: Kevin Holm
---
I resolved the merge conflict so that, after this patch is applied to the
linux-6.10.y branch of the stable git repository, the
ovide something for 6.10.y?
>
> Ciao, Thorsten
>
I reverted 4df96ba6676034 from v6.10.2 from the stable/linux git, resolving the
conflict by removing everything that git marked as from the current branch and
kept everything marked as from before the branch to merge. That resulted in
> [adding a few people and lists to the recipients]
>
> Hi! Thx for your rpeort.
>
> On 27.07.24 18:07, ke...@holm.dev wrote:
>
> >
> > Connecting two 4k displays with display port through a lenovo usb-c
> >
> > dock (type 40AS) to a Lenovo P14s Gen 2 (type 21A0) results in no
> >
> > image
On Sun, Mar 17, 2024 at 08:18:57PM +0100, Frej Drejhammar wrote:
> Hi Kevin,
>
> Kevin Hao writes:
>
> > But after kernel commit c91acda3a380, the FB will not be created
> > successfully due to the check of the valid pixel format. Then the bpp
> > is set to 24,
' combo is not a valid pixel format.
Fix this issue by explicitly setting the preferred_depth in this driver.
With this change, the modesetting driver would choose the correct
depth/bpp combo based on our setting in xorg.conf.
Fixes: c91acda3a380 ("drm/gem: Check for valid formats")
Cc:
> From: Tian, Kevin
> Sent: Tuesday, January 16, 2024 8:46 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, January 16, 2024 12:31 AM
> >
> > On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
> >
> > > > Well, for instance, when you ins
> From: Jason Gunthorpe
> Sent: Tuesday, January 16, 2024 12:31 AM
>
> On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
>
> > > Well, for instance, when you install pages into the KVM the hypervisor
> > > will have taken kernel memory, then zero'd it with cachable writes,
> > > however
> From: Zhao, Yan Y
> Sent: Thursday, December 14, 2023 6:35 PM
>
> - For host non-MMIO pages,
> * virtio guest frontend and host backend driver should be synced to use
> the same memory type to map a buffer. Otherwise, there will be
> potential problem for incorrect memory data. But th
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Kunwu.Chan
Sent: Tuesday, October 10, 2023 2:11 PM
To: Wang, Yang(Kevin)
Cc: Deucher, Alexander ; Kamal, Asad
; Koenig, Christian ; Zhang,
Hawking ; Ma, Le ; Lazar, Lijo
; Pan
Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
Please add above information into your patch commit message.
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: Kunwu.Chan
Sent: Tuesday, October 10, 2023 10:19 AM
To: evan.q...@amd.com; Deucher,
[AMD Official Use Only - General]
Reviewed-by: Yang Wang
Best Regards,
Kevin
-Original Message-
From: dri-devel On Behalf Of Colin
Ian King
Sent: Wednesday, August 23, 2023 5:03 PM
To: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ; David Airlie
; Daniel Vetter ; Lazar, Lijo
n Intel's
drivers/accel/ivpu. :)
Maybe since this is more about generalizing the interface between the
CPU running linux and the APU, what about the name apu_if? But I guess
that applies to the other 3 drivers in drivers/accell also. Hmmm...
Naming things is hard[2], so we're definit
fixes tags then it would be:
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Kevin
it would be:
Fixes: 44cfc6233447 ("drm/bridge: Add NWL MIPI DSI host controller support")
Kevin
to perform a successful DCS read from
a display with a Chipone ICNL9707 driver IC.
Signed-off-by: Kevin Groeneveld
---
drivers/gpu/drm/bridge/nwl-dsi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
in
the current driver.
Signed-off-by: Kevin Groeneveld
---
drivers/gpu/drm/bridge/nwl-dsi.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c
index 6dc2a4e191d7..bb8404ffd3f5 100644
--- a/drivers/gpu
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> These contexts are sleepable, so use the proper annotation. The
> GFP_ATOMIC
> was added mechanically in the prior patches.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
> __domain_mapping().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> This is eventually called by iommufd through intel_iommu_map_pages() and
> it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
OUNT.
>
> However, one of the biggest consumers of kernel memory is the IOPTEs
> stored under the iommu_domain. Many drivers will allocate these at
> iommu_map() time and will trivially do the right thing if we pass in
> GFP_KERNEL_ACCOUNT.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
om an atomic context, so it is safe
> as is, but reads wrong.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> There is only one call site and it can now just pass the GFP_ATOMIC to the
> normal iommu_map().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
_ACCOUNT.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Tuesday, January 17, 2023 9:30 PM
>
> On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Saturday, January 7, 2023 12:43 AM
> > >
> > > @@ -2676,7 +2676,7 @@ st
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct
> dmar_domain *domain,
>
> return __domain_mapping(domain, first_vpfn,
> first_vpfn, last_vpfn - first_vpfn + 1,
> -
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu
> *iommu,
> if (!old_ce)
> goto out;
>
> - new_ce = alloc_pgtable_page(iommu->node
From: Kevin Brace
Commit e3c92eb4a84fb0f00442e6b5cabf4f11b0eaaf41 (drm/ttm: rework on
ttm_resource to use size_t type) reworked ttm_resource{} to use size_t
type size instead of unsigned long type num_pages. In that commit,
when ttm_move_memcpy() is being called from ttm_bo_move_memcpy(),
the
From: Kevin Brace
Hi,
I work on an out of the kernel tree DRM module for VIA Technologies Chrome
integrated graphics (https://cgit.freedesktop.org/openchrome/drm-openchrome/),
and DRM commit e3c92eb4a84fb0f00442e6b5cabf4f11b0eaaf41 (drm/ttm: rework on
ttm_resource to use size_t type) definitely
> From: Jason Gunthorpe
> Sent: Friday, November 11, 2022 1:21 AM
>
> On Thu, Nov 10, 2022 at 03:11:16AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, November 8, 2022 8:53 AM
> > >
> > > +
> > > +int vfio_
same ioctls as VFIO and automatically
> enables the VFIO compatible pinned page accounting mode.
>
> Tested-by: Nicolin Chen
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, November 10, 2022 3:53 AM
>
> On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
>
> > DPDK supports no-iommu mode.
>
> Er? Huh? How? I thought no-iommu was for applications that didn't do
> DMA? How is DPDK getting packets in/out without
fio: Move container code into
> drivers/vfio/container.c")
> Reported-by: "Liu, Yi L"
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> consist of all the mdev drivers.
>
> Like the physical drivers, support for iommufd is provided by the driver
> supplying the correct standard ops. Pro
kernel oops.
> > >
> > > Should probably add something similar:
> > > + if (device->group->iommufd)
> > > + vfio_iommufd_unbind(device);
> > >
> > > Or should check !vdev->iommufd_device inside the ->unbind.
> &
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> +
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + /*
> + * I
a vfio_group_has_iommu() function and consolidate all the duplicated
> WARN_ON's etc related to this.
>
> Call container functions only if a container is actually present on the
> group.
>
> Tested-by: Nicolin Chen
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
he coherency, it never
> attaches a device that supports enforce cache coherency to a less capable
> domain, so the cap test is a sufficient proxy for the ultimate
> outcome. iommufd also ensures that devices that set the cap will be
> connected to enforcing domains.
>
> Tested-by: Nicolin Chen
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 9:11 PM
>
> > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make
> > more sense to remove this patch from this series i.e. let it buried in
> > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if
> > no
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 8:48 PM
>
> On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote:
> > every mail in this series is shown thrice in lore:
> >
> > https://lore.kernel.org/all/0-v2-65016290f146+33e-
> vfio_iommufd
every mail in this series is shown thrice in lore:
https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/
not sure what caused it but it's annoying to check the conversation there.
the iommufd series doesn't have this problem.
> From: Jason Gunthorpe
> Sent: Tuesday, No
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 9:05 AM
>
> On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote:
>
> > > > So why exactly isn't this an issue for VDPA? Are we just burying our
> > > > head in the sand that such platforms exists and can still be useful
> >
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:49 PM
> > > ---
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +
> > > drivers/s390/cio/vfio_ccw_ops.c | 3 +
> > > drivers/s390/crypto/vfio_ap_ops.c | 3 +
> > > drivers/vfio/container.c | 108 ++--
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 7:51 PM
>
> On Tue, Nov 01, 2022 at 02:19:04AM -0700, Nicolin Chen wrote:
> > On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:
> >
> > > > From: Jason Gunthorpe
> > >
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:26 PM
> And this:
>
> /*
>* If the device does not have
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
>* any domain later attached to it will also not support it. If the cap
>* is set then the iommu_domain eventu
remove them from driver release callbacks.
>
> Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
; and behave like everyone else.
>
> Signed-off-by: Eric Farman
This looks good to me. With Jason's suggestion handled,
Reviewed-by: Kevin Tian
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
>
> Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> @@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct
> mdev_device *mdev)
> {
> struct subchannel *sch = to_subchannel(mdev->dev.parent);
> struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> -
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> if VFIO
> +config VFIO_CONTAINER
> + bool "Support for the VFIO container /dev/vfio/vfio"
> + select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM ||
> ARM64)
> + default y
> + help
> + The VFIO contai
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> consist of all the mdev drivers.
>
> Like the physical drivers, support for iommufd is provided by the driver
> supplying the correct correct standar
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + /*
> + * If
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> menuconfig VFIO
> tristate "VFIO Non-Privileged userspace driver framework"
> select IOMMU_API
> + depends on IOMMUFD || !IOMMUFD
Out of curiosity. What is the meaning of this dependency claim?
> @@ -717,12
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> iommufd doesn't establish the iommu_domains until after the device FD is
> opened, even if the container has been set. This design is part of moving
> away from the group centric iommu APIs.
>
> This is fine, except that the
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> These functions don't really assign anything anymore, they just increment
> some refcounts and do a sanity check. Call them
> vfio_group_[un]use_container()
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> +err_container:
> + vfio_device_unassign_container(device);
> err_module_put:
> device->kvm = NULL;
err_module_put should be moved after nullifying device->kvm.
otherwise it looks good
igned-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian , with a nit
> + /*
> + * Here we pass the KVM pointer with the group under the read lock.
Now the read lock is replaced by mutex. Let's correct it when moving this
piece of code.
tely unused, so I'm only leaving omap15xx/omap16xx/omap59xx.
Acked-by: Kevin Hilman
with a few tears shed since omap7xx/omap8xx was the first family I
contributed to upstream. :(
Kevin
->attached becomes false. Unless I'm
> >>> missing something, I think we should also follow-up with a patch to
> >>> remove that bogus warn-on branch, right? Thanks,
> >>
> >> Yes, looks right to me.
> >>
> >> I question all the lo
ing, I think we should also follow-up with a patch to
> > > remove that bogus warn-on branch, right? Thanks,
> >
> > Yes, looks right to me.
> >
> > I question all the logical arround attached, where is the locking?
>
> Zhenyu, Zhi, Kevin,
>
> Could some
> From: Alex Williamson
> Sent: Friday, September 30, 2022 2:24 AM
>
> On Thu, 29 Sep 2022 14:49:56 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > > Hi Kevin,
> > >
> >
was missed for gvt, add it.
>
> Cc: sta...@vger.kernel.org
> Fixes: 978cf586ac35 ("drm/i915/gvt: convert to use
> vfio_register_emulated_iommu_dev")
> Reported-by: Alex Williamson
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, September 22, 2022 12:10 AM
>
> On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, September 21, 2022 4:27 AM
> > >
> > > On Fri, 9
ing future
device-oriented uAPI.
Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
.../ABI/testing/sysfs-devices-vfio-dev| 8 +++
MAINTAINERS
() -> vfio_device_put_registration()
- vfio_device_try_get() -> vfio_device_try_get_registration()
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio_ma
The right fix is to introduce separate structures for mdev and parent,
but this won't happen in short term per prior discussions.
Remove vfio_init/uninit_group_dev() as no user now.
Suggested-by: Jason Gunthorpe
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: E
Implement amba's own vfio_device_ops.
Remove vfio_platform_probe/remove_common() given no user now.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/platform/vfio_amba.c | 72 ++-
drivers/vfio/pla
Move vfio_device_ops from platform core to platform drivers so device
specific init/cleanup can be added.
Introduce two new helpers vfio_platform_init/release_common() for the
use in driver @init/@release.
vfio_platform_probe/remove_common() will be deprecated.
Signed-off-by: Kevin Tian
From: Yi Liu
Also add a comment to mark that vfio core releases device_set if @init
fails.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 85 ++-
1 file changed, 49 insertions(+), 36 deletions
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21
Move vfio_device to the start of intel_vgpu as required by the new
helpers.
Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
as other vgpu helpers do.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/gvt.h | 5
From: Yi Liu
and manage avail_mbytes inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 73 --
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/samples/vfio
From: Yi Liu
and manage available ports inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mtty.c | 67 +++-
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/samples
From: Yi Liu
and manage mdpy_count inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mdpy.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/samples/vfio
From: Yi Liu
Tidy up @probe so all migration specific initialization logic is moved
to migration specific @init callback.
Remove vfio_pci_core_{un}init_device() given no user now.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Shameer Kolothum
From: Yi Liu
mlx5 has its own @init/@release for handling migration cap.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/pci/mlx5/main.c | 50 ++--
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a
From: Yi Liu
Also introduce two pci core helpers as @init/@release for pci drivers:
- vfio_pci_core_init_dev()
- vfio_pci_core_release_dev()
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 20 +-
drivers
ated after all
existing usages are converted to the new model.
Suggested-by: Jason Gunthorpe
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_m
w can use a completion mechanism to delay the
free to css driver;
The second trick is not a real burden to other drivers because they
all require a @release for private cleanup anyway. Later once the ccw
mess is fixed a simple cleanup can be done by moving free from @release
to vfio core.
Thank
> From: Alex Williamson
> Sent: Wednesday, September 21, 2022 4:27 AM
>
> On Fri, 9 Sep 2022 18:22:47 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > sysfs pat
> From: Alex Williamson
> Sent: Wednesday, September 21, 2022 3:17 AM
>
> On Fri, 9 Sep 2022 18:22:38 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and manage available ports inside @init/@release.
> >
> > Signed-off-by: Yi Liu
>
> From: Ethan Zhao
> Sent: Friday, September 9, 2022 4:24 PM
>
> Hi, Kevin,
>
> 在 2022/9/9 18:22, Kevin Tian 写道:
> > The idea is to let vfio core manage the vfio_device life cycle instead
> > of duplicating the logic cross drivers. This is also a preparatory
>
> From: Jason Gunthorpe
> Sent: Thursday, September 8, 2022 8:37 PM
>
> On Thu, Sep 08, 2022 at 11:39:07AM +0200, Eric Auger wrote:
>
> > >> I am not totally clear about remaining 'struct device *dev;' in
> > >> vfio_device struct. I see it used in some places. Is it supposed to
> > >> disappear
() -> vfio_device_put_registration()
- vfio_device_try_get() -> vfio_device_try_get_registration()
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio_ma
ing future
device-oriented uAPI.
Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
Also take this chance to rename chardev 'vfio' to 'vfio-group' in
/proc/devices.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthor
The right fix is to introduce separate structures for mdev and parent,
but this won't happen in short term per prior discussions.
Remove vfio_init/uninit_group_dev() as no user now.
Suggested-by: Jason Gunthorpe
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: E
Implement amba's own vfio_device_ops.
Remove vfio_platform_probe/remove_common() given no user now.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/platform/vfio_amba.c | 72 ++-
drivers/vfio/pla
Move vfio_device to the start of intel_vgpu as required by the new
helpers.
Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
as other vgpu helpers do.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/gvt.h | 5
Move vfio_device_ops from platform core to platform drivers so device
specific init/cleanup can be added.
Introduce two new helpers vfio_platform_init/release_common() for the
use in driver @init/@release.
vfio_platform_probe/remove_common() will be deprecated.
Signed-off-by: Kevin Tian
From: Yi Liu
Also add a comment to mark that vfio core releases device_set if @init
fails.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 85 ++-
1 file changed, 49 insertions(+), 36 deletions
From: Yi Liu
and manage mdpy_count inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mdpy.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/samples/vfio
From: Yi Liu
and manage avail_mbytes inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 73 --
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/samples/vfio
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21
From: Yi Liu
mlx5 has its own @init/@release for handling migration cap.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/pci/mlx5/main.c | 50 ++--
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a
1 - 100 of 637 matches
Mail list logo
