From: Nathan Lynch <nathanl@linux.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Tyrel Datwyler <tyreld@linux.ibm.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
"Oliver O'Halloran" <oohall@gmail.com>,
linux-pci <linux-pci@vger.kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>
Subject: Re: [PATCH v6] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
Date: Thu, 28 Apr 2022 17:31:38 -0500 [thread overview]
Message-ID: <87k0b8q1px.fsf@linux.ibm.com> (raw)
In-Reply-To: <20220428204740.GA42242@bhelgaas>
Bjorn Helgaas <helgaas@kernel.org> writes:
> On Tue, Apr 26, 2022 at 11:07:39PM +0530, Mahesh Salgaonkar wrote:
>> +/*
>> + * RTAS call get-sensor-state(DR_ENTITY_SENSE) return values as per PAPR:
>> + * -1: Hardware Error
>> + * -2: RTAS_BUSY
>> + * -3: Invalid sensor. RTAS Parameter Error.
>> + * -9000: Need DR entity to be powered up and unisolated before RTAS call
>> + * -9001: Need DR entity to be powered up, but not unisolated, before RTAS call
>> + * -9002: DR entity unusable
>> + * 990x: Extended delay - where x is a number in the range of 0-5
>> + */
>> +#define RTAS_HARDWARE_ERROR (-1)
>> +#define RTAS_INVALID_SENSOR (-3)
>> +#define SLOT_UNISOLATED (-9000)
>> +#define SLOT_NOT_UNISOLATED (-9001)
>
> I would say "isolated" instead of "not unisolated", but I suppose this
> follows language in the spec. If so, you should follow the spec.
"not unisolated" is the spec language.
>> +#define SLOT_NOT_USABLE (-9002)
>> +
>> +static int rtas_to_errno(int rtas_rc)
>> +{
>> + int rc;
>> +
>> + switch (rtas_rc) {
>> + case RTAS_HARDWARE_ERROR:
>> + rc = -EIO;
>> + break;
>> + case RTAS_INVALID_SENSOR:
>> + rc = -EINVAL;
>> + break;
>> + case SLOT_UNISOLATED:
>> + case SLOT_NOT_UNISOLATED:
>> + rc = -EFAULT;
>> + break;
>> + case SLOT_NOT_USABLE:
>> + rc = -ENODEV;
>> + break;
>> + case RTAS_BUSY:
>> + case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
>> + rc = -EBUSY;
>> + break;
>> + default:
>> + err("%s: unexpected RTAS error %d\n", __func__, rtas_rc);
>> + rc = -ERANGE;
>> + break;
>> + }
>> + return rc;
>
> This basically duplicates rtas_error_rc(). Why do we need two copies?
It treats RTAS_BUSY, RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX
differently, which is part of the point of this change.
Aside: rtas_error_rc() (from powerpc's rtas.c) is badly named. Its
conversions make sense for only a handful of RTAS calls. RTAS error
codes have function-specific interpretations.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <nathanl@linux.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Tyrel Datwyler <tyreld@linux.ibm.com>,
linux-pci <linux-pci@vger.kernel.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Mahesh Salgaonkar <mahesh@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>,
Oliver O'Halloran <oohall@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH v6] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state
Date: Thu, 28 Apr 2022 17:31:38 -0500 [thread overview]
Message-ID: <87k0b8q1px.fsf@linux.ibm.com> (raw)
In-Reply-To: <20220428204740.GA42242@bhelgaas>
Bjorn Helgaas <helgaas@kernel.org> writes:
> On Tue, Apr 26, 2022 at 11:07:39PM +0530, Mahesh Salgaonkar wrote:
>> +/*
>> + * RTAS call get-sensor-state(DR_ENTITY_SENSE) return values as per PAPR:
>> + * -1: Hardware Error
>> + * -2: RTAS_BUSY
>> + * -3: Invalid sensor. RTAS Parameter Error.
>> + * -9000: Need DR entity to be powered up and unisolated before RTAS call
>> + * -9001: Need DR entity to be powered up, but not unisolated, before RTAS call
>> + * -9002: DR entity unusable
>> + * 990x: Extended delay - where x is a number in the range of 0-5
>> + */
>> +#define RTAS_HARDWARE_ERROR (-1)
>> +#define RTAS_INVALID_SENSOR (-3)
>> +#define SLOT_UNISOLATED (-9000)
>> +#define SLOT_NOT_UNISOLATED (-9001)
>
> I would say "isolated" instead of "not unisolated", but I suppose this
> follows language in the spec. If so, you should follow the spec.
"not unisolated" is the spec language.
>> +#define SLOT_NOT_USABLE (-9002)
>> +
>> +static int rtas_to_errno(int rtas_rc)
>> +{
>> + int rc;
>> +
>> + switch (rtas_rc) {
>> + case RTAS_HARDWARE_ERROR:
>> + rc = -EIO;
>> + break;
>> + case RTAS_INVALID_SENSOR:
>> + rc = -EINVAL;
>> + break;
>> + case SLOT_UNISOLATED:
>> + case SLOT_NOT_UNISOLATED:
>> + rc = -EFAULT;
>> + break;
>> + case SLOT_NOT_USABLE:
>> + rc = -ENODEV;
>> + break;
>> + case RTAS_BUSY:
>> + case RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX:
>> + rc = -EBUSY;
>> + break;
>> + default:
>> + err("%s: unexpected RTAS error %d\n", __func__, rtas_rc);
>> + rc = -ERANGE;
>> + break;
>> + }
>> + return rc;
>
> This basically duplicates rtas_error_rc(). Why do we need two copies?
It treats RTAS_BUSY, RTAS_EXTENDED_DELAY_MIN...RTAS_EXTENDED_DELAY_MAX
differently, which is part of the point of this change.
Aside: rtas_error_rc() (from powerpc's rtas.c) is badly named. Its
conversions make sense for only a handful of RTAS calls. RTAS error
codes have function-specific interpretations.
next prev parent reply other threads:[~2022-04-28 22:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 17:37 [PATCH v6] PCI hotplug: rpaphp: Error out on busy status from get-sensor-state Mahesh Salgaonkar
2022-04-26 17:37 ` Mahesh Salgaonkar
2022-04-28 20:47 ` Bjorn Helgaas
2022-04-28 20:47 ` Bjorn Helgaas
2022-04-28 22:31 ` Nathan Lynch [this message]
2022-04-28 22:31 ` Nathan Lynch
2022-04-29 16:25 ` Bjorn Helgaas
2022-04-29 16:25 ` Bjorn Helgaas
2022-06-12 17:02 ` Mahesh J Salgaonkar
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=87k0b8q1px.fsf@linux.ibm.com \
--to=nathanl@linux.ibm.com \
--cc=bhelgaas@google.com \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--cc=tyreld@linux.ibm.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.