On Thu, Jun 18, 2015 at 1:54 PM, Guenter Roeck li...@roeck-us.net wrote:
On 06/17/2015 11:53 PM, Frans Klaver wrote:
On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd sb...@codeaurora.org
wrote:
On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device
On 06/17/2015 11:53 PM, Frans Klaver wrote:
On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
remove power from the system. For the most part, those
The idle cpus which stay in snooze for a long period can degrade the
perfomance of the sibling cpus. If the cpu stays in snooze for more
than target residency of the next available idle state, then exit from
snooze. This gives a chance to the cpuidle governor to re-evaluate the
last idle state of
On 6/12/15, Denis Kirjanov k...@linux-powerpc.org wrote:
Fix the memory leak in create_gatt_table:
we've lost a kfree on the exit path for the pages array allocated
in uninorth_create_gatt_table
Signed-off-by: Denis Kirjanov k...@linux-powerpc.org
Hi Ben, Michael
Will you take the patch
On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
[ ... ]
What happened to this series? I want to add shutdown support to my
platform and I need to write a register on the PMIC in one driver to
configure it for shutdown instead of restart and then write an MMIO
register to tell
[Sorry for the late reply - I meant to answer in the previous threads
but something always preempted me from that]
On Wed 10-06-15 09:26:48, Eric B Munson wrote:
The cost of faulting in all memory to be locked can be very high when
working with large mappings. If only portions of the mapping
This is an *emergency* parachute to avoid an endless recursion and
consecutively a kernel stack overflow, should any function within some
ftrace framework cause an access fault, which calls _mcount / ftrace_caller
in return and so on. It might also call an ftrace'd function directly.
As Michael
On Thu, 18 Jun 2015 18:21:07 +0200
Torsten Duwe d...@lst.de wrote:
+
_GLOBAL(ftrace_stub)
+ nop
+ nop
+.localentry ftrace_stub,.-ftrace_stub
You might want to run checkpatch and fix your whitespace errors.
-- Steve
blr
#else
_GLOBAL_TOC(_mcount)
@@
Finn Thain fth...@telegraphics.com.au writes:
When I have reliable documentation I always define macros. So I agree that
command bytes like 0x34 and 0x3800 should have names but what are the
correct names? Are we constructing an opcode containing RTC register file
addresses or are we
On Thu, 18 Jun 2015 18:17:27 +0200
Torsten Duwe d...@lst.de wrote:
Did I miss anything else? I have the notrace optimisations and
kernel live patching in the queue, which depends on this, so I'd
really appreciate a comment whether it is acceptable in this form
or not. Thanks in advance!
Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
Initial work started by Vojtech Pavlik, used with permission.
* arch/powerpc/kernel/entry_64.S:
- enhance _mcount with a stub to test (ftrace_trace_function ==
ftrace_stub)
as suggested in Documentation/trace/ftrace-design.txt
* Makefile:
- globally use -mprofile-kernel in case it's configured.
* arch/powerpc/Kconfig / kernel/trace/Kconfig:
- declare that ppc64 HAVE_MPROFILE_KERNEL and HAVE_DYNAMIC_FTRACE_WITH_REGS,
and use it.
Signed-off-by: Torsten Duwe d...@suse.de
--
Makefile |5
Did I miss anything else? I have the notrace optimisations and
kernel live patching in the queue, which depends on this, so I'd
really appreciate a comment whether it is acceptable in this form
or not. Thanks in advance!
Torsten
___
Using -mprofile-kernel on early boot code not only confuses the checker
but is also useless, as the infrastructure is not yet in place. Proceed
like with -pg (remove it from CFLAGS), equally with time.o and ftrace itself.
* arch/powerpc/kernel/Makefile:
- remove -mprofile-kernel from low
The patch changes the type of last argument of pnv_ioda_setup_bus_PE()
and phb::pick_m64_pe() to boolean. No functional change.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 8
arch/powerpc/platforms/powernv/pci.h | 2 +-
2
On PHB3, some PEs might be reserved in advance to reflect the M64
segments consumed by those PEs. We're reserving PEs based on the
M64 window of root port, which might contain VF BAR. The PEs for
VFs are allocated dynamically, not reserved based on the consumed
M64 segments. So the M64 window of
On PHB3, PE might be reserved in advance to reflect the M64 segments
consumed by the PE according to M64 BARs (exclude VF BARs) of the PCI
devices included in the PE. The PE is picked based on M64 BARs instead
of the bridge's M64 windows, which might include VF BARs. Otherwise,
wrong PE could be
The existing device tree bindings are error-prone and inflexible.
Correct the mistake by moving the knowledge into the driver, which
has more flexibility in describing the quirks of each chip. This leaves
the device tree to its proper role of identifying a programming interface
rather than
On 06/18/2015 04:53 PM, Shilpasri G Bhat wrote:
The idle cpus which stay in snooze for a long period can degrade the
perfomance of the sibling cpus. If the cpu stays in snooze for more
than target residency of the next available idle state, then exit from
snooze. This gives a chance to the
When CONFIG_PCI_IOV is enabled in kernel configuration, the logic reserving
PEs according to consumed M64 segments in bridge's M64 window won't work
properly. The bridge's M64 window contains VF BARs, which are M64 BARs.
Current code could reserve and pick PE number according to M64 segments
On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
On 6/12/15, Denis Kirjanov k...@linux-powerpc.org wrote:
Fix the memory leak in create_gatt_table:
we've lost a kfree on the exit path for the pages array allocated
in uninorth_create_gatt_table
Signed-off-by: Denis Kirjanov
Get the CPU clock's potential parent clocks from the clock interface
itself, rather than manually parsing the clocks property to find a
phandle, looking at the clock-names property of that, and assuming that
those are valid parent clocks for the cpu clock.
This is necessary for cpufreq to
The binding requires compatible and reg properties, but the ls1021a
device tree does not contain them. This will break with subsequent
clock driver changes. If required (it's not clear to me whether the
ls1 code currently works at all -- I tried multi_v7_defconfig and it
didn't boot, whereas I
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 patches, which aren't
aligned to M64 segment size finely. It
Having multiple clock implementations pointing at the same hardware is
asking for trouble if both get used -- for example, cached values will be
incorrect. Point the legacy nodes at the new clocks, before anything
starts using the new clocks. The pll/mux details in old device trees
will be
The device tree should describe the chips (or chip-like subblocks) in
the system, but it generally does not describe individual registers --
it should identify, rather than describe, a programming interface.
This has not been the case with the QorIQ clockgen nodes. The
knowledge of what each bit
The driver retains compatibility with old device trees, but we don't
want the old nodes lying around to be copied, or used as a reference
(some of the mux options are incorrect), or even just being clutter.
We will also need the #clock-cells in the clockgen node in order to
add fman nodes.
On Mon, 2015-06-15 at 12:42 -0400, David Long wrote:
From: David A. Long dave.l...@linaro.org
The pt_regs_offset structure is used for HAVE_REGS_AND_STACK_ACCESS_API
feature and has identical definitions in four different arch ptrace.h
include files. It seems unlikely that definition would
Freescale's Layerscape ARM chips use the same structure.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
arch/powerpc/platforms/85xx/p1022_ds.c
On Thu, 2015-06-18 at 18:17 +0200, Torsten Duwe wrote:
Did I miss anything else? I have the notrace optimisations and
kernel live patching in the queue, which depends on this, so I'd
really appreciate a comment whether it is acceptable in this form
or not. Thanks in advance!
Hi Torsten,
The clock driver now takes care of ensuring that the mux only
exposes options that are valid. The driver was currently being overly
conservative in some cases -- for example, the min_cpufreq =
get_bus_freq() restriction only applies to chips with erratum
A-004510, and whether the freq_mask used
This allows the clocks property to be used in the absence of
legacy nodes, and for clocks that the legacy nodes do not describe.
Signed-off-by: Scott Wood scottw...@freescale.com
---
drivers/clk/clk-qoriq.c | 63 -
1 file changed, 62 insertions(+),
On Mon, Jun 15, 2015 at 12:42:59PM -0400, David Long wrote:
From: David A. Long dave.l...@linaro.org
Several architectures have identical or functionally equivalent code
implementing parts of the HAVE_REGS_AND_STACK_ACCESS_API feature. Move
that code out of the architecture directories.
On Thu, 18 Jun 2015, Michal Hocko wrote:
[Sorry for the late reply - I meant to answer in the previous threads
but something always preempted me from that]
On Wed 10-06-15 09:26:48, Eric B Munson wrote:
The cost of faulting in all memory to be locked can be very high when
working with
On 06/18/2015 08:30 AM, Guenter Roeck wrote:
On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote:
[ ... ]
What happened to this series? I want to add shutdown support to my
platform and I need to write a register on the PMIC in one driver to
configure it for shutdown instead of
Hi Finn,
On Thu, Jun 18, 2015 at 6:49 AM, Finn Thain fth...@telegraphics.com.au wrote:
On Tue, 16 Jun 2015, in which I wrote:
On Mon, 15 Jun 2015, Geert Uytterhoeven wrote:
More magic values...
[...] The only useful RTC documentation I've ever come across is this:
Thomas Huth th...@redhat.com writes:
On Thu, 11 Jun 2015 15:48:49 +0530
Nikunj A Dadhania nik...@linux.vnet.ibm.com wrote:
+ block-size * to seek-pos
+ block gptpart-entry-size l@-le to gpt-part-size
+ block gptnum-part-entry l@-le dup 0= IF FALSE EXIT THEN
+ 1+ 1 ?DO
+
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
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
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 weiy...@linux.vnet.ibm.com
Acked-by: Gavin
On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 10/06/2014 10:28 PM, Guenter Roeck wrote:
Various drivers implement architecture and/or device specific means to
remove power from the system. For the most part, those drivers set the
global variable pm_power_off to
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 weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan
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
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_bus_add_device() which is
called by pci_bus_add_device(). In this
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
[46796.501487] Unable to handle kernel paging request for data at
address 0x02dd
[46796.514365] Faulting instruction address: 0xc00c5978
[46796.524217] Oops: Kernel access of bad area, sig: 11 [#1]
[46796.529351] PREEMPT CMPC885
[46796.532144] CPU: 0 PID: 1107 Comm: snmpd Not tainted 3.18.14
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
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
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
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
On Thu, 2015-06-18 at 15:57 +1000, Michael Ellerman wrote:
On Thu, 2015-06-18 at 15:15 +1000, Michael Neuling wrote:
Fix typo in debug print. p1-p2. No functional change.
That's not no functional change, it changes the behaviour, unless p2_base()
implements the same logic as p1_base()?
51 matches
Mail list logo
