[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250121164709.GA951990@bhelgaas>
Date: Tue, 21 Jan 2025 10:47:09 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Saladi.Rakeshbabu@...rochip.com
Cc: linux-pci@...r.kernel.org, bhelgaas@...gle.com,
linux-kernel@...r.kernel.org, logang@...tatee.com,
UNGLinuxDriver@...rochip.com, kurt.schwemmer@...rosemi.com
Subject: Re: [PATCH] PCI: switchtec: Include PCI100X devices support
On Tue, Jan 21, 2025 at 01:16:05PM +0000, Saladi.Rakeshbabu@...rochip.com wrote:
> On Mon, 2025-01-20 at 16:56 -0600, Bjorn Helgaas wrote:
> > [Some people who received this message don't often get email from
> > helgaas@...nel.org. Learn why this is important at
> > https://aka.ms/LearnAboutSenderIdentification ]
> >
> > EXTERNAL EMAIL: Do not click links or open attachments unless you
> > know the content is safe
> >
> > On Mon, Jan 20, 2025 at 03:25:24PM +0530, Rakesh Babu Saladi wrote:
> > > Add the Microchip Parts to the existing device ID
> > > table so that the driver supports PCI100x devices too.
> > >
> > > Add a new macro to quirk the Microchip switchtec PCI100x parts
> > > to allow DMA access via NTB to work when the IOMMU is turned on.
> > >
> > > PCI100x family has 6 variants, each variant is designed for
> > > different
> > > application usages, different port counts and lane counts.
> > >
> > > PCI1001 has 1 x4 upstream port and 3 x4 downstream ports.
> > > PCI1002 has 1 x4 upstream port and 4 x2 downstream ports.
> > > PCI1003 has 2 x4 upstream ports, 2 x2 upstream ports and 2 x2
> > > downstream ports.
> > > PCI1004 has 4 x4 upstream ports.
> > > PCI1005 has 1 x4 upstream port and 6 x2 downstream ports.
> > > PCI1006 has 6 x2 upstream ports and 2 x2 downstream ports.
> > >
> > > Signed-off-by: Rakesh Babu Saladi <Saladi.Rakeshbabu@...rochip.com>
> > > ---
> > > drivers/pci/quirks.c | 11 +++++++++++
> > > drivers/pci/switch/switchtec.c | 26 ++++++++++++++++++++++++++
> > > 2 files changed, 37 insertions(+)
> > >
> > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > > index eeec1d6f9023..266ab5f8c6e1 100644
> > > --- a/drivers/pci/quirks.c
> > > +++ b/drivers/pci/quirks.c
> > > @@ -5906,6 +5906,17 @@ SWITCHTEC_QUIRK(0x5552); /* PAXA 52XG5 */
> > > SWITCHTEC_QUIRK(0x5536); /* PAXA 36XG5 */
> > > SWITCHTEC_QUIRK(0x5528); /* PAXA 28XG5 */
> > >
> > > +#define SWITCHTEC_PCI100X_QUIRK(vid) \
> > > + DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_EFAR, vid, \
> > > + PCI_CLASS_BRIDGE_OTHER, 8,
> > > quirk_switchtec_ntb_dma_alias)
> > > +SWITCHTEC_PCI100X_QUIRK(0x1001); /* PCI1001XG4 */
> > > +SWITCHTEC_PCI100X_QUIRK(0x1002); /* PCI1002XG4 */
> > > +SWITCHTEC_PCI100X_QUIRK(0x1003); /* PCI1003XG4 */
> > > +SWITCHTEC_PCI100X_QUIRK(0x1004); /* PCI1004XG4 */
> > > +SWITCHTEC_PCI100X_QUIRK(0x1005); /* PCI1005XG4 */
> > > +SWITCHTEC_PCI100X_QUIRK(0x1006); /* PCI1006XG4 */
> > > +
> > > +
> > > /*
> > > * The PLX NTB uses devfn proxy IDs to move TLPs between NT
> > > endpoints.
> > > * These IDs are used to forward responses to the originator on
> > > the other
> > > diff --git a/drivers/pci/switch/switchtec.c
> > > b/drivers/pci/switch/switchtec.c
> > > index 5b921387eca6..faaca76407c8 100644
> > > --- a/drivers/pci/switch/switchtec.c
> > > +++ b/drivers/pci/switch/switchtec.c
> > > @@ -1726,6 +1726,26 @@ static void switchtec_pci_remove(struct
> > > pci_dev *pdev)
> > > .driver_data = gen, \
> > > }
> > >
> > > +#define SWITCHTEC_PCI100X_DEVICE(device_id, gen) \
> > > + { \
> > > + .vendor = PCI_VENDOR_ID_EFAR, \
> > > + .device = device_id, \
> > > + .subvendor = PCI_ANY_ID, \
> > > + .subdevice = PCI_ANY_ID, \
> > > + .class = (PCI_CLASS_MEMORY_OTHER << 8), \
> > > + .class_mask = 0xFFFFFFFF, \
> > > + .driver_data = gen, \
> > > + }, \
> > > + { \
> > > + .vendor = PCI_VENDOR_ID_EFAR, \
> > > + .device = device_id, \
> > > + .subvendor = PCI_ANY_ID, \
> > > + .subdevice = PCI_ANY_ID, \
> > > + .class = (PCI_CLASS_BRIDGE_OTHER << 8), \
> > > + .class_mask = 0xFFFFFFFF, \
> > > + .driver_data = gen, \
> >
> > We have this:
> >
> > #define PCI_VENDOR_ID_EFAR 0x1055
> >
> > but searching the PCI-SIG Vendor ID database for 0x1055 doesn't find
> > anything:
> >
> > https://pcisig.com/membership/member-companies
> >
> > You mention "Microchip", and it looks like Microchip is assigned
> > Vendor ID 0x11f8:
> >
> > https://pcisig.com/membership/member-companies?combine=microchip
> >
> > which we also have defined:
> >
> > #define PCI_VENDOR_ID_PMC_Sierra 0x11f8
> > #define PCI_VENDOR_ID_MICROSEMI 0x11f8
> >
> > Can you clarify what's going on here? I assume these parts actually
> > do have Vendor ID 0x1055. But the PCI-SIG really should know about
> > the usage of this ID. There's an email contact address on that web
> > page; can you straighten this out?
>
> PMC, Microsemi are now part of Microchip. The switchtec products are
> from Microsemi and so the vendor ID is 0x11f8. EFAR is also part of
> Microchip. For PCI100x product parts we intended to use the VID 0x1055
> which is of EFAR's VID. PMC, Microsemi and EFAR product parts all are
> now part of Microchip.
>
> The reason why EFAR VID (0x1055) is not listed in the website is
> becuase the site can list only one VID per company.
>
> For further information, please refer to Steen's reply of
> https://lore.kernel.org/linux-pci/f695618054232c5f43c2148c5e6551f3ab318792.camel@microchip.com/to
> https://lore.kernel.org/linux-pci/20240621184923.GA1398370@bhelgaas/
Thanks. What an annoyance that the PCI-SIG can't expose Vendor IDs
that are allocated but no longer correspond to the original vendor.
I'll complain to the SIG again.
Bjorn
Powered by blists - more mailing lists