lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210423093701.594efd86@redhat.com>
Date:   Fri, 23 Apr 2021 09:37:01 -0600
From:   Alex Williamson <alex.williamson@...hat.com>
To:     Sinan Kaya <okaya@...nel.org>
Cc:     Shanker Donthineni <sdonthineni@...dia.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, Vikram Sethi <vsethi@...dia.com>
Subject: Re: [PATCH 1/1] PCI: Add pci reset quirk for Nvidia GPUs

On Fri, 23 Apr 2021 11:12:05 -0400
Sinan Kaya <okaya@...nel.org> wrote:

> +Alex,
> 
> On 4/23/2021 10:54 AM, Shanker Donthineni wrote:
> > +static int reset_nvidia_gpu_quirk(struct pci_dev *dev, int probe)
> > +{
> > +#ifdef CONFIG_ACPI
> > +	acpi_handle handle = ACPI_HANDLE(&dev->dev);
> > +
> > +	/*
> > +	 * Check for the affected devices' ID range. If device is not in
> > +	 * the affected range, return -ENOTTY indicating no device
> > +	 * specific reset method is available.
> > +	 */
> > +	if ((dev->device & 0xffc0) != 0x2340)
> > +		return -ENOTTY;
> > +
> > +	/*
> > +	 * Return -ENOTTY indicating no device-specific reset method if _RST
> > +	 * method is not defined
> > +	 */
> > +	if (!handle || !acpi_has_method(handle, "_RST"))
> > +		return -ENOTTY;
> > +
> > +	/* Return 0 for probe phase indicating that we can reset this device */
> > +	if (probe)
> > +		return 0;
> > +
> > +	/* Invoke _RST() method to perform the device-specific reset */
> > +	if (ACPI_FAILURE(acpi_evaluate_object(handle, "_RST", NULL, NULL))) {
> > +		pci_warn(dev, "Failed to reset the device\n");
> > +		return -EINVAL;
> > +	}
> > +	return 0;
> > +#else
> > +	return -ENOTTY;
> > +#endif
> > +}  
> 
> Interesting, some pieces of this function (especially the ACPI _RST)
> could be generalized.

Agreed, we should add a new function level reset method for this rather
than a device specific reset.  At that point the extent of the device
specific quirk could be to restrict SBR.  It'd be useful to know what
these devices are (not in pciids yet), why we expect to only see them in
specific platforms (embedded device?), and the failure mode of the SBR.
Thanks,

Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ