From: Gavin Shan <shangw@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@lists.ozlabs.org, Gavin Shan <shangw@linux.vnet.ibm.com>
Subject: Re: [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval
Date: Wed, 12 Jun 2013 11:32:03 +0800 [thread overview]
Message-ID: <20130612033203.GA10000@shangw.(null)> (raw)
In-Reply-To: <1370936224.8250.93.camel@pasglop>
On Tue, Jun 11, 2013 at 05:37:04PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2013-06-05 at 15:34 +0800, Gavin Shan wrote:
>> The patch adds I/O chip backend to retrieve the state for the
>> indicated PE. While the PE state is temperarily unavailable,
>> we return the default wait time (1000ms).
>>
>> Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/eeh-ioda.c | 102 ++++++++++++++++++++++++++++-
>> 1 files changed, 101 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
>> index e24622e..3c72321 100644
>> --- a/arch/powerpc/platforms/powernv/eeh-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
>> @@ -125,10 +125,110 @@ static int ioda_eeh_set_option(struct eeh_pe *pe, int option)
>> return ret;
>> }
>>
>> +/**
>> + * ioda_eeh_get_state - Retrieve the state of PE
>> + * @pe: EEH PE
>> + * @state: return value
>> + *
>> + * The PE's state should be retrieved from the PEEV, PEST
>> + * IODA tables. Since the OPAL has exported the function
>> + * to do it, it'd better to use that.
>> + */
>> +static int ioda_eeh_get_state(struct eeh_pe *pe, int *state)
>> +{
>
>So everywhere you have this "state" argument which isn't a state but a delay ...
>
>Moreover you only initialize it in one specific case and leave it otherwise
>uninitialized....
>
>At the very least, init it to 0 by default as to not leave a dangling
>"return argument" like that. However, I still have a problem with it:
>
Ok. I will update accordingly in upper layer (eeh-powernv.c)
- Initialize it to value "0".
- If necessary, return 1 second.
>> + case OPAL_EEH_STOPPED_TEMP_UNAVAIL:
>> + result |= EEH_STATE_UNAVAILABLE;
>> + if (state)
>> + *state = 1000;
>> + break;
>
>This is the *only* case where we return anything here. Why do we bother
>then and not have the upper layer simply wait one second whenever it gets
>a temp unavailable result (btw, you didn't differenciate temp unavailable
>from permanently unavailable in your API).
>
We already defferentiated the permanent/temp availibility through the
return value from the function:
- EEH_STATE_UNAVAILABLE: temporary unavailibility
- EEH_STATE_NOT_SUPPORT: permanent unavailibility
The EEH core will handle the return value (from the function) accordingly.
>This has impacts on patch 18/27 which I'll cover here:
>
>> +/**
>> + * powernv_eeh_set_option - Initialize EEH or MMIO/DMA reenable
>> + * @pe: EEH PE
>> + * @option: operation to be issued
>> + *
>> + * The function is used to control the EEH functionality globally.
>> + * Currently, following options are support according to PAPR:
>> + * Enable EEH, Disable EEH, Enable MMIO and Enable DMA
>> + */
>> +static int powernv_eeh_set_option(struct eeh_pe *pe, int option)
>> +{
>> + struct pci_controller *hose = pe->phb;
>> + struct pnv_phb *phb = hose->private_data;
>> + int ret = -EEXIST;
>> +
>> + /*
>> + * What we need do is pass it down for hardware
>> + * implementation to handle it.
>> + */
>> + if (phb->eeh_ops && phb->eeh_ops->set_option)
>> + ret = phb->eeh_ops->set_option(pe, option);
>> +
>> + return ret;
>> +}
>
>Should we implement something here ? IE. Should we look into
>disabling freezing in the PHB via the firmware ? Or we just don't care ?
>
We just don't care. If EEH functionality has been disabled, we shouldn't
run into the code.
>> +/**
>> + * powernv_eeh_get_pe_addr - Retrieve PE address
>> + * @pe: EEH PE
>> + *
>> + * Retrieve the PE address according to the given tranditional
>> + * PCI BDF (Bus/Device/Function) address.
>> + */
>> +static int powernv_eeh_get_pe_addr(struct eeh_pe *pe)
>> +{
>> + return pe->addr;
>> +}
>>
>> +/**
>> + * powernv_eeh_get_state - Retrieve PE state
>> + * @pe: EEH PE
>> + * @state: return value
>> + *
>> + * Retrieve the state of the specified PE. For IODA-compitable
>> + * platform, it should be retrieved from IODA table. Therefore,
>> + * we prefer passing down to hardware implementation to handle
>> + * it.
>> + */
>> +static int powernv_eeh_get_state(struct eeh_pe *pe, int *state)
>> +{
>> + struct pci_controller *hose = pe->phb;
>> + struct pnv_phb *phb = hose->private_data;
>> + int ret = EEH_STATE_NOT_SUPPORT;
>> +
>> + if (phb->eeh_ops && phb->eeh_ops->get_state)
>> + ret = phb->eeh_ops->get_state(pe, state);
>> +
>> + return ret;
>> +}
>
>Same comments about "state" which is really "delay" and is probably
>not necessary at all ...
>
We need the "delay" in future to support PowerKVM guest. If the
specified PE is being reset, we rely on the delay to hold the
powerkvm guest for a while until the PE reset is done.
>> +/**
>> + * powernv_eeh_reset - Reset the specified PE
>> + * @pe: EEH PE
>> + * @option: reset option
>> + *
>> + * Reset the specified PE
>> + */
>> +static int powernv_eeh_reset(struct eeh_pe *pe, int option)
>> +{
>> + struct pci_controller *hose = pe->phb;
>> + struct pnv_phb *phb = hose->private_data;
>> + int ret = -EEXIST;
>> +
>> + if (phb->eeh_ops && phb->eeh_ops->reset)
>> + ret = phb->eeh_ops->reset(pe, option);
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> + * powernv_eeh_wait_state - Wait for PE state
>> + * @pe: EEH PE
>> + * @max_wait: maximal period in microsecond
>> + *
>> + * Wait for the state of associated PE. It might take some time
>> + * to retrieve the PE's state.
>> + */
>> +static int powernv_eeh_wait_state(struct eeh_pe *pe, int max_wait)
>> +{
>> + int ret;
>> + int mwait;
>> +
>> + while (1) {
>> + ret = powernv_eeh_get_state(pe, &mwait);
>> +
>> + /*
>> + * If the PE's state is temporarily unavailable,
>> + * we have to wait for the specified time. Otherwise,
>> + * the PE's state will be returned immediately.
>> + */
>> + if (ret != EEH_STATE_UNAVAILABLE)
>> + return ret;
>
>So here we do a compare, while ret is actually a bit mask ...
>
>In fact, ret should be named state_mask or something like that for clarity
>and you should do a bit test here. Also do you want to diffenciate
>permanent unavailability from temp. unavailability ?
>
>> + max_wait -= mwait;
>
>You decrement max_wait but never test it or use it. You probably mean to
>
> - Limit mwait to max_wait
> - If mwait is 0, return
>
Yeah, I will change the code accordingly in next revision.
>> + msleep(mwait);
>> + }
>> +
>> + return EEH_STATE_NOT_SUPPORT;
>> +}
>> +
>> +/**
>> + * powernv_eeh_get_log - Retrieve error log
>> + * @pe: EEH PE
>> + * @severity: temporary or permanent error log
>> + * @drv_log: driver log to be combined with retrieved error log
>> + * @len: length of driver log
>> + *
>> + * Retrieve the temporary or permanent error from the PE.
>> + */
>> +static int powernv_eeh_get_log(struct eeh_pe *pe, int severity,
>> + char *drv_log, unsigned long len)
>> +{
>> + struct pci_controller *hose = pe->phb;
>> + struct pnv_phb *phb = hose->private_data;
>> + int ret = -EEXIST;
>> +
>> + if (phb->eeh_ops && phb->eeh_ops->get_log)
>> + ret = phb->eeh_ops->get_log(pe, severity, drv_log, len);
>> +
>> + return ret;
>> +}
>> +
>> +/**
>> + * powernv_eeh_configure_bridge - Configure PCI bridges in the indicated PE
>> + * @pe: EEH PE
>> + *
>> + * The function will be called to reconfigure the bridges included
>> + * in the specified PE so that the mulfunctional PE would be recovered
>> + * again.
>> + */
>> +static int powernv_eeh_configure_bridge(struct eeh_pe *pe)
>> +{
>> + struct pci_controller *hose = pe->phb;
>> + struct pnv_phb *phb = hose->private_data;
>> + int ret = 0;
>> +
>> + if (phb->eeh_ops && phb->eeh_ops->configure_bridge)
>> + ret = phb->eeh_ops->configure_bridge(pe);
>> +
>> + return ret;
>> +}
Thanks,
Gavin
next prev parent reply other threads:[~2013-06-12 3:32 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 7:34 [PATCH v3 00/27] EEH Support for PowerNV platform Gavin Shan
2013-06-05 7:34 ` [PATCH 01/27] powerpc/eeh: Fix fetching bus for single-dev-PE Gavin Shan
2013-06-05 7:34 ` [PATCH 02/27] powerpc/eeh: Enhance converting EEH dev Gavin Shan
2013-06-05 7:34 ` [PATCH 03/27] powerpc/eeh: Make eeh_phb_pe_get() public Gavin Shan
2013-06-05 7:34 ` [PATCH 04/27] powerpc/eeh: Make eeh_pe_get() public Gavin Shan
2013-06-05 7:34 ` [PATCH 05/27] powerpc/eeh: Trace PCI bus from PE Gavin Shan
2013-06-05 7:34 ` [PATCH 06/27] powerpc/eeh: Make eeh_init() public Gavin Shan
2013-06-05 7:34 ` [PATCH 07/27] powerpc/eeh: EEH post initialization operation Gavin Shan
2013-06-05 7:34 ` [PATCH 08/27] powerpc/eeh: Refactor eeh_reset_pe_once() Gavin Shan
2013-06-05 7:34 ` [PATCH 09/27] powerpc/eeh: Delay EEH probe during hotplug Gavin Shan
2013-06-05 7:34 ` [PATCH 10/27] powerpc/eeh: Differentiate EEH events Gavin Shan
2013-06-05 7:34 ` [PATCH 11/27] powerpc/eeh: Sync OPAL API with firmware Gavin Shan
2013-06-05 7:34 ` [PATCH 12/27] powerpc/eeh: EEH backend for P7IOC Gavin Shan
2013-06-05 7:34 ` [PATCH 13/27] powerpc/eeh: I/O chip post initialization Gavin Shan
2013-06-05 7:34 ` [PATCH 14/27] powerpc/eeh: I/O chip EEH enable option Gavin Shan
2013-06-05 7:34 ` [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval Gavin Shan
2013-06-11 7:37 ` Benjamin Herrenschmidt
2013-06-12 3:32 ` Gavin Shan [this message]
2013-06-12 4:19 ` Benjamin Herrenschmidt
2013-06-13 4:26 ` Gavin Shan
2013-06-13 4:42 ` Benjamin Herrenschmidt
2013-06-13 5:50 ` Gavin Shan
2013-06-05 7:34 ` [PATCH 16/27] powerpc/eeh: I/O chip PE reset Gavin Shan
2013-06-05 7:34 ` [PATCH 17/27] powerpc/eeh: I/O chip PE log and bridge setup Gavin Shan
2013-06-11 7:37 ` Benjamin Herrenschmidt
2013-06-12 3:33 ` Gavin Shan
2013-06-05 7:34 ` [PATCH 18/27] powerpc/eeh: PowerNV EEH backends Gavin Shan
2013-06-05 7:34 ` [PATCH 19/27] powerpc/eeh: Initialization for PowerNV Gavin Shan
2013-06-05 7:34 ` [PATCH 20/27] powerpc/eeh: Enable EEH check for config access Gavin Shan
2013-06-05 7:34 ` [PATCH 21/27] powerpc/eeh: Process interrupts caused by EEH Gavin Shan
2013-06-11 8:13 ` Benjamin Herrenschmidt
2013-06-13 4:14 ` Gavin Shan
2013-06-05 7:34 ` [PATCH 22/27] powerpc/eeh: Allow to check fenced PHB proactively Gavin Shan
2013-06-05 7:34 ` [PATCH 23/27] powernv/opal: Notifier for OPAL events Gavin Shan
2013-06-12 0:32 ` Benjamin Herrenschmidt
2013-06-12 3:15 ` Gavin Shan
2013-06-05 7:34 ` [PATCH 24/27] powernv/opal: Disable OPAL notifier upon poweroff Gavin Shan
2013-06-05 7:34 ` [PATCH 25/27] powerpc/eeh: Register OPAL notifier for PCI error Gavin Shan
2013-06-05 7:34 ` [PATCH 26/27] powerpc/powernv: Debugfs directory for PHB Gavin Shan
2013-06-05 7:34 ` [PATCH 27/27] powerpc/eeh: Debugfs for error injection Gavin Shan
2013-06-11 7:46 ` [PATCH v3 00/27] EEH Support for PowerNV platform Benjamin Herrenschmidt
2013-06-12 3:18 ` Gavin Shan
-- strict thread matches above, loose matches on Subject: below --
2013-06-15 9:02 [PATCH v4 " Gavin Shan
2013-06-15 9:03 ` [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval Gavin Shan
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='20130612033203.GA10000@shangw.(null)' \
--to=shangw@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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.