Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
On Tue, 30 Apr 2024 17:38:02 + Easwar Hariharan wrote: > I2C v7, SMBus 3.2, and I3C 1.1.1 specifications have replaced > "master/slave" with more appropriate terms. Inspired by and following > on to Wolfram's series to fix drivers/i2c/[1], fix the terminology > for users of I2C_ALGOBIT bitbanging interface, now that the approved > verbiage exists in the specification. > > Compile tested, no functionality changes intended > For GVT part, Acked-by: Zhi Wang Thanks, Zhi. > [1]: > https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > > Signed-off-by: Easwar Hariharan > --- > drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - > drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- > drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- > drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- > drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- > drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- > drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > .../gpu/drm/i915/display/intel_display_core.h | 2 +- > drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- > drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- > drivers/gpu/drm/i915/display/intel_dvo.c | 14 - > drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- > drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- > drivers/gpu/drm/i915/display/intel_sdvo.c | 30 > +-- drivers/gpu/drm/i915/display/intel_vbt_defs.h | > 4 +-- drivers/gpu/drm/i915/gvt/edid.c | 28 > - drivers/gpu/drm/i915/gvt/edid.h | 4 > +-- drivers/gpu/drm/i915/gvt/opregion.c | 2 +- > 19 files changed, 119 insertions(+), 119 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c > b/drivers/gpu/drm/i915/display/dvo_ch7017.c index > d0c3880d7f80..493e730c685b 100644 --- > a/drivers/gpu/drm/i915/display/dvo_ch7017.c +++ > b/drivers/gpu/drm/i915/display/dvo_ch7017.c @@ -170,13 +170,13 @@ > static bool ch7017_read(struct intel_dvo_device *dvo, u8 addr, u8 > *val) { struct i2c_msg msgs[] = { > { > - .addr = dvo->slave_addr, > + .addr = dvo->target_addr, > .flags = 0, > .len = 1, > .buf = , > }, > { > - .addr = dvo->slave_addr, > + .addr = dvo->target_addr, > .flags = I2C_M_RD, > .len = 1, > .buf = val, > @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device > *dvo, u8 addr, u8 val) { > u8 buf[2] = { addr, val }; > struct i2c_msg msg = { > - .addr = dvo->slave_addr, > + .addr = dvo->target_addr, > .flags = 0, > .len = 2, > .buf = buf, > @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device > *dvo, u8 addr, u8 val) return i2c_transfer(dvo->i2c_bus, , 1) == > 1; } > > -/** Probes for a CH7017 on the given bus and slave address. */ > +/** Probes for a CH7017 on the given bus and target address. */ > static bool ch7017_init(struct intel_dvo_device *dvo, > struct i2c_adapter *adapter) > { > @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device > *dvo, break; > default: > DRM_DEBUG_KMS("ch701x not detected, got %d: from %s " > - "slave %d.\n", > - val, adapter->name, dvo->slave_addr); > + "target %d.\n", > + val, adapter->name, dvo->target_addr); > goto fail; > } > > DRM_DEBUG_KMS("%s detected on %s, addr %d\n", > - str, adapter->name, dvo->slave_addr); > + str, adapter->name, dvo->target_addr); > return true; > > fail: > diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c > b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c index > 2e8e85da5a40..534b8544e0a4 100644 --- > a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c +++ > b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c @@ -153,13 +153,13 @@ > static bool ch7xxx_readb(struct intel_dvo_device *dvo, int addr, u8 > *ch) struct i2c_msg msgs[] = { > { > - .addr = dvo->slave_addr, > + .addr = dvo->target_addr, >
Re: [PATCH] PCI: Add vf reset notification for pf
On Sun, 4 Feb 2024 14:12:57 +0800 Emily Deng wrote: > When a vf has been reset, the pf wants to get notification to remove > the vf out of schedule. > > Solution: > Add the callback function in pci_driver sriov_vf_reset_notification. > When vf reset happens, then call this callback function. > > Signed-off-by: Emily Deng > --- > drivers/pci/pci.c | 8 > include/linux/pci.h | 1 + > 2 files changed, 9 insertions(+) > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c > index 60230da957e0..aca937b05531 100644 > --- a/drivers/pci/pci.c > +++ b/drivers/pci/pci.c > @@ -4780,6 +4780,14 @@ EXPORT_SYMBOL_GPL(pcie_flr); > */ > int pcie_reset_flr(struct pci_dev *dev, bool probe) > { > + struct pci_dev *pf_dev; > + > + if (dev->is_virtfn) { > + pf_dev = dev->physfn; > + if (pf_dev->driver->sriov_vf_reset_notification) > + > pf_dev->driver->sriov_vf_reset_notification(pf_dev, dev); > + } > + > if (dev->dev_flags & PCI_DEV_FLAGS_NO_FLR_RESET) > return -ENOTTY; > > diff --git a/include/linux/pci.h b/include/linux/pci.h > index c69a2cc1f412..4fa31d9b0aa7 100644 > --- a/include/linux/pci.h > +++ b/include/linux/pci.h > @@ -926,6 +926,7 @@ struct pci_driver { > int (*sriov_configure)(struct pci_dev *dev, int num_vfs); > /* On PF */ int (*sriov_set_msix_vec_count)(struct pci_dev *vf, int > msix_vec_count); /* On PF */ u32 (*sriov_get_vf_total_msix)(struct > pci_dev *pf); > + void (*sriov_vf_reset_notification)(struct pci_dev *pf, > struct pci_dev *vf); const struct pci_error_handlers *err_handler; > const struct attribute_group **groups; > const struct attribute_group **dev_groups; Hi: I would suggest you can provide a cover letter including a complete picture that tells the background, detailed problem statement, the solutions and plus the users. As this seems very like a generic change, it needs a better justification to convince folks why this is the best solution. Without a complete picture, the solution just looks like a workaround. Thanks, Zhi.
Re: Possible use_mm() mis-uses
Hi Linus: Thanks for letting us know that. We would fix this ASAP. The kvmgt.c module is a part of GVT-g code. It's our fault that we didn't find this mis-uses, not i915 or KVM guys. Wish they would feel better after seeing this message. Thanks, Zhi. On 08/23/18 00:44, Linus Torvalds wrote: Guys and gals, this is a *very* random list of people on the recipients list, but we had a subtle TLB shootdown issue in the VM, and that brought up some issues when people then went through the code more carefully. I think we have a handle on the TLB shootdown bug itself. But when people were discussing all the possible situations, one thing that came up was "use_mm()" that takes a mm, and makes it temporarily the mm for a kernel thread (until "unuse_mm()", duh). And it turns out that some of those uses are definitely wrong, some of them are right, and some of them are suspect or at least so overly complicated that it's hard for the VM people to know if they are ok. Basically, the rule for "use_mm()" is that the mm in question *has* to have a valid page table associated with it over the whole use_mm() -> unuse_mm() sequence. That may sound obvious, and I guess it actually is so obvious that there isn't even a comment about it, but the actual users are showing that it's sadly apparently not so obvious after all. There is one user that uses the "obviously correct" model: the vhost driver does a "mmget()" and "mmput()" pair around its use of it, thanks to vhost_dev_set_owner() doing a dev->mm = get_task_mm(current); to look up the mm, and then the teardown case does a if (dev->mm) mmput(dev->mm); dev->mm = NULL; This is the *right* sequence. A gold star to the vhost people. Sadly, the vhost people are the only ones who seem to get things unquestionably right. And some of those gold star people are also apparently involved in the cases that didn't get things right. An example of something that *isn't* right, is the i915 kvm interface, which does use_mm(kvm->mm); on an mm that was initialized in virt/kvm/kvm_main.c using mmgrab(current->mm); kvm->mm = current->mm; which is *not* right. Using "mmgrab()" does indeed guarantee the lifetime of the 'struct mm_struct' itself, but it does *not* guarantee the lifetime of the page tables. You need to use "mmget()" and "mmput()", which get the reference to the actual process address space! Now, it is *possible* that the kvm use is correct too, because kvm does register a mmu_notifier chain, and in theory you can avoid the proper refcounting by just making sure the mmu "release" notifier kills any existing uses, but I don't really see kvm doing that. Kvm does register a release notifier, but that just flushes the shadow page tables, it doesn't kill any use_mm() use by some i915 use case. So while the vhost use looks right, the kvm/i915 use looks definitely wrong. The other users of "use_mm()" and "unuse_mm()" are less black-and-white right vs wrong.. One of the complex ones is the amdgpu driver. It does a "use_mm(mmptr)" deep deep in the guts of a macro that ends up being used in fa few places, and it's very hard to tell if it's right. It looks almost certainly buggy (there is no mmget/mmput to get the refcount), but there _is_ a "release" mmu_notifier function and that one - unlike the kvm case - looks like it might actually be trying to flush the existing pending users of that mm. But on the whole, I'm suspicious of the amdgpu use. It smells. Jann Horn pointed out that even if it migth be ok due to the mmu_notifier, the comments are garbage: Where "process" in the uniquely-named "struct queue" is a "struct kfd_process"; that struct's definition has this comment in it: /* * Opaque pointer to mm_struct. We don't hold a reference to * it so it should never be dereferenced from here. This is * only used for looking up processes by their mm. */ void *mm; So I think either that comment is wrong, or their code is wrong? so I'm chalking the amdgpu use up in the "broken" column. It's also actually quite hard to synchronze with some other kernel worker thread correctly, so just on general principles, if you use "use_mm()" it really really should be on something that you've properly gotten a mm refcount on with mmget(). Really. Even if you try to synchronize things. The two final cases are two uses in the USB gadget driver. Again, they don't have the proper mmget/mmput, but they may br ok simply because the uses are done for AIO, and the VM teardown is preceded by an AIO teardown, so the proper serialization may come in from that. Anyway, sorry for the long email, and the big list of participants and odd mailing lists, but I'd really like people to look at their "use_mm()" cases, and ask themselves if they have done enough to guarantee that the full mm exists. Again, "mmgrab()" is *not* enough on its own. You need either
Re: [Intel-gfx] [PATCH 00/18] use ARRAY_SIZE macro
Thanks for the patch! :) 2017-10-01 22:30 GMT+03:00 Jérémy Lefaure: > Hi everyone, > Using ARRAY_SIZE improves the code readability. I used coccinelle (I > made a change to the array_size.cocci file [1]) to find several places > where ARRAY_SIZE could be used instead of other macros or sizeof > division. > > I tried to divide the changes into a patch per subsystem (excepted for > staging). If one of the patch should be split into several patches, let > me know. > > In order to reduce the size of the To: and Cc: lines, each patch of the > series is sent only to the maintainers and lists concerned by the patch. > This cover letter is sent to every list concerned by this series. > > This series is based on linux-next next-20170929. Each patch has been > tested by building the relevant files with W=1. > > This series contains the following patches: > [PATCH 01/18] sound: use ARRAY_SIZE > [PATCH 02/18] tracing/filter: use ARRAY_SIZE > [PATCH 03/18] media: use ARRAY_SIZE > [PATCH 04/18] IB/mlx5: Use ARRAY_SIZE > [PATCH 05/18] net: use ARRAY_SIZE > [PATCH 06/18] drm: use ARRAY_SIZE > [PATCH 07/18] scsi: bfa: use ARRAY_SIZE > [PATCH 08/18] ecryptfs: use ARRAY_SIZE > [PATCH 09/18] nfsd: use ARRAY_SIZE > [PATCH 10/18] orangefs: use ARRAY_SIZE > [PATCH 11/18] dm space map metadata: use ARRAY_SIZE > [PATCH 12/18] x86: use ARRAY_SIZE > [PATCH 13/18] tpm: use ARRAY_SIZE > [PATCH 14/18] ipmi: use ARRAY_SIZE > [PATCH 15/18] acpi: use ARRAY_SIZE > [PATCH 16/18] media: staging: atomisp: use ARRAY_SIZE > [PATCH 17/18] staging: rtl8723bs: use ARRAY_SIZE > [PATCH 18/18] staging: rtlwifi: use ARRAY_SIZE > > > [1]: https://lkml.org/lkml/2017/9/13/689 > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx