Message-ID: <CABhMZUWZOc8n0mU4wL7VX88w936HGaLJHFYVEpRdSUKqhbsdrw@mail.gmail.com>
Date:   Wed, 1 Apr 2020 16:45:49 -0500
From:   Bjorn Helgaas <bjorn.helgaas@...il.com>
To:     "Derrick, Jonathan" <jonathan.derrick@...el.com>
Cc:     "helgaas@...nel.org" <helgaas@...nel.org>,
        "mr.nuke.me@...il.com" <mr.nuke.me@...il.com>,
        "hch@....de" <hch@....de>,
        "Shevchenko, Andriy" <andriy.shevchenko@...el.com>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mika.westerberg@...ux.intel.com" <mika.westerberg@...ux.intel.com>,
        "Baldysiak, Pawel" <pawel.baldysiak@...el.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "okaya@...nel.org" <okaya@...nel.org>,
        "kbusch@...nel.org" <kbusch@...nel.org>,
        "stuart.w.hayes@...il.com" <stuart.w.hayes@...il.com>
Subject: Re: [RFC 0/9] PCIe Hotplug Slot Emulation driver

On Mon, Mar 30, 2020 at 12:43 PM Derrick, Jonathan
<jonathan.derrick@...el.com> wrote:
> On Sat, 2020-03-28 at 16:51 -0500, Bjorn Helgaas wrote:
> > On Fri, Feb 07, 2020 at 04:59:58PM -0700, Jon Derrick wrote:
> > > This set adds an emulation driver for PCIe Hotplug. There may be platforms with
> > > specific configurations that can support hotplug but don't provide the logical
> > > slot hotplug hardware. For instance, the platform may use an
> > > electrically-tolerant interposer between the slot and the device.
> > > ...

> > There's a lot of good work in here, and I don't claim to understand
> > the use case and all the benefits.
> I've received more info that the customer use case is an AIC that
> breaks out 1-4 M.2 cards which have been made hotplug tolerant.
>
> > But it seems like quite a lot of additional code and complexity in an
> > area that's already pretty subtle, so I'm not yet convinced that it's
> > all worthwhile.
> >
> > It seems like this would rely on Data Link Layer Link Active
> > Reporting.  Is that something we could add to pciehp as a generic
> > feature without making a separate driver for it?  I haven't looked at
> > this for a while, but I would assume that if we find out that a link
> > went down, pciehp could/should be smart enough to notice that even if
> > it didn't come via the usual pciehp Slot Status path.
> I had a plan to do V2 by intercepting bus_ops rather than indirecting
> slot_ops in pciehp. That should touch /a lot/ less code.

I assume this is something like pci_bus_set_ops() or
pci_bus_set_aer_ops()?  Probably touches less code, but I'm not really
a fan of either of those current situations because they make things
magical -- there's a lot of stuff going on behind the curtain, and it
makes another thing to consider when we evaluate every pciehp change.

> The problem I saw with adding DLLLA as a primary signal in pciehp is
> that most of the pciehp boilerplate relies on valid Slot register
> logic. I don't know how reliable pciehp will be if there's no backing
> slot register logic, emulated or real. Consider how many slot
> capability reads are in hpc.
>
> I could add a non-slot flag check to each of those callers, but it
> might be worse than the emulation alternative.

I see what you mean -- there are quite a few reads of PCI_EXP_SLTSTA.
I'm not 100% sure all of those really need to exist.  I would expect
that we'd read it once in the ISR and then operate on that value.  So
maybe there's some middle ground of restructuring to remove some of
those reads and making the remaining few more generic.

All that being said, I'm also sympathetic to Christoph's concern about
cluttering pciehp to deal with non-standard topologies.  At some point
if you need to do non-standard things you may have to write and
maintain your own drivers.  I don't know where that point is yet.

Bjorn

Powered by blists - more mailing lists