Hi All,
1028ccf5 did a change for sys_call_table from a pointer to an array of
unsigned long, I think it's not proper, here is my reason:
sys_call_table defined as a label in assembler should be pointer array
rather than an array as described in 1028ccf5. If we defined it as an
array, then arch_s
OCC is an On-Chip-Controller which takes care of power and thermal
safety of the chip. During runtime due to power failure or
overtemperature the OCC may throttle the frequencies of the CPUs to
remain within the power budget.
We want the cpufreq driver to be aware of such situations to be able
to
Re-evaluate the chip's throttled state on recieving OCC_THROTTLE
notification by executing *throttle_check() on any one of the cpu on
the chip. This is a sanity check to verify if we were indeed
throttled/unthrottled after receiving OCC_THROTTLE notification.
We cannot call *throttle_check() direc
On a reset cycle of OCC, although the system retires from safe
frequency state the local pstate is not restored to Pmin or last
requested pstate. Now if the cpufreq governor initiates a pstate
change, the local pstate will be in Psafe and we will be reporting a
false positive when we are not thrott
The On-Chip-Controller(OCC) can throttle cpu frequency by reducing the
max allowed frequency for that chip if the chip exceeds its power or
temperature limits. As Pmax capping is a chip level condition report
this throttling behavior at chip level and also do not set the global
'throttled' on Pmax
Add OPAL_MSG_OCC message definition to opal_message_type to receive
OCC events like reset, load and throttled. Host performance can be
affected when OCC is reset or OCC throttles the max Pstate.
We can register to opal_message_notifier to receive OPAL_MSG_OCC type
of message and report it to the us
This patchset intends to add frequency throttle reporting mechanism
to powernv-cpufreq driver when OCC throttles the frequency. OCC is an
On-Chip-Controller which takes care of the power and thermal safety of
the chip. The CPU frequency can be throttled during an OCC reset or
when OCC tries to limi
If frequency is throttled due to OCC reset then cpus will be in Psafe
frequency, so restore the frequency on all cpus to policy->cur when
OCCs are active again. And if frequency is throttled due to Pmax
capping then restore the frequency of all the cpus in the chip on
unthrottling.
Signed-off-by:
Hi Vasan,
On 07/16/2015 08:54 AM, Vasant Hegde wrote:
On 07/14/2015 02:30 PM, Jacek Anaszewski wrote:
Hi Vasant,
Jacek,
Thanks for the update. I think that we have still room
for improvements, please look at my comments below.
Thanks for the detailed review.
You're welcome.
.../...
On Thu, 2015-07-16 at 10:27 +0200, Jacek Anaszewski wrote:
> On 07/16/2015 08:54 AM, Vasant Hegde wrote:
> >>> +static enum led_brightness powernv_led_get(struct led_classdev *led_cdev)
> >>> +{
> >>> +char *loc_code;
> >>> +int rc, led_type;
> >>> +__be64 led_mask, led_value, max_led_t
On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote:
> Hi All,
>
> 1028ccf5 did a change for sys_call_table from a pointer to an array of
> unsigned long, I think it's not proper, here is my reason:
>
> sys_call_table defined as a label in assembler should be pointer array
> rather than an array
On Tue, 2015-07-07 at 03:56:59 UTC, Anton Blanchard wrote:
> mtmsr() does the right thing on 32bit and 64bit, so use it everywhere.
>
> Signed-off-by: Anton Blanchard
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1c53973172f84fafa8ad
cheers
_
On Mon, 2015-22-06 at 03:45:47 UTC, Gavin Shan wrote:
> The PELTV of PF PE should include VF PE, which is missed by current
> code, so that the VF PE is frozen automatically when freezing PF PE.
> The patch fixes the PELTV of PF PE to include VF PE.
>
> Signed-off-by: Gavin Shan
Applied to power
On Wed, 2015-08-07 at 11:06:01 UTC, Vipin K Parashar wrote:
> This patch adds support for OPAL EPOW (Environmental and Power Warnings)
> and DPO (Delayed Power Off) events for the PowerNV platform. These events
> are generated on FSP (Flexible Service Processor) based systems. EPOW
> events are gen
On Wed, 2015-08-07 at 15:14:36 UTC, Johannes Thumshirn wrote:
> Destroy cxl_adapter_idr on module exit, reclaiming the allocated memory.
>
> Signed-off-by: Johannes Thumshirn
> Acked-by: Ian Munsie
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b2a02ac65e40fb3900d1
cheers
_
On Thu, 2015-09-07 at 07:39:42 UTC, Johannes Thumshirn wrote:
> Destroy afu->contexts_idr on release of an afu, reclaiming the allocated
> memory.
>
> Signed-off-by: Johannes Thumshirn
> Acked-by: Ian Munsie
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/bd664f892e3e2b01c791
On Fri, 2015-19-06 at 02:26:16 UTC, Gavin Shan wrote:
> The PE numbers are reserved according to root port's M64 window,
> which is aligned to M64 segment finely. So one PE shouldn't be
> reserved for multiple times. We will reserve PE numbers according
> to the M64 BARs of PCI device in subsequent
On Tue, 2015-23-06 at 07:01:13 UTC, Gavin Shan wrote:
> When releasing PE for SRIOV VF, the PE is forced to be frozen
> wrongly. When the same PE is picked for another VF, it won't
> work anyhow. The patch fixes the issue by unfreezing, not
> freezing the VF PE when releasing it.
>
> Signed-off-by
On Thu, 2015-11-06 at 11:27:51 UTC, Rasmus Villemoes wrote:
> C99 says that a precision given as simply '.' with no following digits
> or * should be interpreted as 0. The kernel's printf implementation,
> however, treats this case as if the precision was omitted. C99 also
> says that if both the p
On Wed, 2015-24-06 at 05:25:22 UTC, Benjamin Herrenschmidt wrote:
> To support "hybrid" DMA ops in a subsequent patch, we will need both
> a direct DMA offset and an iommu pointer. Those are currently exclusive
> (a union), so change them to be separate fields.
>
> While there, also type iommu_tab
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, July 15, 2015 11:17 PM
To: Jain Priyanka-B32167
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB board
support
On Wed, 2015-07-15 at 15:00 +0530, Priyanka Jain wrote:
> T1
On Thu, 16 Jul 2015, Baolin Wang wrote:
> On 15 July 2015 at 19:55, Thomas Gleixner wrote:
> > On Wed, 15 Jul 2015, Baolin Wang wrote:
> >
> >> On 15 July 2015 at 18:31, Thomas Gleixner wrote:
> >> > On Wed, 15 Jul 2015, Baolin Wang wrote:
> >> >
> >> >> The cputime_to_timespec() and timespec_to_
Kprobes uses a breakpoint instruction to trap into execution flow
and the probed instruction is single-stepped from an alternate location.
On some architectures like x86, under certain conditions, the OPTPROBES
feature enables replacing the probed instruction with a jump instead,
resulting in a si
Nest Counters can be configured via PORE Engine and OPAL
provides an interface to start/stop it.
OPAL side patches are posted in the skiboot mailing.
Cc: Stewart Smith
Cc: Jeremy Kerr
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattipr
Adds cpumask attribute to be used by each nest pmu since nest
units are per-chip. Only one cpu (first online cpu) from each node/chip
is designated to read counters.
On cpu hotplug, dying cpu is checked to see whether it is one of the
designated cpus, if yes, next online cpu from the same node/chi
This patchset enables Nest Instrumentation support on powerpc.
POWER8 has per-chip Nest Intrumentation which provides various
per-chip metrics like memory, powerbus, Xlink and Alink
bandwidth.
Nest Instrumentation provides an interface (via PORE Engine)
to configure and move the nest counter data
Create new header file "nest-pmu.h" to add the data structures
and macros needed for the nest pmu support.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Sriniv
Add code to create event/format attributes and attribute groups for
each nest pmu.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan Srinivasan
---
arch/powerpc/
Add set of generic nest pmu related event functions to be used by
each nest pmu. Add code to register nest pmus.
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Anton Blanchard
Cc: Sukadev Bhattiprolu
Cc: Anshuman Khandual
Cc: Stephane Eranian
Signed-off-by: Madhavan
Parse device tree to detect supported nest pmu units. Traverse
through each nest pmu unit folder to find supported events and
corresponding unit/scale files (if any).
The nest unit event file from DT, will contain the offset in the
reserved memory region to get the counter data for a given event.
Create a file "nest-pmu.c" to contain nest pmu related functions. Code
to detect nest pmu support and parser to collect per-chip reserved memory
region information from device tree (DT).
Detection mechanism is to look for specific property "ibm,ima-chip" in DT.
For Nest pmu, device tree will have
If the OPAL call to receive the ipmi message fails, then we free up the
smi message and return. But, the driver still holds the reference to
old smi message in the 'cur_msg' which can potentially be accessed later
and freed again leading to kernel oops. To fix it up,
The kernel driver should reset
Migrate powerpc driver to the new 'set-state' interface provided by
clockevents core, the earlier 'set-mode' interface is marked obsolete
now.
This also enables us to implement callbacks for new states of clockevent
devices, for example: ONESHOT_STOPPED.
We weren't doing anything in ->set_mode(ON
The hardware RNG on POWER8 and POWER7+ can be relatively slow, since
it can only supply one 64-bit value per microsecond. Currently we
read it in arch_get_random_long(), but that slows down reading from
/dev/urandom since the code in random.c calls arch_get_random_long()
for every longword read fr
On Wed, Jul 15, 2015 at 09:40:19AM +0200, Uwe Kleine-König wrote:
> On Tue, Jul 14, 2015 at 10:54:42AM +0100, Mark Brown wrote:
> > > static const struct of_device_id mpc512x_psc_spi_of_match[] = {
> > > - { .compatible = "fsl,mpc5121-psc-spi", },
> > > + { .compatible = "fsl,mpc5121-psc-spi", .d
Ok, this looks fine. A couple of question...
Do I need to send this upstream right now? How well has this been tested?
Do you want this backported to 4.0 stable?
-corey
On 07/16/2015 06:16 AM, Neelesh Gupta wrote:
> If the OPAL call to receive the ipmi message fails, then we free up the
> smi
On Thu, 9 Jul 2015, Julien Grall wrote:
> The console ring is always based on the page granularity of Xen.
>
> Signed-off-by: Julien Grall
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: David Vrabel
> Cc: Stefano Stabellini
> Cc: Boris Ostrovsky
> Cc: linuxppc-dev@lists.ozlabs.org
Reviewed
To analyze the exit events with perf, we need kvm_perf.h to be added in
the arch/powerpc directory, where the kvm tracepoints needed to trace
the KVM exit events are defined.
This patch adds "kvm_perf_book3s.h" to indicate that the tracepoints are
book3s specific. Generic "kvm_perf.h" then can jus
On Thu, Jun 18, 2015 at 04:06:41PM +0800, Wei Yang wrote:
> Current EEH recovery code works with the assumption: the PE has primary
> bus. Unfortunately, that's not true for VF PEs, which generally contains
> one or multiple VFs (for VF group case).
>
> The patch introduces a weak function pcibios
To analyze the hcalls with perf, we need the hcall related tracepoints
information to be exported.
This patch adds hcall tracepoints "kvm_hv:kvm_hcall_enter" and
"kvm_hv:kvm_hcall_exit" to kvm_perf.h. So, perf will now know as to what
tracepoints to look for if we are using "perf kvm stat record"
From: Srikar Dronamraju
perf kvm can be used to analyze guest exit reasons. This support already
exists in x86. Hence, porting it to powerpc.
- To trace KVM events :
perf kvm stat record
If many guests are running, we can track for a specific guest by using
--pid as in : perf kvm stat rec
Powerpc provides hcall events that also provides insights into guest
behaviour. Enhance perf kvm stat to record and analyze hcall events.
- To trace hcall events :
perf kvm stat record
- To show the results :
perf kvm stat report --event=hcall
The result shows the number of hypervisor call
On 07/16/2015 01:23 AM, Thomas Huth wrote:
> On 07/15/2015 09:58 PM, Nathan Fontenot wrote:
>> On 07/15/2015 09:35 AM, Thomas Huth wrote:
>>> On 07/14/2015 11:22 PM, Benjamin Herrenschmidt wrote:
On Tue, 2015-07-14 at 20:43 +0200, Thomas Huth wrote:
> Any suggestions how to fix this? Simpl
The drivers support MPC5125 additionally to MPC5121, and there is an spi
mode that is also supported. Additionally some minor corrections are
done.
Signed-off-by: Uwe Kleine-König
---
Hello,
I sent a patch adding mpc5125 support to the mpc512x driver and Mark
requested the new compatible to be d
On Thu, 2015-07-16 at 04:34 -0500, Jain Priyanka-B32167 wrote:
>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 15, 2015 11:17 PM
> To: Jain Priyanka-B32167
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
On Thu, 2015-07-16 at 21:18 +0530, Hemant Kumar wrote:
> To analyze the exit events with perf, we need kvm_perf.h to be added in
> the arch/powerpc directory, where the kvm tracepoints needed to trace
> the KVM exit events are defined.
>
> This patch adds "kvm_perf_book3s.h" to indicate that the t
On Tue, Jul 14, 2015 at 08:01:50PM -0700, Sukadev Bhattiprolu wrote:
> @@ -1604,6 +1613,12 @@ static void power_pmu_start_txn(struct pmu *pmu)
> static void power_pmu_cancel_txn(struct pmu *pmu)
> {
> struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
> + int txn_flags;
> +
> +
OK, thanks. Assuming no similar issues when testing, I'll apply this patch
the next time I do a batch of patch application.
Any thoughts regarding better error handling?
-Scott
On Wed, 2015-07-15 at 21:37 -0500, Lu Yangbo-B47093 wrote:
> Hi Scott,
>
> Now the patch below has been merged on
>
On Wed, 2015-07-15 at 21:37 -0500, Lu Yangbo-B47093 wrote:
> Any comments?
> Thanks.
Sorry, I must have missed this on my last time through the patch queue. I
see you've decimalized the fiper and max-adj properties, which is good... but
does it really make sense for tmr-add? I'm not familiar w
On Tue, Jul 14, 2015 at 08:01:50PM -0700, Sukadev Bhattiprolu wrote:
> +DEFINE_PER_CPU(int, nop_txn_flags);
> +
> +static int nop_txn_flags_get_and_clear(void)
> +{
> + int *flagsp;
> + int flags;
> +
> + flagsp = &get_cpu_var(nop_txn_flags);
> +
> + flags = *flagsp;
> + *f
On 27/05/2015 01:56, Sam Bobroff wrote:
> In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
> bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
> accessed as such.
>
> This patch corrects places where it is accessed as a 32 bit field by a
> 64 bit kernel. I
On Tue, Jul 14, 2015 at 08:01:52PM -0700, Sukadev Bhattiprolu wrote:
> Move the part of perf_event_read_value() that computes the event
> counts and event times into a new function, perf_event_compute().
>
> This would allow us to call perf_event_compute() independently.
>
> Signed-off-by: Sukade
On 05/27/2015 01:56 AM, Sam Bobroff wrote:
> In 64 bit kernels, the Fixed Point Exception Register (XER) is a 64
> bit field (e.g. in kvm_regs and kvm_vcpu_arch) and in most places it is
> accessed as such.
>
> This patch corrects places where it is accessed as a 32 bit field by a
> 64 bit kernel.
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Jul 14, 2015 at 08:01:50PM -0700, Sukadev Bhattiprolu wrote:
| > @@ -1604,6 +1613,12 @@ static void power_pmu_start_txn(struct pmu *pmu)
| > static void power_pmu_cancel_txn(struct pmu *pmu)
| > {
| > struct cpu_hw_events *cpuhw = this_cp
Peter Zijlstra [pet...@infradead.org] wrote:
| On Tue, Jul 14, 2015 at 08:01:52PM -0700, Sukadev Bhattiprolu wrote:
| > Move the part of perf_event_read_value() that computes the event
| > counts and event times into a new function, perf_event_compute().
| >
| > This would allow us to call perf_ev
On Tue, Jul 14, 2015 at 08:01:54PM -0700, Sukadev Bhattiprolu wrote:
> +/*
> + * Use the transaction interface to read the group of events in @leader.
> + * PMUs like the 24x7 counters in Power, can use this to queue the events
> + * in the ->read() operation and perform the actual read in ->commit
On Wed, 2015-07-15 at 17:37 +1000, Michael Ellerman wrote:
> To call do_syscall_trace_enter() we need pt_regs in r3, but we don't need
> to recalculate it based on r1, it's already in r9.
>
> Signed-off-by: Michael Ellerman
Is there any performance difference ?
I find the addi a bit more robust
On Wed, 2015-07-15 at 17:37 +1000, Michael Ellerman wrote:
> Currently on powerpc we have our own #define for the highest (negative)
> errno value, called _LAST_ERRNO. This is defined to be 516, for reasons
> which are not clear.
>
> The generic code, and x86, use MAX_ERRNO, which is defined to be
According to Yuantian, this is needed for forthcoming power management
patches -- IIRC, for resuming from certain deep sleep states.
This also allows SMP kernels to work as kdump crash kernels. While
crash kernels don't really need to be SMP, this prevents things from
breaking if a user does it a
IOV BAR is extended to cover 256 VFs or number of supported VFs,
the alignment is the IOV BAR size, which is usually huge and bigger
than M64 segment size (256MB). That means the IOV BAR is expected
to be assigned to the beginning of PHB's M64 window prior to other
M64 BARs in PCI devices that are
When VF BAR size is equal to 128MB or bigger than that, we extend
the corresponding PF's IOV BAR to cover number of total VFs supported
by the PF. Otherwise, we extend the PF's IOV BAR to cover 256 VFs.
For the former case, we have to create compound PE, which includes
4 VFs. Those 4 VFs included i
When the VF BAR size is equal to 128MB or bigger than that, the IOV BAR
is extended to cover number of maximal VFs supported by the PF, not 256.
Also, one PHB's M64 BAR is picked to cover VF BARs for 4 continous VFs,
but the PHB's M64 BAR is configured as being owned by single PE. Eventually,
those
On Fri, Jul 17, 2015 at 10:14:43AM +1000, Gavin Shan wrote:
>When VF BAR size is equal to 128MB or bigger than that, we extend
>the corresponding PF's IOV BAR to cover number of total VFs supported
>by the PF. Otherwise, we extend the PF's IOV BAR to cover 256 VFs.
>For the former case, we have to
On 2015年07月16日 17:04, Michael Ellerman wrote:
> On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote:
>> Hi All,
>>
>> 1028ccf5 did a change for sys_call_table from a pointer to an array of
>> unsigned long, I think it's not proper, here is my reason:
>>
>> sys_call_table defined as a label in asse
Zumeng Chen [zumeng.c...@gmail.com] wrote:
| 3. What I have seen in 3.14.x kernel,
| ==
| And so far, no more difference to 4.x kernel from me about this part if
| I'm right.
|
| *) With 1028ccf5
|
| perf list|grep -i syscall got me nothing.
|
|
| *) Without 1028ccf5
| root@
On Fri, 2015-07-10 at 15:19 +1000, Samuel Mendoza-Jonas wrote:
> +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_POWERNV)
> + li r3,(FW_FEATURE_OPAL >> 16)
> + rldicr r3,r3,16,63
> + and.r3,r3,r26
> + cmpwi r3,0
> + beq 99f
If FW_FEATRURE_OPAL
Excerpts from Sukadev Bhattiprolu's message of 2015-07-17 11:51:04 +1000:
> Are you seeing this on big-endian or little-endian system?
>
> IIRC, I saw the opposite behavior on an LE system a few months ago.
> i.e. without 1028ccf5, 'perf listf|grep syscall' failed.
>
> Applying 1028ccf5, seemed t
On Fri, 2015-07-17 at 11:53 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2015-07-10 at 15:19 +1000, Samuel Mendoza-Jonas wrote:
> > +#if defined(CONFIG_PPC_BOOK3S_64) && defined(CONFIG_PPC_POWERNV)
> > + li r3,(FW_FEATURE_OPAL >> 16)
> > + rldicr r3,r3,16,63
> > + and.
On Fri, 2015-07-17 at 09:27 +0800, Zumeng Chen wrote:
> On 2015年07月16日 17:04, Michael Ellerman wrote:
> > On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote:
> >> Hi All,
> >>
> >> 1028ccf5 did a change for sys_call_table from a pointer to an array of
> >> unsigned long, I think it's not proper,
On Fri, 2015-07-17 at 08:40 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2015-07-15 at 17:37 +1000, Michael Ellerman wrote:
> > To call do_syscall_trace_enter() we need pt_regs in r3, but we don't need
> > to recalculate it based on r1, it's already in r9.
> >
> > Signed-off-by: Michael Ellerman
On Thu, 2015-07-16 at 22:12 +1000, Paul Mackerras wrote:
> The hardware RNG on POWER8 and POWER7+ can be relatively slow, since
> it can only supply one 64-bit value per microsecond. Currently we
> read it in arch_get_random_long(), but that slows down reading from
> /dev/urandom since the code in
On 2015年07月17日 12:07, Michael Ellerman wrote:
On Fri, 2015-07-17 at 09:27 +0800, Zumeng Chen wrote:
On 2015年07月16日 17:04, Michael Ellerman wrote:
On Thu, 2015-07-16 at 13:57 +0800, Zumeng Chen wrote:
Hi All,
1028ccf5 did a change for sys_call_table from a pointer to an array of
unsigned long,
On 07/16/2015 01:57 PM, Jacek Anaszewski wrote:
> Hi Vasan,
>
Hello Jacek,
.../...
>>
>> I have added as
>> - compatible : "ibm,opal-v3-led".
>
> Please retain "Should be :".
>
Done.
.../...
>>>
>>> Please parse the led type once upon initialization and add related
>>> property to the str
On 07/16/2015 02:17 PM, Michael Ellerman wrote:
> On Thu, 2015-07-16 at 10:27 +0200, Jacek Anaszewski wrote:
>> On 07/16/2015 08:54 AM, Vasant Hegde wrote:
> +static enum led_brightness powernv_led_get(struct led_classdev *led_cdev)
> +{
> +char *loc_code;
> +int rc, led_typ
This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.
Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.
First, the VF's re
This patch adds a weak function pcibios_bus_add_device() for arch dependent
code could do proper setup. For example, powerpc could setup EEH related
resources.
Signed-off-by: Wei Yang
Acked-by: Bjorn Helgaas
---
drivers/pci/bus.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers
During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
The patch renames virtn_{add,remove}() and exports them so that they
can be used in PCI
The patch caches the VF index in pci_dn, which can be used to calculate
VF's bus, device and function number. Those information helps to locate
the VF's PCI device instance when doing hotplug during EEH recovery if
necessary.
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/include
EEH address cache, which helps to locate the PCI device according to
the given (physical) MMIO address, didn't cover PCI bridges. Also, it
shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
should be returned.
Also, by doing so, it removes the type check in
eeh_addr_cache_insert_d
VFs and their corresponding pci_dn instances are created and released
dynamically as their PF's SRIOV capability is enabled and disabled.
The patch creates and releases EEH devices for VFs when creating and
releasing their pci_dn instances, which means EEH devices and pci_dn
instances have same lif
Current EEH recovery code works with the assumption: the PE has primary
bus. Unfortunately, that's not true for VF PEs, which generally contains
one or multiple VFs (for VF group case).
The patch creates PEs for VFs in the weak function
pcibios_bus_add_device(). Those PEs for VFs are identified wi
PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei Ya
After PE reset, OPAL API opal_pci_reinit() is called on all devices
contained in the PE to reinitialize them. However, VFs can't be seen
from skiboot firmware. We have to implement the functions, similar
those in skiboot firmware, to reinitialize VFs after reset on PE
for VFs.
[gwshan: changelog a
As commit ac205b7bb72f ("PCI: make sriov work with hotplug remove") indicates,
VFs, which might be hooked to same PCI bus as their PF should be removed
before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
cause kernel crash.
The patch applies the above pattern to PowerPC PCI hotpl
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang
Acked-by: Gavin Shan
---
arch/powerpc/pl
Different from PCI bus dependent PE, PE for VFs doesn't have the
primary bus, on which the PCI hotplug is implemented. The patch
supports error recovery, especially the PCI hotplug for VF's PE.
The hotplug on VF's PE is implemented based on VFs, instead of
PCI bus any more.
[gwshan: changelog and
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, July 17, 2015 1:06 AM
> To: Jain Priyanka-B32167
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH][v2] powerpc/fsl-booke: Add T1040D4RDB/T1042D4RDB
> board support
>
> On Thu, 2015-07-16 at 04:34 -0500, Jain Priyanka
87 matches
Mail list logo
