From: Bjorn Helgaas <helgaas@kernel.org>
To: Amey Narkhede <ameynarkhede03@gmail.com>
Cc: alex.williamson@redhat.com,
Raphael Norwitz <raphael.norwitz@nutanix.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kw@linux.com, Shanker Donthineni <sdonthineni@nvidia.com>,
Sinan Kaya <okaya@kernel.org>, Len Brown <lenb@kernel.org>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v7 4/8] PCI/sysfs: Allow userspace to query and set device reset mechanism
Date: Thu, 24 Jun 2021 12:59:09 -0500 [thread overview]
Message-ID: <20210624175909.GA3542781@bjorn-Precision-5520> (raw)
In-Reply-To: <20210624172806.ay6dak2wdtv3nruj@archlinux>
On Thu, Jun 24, 2021 at 10:58:06PM +0530, Amey Narkhede wrote:
> On 21/06/24 11:56AM, Bjorn Helgaas wrote:
> > On Thu, Jun 24, 2021 at 08:42:42PM +0530, Amey Narkhede wrote:
> > > On 21/06/24 07:15AM, Bjorn Helgaas wrote:
> > > > On Tue, Jun 08, 2021 at 11:18:53AM +0530, Amey Narkhede wrote:
> > > > > Add reset_method sysfs attribute to enable user to
> > > > > query and set user preferred device reset methods and
> > > > > their ordering.
> > > >
> > > > > + Writing the name or comma separated list of names of any of
> > > > > + the device supported reset methods to this file will set the
> > > > > + reset methods and their ordering to be used when resetting
> > > > > + the device.
> > > >
> > > > > + while ((name = strsep(&options, ",")) != NULL) {
> > > > > + if (sysfs_streq(name, ""))
> > > > > + continue;
> > > > > +
> > > > > + name = strim(name);
> > > > > +
> > > > > + for (i = 0; i < PCI_RESET_METHODS_NUM; i++) {
> > > > > + if (reset_methods[i] &&
> > > > > + sysfs_streq(name, pci_reset_fn_methods[i].name)) {
> > > > > + reset_methods[i] = prio--;
> > > > > + break;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + if (i == PCI_RESET_METHODS_NUM) {
> > > > > + kfree(options);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > + }
> > > >
> > > > Asking again since we didn't get this clarified before. The above
> > > > tells me that "reset_methods" allows the user to control the
> > > > *order* in which we try reset methods.
> > > >
> > > > Consider the following two uses:
> > > >
> > > > (1) # echo bus,flr > reset_methods
> > > >
> > > > (2) # echo flr,bus > reset_methods
> > > >
> > > > Do these have the same effect or not?
> > > >
> > > They have different effect.
> >
> > I asked about this because Shanker's idea [1] of using two bitmaps
> > only keeps track of which resets are *enabled*. It does not keep
> > track of the *ordering*. Since you want to control the ordering, I
> > think we need more state than just the supported/enabled bitmaps.
> >
> > > > If "reset_methods" allows control over the order, I expect them to
> > > > be different: (1) would try a bus reset and, if the bus reset
> > > > failed, an FLR, while (2) would try an FLR and, if the FLR failed,
> > > > a bus reset.
> > >
> > > Exactly you are right.
> > >
> > > Now the point I was presenting was with new encoding we have to
> > > write list of *all of the supported reset methods* in order for
> > > example, in above example flr,bus or bus,flr. We can't just write
> > > 'flr' or 'bus' then switch back to writing flr,bus/bus,flr (these
> > > have different effect as mentioned earlier).
> >
> > It sounds like you're saying this sequence can't work:
> >
> > # echo flr > reset_methods
>
> # dev->reset_methods = [3, 0, 0, ..]
>
> > # echo bus,flr > reset_methods
>
> # to get dev->reset_methods = [6, 3, 0, ...]
> we'll need to probe reset methods here.
>
> > But I'm afraid you'll have to walk me through the reasons why this
> > can't be made to work.
>
> I wrote incomplete description. It can work but we'll need to probe
> everytime which involves reading different capabilities(PCI_CAP_ID_AF,
> PCI_PM_CTRL etc) from device. With current encoding we just have to
> probe at the begining.
>
> > > Basically with new encoding an user can't write subset of reset
> > > methods they have to write list of *all* supported methods
> > > everytime.
> >
> > Why does the user have to write all supported methods? Is that to
> > preserve the fact that "cat reset_methods" always shows all the
> > supported methods so the user knows what's available?
> >
> > I'm wondering why we can't do something like this (pidgin code):
> >
> > if (option == "default") {
> > pci_init_reset_methods(dev);
> > return;
> > }
> >
> > n = 0;
> > foreach method in option {
> > i = lookup_reset_method(method);
> > if (pci_reset_methods[i].reset_fn(dev, PROBE) == 0)
>
> Repeatedly calling probe might have some impact as it involves reading
> device registers as explained earlier.
>
> > dev->reset_methods[n++] = i; # method i supported
> > }
> > dev->reset_methods[n++] = 0; # end of supported methods
> >
> > If we did something like the above, the user could always find the
> > list of all methods supported by a device by doing this:
> >
> > # echo default > reset_methods
> > # cat reset_methods
>
> This is one solution for current problem with new encoding.
>
> > Yes, this does call the "probe" methods several times. I don't think
> > that's necessarily a problem.
>
> I thought this would be a problem because of your earlier suggestion
> of caching flr capability to avoid probing multiple times. In this case
> we'll need to read different device registers multiple times. With
> current encoding we don't have to do that multiple times.
I don't think it's a problem to run "probe" methods when we're setting
the enabled reset methods (either at enumeration-time or when we write
to "reset_methods"). These are low-frequency events and I don't think
there's any performance issue.
I don't think we should have to run "probe" methods every time we call
pci_reset_function().
I suggested a dev->has_flr bit for two reasons:
1) It avoids reading PCI_EXP_DEVCAP every time a driver calls
pcie_reset_flr(), and
2) It gives a nice opportunity for quirks to disable FLR for devices
where it's broken.
> > [1] https://lore.kernel.org/r/1fb0a184-908c-5f98-ef6d-74edc602c2e0@nvidia.com
next prev parent reply other threads:[~2021-06-24 17:59 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-08 5:48 [PATCH v7 0/8] Expose and manage PCI device reset Amey Narkhede
2021-06-08 5:48 ` [PATCH v7 1/8] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-06-10 20:15 ` Shanker R Donthineni
2021-06-17 21:57 ` Bjorn Helgaas
2021-06-17 22:51 ` Alex Williamson
2021-06-18 16:32 ` Amey Narkhede
2021-06-24 12:23 ` Bjorn Helgaas
2021-06-24 15:28 ` Amey Narkhede
2021-06-24 16:15 ` Bjorn Helgaas
2021-06-24 18:48 ` Alex Williamson
2021-06-08 5:48 ` [PATCH v7 2/8] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-06-10 20:15 ` Shanker R Donthineni
2021-06-17 23:13 ` Bjorn Helgaas
2021-06-18 17:22 ` Amey Narkhede
2021-06-21 15:02 ` Shanker R Donthineni
2021-06-21 17:15 ` Amey Narkhede
2021-06-21 18:37 ` Bjorn Helgaas
2021-06-08 5:48 ` [PATCH v7 3/8] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-06-10 20:16 ` Shanker R Donthineni
2021-06-08 5:48 ` [PATCH v7 4/8] PCI/sysfs: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-06-09 21:57 ` Raphael Norwitz
2021-06-09 22:36 ` Shanker R Donthineni
2021-06-09 22:48 ` Raphael Norwitz
2021-06-10 20:16 ` Shanker R Donthineni
2021-06-18 20:00 ` Bjorn Helgaas
2021-06-19 13:59 ` Amey Narkhede
2021-06-21 13:01 ` Bjorn Helgaas
2021-06-21 17:28 ` Amey Narkhede
2021-06-21 19:07 ` Bjorn Helgaas
2021-06-21 19:33 ` Amey Narkhede
2021-06-23 12:06 ` Bjorn Helgaas
2021-06-23 14:07 ` Amey Narkhede
2021-06-23 17:56 ` Amey Narkhede
2021-06-23 17:21 ` Alex Williamson
2021-06-24 12:15 ` Bjorn Helgaas
2021-06-24 15:12 ` Amey Narkhede
2021-06-24 16:56 ` Bjorn Helgaas
2021-06-24 17:20 ` Shanker R Donthineni
2021-06-24 17:28 ` Amey Narkhede
2021-06-24 17:59 ` Bjorn Helgaas [this message]
2021-06-08 5:48 ` [PATCH v7 5/8] PCI: Setup ACPI_COMPANION early Amey Narkhede
2021-06-08 5:48 ` [PATCH v7 6/8] PCI: Add support for ACPI _RST reset method Amey Narkhede
2021-06-08 5:48 ` [PATCH v7 7/8] PCI: Enable NO_BUS_RESET quirk for Nvidia GPUs Amey Narkhede
2021-06-10 23:16 ` Bjorn Helgaas
2021-06-10 23:33 ` Shanker R Donthineni
2021-06-10 23:43 ` Shanker R Donthineni
2021-06-10 23:53 ` Bjorn Helgaas
2021-06-11 4:15 ` Shanker R Donthineni
2021-06-08 5:48 ` [PATCH v7 8/8] PCI: Change the type of probe argument in reset functions Amey Narkhede
2021-06-09 21:40 ` Raphael Norwitz
2021-06-08 10:05 ` [PATCH v7 0/8] Expose and manage PCI device reset Enrico Weigelt, metux IT consult
2021-06-08 15:44 ` Amey Narkhede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210624175909.GA3542781@bjorn-Precision-5520 \
--to=helgaas@kernel.org \
--cc=alex.williamson@redhat.com \
--cc=ameynarkhede03@gmail.com \
--cc=kw@linux.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=okaya@kernel.org \
--cc=raphael.norwitz@nutanix.com \
--cc=rjw@rjwysocki.net \
--cc=sdonthineni@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).