All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: "Kuppuswamy,
	Sathyanarayanan"  <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	ashok.raj@intel.com, Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v18 10/11] PCI/DPC: Add Error Disconnect Recover (EDR) support
Date: Thu, 26 Mar 2020 17:36:37 -0500	[thread overview]
Message-ID: <20200326223637.GA106135@google.com> (raw)
In-Reply-To: <f71c989b-b8f8-3437-b086-a97c2aa1e2c5@linux.intel.com>

On Tue, Mar 24, 2020 at 06:00:31PM -0700, Kuppuswamy, Sathyanarayanan wrote:
> Hi Bjorn,
> 
> On 3/24/20 2:37 PM, Bjorn Helgaas wrote:
> > This is really ugly.  What's the story on this firmware?  It sounds
> > defective to me.
>
> I think there is no defined standard for this. I have checked few
> _DSM implementations. Some of them return default value and some
> don't. But atleast in the test hardware I use, we need this check.

I agree that I don't see anything in the ACPI spec v6.3 about what
should happen if we supply a Function Index that isn't supported.
That looks like a hole in the spec.

> > Or is everybody that uses _DSM supposed to check before evaluating it?
>
> I think its safer to do this check.
>
> > E.g.,
> > 
> >    if (!acpi_check_dsm(...))
> >      return -EINVAL;
> > 
> >    obj = acpi_evaluate_dsm(...);
> > 
> > If everybody is supposed to do this, it seems like the check part
> > should be moved into acpi_evaluate_dsm().

So my question, and I guess this is really for Rafael, is that since
it seems like *everybody* needs to use acpi_check_dsm() in order to
use acpi_evaluate_dsm() safely, why don't we move the check *into*
acpi_evaluate_dsm()?

It's just error prone if we expect everybody to call both interfaces.

Bjorn

  reply	other threads:[~2020-03-26 22:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24  0:25 [PATCH v18 00/11] Add Error Disconnect Recover (EDR) support sathyanarayanan.kuppuswamy
2020-03-24  0:25 ` [PATCH v18 01/11] PCI/ERR: Update error status after reset_link() sathyanarayanan.kuppuswamy
2020-03-24  0:25 ` [PATCH v18 02/11] PCI: move {pciehp,shpchp}_is_native() definitions to pci.c sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 03/11] PCI/DPC: Fix DPC recovery issue in non hotplug case sathyanarayanan.kuppuswamy
2020-03-24 23:49   ` Bjorn Helgaas
2020-03-25  1:17     ` Kuppuswamy, Sathyanarayanan
2020-03-28 17:10       ` Bjorn Helgaas
2020-03-28 22:04         ` Kuppuswamy, Sathyanarayanan
2020-03-28 22:21           ` Bjorn Helgaas
2020-03-28 22:40             ` Kuppuswamy, Sathyanarayanan
2020-03-24  0:26 ` [PATCH v18 04/11] PCI/DPC: Move DPC data into struct pci_dev sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 05/11] PCI/ERR: Remove service dependency in pcie_do_recovery() sathyanarayanan.kuppuswamy
2020-03-28 21:12   ` Kuppuswamy, Sathyanarayanan
2020-03-28 21:32     ` Bjorn Helgaas
2020-03-28 21:55       ` Kuppuswamy, Sathyanarayanan
2020-03-28 22:16         ` Bjorn Helgaas
2020-03-24  0:26 ` [PATCH v18 06/11] PCI/ERR: Return status of pcie_do_recovery() sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 07/11] PCI/DPC: Cache DPC capabilities in pci_init_capabilities() sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 08/11] PCI/AER: Add pci_aer_raw_clear_status() to unconditionally clear Error Status sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 09/11] PCI/DPC: Expose dpc_process_error(), dpc_reset_link() for use by EDR sathyanarayanan.kuppuswamy
2020-03-24  0:26 ` [PATCH v18 10/11] PCI/DPC: Add Error Disconnect Recover (EDR) support sathyanarayanan.kuppuswamy
2020-03-24 21:37   ` Bjorn Helgaas
2020-03-25  1:00     ` Kuppuswamy, Sathyanarayanan
2020-03-26 22:36       ` Bjorn Helgaas [this message]
2024-04-11 18:07   ` Bjorn Helgaas
2024-04-11 19:16     ` Kuppuswamy Sathyanarayanan
2020-03-24  0:26 ` [PATCH v18 11/11] PCI/AER: Rationalize error status register clearing sathyanarayanan.kuppuswamy
2020-03-31 15:28 ` [PATCH v18 00/11] Add Error Disconnect Recover (EDR) support Bjorn Helgaas
2020-03-31 16:28   ` Kuppuswamy, Sathyanarayanan

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=20200326223637.GA106135@google.com \
    --to=helgaas@kernel.org \
    --cc=ashok.raj@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.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.