Re: [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive
On 4/3/24 4:30 AM, Leon Romanovsky wrote: > On Fri, Mar 29, 2024 at 05:00:25PM +, Easwar Hariharan wrote: >> I2C v7, SMBus 3.2, and I3C 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 where I had a role to play, now >> that >> the approved verbiage exists in the specification. >> >> Compile tested, no functionality changes intended >> >> [1]: >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ >> >> Signed-off-by: Easwar Hariharan >> --- >> drivers/infiniband/hw/hfi1/chip.c | 6 ++-- >> drivers/infiniband/hw/hfi1/chip.h | 2 +- >> drivers/infiniband/hw/hfi1/chip_registers.h | 2 +- >> drivers/infiniband/hw/hfi1/file_ops.c | 2 +- >> drivers/infiniband/hw/hfi1/firmware.c | 22 ++--- >> drivers/infiniband/hw/hfi1/pcie.c | 2 +- >> drivers/infiniband/hw/hfi1/qsfp.c | 36 ++--- >> drivers/infiniband/hw/hfi1/user_exp_rcv.c | 2 +- >> drivers/infiniband/hw/qib/qib_twsi.c| 6 ++-- >> 9 files changed, 40 insertions(+), 40 deletions(-) > > hfi1 and qib work perfectly fine with the current terminology. There is > no need to change old code just for the sake of change. > > Let's drop this patch. Agreed.
Re: [PATCH 11/28] infiniband: qib: Use PCI_IRQ_INTX
On 3/25/24 3:09 AM, Damien Le Moal wrote: > Use the macro PCI_IRQ_INTX instead of the deprecated PCI_IRQ_LEGACY > macro. > > Signed-off-by: Damien Le Moal > --- > drivers/infiniband/hw/qib/qib_iba7220.c | 2 +- > drivers/infiniband/hw/qib/qib_iba7322.c | 5 ++--- > drivers/infiniband/hw/qib/qib_pcie.c| 2 +- > 3 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/infiniband/hw/qib/qib_iba7220.c > b/drivers/infiniband/hw/qib/qib_iba7220.c > index 6af57067c32e..78dfe98ebcf7 100644 > --- a/drivers/infiniband/hw/qib/qib_iba7220.c > +++ b/drivers/infiniband/hw/qib/qib_iba7220.c > @@ -3281,7 +3281,7 @@ static int qib_7220_intr_fallback(struct qib_devdata > *dd) > > qib_free_irq(dd); > dd->msi_lo = 0; > - if (pci_alloc_irq_vectors(dd->pcidev, 1, 1, PCI_IRQ_LEGACY) < 0) > + if (pci_alloc_irq_vectors(dd->pcidev, 1, 1, PCI_IRQ_INTX) < 0) > qib_dev_err(dd, "Failed to enable INTx\n"); > qib_setup_7220_interrupt(dd); > return 1; > diff --git a/drivers/infiniband/hw/qib/qib_iba7322.c > b/drivers/infiniband/hw/qib/qib_iba7322.c > index f93906d8fc09..9db29916e35a 100644 > --- a/drivers/infiniband/hw/qib/qib_iba7322.c > +++ b/drivers/infiniband/hw/qib/qib_iba7322.c > @@ -3471,8 +3471,7 @@ static void qib_setup_7322_interrupt(struct qib_devdata > *dd, int clearpend) > pci_irq_vector(dd->pcidev, msixnum), > ret); > qib_7322_free_irq(dd); > - pci_alloc_irq_vectors(dd->pcidev, 1, 1, > - PCI_IRQ_LEGACY); > + pci_alloc_irq_vectors(dd->pcidev, 1, 1, PCI_IRQ_INTX); > goto try_intx; > } > dd->cspec->msix_entries[msixnum].arg = arg; > @@ -5143,7 +5142,7 @@ static int qib_7322_intr_fallback(struct qib_devdata > *dd) > qib_devinfo(dd->pcidev, > "MSIx interrupt not detected, trying INTx interrupts\n"); > qib_7322_free_irq(dd); > - if (pci_alloc_irq_vectors(dd->pcidev, 1, 1, PCI_IRQ_LEGACY) < 0) > + if (pci_alloc_irq_vectors(dd->pcidev, 1, 1, PCI_IRQ_INTX) < 0) > qib_dev_err(dd, "Failed to enable INTx\n"); > qib_setup_7322_interrupt(dd, 0); > return 1; > diff --git a/drivers/infiniband/hw/qib/qib_pcie.c > b/drivers/infiniband/hw/qib/qib_pcie.c > index 47bf64ace05c..58c1d62d341b 100644 > --- a/drivers/infiniband/hw/qib/qib_pcie.c > +++ b/drivers/infiniband/hw/qib/qib_pcie.c > @@ -210,7 +210,7 @@ int qib_pcie_params(struct qib_devdata *dd, u32 minw, u32 > *nent) > } > > if (dd->flags & QIB_HAS_INTX) > - flags |= PCI_IRQ_LEGACY; > + flags |= PCI_IRQ_INTX; > maxvec = (nent && *nent) ? *nent : 1; > nvec = pci_alloc_irq_vectors(dd->pcidev, 1, maxvec, flags); > if (nvec < 0) No problems here. Acked-by: Dennis Dalessandro
Re: [PATCH v4 0/2] Add p2p via dmabuf to habanalabs
On 7/6/21 1:59 PM, Jason Gunthorpe wrote: > I can not say the same about other company's RDMA driver > distributions, Daniel's description of "minimal effort to get > goodwill" would match others much better. Not sure what other RDMA driver you are talking about but as for Cornelis Networks, we do have a packaged up version of our software. However it is meant to make things easier on end users to bridge the gap between the distro kernel drivers and the upstream kernel. It's definitely not a requirement and plenty of folks do use distro kernels/drivers. I'm not sure how many large sites are using something straight off kernel.org but the upstream hfi1 driver is 100% the real deal. We continually develop on and test the upstream kernel. Our goal is always to upstream patches first. We learned that lesson the hard way when we first tried to upstream hfi1. -Denny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 06/15] RDMA/hfi1: Use mmu_range_notifier_inset for user_exp_rcv
On 10/28/2019 4:10 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This converts one of the two users of mmu_notifiers to use the new API. The conversion is fairly straightforward, however the existing use of notifiers here seems to be racey. Cc: Mike Marciniszyn Cc: Dennis Dalessandro Signed-off-by: Jason Gunthorpe I tested v1, and replied to it [1]. I can re-test with this version if you like as well. [1] https://marc.info/?l=linux-rdma=157235130606412=2 -Denny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH hmm 06/15] RDMA/hfi1: Use mmu_range_notifier_inset for user_exp_rcv
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote: From: Jason Gunthorpe This converts one of the two users of mmu_notifiers to use the new API. The conversion is fairly straightforward, however the existing use of notifiers here seems to be racey. Cc: Mike Marciniszyn Cc: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Typo in subject s/inset/insert. Tested-by: Dennis Dalessandro Thanks -Denny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
On 10/21/2019 12:58 PM, Jason Gunthorpe wrote: On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote: On 10/15/2019 2:12 PM, Jason Gunthorpe wrote: This is still being tested, but I figured to send it to start getting help from the xen, amd and hfi drivers which I cannot test here. Sorry for the delay, I never seen this. Was not on Cc list and didn't register to me it impacted hfi. I'll take a look and run it through some hfi1 tests. Hm, you were cc'd on the hfi1 patch of the series: https://patchwork.kernel.org/patch/11191395/ So you saw that, right? I do now. But it seems that git send-email didn't pull all the cc's together? I don't know. I thought it did, at one time I recall trying to get it *not* to do that, when preparing some internal reviews. Haven't used it for a long time though, I've been using stgit. At any rate can you give me a SHA or branch this applies on top of? I have pulled rdma/hmm, rdma/wip/jgg, linus/master but seem to have conflicts. -Denny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
On 10/15/2019 2:12 PM, Jason Gunthorpe wrote: This is still being tested, but I figured to send it to start getting help from the xen, amd and hfi drivers which I cannot test here. Sorry for the delay, I never seen this. Was not on Cc list and didn't register to me it impacted hfi. I'll take a look and run it through some hfi1 tests. -Denny ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
