* [PATCH 2/2] MAINTAINERS: ibmvfc driver maintainer change
From: Tyrel Datwyler @ 2015-01-13 0:31 UTC (permalink / raw)
To: linux-scsi; +Cc: brking, nfont, linux-kernel, linuxppc-dev, Tyrel Datwyler
In-Reply-To: <1421109095-18613-1-git-send-email-tyreld@linux.vnet.ibm.com>
Change maintainer of ibmvfc driver to Tyrel Datwyler.
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index a646b94..f0d7593 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4761,7 +4761,7 @@ F: drivers/scsi/ibmvscsi/ibmvscsi*
F: drivers/scsi/ibmvscsi/viosrp.h
IBM Power Virtual FC Device Drivers
-M: Brian King <brking@linux.vnet.ibm.com>
+M: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
L: linux-scsi@vger.kernel.org
S: Supported
F: drivers/scsi/ibmvscsi/ibmvfc*
--
1.7.12.2
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl: Add empty ranges to etsec2 dts files
From: Scott Wood @ 2015-01-12 21:31 UTC (permalink / raw)
To: Martin Hicks; +Cc: linuxppc-dev
In-Reply-To: <20150112152749.GA5450@darwin.bork.org>
On Mon, 2015-01-12 at 10:27 -0500, Martin Hicks wrote:
>
> With an earlier change (746c9e9f - Fix PowerPC address parsing hack), ethernet
> has broken on Freescale boards such as the P1022. All ranges used by the
> ethernet controllers are also covered by sub-devices that properly
> declared the used ranges. The error shown is:
>
> fsl-gianfar: probe of soc@ffe00000:ethernet@b0000 failed with error -12
>
> Signed-off-by: Martin Hicks <mort@bork.org>
> ---
> arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi | 1 +
> 3 files changed, 3 insertions(+)
http://patchwork.ozlabs.org/patch/422446/
> diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
> index 1382fec..d1a6c48 100644
> --- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
> @@ -43,6 +43,7 @@ mdio@24000 {
> ethernet@b0000 {
> #address-cells = <1>;
> #size-cells = <1>;
> + ranges = <>;
The " = <>" is usually omitted for empty properties.
-Scott
^ permalink raw reply
* [PATCH 09/10] PCI, powerpc: clip firmware assigned resource under parent bridge's
From: Yinghai Lu @ 2015-01-12 19:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Wei Yang, linuxppc-dev, Andrew Murray, Sebastian Ott,
linux-kernel, Gavin Shan, Paul Mackerras, Anton Blanchard,
linux-pci, Yinghai Lu
In-Reply-To: <1421090600-9750-1-git-send-email-yinghai@kernel.org>
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Wei Yang <weiyang@linux.vnet.ibm.com>
Cc: Andrew Murray <amurray@embedded-bits.co.uk>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 43 +++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 37d512d..6909546 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1148,6 +1148,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
struct pci_bus *b;
int i;
struct resource *res, *pr;
+ bool changed = false;
pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
pci_domain_nr(bus), bus->number);
@@ -1184,6 +1185,8 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
pr, (pr && pr->name) ? pr->name : "nil");
if (pr && !(pr->flags & IORESOURCE_UNSET)) {
+ struct pci_dev *dev = bus->self;
+
if (request_resource(pr, res) == 0)
continue;
/*
@@ -1193,6 +1196,16 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
*/
if (reparent_resources(pr, res) == 0)
continue;
+
+ if (dev && i >= PCI_BRIDGE_RESOURCES &&
+ i < PCI_NUM_RESOURCES &&
+ (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
+ pci_bus_clip_resource(dev, res)) {
+ changed = true;
+ if (pci_claim_resource(dev, i) >= 0)
+ continue;
+ }
+
}
pr_warning("PCI: Cannot allocate resource region "
"%d of PCI bridge %d, will remap\n", i, bus->number);
@@ -1208,6 +1221,9 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
res->flags = 0;
}
+ if (changed)
+ pci_setup_bridge(bus);
+
list_for_each_entry(b, &bus->children, node)
pcibios_allocate_bus_resources(b);
}
@@ -1225,6 +1241,13 @@ static inline void alloc_resource(struct pci_dev *dev, int idx)
pr = pci_find_parent_resource(dev, r);
if (!pr || (pr->flags & IORESOURCE_UNSET) ||
request_resource(pr, r) < 0) {
+ /* try again with clip */
+ if (idx != PCI_ROM_RESOURCE && pci_bus_clip_resource(dev, r)) {
+ pci_update_resource(dev, idx);
+ if (pci_claim_resource(dev, idx) >= 0)
+ return;
+ }
+
printk(KERN_WARNING "PCI: Cannot allocate resource region %d"
" of device %s, will remap\n", idx, pci_name(dev));
if (pr)
@@ -1386,6 +1409,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
struct pci_bus *child_bus;
list_for_each_entry(dev, &bus->devices, bus_list) {
+ bool changed = false;
int i;
for (i = 0; i < PCI_NUM_RESOURCES; i++) {
@@ -1401,8 +1425,25 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
(unsigned long long)r->end,
(unsigned int)r->flags);
- pci_claim_resource(dev, i);
+ if (pci_claim_resource(dev, i) >= 0)
+ continue;
+
+ if (dev->subordinate &&
+ i >= PCI_BRIDGE_RESOURCES &&
+ i < PCI_NUM_RESOURCES &&
+ (dev->class >> 8) == PCI_CLASS_BRIDGE_PCI &&
+ pci_bus_clip_resource(dev, r)) {
+ changed = true;
+ pci_claim_resource(dev, i);
+ } else if (i < PCI_BRIDGE_RESOURCES &&
+ i != PCI_ROM_RESOURCE &&
+ pci_bus_clip_resource(dev, r)) {
+ pci_update_resource(dev, i);
+ pci_claim_resource(dev, i);
+ }
}
+ if (changed)
+ pci_setup_bridge(dev->subordinate);
}
list_for_each_entry(child_bus, &bus->children, node)
--
1.8.4.5
^ permalink raw reply related
* [PATCH 3.16.y-ckt 175/216] powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode
From: Luis Henriques @ 2015-01-12 18:29 UTC (permalink / raw)
To: linux-kernel, stable, kernel-team
Cc: Luis Henriques, Shreyas B. Prabhu, Paul Mackerras, linuxppc-dev
In-Reply-To: <1421085933-32536-1-git-send-email-luis.henriques@canonical.com>
3.16.7-ckt4 -stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Mackerras <paulus@samba.org>
commit 8117ac6a6c2fa0f847ff6a21a1f32c8d2c8501d0 upstream.
Currently, when going idle, we set the flag indicating that we are in
nap mode (paca->kvm_hstate.hwthread_state) and then execute the nap
(or sleep or rvwinkle) instruction, all with the MMU on. This is bad
for two reasons: (a) the architecture specifies that those instructions
must be executed with the MMU off, and in fact with only the SF, HV, ME
and possibly RI bits set, and (b) this introduces a race, because as
soon as we set the flag, another thread can switch the MMU to a guest
context. If the race is lost, this thread will typically start looping
on relocation-on ISIs at 0xc...4400.
This fixes it by setting the MSR as required by the architecture before
setting the flag or executing the nap/sleep/rvwinkle instruction.
[ shreyas@linux.vnet.ibm.com: Edited to handle LE ]
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
---
arch/powerpc/include/asm/reg.h | 2 ++
arch/powerpc/kernel/idle_power7.S | 18 +++++++++++++++++-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index bffd89d27301..e73cdadab785 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -118,8 +118,10 @@
#define __MSR (MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_ISF |MSR_HV)
#ifdef __BIG_ENDIAN__
#define MSR_ __MSR
+#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV)
#else
#define MSR_ (__MSR | MSR_LE)
+#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV | MSR_LE)
#endif
#define MSR_KERNEL (MSR_ | MSR_64BIT)
#define MSR_USER32 (MSR_ | MSR_PR | MSR_EE)
diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S
index 5cf3d367190d..a29f5b0f9d3e 100644
--- a/arch/powerpc/kernel/idle_power7.S
+++ b/arch/powerpc/kernel/idle_power7.S
@@ -101,7 +101,23 @@ _GLOBAL(power7_powersave_common)
std r9,_MSR(r1)
std r1,PACAR1(r13)
-_GLOBAL(power7_enter_nap_mode)
+ /*
+ * Go to real mode to do the nap, as required by the architecture.
+ * Also, we need to be in real mode before setting hwthread_state,
+ * because as soon as we do that, another thread can switch
+ * the MMU context to the guest.
+ */
+ LOAD_REG_IMMEDIATE(r5, MSR_IDLE)
+ li r6, MSR_RI
+ andc r6, r9, r6
+ LOAD_REG_ADDR(r7, power7_enter_nap_mode)
+ mtmsrd r6, 1 /* clear RI before setting SRR0/1 */
+ mtspr SPRN_SRR0, r7
+ mtspr SPRN_SRR1, r5
+ rfid
+
+ .globl power7_enter_nap_mode
+power7_enter_nap_mode:
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
/* Tell KVM we're napping */
li r4,KVM_HWTHREAD_IN_NAP
--
2.1.4
^ permalink raw reply related
* Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
From: Guenter Roeck @ 2015-01-12 17:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, linux-m68k, linux-kernel@vger.kernel.org,
Rob Clark, Linux-Next, Daniel Vetter,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAMuHMdUYEe=L=H75AOYVjinRSW=okRJNrNJVy-bY1gshdVrO7Q@mail.gmail.com>
On Mon, Jan 12, 2015 at 05:27:08PM +0100, Geert Uytterhoeven wrote:
> On Mon, Jan 12, 2015 at 5:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> Changes since 20150109:
> >>
> >> The usb-gadget-fixes tree gained a conflict against the usb.current tree.
> >>
> >> The net-next tree gained a build failure for which I reverted a commit.
> >>
> >> The pinctrl tree gained a build failure so I used the version from
> >> next-20150109.
> >>
> >> The akpm tree lost a few patches that turned up elsewhere.
> >>
> >> Non-merge commits (relative to Linus' tree): 2202
> >> 2272 files changed, 69868 insertions(+), 38441 deletions(-)
> >>
> >
> > Build failures, seen since next-20150109:
> > m68k:allmodconfig
> > powerpc:ppc6xx_defconfig
> >
> > Due to:
> > ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
> > make[1]: *** [__modpost] Error 1
> >
> > Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl).
>
> Yeah, it needs a get_user() that supports 64-bit data.
>
Hi Geert,
I assume you mean m68k, where 64 bit support for get_user has been disabled.
The problem on powerpc is different though: __get_user_nocheck()
and __get_user_check() use
unsigned long __gu_val;
followed by
__get_user_size(__gu_val, __gu_addr, (size), __gu_err);
__get_user_size() fails in
if (size > sizeof(x))
(x) = __get_user_bad();
Presumably "unsigned long" is 32 bit on 32 bit powerpc, not 64 bit.
Overall, the explicit 64-bit use of get_user() seems to be quite unusual.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] powerpc: Reword the "returning from prom_init" message
From: Paul Clarke @ 2015-01-12 17:27 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <1421056096-20043-1-git-send-email-mpe@ellerman.id.au>
On 01/12/2015 03:48 AM, Michael Ellerman wrote:
> We get way too many bug reports that say "the kernel is hung in
> prom_init", which stems from the fact that the last piece of output
> people see is "returning from prom_init".
>
> The kernel is almost never hung in prom_init(), it's just that it's
> crashed somewhere after prom_init() but prior to the console coming up.
>
> The existing message should give a clue to that, ie. "returning from"
> indicates that prom_init() has finished, but it doesn't seem to work.
> Let's try something different.
>
> This prints:
>
> Calling quiesce...
> Shutting down Open Firmware, booting Linux via __start() ...
>
> Which hopefully makes it clear that prom_init() is not the problem, and
> although __start() probably isn't either, it's at least the right place
> to begin looking.
I'm very much in favor of anything that increases usability or decreases
confusion.
I worry about confusion caused by any phrase that begins "Shutting
down.." Even if accurate, I wonder if something more positive that
indicates that, at least at this point, things are continuing to proceed
along would be preferred.
Perhaps something like "Transferring control from Open Firmware to
kernel (via __start) ...".
(Do we know for certain that what is about to be invoked is "Linux"
per-se, or can it be something else that has a "__start"?)
PC
^ permalink raw reply
* Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
From: Geert Uytterhoeven @ 2015-01-12 16:27 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, linux-m68k, linux-kernel@vger.kernel.org,
Rob Clark, Linux-Next, Daniel Vetter,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20150112162438.GA18723@roeck-us.net>
On Mon, Jan 12, 2015 at 5:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20150109:
>>
>> The usb-gadget-fixes tree gained a conflict against the usb.current tree.
>>
>> The net-next tree gained a build failure for which I reverted a commit.
>>
>> The pinctrl tree gained a build failure so I used the version from
>> next-20150109.
>>
>> The akpm tree lost a few patches that turned up elsewhere.
>>
>> Non-merge commits (relative to Linus' tree): 2202
>> 2272 files changed, 69868 insertions(+), 38441 deletions(-)
>>
>
> Build failures, seen since next-20150109:
> m68k:allmodconfig
> powerpc:ppc6xx_defconfig
>
> Due to:
> ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
> make[1]: *** [__modpost] Error 1
>
> Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl).
Yeah, it needs a get_user() that supports 64-bit data.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
From: Guenter Roeck @ 2015-01-12 16:24 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-m68k, Daniel Vetter, linux-kernel, Rob Clark, linux-next,
Geert Uytterhoeven, linuxppc-dev
In-Reply-To: <20150112180322.003b44f2@canb.auug.org.au>
On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20150109:
>
> The usb-gadget-fixes tree gained a conflict against the usb.current tree.
>
> The net-next tree gained a build failure for which I reverted a commit.
>
> The pinctrl tree gained a build failure so I used the version from
> next-20150109.
>
> The akpm tree lost a few patches that turned up elsewhere.
>
> Non-merge commits (relative to Linus' tree): 2202
> 2272 files changed, 69868 insertions(+), 38441 deletions(-)
>
Build failures, seen since next-20150109:
m68k:allmodconfig
powerpc:ppc6xx_defconfig
Due to:
ERROR: "__get_user_bad" [drivers/gpu/drm/drm.ko] undefined!
make[1]: *** [__modpost] Error 1
Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl).
Bisect results:
# bad: [39b673bba50275b516543d32ef78767a524b9f26] Add linux-next specific files for 20150109
# good: [b1940cd21c0f4abdce101253e860feff547291b0] Linux 3.19-rc3
git bisect start 'HEAD' 'v3.19-rc3'
# good: [d01312ff089667b0b996228ca165d4a9c124b28f] Merge remote-tracking branch 'net-next/master'
git bisect good d01312ff089667b0b996228ca165d4a9c124b28f
# bad: [b90b3ee4f96067f9eb2edf9e61c9f6356b796232] Merge remote-tracking branch 'device-mapper/for-next'
git bisect bad b90b3ee4f96067f9eb2edf9e61c9f6356b796232
# bad: [d4a32441dd063fd10f41826a69dea2b3f410501a] Merge remote-tracking branch 'drm-intel/for-linux-next'
git bisect bad d4a32441dd063fd10f41826a69dea2b3f410501a
# good: [d01203fd1b8c822adbadb0f0e417a7d344456150] Merge remote-tracking branch 'crypto/master'
git bisect good d01203fd1b8c822adbadb0f0e417a7d344456150
# good: [2be57922d46fdec4360ced2eb108832c5a90bc0e] drm/i915: Fix CRC support for DP port D on CHV
git bisect good 2be57922d46fdec4360ced2eb108832c5a90bc0e
# bad: [4baddea51fe5d73a4f2226e9febc6da21e11bac0] Merge remote-tracking branch 'drm/drm-next'
git bisect bad 4baddea51fe5d73a4f2226e9febc6da21e11bac0
# good: [72a3697097b8dc92f5b8362598f5730a9986eb83] Merge branch 'topic/core-stuff' into topic/atomic-core
git bisect good 72a3697097b8dc92f5b8362598f5730a9986eb83
# bad: [a97df1ccd3c30f16385696964767adf854878021] drm/atomic: Hide drm.ko internal interfaces
git bisect bad a97df1ccd3c30f16385696964767adf854878021
# good: [88a48e297b3a3bac6022c03babfb038f1a886cea] drm: add atomic properties
git bisect good 88a48e297b3a3bac6022c03babfb038f1a886cea
# good: [6b4959f43a04e12d39c5700607727f2cbcfeac31] drm/atomic: atomic plane properties
git bisect good 6b4959f43a04e12d39c5700607727f2cbcfeac31
# bad: [d34f20d6e2f21bd3531b969dc40913181a8ae31a] drm: Atomic modeset ioctl
git bisect bad d34f20d6e2f21bd3531b969dc40913181a8ae31a
# good: [ae16c597b61ae4613b13a0c3fac302e8d8827ac7] drm/atomic: atomic connector properties
git bisect good ae16c597b61ae4613b13a0c3fac302e8d8827ac7
# first bad commit: [d34f20d6e2f21bd3531b969dc40913181a8ae31a] drm: Atomic modeset ioctl
^ permalink raw reply
* [PATCH] powerpc/fsl: Add empty ranges to etsec2 dts files
From: Martin Hicks @ 2015-01-12 15:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood
With an earlier change (746c9e9f - Fix PowerPC address parsing hack), ethernet
has broken on Freescale boards such as the P1022. All ranges used by the
ethernet controllers are also covered by sub-devices that properly
declared the used ranges. The error shown is:
fsl-gianfar: probe of soc@ffe00000:ethernet@b0000 failed with error -12
Signed-off-by: Martin Hicks <mort@bork.org>
---
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi | 1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi | 1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
index 1382fec..d1a6c48 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
@@ -43,6 +43,7 @@ mdio@24000 {
ethernet@b0000 {
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
index 221cd2e..0447d38 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
@@ -43,6 +43,7 @@ mdio@25000 {
ethernet@b1000 {
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
index 61456c3..d2b7255 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
@@ -42,6 +42,7 @@ mdio@26000 {
ethernet@b2000 {
#address-cells = <1>;
#size-cells = <1>;
+ ranges = <>;
device_type = "network";
model = "eTSEC";
compatible = "fsl,etsec2";
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v7 0/4] Add support for parametrized events
From: Arnaldo Carvalho de Melo @ 2015-01-12 14:18 UTC (permalink / raw)
To: Jiri Olsa
Cc: peterz, linux-kernel, Paul Mackerras, dev, Sukadev Bhattiprolu,
linuxppc-dev
In-Reply-To: <20150108095434.GA16059@krava.redhat.com>
Em Thu, Jan 08, 2015 at 10:54:34AM +0100, Jiri Olsa escreveu:
> for the patchset:
>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
Applied to perf/core
Thanks,
- Arnaldo
^ permalink raw reply
* Re: [RFC 02/11] i2c: add quirk checks to core
From: Matthias Brugger @ 2015-01-12 13:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mips, linux-kernel@vger.kernel.org, Ludovic Desroches,
linux-i2c, Yingjoe Chen, linuxppc-dev,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1420824103-24169-3-git-send-email-wsa@the-dreams.de>
2015-01-09 18:21 GMT+01:00 Wolfram Sang <wsa@the-dreams.de>:
> Let the core do the checks if HW quirks prevent a transfer. Saves code
> from drivers and adds consistency.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> drivers/i2c/i2c-core.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 39d25a8cb1ad..7b10a19abf5b 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -2063,6 +2063,56 @@ module_exit(i2c_exit);
> * ----------------------------------------------------
> */
>
> +/* Check if val is exceeding the quirk IFF quirk is non 0 */
> +#define i2c_quirk_exceeded(val, quirk) ((quirk) && ((val) > (quirk)))
> +
> +static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg, char *err_msg)
> +{
> + dev_err(&adap->dev, "quirk: %s (addr 0x%04x, size %u)\n", err_msg, msg->addr, msg->len);
> + return -EOPNOTSUPP;
> +}
> +
> +static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +{
> + struct i2c_adapter_quirks *q = adap->quirks;
> + u16 max_read = q->max_read_len, max_write = q->max_write_len;
> + int max_num = q->max_num_msgs, i;
> +
> + if (q->flags & I2C_ADAPTER_QUIRK_COMB_WRITE_THEN_READ)
> + max_num = 2;
> +
> + if (i2c_quirk_exceeded(num, max_num))
> + return i2c_quirk_error(adap, &msgs[0], "too many messages");
> +
> + if (num == 2 && q->flags & I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST) {
> + if (msgs[0].flags & I2C_M_RD)
> + return i2c_quirk_error(adap, &msgs[0], "invalid first write msg");
> +
> + max_write = q->max_comb_write_len;
> + }
> +
> + if (num == 2 && q->flags & I2C_ADAPTER_QUIRK_COMB_READ_SECOND) {
> + if (!(msgs[1].flags & I2C_M_RD) || msgs[0].addr != msgs[1].addr)
> + return i2c_quirk_error(adap, &msgs[1], "invalid second read msg");
> +
> + max_read = q->max_comb_read_len;
> + }
> +
> + for (i = 0; i < num; i++) {
> + u16 len = msgs[i].len;
> +
> + if (msgs[i].flags & I2C_M_RD) {
> + if (i2c_quirk_exceeded(len, max_read))
> + return i2c_quirk_error(adap, &msgs[i], "msg too long");
> + } else {
> + if (i2c_quirk_exceeded(len, max_write))
> + return i2c_quirk_error(adap, &msgs[i], "msg too long");
> + }
What about being more verbose in the error message, specifying if it
was a read or a write message that failed?
> + }
> +
> + return 0;
> +}
> +
> /**
> * __i2c_transfer - unlocked flavor of i2c_transfer
> * @adap: Handle to I2C bus
> @@ -2080,6 +2130,9 @@ int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> unsigned long orig_jiffies;
> int ret, try;
>
> + if (adap->quirks && i2c_check_for_quirks(adap, msgs, num))
> + return -EOPNOTSUPP;
> +
> /* i2c_trace_msg gets enabled when tracepoint i2c_transfer gets
> * enabled. This is an efficient way of keeping the for-loop from
> * being executed when not needed.
> --
> 2.1.3
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
motzblog.wordpress.com
^ permalink raw reply
* Re: [RFC 02/11] i2c: add quirk checks to core
From: Russell King - ARM Linux @ 2015-01-12 12:08 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mips, linux-kernel, Ludovic Desroches, linux-i2c,
Yingjoe Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1420824103-24169-3-git-send-email-wsa@the-dreams.de>
On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
> +static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg, char *err_msg)
> +{
> + dev_err(&adap->dev, "quirk: %s (addr 0x%04x, size %u)\n", err_msg, msg->addr, msg->len);
> + return -EOPNOTSUPP;
> +}
So, what happens if I open an I2C adapter, find a message which causes
i2c_quirk_error() to be called, and then spin repeatedly calling that...
Shouldn't there be some rate limiting to this?
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] powerpc/dts: Update platform PLL node
From: Igal.Liberman @ 2015-01-12 6:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Igal Liberman, Emilian.Medve
From: Igal Liberman <Igal.Liberman@freescale.com>
Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
Change-Id: I92d020651237041d3767aa35e9345439714f9831
---
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
index 48e0b6e..7e1f074 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
@@ -49,14 +49,16 @@ global-utilities@e1000 {
reg = <0x800 0x4>;
compatible = "fsl,qoriq-core-pll-2.0";
clocks = <&sysclk>;
- clock-output-names = "pll0", "pll0-div2", "pll0-div4";
+ clock-output-names = "pll0", "pll0-div2", "pll0-div3",
+ "pll0-div4";
};
pll1: pll1@820 {
#clock-cells = <1>;
reg = <0x820 0x4>;
compatible = "fsl,qoriq-core-pll-2.0";
clocks = <&sysclk>;
- clock-output-names = "pll1", "pll1-div2", "pll1-div4";
+ clock-output-names = "pll1", "pll1-div2", "pll1-div3",
+ "pll1-div4";
};
platform_pll: platform-pll@c00 {
#clock-cells = <1>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc/dts: Unify B4 mux nodes
From: Igal.Liberman @ 2015-01-12 6:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: scottwood, Igal Liberman, Emilian.Medve
From: Igal Liberman <Igal.Liberman@freescale.com>
Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
Change-Id: Ic5f28f7b492b708f00a5ff74dda723ce5e1da0ba
---
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 15 ++-------------
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 15 ++-------------
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 12 ++++++++++++
3 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 86161ae..1ea8602 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -80,20 +80,9 @@
compatible = "fsl,b4420-device-config", "fsl,qoriq-device-config-2.0";
};
-/include/ "qoriq-clockgen2.dtsi"
global-utilities@e1000 {
- compatible = "fsl,b4420-clockgen", "fsl,qoriq-clockgen-2.0";
-
- mux0: mux0@0 {
- #clock-cells = <0>;
- reg = <0x0 0x4>;
- compatible = "fsl,qoriq-core-mux-2.0";
- clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
- <&pll1 0>, <&pll1 1>, <&pll1 2>;
- clock-names = "pll0", "pll0-div2", "pll0-div4",
- "pll1", "pll1-div2", "pll1-div4";
- clock-output-names = "cmux0";
- };
+ compatible = "fsl,b4420-clockgen", "fsl,b4-clockgen",
+ "fsl,qoriq-clockgen-2.0";
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 65100b9..d0a5cde 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -124,20 +124,9 @@
compatible = "fsl,b4860-device-config", "fsl,qoriq-device-config-2.0";
};
-/include/ "qoriq-clockgen2.dtsi"
global-utilities@e1000 {
- compatible = "fsl,b4860-clockgen", "fsl,qoriq-clockgen-2.0";
-
- mux0: mux0@0 {
- #clock-cells = <0>;
- reg = <0x0 0x4>;
- compatible = "fsl,qoriq-core-mux-2.0";
- clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
- <&pll1 0>, <&pll1 1>, <&pll1 2>;
- clock-names = "pll0", "pll0-div2", "pll0-div4",
- "pll1", "pll1-div2", "pll1-div4";
- clock-output-names = "cmux0";
- };
+ compatible = "fsl,b4860-clockgen", "fsl,b4-clockgen",
+ "fsl,qoriq-clockgen-2.0";
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 1a54ba7..e4e69b0 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -214,9 +214,21 @@
fsl,liodn-bits = <12>;
};
+/include/ "qoriq-clockgen2.dtsi"
clockgen: global-utilities@e1000 {
compatible = "fsl,b4-clockgen", "fsl,qoriq-clockgen-2.0";
reg = <0xe1000 0x1000>;
+
+ mux0: mux0@0 {
+ #clock-cells = <0>;
+ reg = <0x0 0x4>;
+ compatible = "fsl,qoriq-core-mux-2.0";
+ clocks = <&pll0 0>, <&pll0 1>, <&pll0 2>,
+ <&pll1 0>, <&pll1 1>, <&pll1 2>;
+ clock-names = "pll0", "pll0-div2", "pll0-div4",
+ "pll1", "pll1-div2", "pll1-div4";
+ clock-output-names = "cmux0";
+ };
};
rcpm: global-utilities@e2000 {
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC 02/11] i2c: add quirk checks to core
From: Wolfram Sang @ 2015-01-12 10:13 UTC (permalink / raw)
To: linux-i2c, linux-arm-kernel, linuxppc-dev, linux-mips,
Benjamin Herrenschmidt, Yingjoe Chen, linux-kernel
In-Reply-To: <20150112095847.GD3625@ldesroches-Latitude-E6320>
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
> I am not sure it will perfectly fit at91 quirks.
I think it does.
> The hardware can handle two messages by using the internal address
> feature. The internal address size is from one byte to three bytes. Then
> the length of the first message is limited to three but we don't have
> this constraint for the second one. If we have 'write then read' no problem
> but if we have two write messages, the second one will cause a quirk
> exceeded error.
Yeah, for this reason I seperated I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST
out. The first message is checked against max_comb_write_len which is
set to 3 for your driver. The second is checked agains max_write_len
which is unset in your driver and thus can be of any length.
That should work, no?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [RFC 02/11] i2c: add quirk checks to core
From: Ludovic Desroches @ 2015-01-12 9:58 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-mips, linux-kernel, Ludovic Desroches, linux-i2c,
Yingjoe Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1420824103-24169-3-git-send-email-wsa@the-dreams.de>
Hi Wolfram,
On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
> Let the core do the checks if HW quirks prevent a transfer. Saves code
> from drivers and adds consistency.
>
> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
> ---
> drivers/i2c/i2c-core.c | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 39d25a8cb1ad..7b10a19abf5b 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -2063,6 +2063,56 @@ module_exit(i2c_exit);
> * ----------------------------------------------------
> */
>
> +/* Check if val is exceeding the quirk IFF quirk is non 0 */
> +#define i2c_quirk_exceeded(val, quirk) ((quirk) && ((val) > (quirk)))
> +
> +static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg, char *err_msg)
> +{
> + dev_err(&adap->dev, "quirk: %s (addr 0x%04x, size %u)\n", err_msg, msg->addr, msg->len);
> + return -EOPNOTSUPP;
> +}
> +
> +static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> +{
> + struct i2c_adapter_quirks *q = adap->quirks;
> + u16 max_read = q->max_read_len, max_write = q->max_write_len;
> + int max_num = q->max_num_msgs, i;
> +
> + if (q->flags & I2C_ADAPTER_QUIRK_COMB_WRITE_THEN_READ)
> + max_num = 2;
> +
> + if (i2c_quirk_exceeded(num, max_num))
> + return i2c_quirk_error(adap, &msgs[0], "too many messages");
> +
> + if (num == 2 && q->flags & I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST) {
> + if (msgs[0].flags & I2C_M_RD)
> + return i2c_quirk_error(adap, &msgs[0], "invalid first write msg");
> +
> + max_write = q->max_comb_write_len;
> + }
> +
> + if (num == 2 && q->flags & I2C_ADAPTER_QUIRK_COMB_READ_SECOND) {
> + if (!(msgs[1].flags & I2C_M_RD) || msgs[0].addr != msgs[1].addr)
> + return i2c_quirk_error(adap, &msgs[1], "invalid second read msg");
> +
> + max_read = q->max_comb_read_len;
> + }
> +
> + for (i = 0; i < num; i++) {
> + u16 len = msgs[i].len;
> +
> + if (msgs[i].flags & I2C_M_RD) {
> + if (i2c_quirk_exceeded(len, max_read))
> + return i2c_quirk_error(adap, &msgs[i], "msg too long");
> + } else {
> + if (i2c_quirk_exceeded(len, max_write))
> + return i2c_quirk_error(adap, &msgs[i], "msg too long");
> + }
> + }
> +
I am not sure it will perfectly fit at91 quirks.
The hardware can handle two messages by using the internal address
feature. The internal address size is from one byte to three bytes. Then
the length of the first message is limited to three but we don't have
this constraint for the second one. If we have 'write then read' no problem
but if we have two write messages, the second one will cause a quirk
exceeded error.
Regards
Ludovic
> + return 0;
> +}
> +
> /**
> * __i2c_transfer - unlocked flavor of i2c_transfer
> * @adap: Handle to I2C bus
> @@ -2080,6 +2130,9 @@ int __i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
> unsigned long orig_jiffies;
> int ret, try;
>
> + if (adap->quirks && i2c_check_for_quirks(adap, msgs, num))
> + return -EOPNOTSUPP;
> +
> /* i2c_trace_msg gets enabled when tracepoint i2c_transfer gets
> * enabled. This is an efficient way of keeping the for-loop from
> * being executed when not needed.
> --
> 2.1.3
>
^ permalink raw reply
* [PATCH] powerpc: Reword the "returning from prom_init" message
From: Michael Ellerman @ 2015-01-12 9:48 UTC (permalink / raw)
To: linuxppc-dev
We get way too many bug reports that say "the kernel is hung in
prom_init", which stems from the fact that the last piece of output
people see is "returning from prom_init".
The kernel is almost never hung in prom_init(), it's just that it's
crashed somewhere after prom_init() but prior to the console coming up.
The existing message should give a clue to that, ie. "returning from"
indicates that prom_init() has finished, but it doesn't seem to work.
Let's try something different.
This prints:
Calling quiesce...
Shutting down Open Firmware, booting Linux via __start() ...
Which hopefully makes it clear that prom_init() is not the problem, and
although __start() probably isn't either, it's at least the right place
to begin looking.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1a85d8f96739..bd3e0d8ac8fd 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2910,7 +2910,7 @@ unsigned long __init prom_init(unsigned long r3, unsigned long r4,
/* Don't print anything after quiesce under OPAL, it crashes OFW */
if (of_platform != PLATFORM_OPAL) {
- prom_printf("returning from prom_init\n");
+ prom_printf("Shutting down Open Firmware, booting Linux via __start() ...\n");
prom_debug("->dt_header_start=0x%x\n", hdr);
}
--
2.1.0
^ permalink raw reply related
* RE: [PATCH 1/2] powerpc: Add 64bit optimised memcmp
From: David Laight @ 2015-01-12 9:45 UTC (permalink / raw)
To: 'Joakim Tjernlund', anton@samba.org
Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1421045727.3055.101.camel@transmode.se>
From: Joakim Tjernlund=20
> On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote:
> > Hi David,
> >
> > > The unrolled loop (deleted) looks excessive.
> > > On a modern cpu with multiple execution units you can usually
> > > manage to get the loop overhead to execute in parallel to the
> > > actual 'work'.
> > > So I suspect that a much simpler 'word at a time' loop will be almost=
as fast - especially in the
> case where the code isn't
> > > already in the cache and the compare is relatively short.
> >
> > I'm always keen to keep things as simple as possible, but your loop is =
over 50% slower. Once the
> loop hits a steady state you are going to run into front end issues with =
instruction fetch on POWER8.
Interesting, I'm not an expert on ppc scheduling, but on my old x86 Athon 7=
00 (I think
it was that one) a similar loop ran as fast as 'rep movsw'.
> Out of curiosity, does preincrement make any difference(or can gcc do tha=
t for you nowadays)?
It will only change register pressure slightly, and might allow any executi=
on
delays be filled - but that is very processor dependant.
Actually you probably want to do 'a +=3D 2' somewhere to reduce the instruc=
tion count.
Similarly the end condition needs to compare one of the pointers.
Elsewhere (not ppc) I've used (++p)[-1] instead of *p++ to move the increme=
nt
before the load to get better scheduling.
> a1 =3D *a;
> b1 =3D *b;
> while {
> a2 =3D *++a;
> b2 =3D *++b;
> if (a1 !=3D a2)
That should have been a1 !=3D b1
> break;
> a1 =3D *++a;
> b1 =3D *++b;
> } while (a2 !=3D a1);
and a2 !=3D b2
David
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add 64bit optimised memcmp
From: Joakim Tjernlund @ 2015-01-12 6:55 UTC (permalink / raw)
To: anton@samba.org
Cc: paulus@samba.org, David.Laight@ACULAB.COM,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20150112115505.15d95434@kryten>
On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote:
> Hi David,
>=20
> > The unrolled loop (deleted) looks excessive.
> > On a modern cpu with multiple execution units you can usually
> > manage to get the loop overhead to execute in parallel to the
> > actual 'work'.
> > So I suspect that a much simpler 'word at a time' loop will be almost a=
s fast - especially in the case where the code isn't
> > already in the cache and the compare is relatively short.
>=20
> I'm always keen to keep things as simple as possible, but your loop is ov=
er 50% slower. Once the loop hits a steady state you are going to run into =
front end issues with instruction fetch on POWER8.
>=20
Out of curiosity, does preincrement make any difference(or can gcc do that =
for you nowadays)?
a1 =3D *a;
b1 =3D *b;
while {
a2 =3D *++a;
b2 =3D *++b;
if (a1 !=3D a2)
break;
a1 =3D *++a;
b1 =3D *++b;
} while (a2 !=3D a1);
Jocke
> Anton
>=20
> > Try something based on:
> > a1 =3D *a++;
> > b1 =3D *b++;
> > while {
> > a2 =3D *a++;
> > b2 =3D *b++;
> > if (a1 !=3D a2)
> > break;
> > a1 =3D *a++;
> > b1 =3D *b++;
> > } while (a2 !=3D a1);
> >=20
> > David
> >=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozl=
abs.org/listinfo/linuxppc-dev=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: Add 64bit optimised memcmp
From: Anton Blanchard @ 2015-01-12 0:55 UTC (permalink / raw)
To: David Laight; +Cc: paulus@samba.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAC418D@AcuExch.aculab.com>
Hi David,
> The unrolled loop (deleted) looks excessive.
> On a modern cpu with multiple execution units you can usually
> manage to get the loop overhead to execute in parallel to the
> actual 'work'.
> So I suspect that a much simpler 'word at a time' loop will be
> almost as fast - especially in the case where the code isn't
> already in the cache and the compare is relatively short.
I'm always keen to keep things as simple as possible, but your loop is
over 50% slower. Once the loop hits a steady state you are going to run
into front end issues with instruction fetch on POWER8.
Anton
> Try something based on:
> a1 = *a++;
> b1 = *b++;
> while {
> a2 = *a++;
> b2 = *b++;
> if (a1 != a2)
> break;
> a1 = *a++;
> b1 = *b++;
> } while (a2 != a1);
>
> David
>
^ permalink raw reply
* ppc + netfilter rx performance issues
From: Bill Cribbs @ 2015-01-12 0:37 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
Hi Folks,
Hope to humbly ask for some advice if this list is still active. I’m supporting a legacy product and looking to improve networking performance. It is a PPC460GT used as a bridge device with an ethernet 1Gb (marvell), that routes packets to a pci network card (using igb).
Going in the pci interface and out tx to the network, we get a nominal 700Mb, however…
RX - to the marvell we see two things:
1. 300Mbps
2. sys = 100%
Any ideas? I’m suspicious that packets are not being handled at a low level and getting copied through iptables rules to userspace. Maybe there is a way to enable DMA to the benefit of incoming packets?
Linux mbu-100 2.6.33.1 #245 Fri Nov 1 17:41:21 PDT 2013 ppc GNU/Linux
Glacier
Thanks!
Bill
[-- Attachment #2: Type: text/html, Size: 2444 bytes --]
^ permalink raw reply
* [PATCH 11/16] powerpc: powermac: convert PCI to use generic config accesses
From: Rob Herring @ 2015-01-10 2:34 UTC (permalink / raw)
To: linux-kernel
Cc: Rob Herring, Arnd Bergmann, linux-pci, Paul Mackerras,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <1420857290-8373-1-git-send-email-robh@kernel.org>
Convert the powermac PCI driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/platforms/powermac/pci.c | 209 +++++++---------------------------
1 file changed, 39 insertions(+), 170 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c b/arch/powerpc/platforms/powermac/pci.c
index 04702db..f4071a6 100644
--- a/arch/powerpc/platforms/powermac/pci.c
+++ b/arch/powerpc/platforms/powermac/pci.c
@@ -133,17 +133,23 @@ static void __init fixup_bus_range(struct device_node *bridge)
|(((unsigned int)(off)) & 0xFCUL) \
|1UL)
-static volatile void __iomem *macrisc_cfg_access(struct pci_controller* hose,
- u8 bus, u8 dev_fn, u8 offset)
+static void __iomem *macrisc_cfg_map_bus(struct pci_bus *bus,
+ unsigned int dev_fn,
+ int offset)
{
unsigned int caddr;
+ struct pci_controller *hose;
- if (bus == hose->first_busno) {
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return NULL;
+
+ if (bus->number == hose->first_busno) {
if (dev_fn < (11 << 3))
return NULL;
caddr = MACRISC_CFA0(dev_fn, offset);
} else
- caddr = MACRISC_CFA1(bus, dev_fn, offset);
+ caddr = MACRISC_CFA1(bus->number, dev_fn, offset);
/* Uninorth will return garbage if we don't read back the value ! */
do {
@@ -154,129 +160,46 @@ static volatile void __iomem *macrisc_cfg_access(struct pci_controller* hose,
return hose->cfg_data + offset;
}
-static int macrisc_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
- * Note: the caller has already checked that offset is
- * suitably aligned and that len is 1, 2 or 4.
- */
- switch (len) {
- case 1:
- *val = in_8(addr);
- break;
- case 2:
- *val = in_le16(addr);
- break;
- default:
- *val = in_le32(addr);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int macrisc_write_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = macrisc_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
- * Note: the caller has already checked that offset is
- * suitably aligned and that len is 1, 2 or 4.
- */
- switch (len) {
- case 1:
- out_8(addr, val);
- break;
- case 2:
- out_le16(addr, val);
- break;
- default:
- out_le32(addr, val);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
static struct pci_ops macrisc_pci_ops =
{
- .read = macrisc_read_config,
- .write = macrisc_write_config,
+ .map_bus = macrisc_cfg_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
};
#ifdef CONFIG_PPC32
/*
* Verify that a specific (bus, dev_fn) exists on chaos
*/
-static int chaos_validate_dev(struct pci_bus *bus, int devfn, int offset)
+static void __iomem *chaos_map_bus(struct pci_bus *bus, unsigned int devfn,
+ int offset)
{
struct device_node *np;
const u32 *vendor, *device;
if (offset >= 0x100)
- return PCIBIOS_BAD_REGISTER_NUMBER;
+ return NULL;
np = of_pci_find_child_device(bus->dev.of_node, devfn);
if (np == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
+ return NULL;
vendor = of_get_property(np, "vendor-id", NULL);
device = of_get_property(np, "device-id", NULL);
if (vendor == NULL || device == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
+ return NULL;
if ((*vendor == 0x106b) && (*device == 3) && (offset >= 0x10)
&& (offset != 0x14) && (offset != 0x18) && (offset <= 0x24))
- return PCIBIOS_BAD_REGISTER_NUMBER;
-
- return PCIBIOS_SUCCESSFUL;
-}
+ return NULL;
-static int
-chaos_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
- int len, u32 *val)
-{
- int result = chaos_validate_dev(bus, devfn, offset);
- if (result == PCIBIOS_BAD_REGISTER_NUMBER)
- *val = ~0U;
- if (result != PCIBIOS_SUCCESSFUL)
- return result;
- return macrisc_read_config(bus, devfn, offset, len, val);
-}
-
-static int
-chaos_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
- int len, u32 val)
-{
- int result = chaos_validate_dev(bus, devfn, offset);
- if (result != PCIBIOS_SUCCESSFUL)
- return result;
- return macrisc_write_config(bus, devfn, offset, len, val);
+ return macrisc_cfg_map_bus(bus, devfn, offset);
}
static struct pci_ops chaos_pci_ops =
{
- .read = chaos_read_config,
- .write = chaos_write_config,
+ .map_bus = chaos_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
};
static void __init setup_chaos(struct pci_controller *hose,
@@ -471,15 +394,24 @@ static struct pci_ops u3_ht_pci_ops =
|(((unsigned int)(off)) & 0xfcU) \
|1UL)
-static volatile void __iomem *u4_pcie_cfg_access(struct pci_controller* hose,
- u8 bus, u8 dev_fn, int offset)
+static void __iomem *u4_pcie_cfg_map_bus(struct pci_bus *bus,
+ unsigned int dev_fn,
+ int offset)
{
+ struct pci_controller *hose;
unsigned int caddr;
- if (bus == hose->first_busno) {
+ if (offset >= 0x1000)
+ return NULL;
+
+ hose = pci_bus_to_host(bus);
+ if (!hose)
+ return NULL;
+
+ if (bus->number == hose->first_busno) {
caddr = U4_PCIE_CFA0(dev_fn, offset);
} else
- caddr = U4_PCIE_CFA1(bus, dev_fn, offset);
+ caddr = U4_PCIE_CFA1(bus->number, dev_fn, offset);
/* Uninorth will return garbage if we don't read back the value ! */
do {
@@ -490,74 +422,11 @@ static volatile void __iomem *u4_pcie_cfg_access(struct pci_controller* hose,
return hose->cfg_data + offset;
}
-static int u4_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x1000)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
- * Note: the caller has already checked that offset is
- * suitably aligned and that len is 1, 2 or 4.
- */
- switch (len) {
- case 1:
- *val = in_8(addr);
- break;
- case 2:
- *val = in_le16(addr);
- break;
- default:
- *val = in_le32(addr);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
-static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 val)
-{
- struct pci_controller *hose;
- volatile void __iomem *addr;
-
- hose = pci_bus_to_host(bus);
- if (hose == NULL)
- return PCIBIOS_DEVICE_NOT_FOUND;
- if (offset >= 0x1000)
- return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
- if (!addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
- /*
- * Note: the caller has already checked that offset is
- * suitably aligned and that len is 1, 2 or 4.
- */
- switch (len) {
- case 1:
- out_8(addr, val);
- break;
- case 2:
- out_le16(addr, val);
- break;
- default:
- out_le32(addr, val);
- break;
- }
- return PCIBIOS_SUCCESSFUL;
-}
-
static struct pci_ops u4_pcie_pci_ops =
{
- .read = u4_pcie_read_config,
- .write = u4_pcie_write_config,
+ .map_bus = u4_pcie_cfg_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
};
static void pmac_pci_fixup_u4_of_node(struct pci_dev *dev)
--
2.1.0
^ permalink raw reply related
* [PATCH 10/16] powerpc: fsl_pci: convert PCI to use generic config accesses
From: Rob Herring @ 2015-01-10 2:34 UTC (permalink / raw)
To: linux-kernel
Cc: Rob Herring, Arnd Bergmann, linux-pci, Paul Mackerras,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <1420857290-8373-1-git-send-email-robh@kernel.org>
Convert the fsl_pci driver to use the generic config access functions.
This changes accesses from (in|out)_(8|le16|le32) to readX/writeX
variants. I believe these should be equivalent for PCI config space
accesses, but confirmation would be nice.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/sysdev/fsl_pci.c | 46 +++----------------------------------------
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 6455c1e..271b67e 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -645,61 +645,21 @@ mapped:
return pcie->cfg_type1 + offset;
}
-static int mpc83xx_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
- int offset, int len, u32 *val)
-{
- void __iomem *cfg_addr;
-
- cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
- if (!cfg_addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
-
- switch (len) {
- case 1:
- *val = in_8(cfg_addr);
- break;
- case 2:
- *val = in_le16(cfg_addr);
- break;
- default:
- *val = in_le32(cfg_addr);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
-}
-
static int mpc83xx_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 val)
{
struct pci_controller *hose = pci_bus_to_host(bus);
- void __iomem *cfg_addr;
-
- cfg_addr = mpc83xx_pcie_remap_cfg(bus, devfn, offset);
- if (!cfg_addr)
- return PCIBIOS_DEVICE_NOT_FOUND;
/* PPC_INDIRECT_TYPE_SURPRESS_PRIMARY_BUS */
if (offset == PCI_PRIMARY_BUS && bus->number == hose->first_busno)
val &= 0xffffff00;
- switch (len) {
- case 1:
- out_8(cfg_addr, val);
- break;
- case 2:
- out_le16(cfg_addr, val);
- break;
- default:
- out_le32(cfg_addr, val);
- break;
- }
-
- return PCIBIOS_SUCCESSFUL;
+ return pci_generic_config_write(bus, devfn, offset, len, val);
}
static struct pci_ops mpc83xx_pcie_ops = {
- .read = mpc83xx_pcie_read_config,
+ .map_bus = mpc83xx_pcie_remap_cfg,
+ .read = pci_generic_config_read,
.write = mpc83xx_pcie_write_config,
};
--
2.1.0
^ permalink raw reply related
* [PATCH 04/16] powerpc: add struct pci_ops member names to initialization
From: Rob Herring @ 2015-01-10 2:34 UTC (permalink / raw)
To: linux-kernel
Cc: cbe-oss-dev, Rob Herring, Arnd Bergmann, linux-pci,
Paul Mackerras, Bjorn Helgaas, linuxppc-dev
In-Reply-To: <1420857290-8373-1-git-send-email-robh@kernel.org>
Some instances of pci_ops initialization rely on the read/write members'
location in the struct. This is fragile and may break when adding new
members to the beginning of the struct.
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: cbe-oss-dev@lists.ozlabs.org
---
arch/powerpc/platforms/cell/celleb_scc_pciex.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/celleb_scc_pciex.c b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
index f223875..94170e4 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_pciex.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_pciex.c
@@ -399,8 +399,8 @@ static int scc_pciex_write_config(struct pci_bus *bus, unsigned int devfn,
}
static struct pci_ops scc_pciex_pci_ops = {
- scc_pciex_read_config,
- scc_pciex_write_config,
+ .read = scc_pciex_read_config,
+ .write = scc_pciex_write_config,
};
static void pciex_clear_intr_all(unsigned int __iomem *base)
--
2.1.0
^ permalink raw reply related
* [PATCH 00/16] PCI generic configuration space accessors
From: Rob Herring @ 2015-01-10 2:34 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mips, linux-sh, linux-pci, Linus Walleij, Will Deacon,
David Howells, linux-tegra, Thierry Reding, Paul Mackerras,
Tanmay Inamdar, Greg Ungerer, Alexandre Courbot, linux-am33-list,
Russell King, Stephen Warren, Michal Simek, linux-arm-kernel,
cbe-oss-dev, Arnd Bergmann, Rob Herring, Simon Horman,
Krzysztof Halasa, Bjorn Helgaas, Sören Brinkmann,
Ralf Baechle, Koichi Yasutake, linuxppc-dev
This series adds common accessor functions for PCI configuration space
accesses. This supports most PCI hosts with memory mapped configuration
space like ECAM or hosts with memory mapped address/data registers. ECAM
is not generically supported by this series, but could be added on top
of this. While some hosts have standard address decoding which could be
common as well, the various checks on bus numbers and device numbers are
quite varied. It is unclear how much of that is really necessary or
could be common.
The first 4 patches are preparatory cleanup. Patch 5 introduces the
common accessors. The remaining patches convert several PCI host
controllers. This is in no way a complete list of host controllers. The
conversion of more hosts should be possible. The Designware controller
in particular should be able to be converted, but its config space
accessors are a mess of override-able functions that I've not gotten my
head around.
This series is available here [1].
Rob
[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git pci-config-access
Rob Herring (16):
frv: add struct pci_ops member names to initialization
mips: add struct pci_ops member names to initialization
mn10300: add struct pci_ops member names to initialization
powerpc: add struct pci_ops member names to initialization
pci: introduce common pci config space accessors
ARM: cns3xxx: convert PCI to use generic config accesses
ARM: integrator: convert PCI to use generic config accesses
ARM: sa1100: convert PCI to use generic config accesses
ARM: ks8695: convert PCI to use generic config accesses
powerpc: fsl_pci: convert PCI to use generic config accesses
powerpc: powermac: convert PCI to use generic config accesses
pci/host: generic: convert to use generic config accesses
pci/host: rcar-gen2: convert to use generic config accesses
pci/host: tegra: convert to use generic config accesses
pci/host: xgene: convert to use generic config accesses
pci/host: xilinx: convert to use generic config accesses
arch/arm/mach-cns3xxx/pcie.c | 52 ++----
arch/arm/mach-integrator/pci_v3.c | 61 +-------
arch/arm/mach-ks8695/pci.c | 77 +--------
arch/arm/mach-sa1100/pci-nanoengine.c | 94 +----------
arch/frv/mb93090-mb00/pci-vdk.c | 4 +-
arch/mips/pci/pci-bcm1480.c | 4 +-
arch/mips/pci/pci-octeon.c | 4 +-
arch/mips/pci/pcie-octeon.c | 12 +-
arch/mn10300/unit-asb2305/pci.c | 4 +-
arch/powerpc/platforms/cell/celleb_scc_pciex.c | 4 +-
arch/powerpc/platforms/powermac/pci.c | 209 +++++--------------------
arch/powerpc/sysdev/fsl_pci.c | 46 +-----
drivers/pci/access.c | 87 ++++++++++
drivers/pci/host/pci-host-generic.c | 51 +-----
drivers/pci/host/pci-rcar-gen2.c | 51 +-----
drivers/pci/host/pci-tegra.c | 55 +------
drivers/pci/host/pci-xgene.c | 150 ++----------------
drivers/pci/host/pcie-xilinx.c | 88 ++---------
include/linux/pci.h | 11 ++
19 files changed, 212 insertions(+), 852 deletions(-)
--
2.1.0
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox