On Wed, Oct 09, 2013 at 10:16:32AM +0530, Anshuman Khandual wrote:
On 10/09/2013 06:51 AM, Michael Ellerman wrote:
On Tue, Oct 08, 2013 at 12:51:18PM +0530, Anshuman Khandual wrote:
On 10/08/2013 09:51 AM, Michael Ellerman wrote:
On Mon, Oct 07, 2013 at 10:00:26AM +0530, Anshuman Khandual
On Wed, Oct 09, 2013 at 03:23:21PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2013-10-09 at 14:23 +1100, Michael Ellerman wrote:
On Tue, Oct 08, 2013 at 06:46:40PM +1100, Benjamin Herrenschmidt wrote:
With OPALv3, the firmware can provide the address of it's internal console
to Linux,
From: Tang Yuantian yuantian.t...@freescale.com
The following SoCs will be affected: p2041, p3041, p4080,
p5020, p5040, b4420, b4860, t4240
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v5:
- refine the binding document
-
On Wed, 2013-10-09 at 17:06 +1100, Michael Ellerman wrote:
Call it twice.
And you wonder why no one reviews your patches?
Not that easy :-) I had a look at using it and unless I did something
stupid, it wasn't actually that trivial to figure out what arg to pass
it for calling it twice, ie,
On Tue, 2013-10-08 at 07:10 +1100, Benjamin Herrenschmidt wrote:
On Mon, 2013-10-07 at 14:01 -0400, Tejun Heo wrote:
I don't think the same race condition would happen with the loop. The
problem case is where multiple msi(x) allocation fails completely
because the global limit went down
-Original Message-
From: Alexander Gordeev [mailto:agord...@redhat.com]
Sent: Wednesday, October 02, 2013 3:49 AM
To: linux-kernel
Cc: Alexander Gordeev; Bjorn Helgaas; Ralf Baechle; Michael Ellerman;
Benjamin Herrenschmidt; Martin Schwidefsky; Ingo Molnar; Tejun Heo; Dan
Williams;
On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
Hmmm... yean, the race condition could be an issue as multiple msi
allocation might fail even if the driver can and explicitly handle
multiple allocation if the quota gets reduced inbetween.
BTW, should we care about the quota getting
On Wed, Oct 9, 2013 at 4:14 AM, Lian Minghuan-b31939
b31...@freescale.com wrote:
arch/powerpc/sysdev/fsl_pci.c | 521 +-
arch/powerpc/sysdev/fsl_pci.h | 89
.../fsl_pci.c = drivers/pci/host/pci-fsl-common.c | 591
Hello,
On Tue, Oct 08, 2013 at 02:22:16PM +0200, Alexander Gordeev wrote:
If we talk about pSeries quota, then the current pSeries pci_enable_msix()
implementation is racy internally and could fail if the quota went down
*while* pci_enable_msix() is executing. In this case the loop will have
Hello,
On Wed, Oct 09, 2013 at 02:57:16PM +0200, Alexander Gordeev wrote:
On Mon, Oct 07, 2013 at 02:01:11PM -0400, Tejun Heo wrote:
Hmmm... yean, the race condition could be an issue as multiple msi
allocation might fail even if the driver can and explicitly handle
multiple allocation if
On Mon, Oct 07, 2013 at 09:48:01PM +0100, Ben Hutchings wrote:
There is one major flaw in min-max approach - the generic MSI layer
will have to take decisions on exact number of MSIs to request, not
device drivers.
[...
No, the min-max functions should be implemented using the same loop
Hello, Alexander.
On Tue, Oct 08, 2013 at 09:48:26AM +0200, Alexander Gordeev wrote:
If there are many which duplicate the above pattern, it'd probably be
worthwhile to provide a helper? It's usually a good idea to reduce
the amount of boilerplate code in drivers.
I wanted to limit
Hello,
On Tue, Oct 08, 2013 at 11:07:16AM +0200, Alexander Gordeev wrote:
Multipe MSIs is just a handful of drivers, really. MSI-X impact still
Yes, so it's pretty nice to try out things there before going full-on.
will be huge. But if we opt a different name for the new pci_enable_msix()
A002 is still in no plans to fix state, and applies to all
the current P1/P2 parts as well, so it's resonable to enable
its workaround by default, for all the soc's with etsec.
The impact of not enabling this workaround for affected parts
is that under certain conditons (runt frames or even frames
Use the macros and defines from mpc85xx.h to simplify
and prevent errors in identifying a mpc85xx based SoC
for errata detection.
This should help enabling (and identifying) workarounds
for various mpc85xx based chips and revisions.
For instance, express MPC8548 Rev.2 as:
(SVR_SOC_VER(svr) ==
Enable workaround for P2020/P2010 erratum eTSEC 20,
Excess delays when transmitting TOE=1 large frames.
The impact is that frames lager than 2500-bytes for which
TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled
may see excess delay before start of transmission.
This erratum was fixed in
From: Claudiu Manoil claudiu.man...@freescale.com
Date: Wed, 9 Oct 2013 20:20:40 +0300
A002 is still in no plans to fix state, and applies to all
the current P1/P2 parts as well, so it's resonable to enable
its workaround by default, for all the soc's with etsec.
The impact of not enabling
From: Claudiu Manoil claudiu.man...@freescale.com
Date: Wed, 9 Oct 2013 20:20:42 +0300
Enable workaround for P2020/P2010 erratum eTSEC 20,
Excess delays when transmitting TOE=1 large frames.
The impact is that frames lager than 2500-bytes for which
TOE (i.e. TCP/IP hw accelerations like Tx
From: Claudiu Manoil claudiu.man...@freescale.com
Date: Wed, 9 Oct 2013 20:20:41 +0300
Use the macros and defines from mpc85xx.h to simplify
and prevent errors in identifying a mpc85xx based SoC
for errata detection.
This should help enabling (and identifying) workarounds
for various mpc85xx
Hi all,
(Please keep me on the CC list, as I'm not subscribed)
On Fri, Sep 27, 2013 at 05:28:38PM +0200, Gerhard Sittig wrote:
a disabled Kconfig option results in a reference to a not implemented
routine when the IS_ENABLED() macro is used for both conditional
implementation of the routine
On Wed, 2013-10-09 at 20:20 +0300, Claudiu Manoil wrote:
+static void gfar_detect_errata(struct gfar_private *priv)
+{
+ struct device *dev = priv-ofdev-dev;
+
+ /* no plans to fix */
+ priv-errata |= GFAR_ERRATA_A002;
+
+ if (pvr_version_is(PVR_VER_E500V1) ||
On 09/26/2013 04:44 PM, Stephane Eranian wrote:
So you are saying that the HW filter is exclusive. That seems odd. But
I think it is
because of the choices is ANY. ANY covers all the types of branches. Therefore
it does not make a difference whether you add COND or not. And
vice-versa, if you
22 matches
Mail list logo
