Hi Michael,
On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote:
On Tue, 2015-04-08 at 08:30:58 UTC, Gautham R. Shenoy wrote:
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction (Page 91).
Create an inline function name update_hid0() which follows this recipe
and invoke it from the static split core path.
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Invoke new opal_cec_reboot2() call with reboot type
OPAL_REBOOT_PLATFORM_ERROR (for unrecoverable HMI interrupts) to inform
BMC/OCC about this error, so that BMC can collect relevant data for error
analysis and decide what component to
On Tue, 2015-04-08 at 08:30:58 UTC, Gautham R. Shenoy wrote:
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction (Page 91).
Create a function name update_hid0() which follows
Regards,
Igal Liberman
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, August 04, 2015 8:00 AM
To: Liberman Igal-B31950 igal.liber...@freescale.com
Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Bucur
Madalin-Cristian-B32716 madalin.bu...@freescale.com;
On Tuesday 04 August 2015 03:38 PM, Michael Ellerman wrote:
On Tue, 2015-04-08 at 08:30:58 UTC, Gautham R. Shenoy wrote:
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction (Page 91).
Create a function name update_hid0() which follows this recipe and
invoke it from the static split core path.
On Mon, 2015-13-07 at 08:16:06 UTC, Anshuman Khandual wrote:
This patch enables facility unavailable exceptions for generic facility,
FPU, ALTIVEC and VSX in /proc/interrupts listing by incrementing their
newly added IRQ statistical counters as and when these exceptions happen.
This also adds
The helper kstrndup() will do the same in one line.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/powerpc/platforms/pseries/of_helpers.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/of_helpers.c
The derive_parent() has similar semantics to what we have in newly introduced
of_helpers module. The replacement reduces code base and propagates the actual
error code to the caller.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/powerpc/platforms/pseries/dlpar.c | 31
There is no need to call strrchr() second time. We already know that in that
case parent_path_len either 1 (/foo) or bigger (/foo/bar).
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/powerpc/platforms/pseries/of_helpers.c | 2 +-
1 file changed, 1 insertion(+), 1
In case we have a full node name like /foo/bar and /foo is not found the
parent_path left unfreed. So, free a memory before return to a caller.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/powerpc/platforms/pseries/of_helpers.c | 6 ++
1 file changed, 2
Extract a new module to share the code between other modules.
There is no functional change.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
arch/powerpc/platforms/pseries/Makefile | 1 +
arch/powerpc/platforms/pseries/of_helpers.c | 38 +
Le 02/08/2015 21:05, Markus Stockhausen a écrit :
Hi Christophe,
I saw that this patch from you is still missing in Linux mainline:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121144.html
Is there any reason for not using it?
Markus
Hi,
I sent v3 of that Patch on 19 May
On Tue, Aug 04, 2015 at 12:42:48AM +0200, Maciej S. Szmigiero wrote:
In cases like this where only one patch of six patch series is updated
should other ones be resubmitted as well to keep the full patch series
together?
Yes, any unapplied patches should be resubmitted.
signature.asc
Hello,
I would please like to ask if describing flash nor used with GPMC,
whould be done as described in:
https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
It is described in the above link as TI's GPMC, so I'm not sure if
it is relevent for powerpc too.
Thank you,
On Fri, 2015-31-07 at 12:08:58 UTC, Paul Bolle wrote:
wf_unregister_client() increments the client count when a client
unregisters. That is obviously incorrect. Decrement that client count
instead.
Fixes: 75722d3992f5 ([PATCH] ppc64: Thermal control for SMU based machines)
Signed-off-by:
Hi Anton,
On Wed, Aug 05, 2015 at 02:03:00PM +1000, Anton Blanchard wrote:
While looking at traces of kernel workloads, I noticed places where gcc
used a large number of non volatiles. Some of these functions
did very little work, and we spent most of our time saving the
non volatiles to the
On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote:
On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote:
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote:
From: Shaohui Xie shaohui@freescale.com
The PHY uses XAUI interface to connect to MAC, mostly the PHY used
Hi Andy,
On Tue, Aug 04, 2015 at 05:36:45PM +0300, Andy Shevchenko wrote:
+struct device_node *pseries_of_derive_parent(const char *path)
+{
+ struct device_node *parent = NULL;
+ char *parent_path = /;
+ size_t parent_path_len = strrchr(path, '/') - path + 1;
+
+ /* reject
In current implementation, when VF BAR is bigger than 64MB, it uses 4 M64
BAR in Single PE mode to cover the number of VFs required to be enabled.
By doing so, several VFs would be in one VF Group and leads to interference
between VFs in the same group.
This patch changes the design by using one
Each VF could have 6 BARs at most. When the total BAR size exceeds the
gate, after expanding it will also exhaust the M64 Window.
This patch limits the boundary by checking the total VF BAR size instead of
the individual BAR.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
On Tue, 2015-08-04 at 19:36 +0530, Madhavan Srinivasan wrote:
On Tuesday 04 August 2015 03:38 PM, Michael Ellerman wrote:
On Tue, 2015-04-08 at 08:30:58 UTC, Gautham R. Shenoy wrote:
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be
On Tue, 2015-08-04 at 22:06 -0500, Xie Shaohui-B21989 wrote:
-Original Message-
From: Xie Shaohui-B21989
Sent: Wednesday, August 05, 2015 11:00 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [1/2] powerpc/config: enable teranetics PHY
On Tue,
In original design, it tries to group VFs to enable more number of VFs in the
system, when VF BAR is bigger than 64MB. This design has a flaw in which one
error on a VF will interfere other VFs in the same group.
This patch series change this design by using M64 BAR in Single PE mode to
cover
The alignment of IOV BAR on PowerNV platform is the total size of the IOV
BAR. No matter whether the IOV BAR is truncated or not, the total size
could be calculated by (vfs_expanded * VF size).
This patch simplifies the pnv_pci_iov_resource_alignment() by removing the
first case.
Signed-off-by:
On Tue, Aug 04, 2015 at 08:08:58PM +1000, Michael Ellerman wrote:
+static inline void update_hid0(unsigned long hid0)
+{
+ /*
+* The HID0 update should at the very least be preceded by a
+* a SYNC instruction followed by an ISYNC instruction
+*/
+ mb();
+
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, August 05, 2015 8:19 AM
To: shaohui xie
Cc: linuxppc-dev@lists.ozlabs.org; Xie Shaohui-B21989
Subject: Re: [1/2] powerpc/config: enable teranetics PHY
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote:
From:
On Wed, Aug 5, 2015 at 12:25 AM, Scott Wood scottw...@freescale.com wrote:
On Wed, 2015-08-05 at 00:22 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 9:54 PM,
-Original Message-
From: Xie Shaohui-B21989
Sent: Wednesday, August 05, 2015 11:00 AM
To: Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org
Subject: RE: [1/2] powerpc/config: enable teranetics PHY
On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote:
On Tue, 2015-08-04 at
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote:
From: Shaohui Xie shaohui@freescale.com
The PHY uses XAUI interface to connect to MAC, mostly the PHY used on
riser card.
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
On Tue, 2015-08-04 at 19:24 -0500, Scott Wood wrote:
On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote:
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote:
From: Shaohui Xie shaohui@freescale.com
The PHY uses XAUI interface to connect to MAC, mostly the PHY used on
On Wed, 2015-08-05 at 00:22 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood scottw...@freescale.com
wrote:
On Tue, 2015-08-04 at 18:29
On Tue, 2015-08-04 at 19:18 -0500, Scott Wood wrote:
On Fri, Jul 24, 2015 at 11:45:33AM +0800, shaohui xie wrote:
From: Shaohui Xie shaohui@freescale.com
The PHY uses XAUI interface to connect to MAC, mostly the PHY used on
riser card.
Signed-off-by: Shaohui Xie
On Tue, Aug 4, 2015 at 11:31 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote:
Hello,
I would please like to
On Thu, Jul 23, 2015 at 11:55:45AM +0800, chenhui zhao wrote:
Core reset may cause issue if using the proxy mode of MPIC.
Use the mixed mode of MPIC if enabling CPU hotplug.
Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com
---
arch/powerpc/platforms/85xx/corenet_generic.c | 8
Hi,
On Fri, Jul 31, 2015 at 04:00:12PM +0200, Robert Baldyga wrote:
Hello,
This patch series reworks endpoint matching and claiming mechanism in
epautoconf. From v2 there are couple of new patches adding 'ep_match'
to usb_gadget_ops and removing chip-specific quirk handling from generic
Based on include/xen/mm.h [1], Linux is mistakenly using MFN when GFN
is meant, I suspect this is because the first support for Xen was for
PV. This resulted in some misimplementation of helpers on ARM and
confused developers about the expected behavior.
For instance, with pfn_to_mfn, we expect
HVM_PARAM_CONSOLE_PFN is used to retrieved the console PFN for HVM
guest. It returns a PFN (aka GFN) and not a MFN.
Furthermore, use directly virt_to_gfn for both PV and HVM domain rather
than doing a special case for each of the them.
Signed-off-by: Julien Grall julien.gr...@citrix.com
Hi all,
This patch series aims to use the memory terminologies described in
include/xen/mm.h [1] for Linux xen code.
Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
first support of Xen was for PV. This has brought some misimplementation
of memory helpers on ARM
On Fri, Jul 31, 2015 at 04:00:52PM +0200, Robert Baldyga wrote:
Rework ep_matches() function to make it shorter and more readable.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
this regresses at least mass storage. How did you test it ? I'll keep
all patches up to this one, please fix
On Fri, Jul 31, 2015 at 04:00:19PM +0200, Robert Baldyga wrote:
Convert endpoint configuration to new capabilities model.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
---
drivers/usb/dwc3/gadget.c | 13 +
1 file changed, 13 insertions(+)
diff --git
On Tue, 2015-08-04 at 11:07 +0200, leroy christophe wrote:
Le 02/08/2015 21:05, Markus Stockhausen a écrit :
Hi Christophe,
I saw that this patch from you is still missing in Linux mainline:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-September/121144.html
Is there any
On Wed, 2015-05-27 at 20:19 -0500, Scott Wood wrote:
On Wed, May 20, 2015 at 09:17:11PM -0500, Scott Wood wrote:
From: Jaiprakash Singh b44...@freescale.com
IFC IO accressor are set at run time based
on IFC IP registers endianness.IFC node in
DTS file contains information about
On Tue, 2015-08-04 at 23:26 +0300, Ran Shalit wrote:
On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote:
Hello,
I would please like to ask if describing flash nor used with GPMC,
whould be done as described
On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote:
Hello,
I would please like to ask if describing flash nor used with GPMC,
whould be done as described in:
https://www.kernel.org/doc/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
It is described in the above link as TI's GPMC, so I'm
On Tue, Aug 4, 2015 at 9:54 PM, Scott Wood scottw...@freescale.com wrote:
On Tue, 2015-08-04 at 18:29 +0300, Ran Shalit wrote:
Hello,
I would please like to ask if describing flash nor used with GPMC,
whould be done as described in:
Based on the limitation of M64 Window size, when VF BAR size is bigger than
64MB, IOV BAR just round up power of 2 of the total_vfs. While the 64MB is
a magic boundary in code, which is hard to maintain.
This patch replaces the hard coded boundary with gate, which is calculated
from m64_segsize
On PHB_IODA2, we enable SRIOV devices by mapping IOV BAR with M64 BARs. If
a SRIOV device's BAR is not 64-bit prefetchable, this is not assigned from
M64 windwo, which means M64 BAR can't work on it.
This patch makes this explicit.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
On 08/04/2015 02:12 PM, Julien Grall wrote:
/*
* We detect special mappings in one of two ways:
@@ -217,9 +232,13 @@ static inline unsigned long bfn_to_local_pfn(unsigned long
mfn)
/* VIRT - MACHINE conversion */
#define virt_to_machine(v)(phys_to_machine(XPADDR(__pa(v
When M64 BAR is set to Single PE mode, the PE# assigned to VF could be
discrete.
This patch restructures the patch to allocate discrete PE# for VFs when M64
BAR is set to Single PE mode.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/pci-bridge.h |2 +-
Hi,
While looking at traces of kernel workloads, I noticed places where gcc
used a large number of non volatiles. Some of these functions
did very little work, and we spent most of our time saving the
non volatiles to the stack and reading them back.
It made me wonder if we have the right ratio
52 matches
Mail list logo
