All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amey Narkhede <ameynarkhede03@gmail.com>
To: Bjorn Helgaas <helgaas@kernel.org>
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 v10 4/8] PCI/sysfs: Allow userspace to query and set device reset mechanism
Date: Sun, 1 Aug 2021 00:45:05 +0530	[thread overview]
Message-ID: <20210731191505.xzor5lpqv4ubmijf@archlinux> (raw)
In-Reply-To: <20210727232808.GA754831@bjorn-Precision-5520>

On 21/07/27 06:28PM, Bjorn Helgaas wrote:
> On Fri, Jul 09, 2021 at 06:08:09PM +0530, Amey Narkhede wrote:
> > Add reset_method sysfs attribute to enable user to query and set user
> > preferred device reset methods and their ordering.
> >
> > Co-developed-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Amey Narkhede <ameynarkhede03@gmail.com>
> > ---
> >  Documentation/ABI/testing/sysfs-bus-pci |  19 +++++
> >  drivers/pci/pci-sysfs.c                 | 103 ++++++++++++++++++++++++
> >  2 files changed, 122 insertions(+)
> >
[...]

> > +		if (i == PCI_NUM_RESET_METHODS) {
> > +			kfree(options);
> > +			return -EINVAL;
> > +		}
> > +	}
> > +
> > +	if (!pci_reset_fn_methods[1].reset_fn(pdev, 1) && reset_methods[0] != 1)
> > +		pci_warn(pdev, "Device specific reset disabled/de-prioritized by user");
>
> Hmmm.  I sort of see the point here, but I wish we didn't have the
> implicit dependency on pci_reset_fn_methods[1] being
> pci_dev_specific_reset().
>
> I know we've talked about this before.  I'm still not 100% sure either
> of these warnings is worthwhile, especially since we're not *using*
> the reset here.  It might be useful at the point where we try to *do*
> a reset.  I dunno.  Maybe this is the best place since this is where
> the user potentially screwed up.
>
I agree this is the best place for the warning as this where potentially
broken reset methods may get called/prioritized. We can move this check
to __pci_reset_function_locked() if you want.

> > +set_reset_methods:
> > +	memcpy(pdev->reset_methods, reset_methods, sizeof(reset_methods));
> > +	kfree(options);
> > +	return count;
> > +}
> > +static DEVICE_ATTR_RW(reset_method);
> > +
> > +static struct attribute *pci_dev_reset_method_attrs[] = {
> > +	&dev_attr_reset_method.attr,
> > +	NULL,
> > +};
> > +
> > +static umode_t pci_dev_reset_method_attr_is_visible(struct kobject *kobj,
> > +						    struct attribute *a, int n)
> > +{
> > +	struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
> > +
> > +	if (!pci_reset_supported(pdev))
> > +		return 0;
> > +
> > +	return a->mode;
> > +}
> > +
> > +static const struct attribute_group pci_dev_reset_method_attr_group = {
> > +	.attrs = pci_dev_reset_method_attrs,
> > +	.is_visible = pci_dev_reset_method_attr_is_visible,
> > +};
> > +
> >  static ssize_t reset_store(struct device *dev, struct device_attribute *attr,
> >  			   const char *buf, size_t count)
> >  {
> > @@ -1491,6 +1593,7 @@ const struct attribute_group *pci_dev_groups[] = {
> >  	&pci_dev_config_attr_group,
> >  	&pci_dev_rom_attr_group,
> >  	&pci_dev_reset_attr_group,
> > +	&pci_dev_reset_method_attr_group,
> >  	&pci_dev_vpd_attr_group,
> >  #ifdef CONFIG_DMI
> >  	&pci_dev_smbios_attr_group,
> > --
> > 2.32.0
> >

  parent reply	other threads:[~2021-07-31 19:15 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-09 12:38 [PATCH v10 0/8] Expose and manage PCI device reset Amey Narkhede
2021-07-09 12:38 ` [PATCH v10 1/8] PCI: Add pcie_reset_flr to follow calling convention of other reset methods Amey Narkhede
2021-07-12 22:07   ` Alex Williamson
2021-07-27 22:12   ` Bjorn Helgaas
2021-07-28 18:54     ` Shanker R Donthineni
2021-07-28 20:23       ` Bjorn Helgaas
2021-07-28 21:58         ` Shanker R Donthineni
2021-07-28 22:04           ` Shanker R Donthineni
2021-07-28 22:16           ` Bjorn Helgaas
2021-07-09 12:38 ` [PATCH v10 2/8] PCI: Add new array for keeping track of ordering of " Amey Narkhede
2021-07-27 22:59   ` Bjorn Helgaas
2021-07-28 17:45     ` Amey Narkhede
2021-07-28 17:59       ` Bjorn Helgaas
2021-07-28 18:17         ` Shanker R Donthineni
2021-07-28 18:08       ` Shanker R Donthineni
2021-07-28 18:31     ` Shanker R Donthineni
2021-07-28 20:25       ` Bjorn Helgaas
2021-07-28 22:01         ` Shanker R Donthineni
2021-07-09 12:38 ` [PATCH v10 3/8] PCI: Remove reset_fn field from pci_dev Amey Narkhede
2021-07-09 12:38 ` [PATCH v10 4/8] PCI/sysfs: Allow userspace to query and set device reset mechanism Amey Narkhede
2021-07-27 23:28   ` Bjorn Helgaas
2021-07-28  1:27     ` Krzysztof Wilczyński
2021-07-28 15:36       ` Bjorn Helgaas
2021-07-28 17:59     ` Amey Narkhede
2021-07-28 18:13       ` Bjorn Helgaas
2021-07-28 18:58         ` Amey Narkhede
2021-07-28 20:18           ` Bjorn Helgaas
2021-07-31 19:15     ` Amey Narkhede [this message]
2021-07-28 17:09   ` Bjorn Helgaas
2021-07-09 12:38 ` [PATCH v10 5/8] PCI: Define a function to set ACPI_COMPANION in pci_dev Amey Narkhede
2021-07-12 22:29   ` Alex Williamson
2021-07-09 12:38 ` [PATCH v10 6/8] PCI: Setup ACPI fwnode early and at the same time with OF Amey Narkhede
2021-07-12 23:09   ` Alex Williamson
2021-07-27 23:30   ` Bjorn Helgaas
2021-07-27 23:50     ` Shanker R Donthineni
2021-07-09 12:38 ` [PATCH v10 7/8] PCI: Add support for ACPI _RST reset method Amey Narkhede
2021-07-12 23:09   ` Alex Williamson
2021-07-13  0:51     ` Shanker R Donthineni
2021-07-14 22:56       ` Alex Williamson
2021-07-09 12:38 ` [PATCH v10 8/8] PCI: Change the type of probe argument in reset functions Amey Narkhede
2021-07-12 22:24   ` Alex Williamson
2021-07-27 22:22   ` Bjorn Helgaas
2021-07-28 17:35     ` Amey Narkhede
2021-07-28 17:55       ` Bjorn Helgaas
2021-07-09 12:46 ` [PATCH v10 0/8] Expose and manage PCI device reset 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=20210731191505.xzor5lpqv4ubmijf@archlinux \
    --to=ameynarkhede03@gmail.com \
    --cc=alex.williamson@redhat.com \
    --cc=helgaas@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.