[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6659e61c-f9ae-4450-53ab-75b76a9f3c5e@nvidia.com>
Date: Thu, 24 Jun 2021 12:20:52 -0500
From: Shanker R Donthineni <sdonthineni@...dia.com>
To: Bjorn Helgaas <helgaas@...nel.org>,
Amey Narkhede <ameynarkhede03@...il.com>
CC: <alex.williamson@...hat.com>,
Raphael Norwitz <raphael.norwitz@...anix.com>,
<linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kw@...ux.com>, Sinan Kaya <okaya@...nel.org>,
Len Brown <lenb@...nel.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v7 4/8] PCI/sysfs: Allow userspace to query and set device
reset mechanism
On 6/24/21 11:56 AM, Bjorn Helgaas wrote:
> 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)
> 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
>
> Yes, this does call the "probe" methods several times. I don't think
> that's necessarily a problem.
Agree, I don't think admin/user will change reset methods frequently and no
side effects or performance impacts on probing multiple times.
We should support enabling partially ordered reset methods and restore
default methods either by re-probing resets or remember supported
resets in pci_dev.
Powered by blists - more mailing lists