[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210624151242.ybew2z5rseuusj7v@archlinux>
Date: Thu, 24 Jun 2021 20:42:42 +0530
From: Amey Narkhede <ameynarkhede03@...il.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: alex.williamson@...hat.com,
Raphael Norwitz <raphael.norwitz@...anix.com>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
kw@...ux.com, Shanker Donthineni <sdonthineni@...dia.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 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.
> 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).
Basically with new encoding an user can't write subset of reset methods
they have to write list of *all* supported methods everytime.
Thanks,
Amey
Powered by blists - more mailing lists