Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
On 05/31/2013 02:55 AM, David Miller wrote: From: Sebastian Hesselbarthsebastian.hesselba...@gmail.com Date: Wed, 29 May 2013 21:32:42 +0200 For the patches above I suggest to take Patches 1-6 through David Miller's branch, and Patches 7-12 through Jason Cooper's when the former have appeared on mainline linux. The patch set has been based on v3.10-rc3. Patches 1-6 applied to net-next, and patch #1 queued up for -stable. David, thanks for pulling these in. I finally found how to check if a patch already went into -stable. As Jason already said, the mdio patch that #1 fixes did not yet went into -stable. Can you unqueue it? Sorry for the confusion. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote: On 05/30/2013 05:20:34 AM, Kevin Hao wrote: On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote: On 05/21/2013 07:04:58 AM, Kevin Hao wrote: It also seems that we don't support ISA on all the current corenet ds boards. So picking a primary bus seems useless, remove that function too. IIRC that was due to some bugs in the PPC PCI code in the absence of any primary bus. Do you know more about these bugs? Not off the top of my head -- either search the archives or ask Ben. Hi Ben, Could you shed some light on this issue? Do we really has the restriction that we have to pick one bus controller as primary even there is no ISA bus on the board? I did check the current code and found no code has a requirement for this. I also searched the archives and but found nothing useful. :-( Thanks, Kevin fsl_pci_assign_primary() will arbitrarily pick one to be primary if there's no ISA. Have the bugs been fixed? I know there should be some reason that we put the fsl_pci_assign_primary() here. But frankly I am not sure what bugs this workaround try to fix. For these corenet boards picking one to be primary has no effect to the 64bit kernel. And for 32bit kernel, the only effect of this is that isa_io_base is set to the io virtual base of the primary bus. But the isa_io_base only make sense when we do have a isa bus, so that we can access some well-known io ports directly by using outx/inx. But if we don't have isa bus on the board, the value of isa_io_base should make no sense at all. So we really don't need to pick a fake primary bus. Of course I may miss something, correct me if I am wrong. :-) outx/inx can also be used for PCI I/O BARs. -Scott pgpBMV7MhNfBK.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote: On 05/30/2013 05:20:34 AM, Kevin Hao wrote: On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote: On 05/21/2013 07:04:58 AM, Kevin Hao wrote: It also seems that we don't support ISA on all the current corenet ds boards. So picking a primary bus seems useless, remove that function too. IIRC that was due to some bugs in the PPC PCI code in the absence of any primary bus. Do you know more about these bugs? Not off the top of my head -- either search the archives or ask Ben. fsl_pci_assign_primary() will arbitrarily pick one to be primary if there's no ISA. Have the bugs been fixed? I know there should be some reason that we put the fsl_pci_assign_primary() here. But frankly I am not sure what bugs this workaround try to fix. For these corenet boards picking one to be primary has no effect to the 64bit kernel. And for 32bit kernel, the only effect of this is that isa_io_base is set to the io virtual base of the primary bus. But the isa_io_base only make sense when we do have a isa bus, so that we can access some well-known io ports directly by using outx/inx. But if we don't have isa bus on the board, the value of isa_io_base should make no sense at all. So we really don't need to pick a fake primary bus. Of course I may miss something, correct me if I am wrong. :-) outx/inx can also be used for PCI I/O BARs. Yes, I know there is also PIO. But the value of isa_io_base doesn't have any effect for this. Thanks, Kevin -Scott pgpommziflQGU.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc85xx: match with the pci bus address used by u-boot for all p1_p2_rdb_pc boards
On Thu, May 30, 2013 at 01:57:42PM -0500, Scott Wood wrote: On 05/29/2013 10:25:25 PM, Kevin Hao wrote: On Tue, May 28, 2013 at 05:45:56PM -0500, Scott Wood wrote: On 05/16/2013 01:29:45 AM, Kevin Hao wrote: All these boards use the same configuration file p1_p2_rdb_pc.h in u-boot. So they have the same pci bus address set by the u-boot. But in some of these boards the bus address set in dtb don't match the one used by u-boot. And this will trigger a kernel bug in 32bit kernel and cause the pci device malfunction. For example, on a p2020rdb-pc board the u-boot use the 0xa000 as both bus address and cpu address for one pci controller and then assign bus address such as 0xa4000 to some pci device. But in the kernel, the dtb set the bus address to 0xe000 and the cpu address to 0xa000. The kernel assumes mistakenly the assigned bus address 0xa0004000 in pci device is correct and keep it unchanged. This will definitely cause the pci device malfunction. I have made two patches to fix this in the pci subsystem. http://patchwork.ozlabs.org/patch/243702/ http://patchwork.ozlabs.org/patch/243703/ But I still think it makes sense to set these bus address to match with the u-boot. This issue can't be reproduced on 36bit kernel. But I also tweak the 36bit dtb for the above reason. IIRC the reason for using 0xe000 on all PCIe roots is to maximize the memory that is DMA-addressable without involving swiotlb. OK, this sounds reasonable. I can drop the changes for the 36bit dts. But for the 32bit dts, it does cause the kernel hang on my p2020rdb-pca board when the SiI3132 driver probe the on-board pcie to sata controller. I think this issue should apply to all these boards if it has a pci device plugged. So we should fix them ASAP. Is this what your 3.11 patch fixes, Yes, the patch in the pci next tree fix this issue in a more general level. or does it hang even with that? No. Maybe U-Boot should be fixed? Maybe. I have created patch for kernel to detect this kind of mismatch between kernel and bootloader and then try to reassign the bus address automatically. https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/commit/?h=nextid=cf4d1cf5ac5e7d2b886af6ed906ea0dcdc5b6855 So with this patch the kernel should just work even without this patch and the fix for u-boot. But this patch is just queued for 3.11. So I wish we can tweak the 32bit dts to accommodate to the u-boot now so that we can make sure that these boards are at least bootable for 3.10 or previous kernel. Then we can revert this patch for more DMA address space once the pci patch are merged into mainline. Is this a regression, or has it been broken for a while? It seems that the p2020rdb-pc_32b.dts was not bootable since it was first introduced into the mainline kernel. The reason is that the following patch change the method of doing the translation of the bus-resource and resource-bus and then disclose this mismatch between bootloader and kernel. commit 6c5705fec63d83eeb165fe61e34adc92ecc2ce75 Author: Bjorn Helgaas bhelg...@google.com Date: Thu Feb 23 20:19:03 2012 -0700 powerpc/PCI: get rid of device resource fixups Tell the PCI core about host bridge address translation so it can take care of bus-to-resource conversion for us. CC: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Bjorn Helgaas bhelg...@google.com Thanks, Kevin -Scott pgp7KK1sHIC3b.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/mpc85xx: Update the clock device tree nodes
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
---
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 32 -
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 32 -
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 100 +++-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi | 8 +++
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 38 ++-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi | 2 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 54 ++-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi | 4 ++
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 77 -
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 12
16 files changed, 473 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 5a6615d..b69d6e5 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -85,7 +85,37 @@
};
clockgen: global-utilities@e1000 {
- compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0;
+ compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0,
+ fixed-clock;
+ clock-output-names = sysclk;
+ #clock-cells = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll1, pll1-div2, pll1-div4;
+ };
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0;
+ compatible = fsl,core-mux-clock;
+ clocks = pll0 0, pll0 1, pll0 2,
+pll1 0, pll1 1, pll1 2;
+ clock-names = pll0_0, pll0_1, pll0_2,
+ pll1_0, pll1_1, pll1_2;
+ clock-output-names = cmux0;
+ };
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 7b4426e..a11126b 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -62,11 +62,13 @@
cpu0: PowerPC,e6500@0 {
device_type = cpu;
reg = 0 1;
+ clocks = mux0;
next-level-cache = L2;
};
cpu1: PowerPC,e6500@2 {
device_type = cpu;
reg = 2 3;
+ clocks = mux0;
next-level-cache = L2;
};
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index e5cf6c8..507a22d 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -129,7 +129,37 @@
};
clockgen: global-utilities@e1000 {
- compatible = fsl,b4860-clockgen, fsl,qoriq-clockgen-2.0;
+ compatible = fsl,b4860-clockgen, fsl,qoriq-clockgen-2.0,
+ fixed-clock;
+ clock-output-names = sysclk;
+ #clock-cells = 0;
+
+ #address-cells = 1;
+ #size-cells = 0;
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800;
+ compatible = fsl,core-pll-clock;
+ clocks = clockgen;
+ clock-output-names = pll0, pll0-div2, pll0-div4;
+ };
+ pll1: pll1@820 {
+ #clock-cells = 1;
+ reg = 0x820;
+ compatible = fsl,core-pll-clock;
Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com Date: Fri, 31 May 2013 08:28:58 +0200 thanks for pulling these in. I finally found how to check if a patch already went into -stable. As Jason already said, the mdio patch that #1 fixes did not yet went into -stable. Can you unqueue it? Sorry for the confusion. I'll unqueue it, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can't access PCIe card under sbc8548
On Thu, 2013-05-30 at 11:24 -0500, Scott Wood wrote: ioremap() and out_bex/in_bex are not appropriate for PCI I/O regions (and presumably that's what it is, if pci_iomap is calling ioport_map). Big-endian is not appropriate for PCI in any case. The whole point of pci_iomap() appears to be that the driver doesn't need to care whether it's MMIO or PIO, and can use ioread/writeX on the resulting cookie. If PPC is messing this up it's not the driver's fault. We are not messing this up and it should work. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can't access PCIe card under sbc8548
On Thu, 2013-05-30 at 17:40 -0700, wolfking wrote: hi, scott: Thanks for replying! In what specific way does it not work? when I use iowrite8 to write, things seem OK, the codes continue running, when I use ioread8 to read, the console I use freezes. The console stops responding. Why can't it succeed? Is there nothing mapped at 0xfc7fc000? My PCIe card's local bus register is at BAR0+0xC7, so the driver should access 0xfc7fc027 and the following 7 bytes. But When I access the areas: ioread8 just freezes. That looks more like a HW error to me unless you are hitting completely the wrong system addresses. What would be useful would be to add printk's to check what exact physical address pci_iomap ends up using and whether that matches to the iobase_phys of the PCI bridge + the BAR value of the card. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On Fri, 2013-05-31 at 14:41 +0800, Kevin Hao wrote: Hi Ben, Could you shed some light on this issue? Do we really has the restriction that we have to pick one bus controller as primary even there is no ISA bus on the board? I did check the current code and found no code has a requirement for this. I also searched the archives and but found nothing useful. :-( You can just pick the first one as primary... The reason we somewhat need a primary is related to how we handle IO space. We ioremap the IO space of all busses and assign the base of the primary one to a global _IO_BASE. Then any port access is an offset from that which means that non-primary can end up having negative offsets. We fix up all resources, which works fine ... unless drivers do stupid casts and the wrap-around fails. The main reason we did that originally is because we still had a slew of x86 originated HW that would access hard wired IO ports, especially on things like CHRP machines, looking for things like 8259 PIC, legacy kbd controllers, UARTs, etc... at fixed IO port numbers. We still support some of these boxes (though I do wonder how long since somebody last booted a Pegasos) so I'm not quite yet keen on getting rid of that stuff... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl-booke: Rename b4qds.dts - b4qds.dtsi.
This file is a common include for B4860 and B4420 but is not a valid DTS itself:
DTC arch/powerpc/boot/b4qds.dtb
Error: arch/powerpc/boot/dts/b4qds.dts:35.1-2 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/powerpc/boot/b4qds.dtb] Error 1
make: *** [b4qds.dtb] Error 2
I spotted in build tests of device-tree.git, announcement
https://lkml.org/lkml/2013/4/24/209, which builds *.dts. Probably no one would
do this this in real life on linux.git but it still seems worth fixing.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Cc: Shaveta Leekha shav...@freescale.com
Cc: Minghuan Lian minghuan.l...@freescale.com
Cc: Andy Fleming aflem...@freescale.com
Cc: Poonam Aggrwal poonam.aggr...@freescale.com
Cc: Ramneek Mehresh ramneek.mehr...@freescale.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/powerpc/boot/dts/b4420qds.dts |2 +-
arch/powerpc/boot/dts/b4860qds.dts |2 +-
arch/powerpc/boot/dts/b4qds.dts| 169
arch/powerpc/boot/dts/b4qds.dtsi | 169
4 files changed, 171 insertions(+), 171 deletions(-)
delete mode 100644 arch/powerpc/boot/dts/b4qds.dts
create mode 100644 arch/powerpc/boot/dts/b4qds.dtsi
diff --git a/arch/powerpc/boot/dts/b4420qds.dts
b/arch/powerpc/boot/dts/b4420qds.dts
index 923156d..508dbdf 100644
--- a/arch/powerpc/boot/dts/b4420qds.dts
+++ b/arch/powerpc/boot/dts/b4420qds.dts
@@ -33,7 +33,7 @@
*/
/include/ fsl/b4420si-pre.dtsi
-/include/ b4qds.dts
+/include/ b4qds.dtsi
/ {
model = fsl,B4420QDS;
diff --git a/arch/powerpc/boot/dts/b4860qds.dts
b/arch/powerpc/boot/dts/b4860qds.dts
index 78907f3..6bb3707 100644
--- a/arch/powerpc/boot/dts/b4860qds.dts
+++ b/arch/powerpc/boot/dts/b4860qds.dts
@@ -33,7 +33,7 @@
*/
/include/ fsl/b4860si-pre.dtsi
-/include/ b4qds.dts
+/include/ b4qds.dtsi
/ {
model = fsl,B4860QDS;
diff --git a/arch/powerpc/boot/dts/b4qds.dts b/arch/powerpc/boot/dts/b4qds.dts
deleted file mode 100644
index e6d2f8f..000
--- a/arch/powerpc/boot/dts/b4qds.dts
+++ /dev/null
@@ -1,169 +0,0 @@
-/*
- * B4420DS Device Tree Source
- *
- * Copyright 2012 Freescale Semiconductor, Inc.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- * * Neither the name of Freescale Semiconductor nor the
- * names of its contributors may be used to endorse or promote products
- * derived from this software without specific prior written permission.
- *
- *
- * ALTERNATIVELY, this software may be distributed under the terms of the
- * GNU General Public License (GPL) as published by the Free Software
- * Foundation, either version 2 of that License or (at your option) any
- * later version.
- *
- * This software is provided by Freescale Semiconductor as is and any
- * express or implied warranties, including, but not limited to, the implied
- * warranties of merchantability and fitness for a particular purpose are
- * disclaimed. In no event shall Freescale Semiconductor be liable for any
- * direct, indirect, incidental, special, exemplary, or consequential damages
- * (including, but not limited to, procurement of substitute goods or services;
- * loss of use, data, or profits; or business interruption) however caused and
- * on any theory of liability, whether in contract, strict liability, or tort
- * (including negligence or otherwise) arising in any way out of the use of
- * this software, even if advised of the possibility of such damage.
- */
-
-/ {
- model = fsl,B4QDS;
- compatible = fsl,B4QDS;
- #address-cells = 2;
- #size-cells = 2;
- interrupt-parent = mpic;
-
- ifc: localbus@ffe124000 {
- reg = 0xf 0xfe124000 0 0x2000;
- ranges = 0 0 0xf 0xe800 0x0800
- 2 0 0xf 0xff80 0x0001
- 3 0 0xf 0xffdf 0x8000;
-
- nor@0,0 {
- #address-cells = 1;
- #size-cells = 1;
- compatible = cfi-flash;
- reg = 0x0 0x0 0x800;
- bank-width = 2;
- device-width = 1;
- };
-
- nand@2,0 {
- #address-cells = 1;
- #size-cells = 1;
-
DTB build failure due to preproccessing
This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is actually a more general issue: $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost DTC arch/powerpc/boot/virtex440-ml510.dtb Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 make: *** [virtex440-ml510.dtb] Error 2 Line 374 is the IDSEL 0x16... line here: interrupt-map = /* IRQ mapping for pci slots and ALI M1533 ... * management core also isn't used. */ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 Which gets preprocessed into: interrupt-map = # 375 arch/powerpc/boot/dts/virtex440-ml510.dts 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 If I manually remove the # 375 line then that fixes the error (although there is then a subsequent one of the same type). I suppose this is a bug in dtc? It appears to have at least some awareness of these preprocessor line number comments since it manages to report the original source line number. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
On 20 May 2013 10:10, Viresh Kumar viresh.ku...@linaro.org wrote: On 13 May 2013 11:34, Viresh Kumar viresh.ku...@linaro.org wrote: On 22 April 2013 12:19, Viresh Kumar viresh.ku...@linaro.org wrote: On 9 April 2013 14:05, Viresh Kumar viresh.ku...@linaro.org wrote: On 5 April 2013 12:16, Viresh Kumar viresh.ku...@linaro.org wrote: On 4 April 2013 18:24, Viresh Kumar viresh.ku...@linaro.org wrote: This patch moves cpufreq driver of powerpc platform to drivers/cpufreq. Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Olof Johansson o...@lixom.net Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- Compile Tested only. arch/powerpc/platforms/Kconfig | 31 -- arch/powerpc/platforms/pasemi/Makefile | 1 - arch/powerpc/platforms/powermac/Makefile | 2 -- drivers/cpufreq/Kconfig.powerpc| 26 ++ drivers/cpufreq/Makefile | 3 +++ .../cpufreq.c = drivers/cpufreq/pasemi-cpufreq.c | 0 .../cpufreq/pmac32-cpufreq.c | 0 .../cpufreq/pmac64-cpufreq.c | 0 8 files changed, 29 insertions(+), 34 deletions(-) rename arch/powerpc/platforms/pasemi/cpufreq.c = drivers/cpufreq/pasemi-cpufreq.c (100%) rename arch/powerpc/platforms/powermac/cpufreq_32.c = drivers/cpufreq/pmac32-cpufreq.c (100%) rename arch/powerpc/platforms/powermac/cpufreq_64.c = drivers/cpufreq/pmac64-cpufreq.c (100%) Hi Deepthi, Can you help testing this please? Ping!! Ping!! Hi Benjamin, Hope you are back from your vacations. Can you give it a try now? Ping!! Ping!! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Always invalidate tlb on hpte invalidate and update
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
If a hash bucket gets full, we evict a more/less random entry from it.
When we do that we don't invalidate the TLB (hpte_remove) because we assume
the old translation is still technically valid. This implies that when
we are invalidating or updating pte, even if HPTE entry is not valid
we should do a tlb invalidate.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/mm/hash_native_64.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 6a2aead..4c122c3 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -336,11 +336,18 @@ static long native_hpte_updatepp(unsigned long slot,
unsigned long newpp,
hpte_v = hptep-v;
actual_psize = hpte_actual_psize(hptep, psize);
+ /*
+* We need to invalidate the TLB always because hpte_remove doesn't do
+* a tlb invalidate. If a hash bucket gets full, we evict a more/less
+* random entry from it. When we do that we don't invalidate the TLB
+* (hpte_remove) because we assume the old translation is still
+* technically valid.
+*/
if (actual_psize 0) {
- native_unlock_hpte(hptep);
- return -1;
+ actual_psize = psize;
+ ret = -1;
+ goto err_out;
}
- /* Even if we miss, we need to invalidate the TLB */
if (!HPTE_V_COMPARE(hpte_v, want_v)) {
DBG_LOW( - miss\n);
ret = -1;
@@ -350,6 +357,7 @@ static long native_hpte_updatepp(unsigned long slot,
unsigned long newpp,
hptep-r = (hptep-r ~(HPTE_R_PP | HPTE_R_N)) |
(newpp (HPTE_R_PP | HPTE_R_N | HPTE_R_C));
}
+err_out:
native_unlock_hpte(hptep);
/* Ensure it is out of the tlb too. */
@@ -409,7 +417,7 @@ static void native_hpte_updateboltedpp(unsigned long newpp,
unsigned long ea,
hptep = htab_address + slot;
actual_psize = hpte_actual_psize(hptep, psize);
if (actual_psize 0)
- return;
+ actual_psize = psize;
/* Update the HPTE */
hptep-r = (hptep-r ~(HPTE_R_PP | HPTE_R_N)) |
@@ -437,21 +445,27 @@ static void native_hpte_invalidate(unsigned long slot,
unsigned long vpn,
hpte_v = hptep-v;
actual_psize = hpte_actual_psize(hptep, psize);
+ /*
+* We need to invalidate the TLB always because hpte_remove doesn't do
+* a tlb invalidate. If a hash bucket gets full, we evict a more/less
+* random entry from it. When we do that we don't invalidate the TLB
+* (hpte_remove) because we assume the old translation is still
+* technically valid.
+*/
if (actual_psize 0) {
+ actual_psize = psize;
native_unlock_hpte(hptep);
- local_irq_restore(flags);
- return;
+ goto err_out;
}
- /* Even if we miss, we need to invalidate the TLB */
if (!HPTE_V_COMPARE(hpte_v, want_v))
native_unlock_hpte(hptep);
else
/* Invalidate the hpte. NOTE: this also unlocks it */
hptep-v = 0;
+err_out:
/* Invalidate the TLB */
tlbie(vpn, psize, actual_psize, ssize, local);
-
local_irq_restore(flags);
}
--
1.8.1.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [GIT PULL 00/66] perf/core improvements and fixes
* Arnaldo Carvalho de Melo a...@infradead.org wrote: From: Arnaldo Carvalho de Melo a...@ghostprotocols.net Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit c0ffaf3655fab1909a920c8f30ba1722932d01bb: watchdog: Remove softlockup_thresh from Documentation (2013-05-28 11:28:20 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux tags/perf-core-for-mingo for you to fetch changes up to c3c44709b5095091216c06b8df83feddc01ba6b0: perf tools: Add missing liblk.a dependency for python/perf.so (2013-05-30 17:36:16 +0300) perf/core improvements and fixes: . Reset SIGTERM handler in workload child process, fix from David Ahern. . Handle death by SIGTERM in 'perf record', fix from David Ahern. . Fix printing of perf_event_paranoid message, from David Ahern. . Handle realloc failures in 'perf kvm', from David Ahern. . Fix divide by 0 in variance, from David Ahern. . Save parent pid in thread struct, from David Ahern. . Handle JITed code in shared memory, from Andi Kleen. . Makefile reorganization, prep work for Kconfig patches, from Jiri Olsa. . Fixes for 'perf diff', from Jiri Olsa. . Add automated make test suite, from Jiri Olsa. . 'perf tests' fixes from Jiri Olsa. . Remove some unused struct members, from Jiri Olsa. . Add missing liblk.a dependency for python/perf.so, fix from Jiri Olsa. . Respect CROSS_COMPILE in liblk.a, from Rabin Vincent. . Expand definition of sysfs format attribute, from Michael Ellerman. . No need to do locking when adding hists in perf report, only 'top' needs that, from Namhyung Kim. . Sorting improvements, from Namhyung Kim. . Fix alignment of symbol column in in the hists browser (top, report) when -v is given, from NAmhyung Kim. . Add --percent-limit option to 'top' and 'report', from Namhyung Kim. . Fix 'perf top' -E option behavior, from Namhyung Kim. . Fix bug in isupper() and islower(), from Sukadev Bhattiprolu. . Fix compile errors in bp_signal 'perf test', from Sukadev Bhattiprolu. . Make Power7 CPI stack events available in sysfs, from Sukadev Bhattiprolu. Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com Andi Kleen (1): perf tools: Handle JITed code in shared memory Arnaldo Carvalho de Melo (3): perf archive: Fix typo on Documentation perf hists browser: Use sort__has_sym perf test: Fix typo David Ahern (6): perf record: handle death by SIGTERM perf evsel: Fix printing of perf_event_paranoid message perf kvm: Handle realloc failures perf stats: Fix divide by 0 in variance perf tools: Save parent pid in thread struct perf evlist: Reset SIGTERM handler in workload child process Jiri Olsa (32): perf tools: Fix tab vs spaces issue in Makefile ifdef/endif perf diff: Use internal rb tree for hists__precompute perf hists: Rename hist_entry__add_pair arguments perf tools: Add automated make test suite perf tools: Move arch check into config/Makefile perf tools: Move programs check into config/Makefile perf tools: Move compiler and linker flags check into config/Makefile perf tools: Move libelf check config into config/Makefile perf tools: Move libdw check config into config/Makefile perf tools: Move libunwind check config into config/Makefile perf tools: Move libaudit check config into config/Makefile perf tools: Move slang check config into config/Makefile perf tools: Move gtk2 check config into config/Makefile perf tools: Move libperl check config into config/Makefile perf tools: Move libpython check config into config/Makefile perf tools: Move libbfd check config into config/Makefile perf tools: Move stdlib check config into config/Makefile perf tools: Move libnuma check config into config/Makefile perf tools: Move paths config into config/Makefile perf tools: Final touches for CHK config move perf tests: Fix attr test for record -d option perf tests: Fix exclude_guest|exclude_host checking for attr tests perf tools: Remove frozen from perf_header struct perf tools: Remove cwdlen from struct perf_session perf tools: Merge all *CFLAGS* make variable into CFLAGS perf tools: Merge all *LDFLAGS* make variable into LDFLAGS perf tools: Switch to full path C include directories perf tools: Add NO_BIONIC variable to confiure bionic setup perf tools: Replace tabs with spaces for all non-commands statements perf tools: Replace multiple line assignment with multiple statements perf tools: Remove '?=' Makefile STRIP assignment perf tools: Add missing
[PATCH] powerpc/32bit:Store temporary result in r0 instead of r8
While returning from exception handling in case of PREEMPT enabled, _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current task. Only if this bit is set, it should continue with the process of calling preempt_schedule_irq() to schedule highest priority task if available. Current code assumes that r8 contains TI_FLAGS and check this for _TIF_NEED_RESCHED, but as r8 is modified in the code which executes before this check, r8 no longer contains the expected TI_FLAGS information. As a result check for comparison with _TIF_NEED_RESCHED was failing even if NEED_RESCHED bit is set in the current thread_info flag. Due to this, preempt_schedule_irq() and in turn scheduler was not getting called even if highest priority task is ready for execution. So, store temporary results in r0 instead of r8 to prevent r8 from getting modified as subsequent code is dependent on its value. Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- arch/powerpc/kernel/entry_32.S |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index d22e73e..22b45a4 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -849,7 +849,7 @@ resume_kernel: /* check current_thread_info, _TIF_EMULATE_STACK_STORE */ CURRENT_THREAD_INFO(r9, r1) lwz r8,TI_FLAGS(r9) - andis. r8,r8,_TIF_EMULATE_STACK_STORE@h + andis. r0,r8,_TIF_EMULATE_STACK_STORE@h beq+1f addir8,r1,INT_FRAME_SIZE/* Get the kprobed function entry */ -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/32bit:Store temporary result in r0 instead of r8
On Mon, May 27, 2013 at 01:00:17PM +0530, Priyanka Jain wrote: While returning from exception handling in case of PREEMPT enabled, _TIF_NEED_RESCHED bit is checked in TI_FLAGS (thread_info flag) of current task. Only if this bit is set, it should continue with the process of calling preempt_schedule_irq() to schedule highest priority task if available. This is broken since a9c4e541 (powerpc/kprobe: Complete kprobe and migrate exception frame) and this commit joined Linus' tree in v3.7-rc1. Ben, please add Cc: sta...@vger.kernel.org # 3.7+ so it gets into the stable tree. Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell ian.campb...@citrix.com wrote: This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is actually a more general issue: $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost DTC arch/powerpc/boot/virtex440-ml510.dtb Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 make: *** [virtex440-ml510.dtb] Error 2 Line 374 is the IDSEL 0x16... line here: interrupt-map = /* IRQ mapping for pci slots and ALI M1533 ... * management core also isn't used. */ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 Which gets preprocessed into: interrupt-map = # 375 arch/powerpc/boot/dts/virtex440-ml510.dts 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 If I manually remove the # 375 line then that fixes the error (although there is then a subsequent one of the same type). I suppose this is a bug in dtc? It appears to have at least some awareness of these preprocessor line number comments since it manages to report the original source line number. dtc is only able to track line numbers when the native /include/ directive is used. The #include directive doesn't help it. It should be added, but until it is the following patch solves the problem: I've got this patch in my tree. Either Rob or I will push it to Linus in the next few days. g. --- commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37 Author: Grant Likely grant.lik...@linaro.org Date: Fri May 31 12:45:18 2013 +0100 dtc: Suppress cpp linemarker annotations DTC isn't able to parse cpp linemarker annotations, so suppress them in the cpp output by adding the -P flag to the cpp options. Signed-off-by: Grant Likely grant.lik...@linaro.org diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 51bb3de..fc08a2b 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -149,7 +149,7 @@ cpp_flags = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE) \ ld_flags = $(LDFLAGS) $(ldflags-y) -dtc_cpp_flags = -Wp,-MD,$(depfile).pre -nostdinc\ +dtc_cpp_flags = -Wp,-MD,$(depfile).pre -nostdinc -P \ -I$(srctree)/arch/$(SRCARCH)/boot/dts \ -I$(srctree)/arch/$(SRCARCH)/boot/dts/include \ -undef -D__DTS__ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 12/13] ARM: kirkwood: remove redundant DT board files
Arnaud, On Fri, May 31, 2013 at 12:28:56AM +0200, Arnaud Ebalard wrote: Hi, Jason Cooper ja...@lakedaemon.net writes: For instance 6bd98481ab34 (arm: kirkwood: NETGEAR ReadyNAS Duo v2 init PCIe via DT) currently sitting in jcooper/mvebu/pcie_kirkwood removes the PCIE init routine in board-readynas.c, and yours remove ge00 init. With both applied, the whole file can go away. AFAICT, this may be the case soon for: arch/arm/mach-kirkwood/board-iconnect.c (36e5722089) arch/arm/mach-kirkwood/board-mplcec4.c(9470fbfb8d) arch/arm/mach-kirkwood/board-nsa310.c (40fa8e5da2) arch/arm/mach-kirkwood/board-readynas.c (6bd98481ab) arch/arm/mach-kirkwood/board-ts219.c (259e234608) Would you mind putting a patch together (for after v3.10 drops) to do this? If you applied Sebastian's series on top of mvebu/pcie_kirkwood, that should get you almost there. The last half of his series is going in after v3.10... Something like the quick quilt-generated patch at the end of this email (done after a dummy merge of Sebastian's set in mvebu/pcie_kirkwood)? yep. I will take a look at what remains after Sebastian's set hit one of your branch but I guess he will have included most of what is in the patch to help you with the merge. Anyway, at the end here is what DT board files would remain: $ ls -1 arch/arm/mach-kirkwood/board-*.c arch/arm/mach-kirkwood/board-dnskw.c This one seems to just be setting a gpio to enable reboot after power failure. Should be simple to move to DT. arch/arm/mach-kirkwood/board-dt.c We obviously need this one. ;-) arch/arm/mach-kirkwood/board-lsxl.c This is taken care of in mvebu/boards 391a16c ARM: Kirkwood: Convert LSXL to restart-poweroff driver. arch/arm/mach-kirkwood/board-ts219.c Also in mvebu/boards 4350a47 ARM: Kirkwood: Make use of the QNAP Power off driver. Just one question though: the removal of MACH_*_DT in Kconfig removes the automatic selection of useful board specific options like ARM_APPENDED_DTB, ARM_ATAG_DTB_COMPAT, POWER_RESET_RESTART, POWER_RESET_QNAP. Is that expected? I would select POWER_RESET_QNAP and POWER_RESET_RESTART in Kconfig for ARCH_KIRKWOOD_DT, and put ARM_APPENDED_DTB and ARM_ATAG_DTB_COMPAT into the defconfig. thx, Jason. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On Fri, 2013-05-31 at 12:48 +0100, Grant Likely wrote: On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell ian.campb...@citrix.com wrote: This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is actually a more general issue: $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost DTC arch/powerpc/boot/virtex440-ml510.dtb Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 make: *** [virtex440-ml510.dtb] Error 2 Line 374 is the IDSEL 0x16... line here: interrupt-map = /* IRQ mapping for pci slots and ALI M1533 ... * management core also isn't used. */ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 Which gets preprocessed into: interrupt-map = # 375 arch/powerpc/boot/dts/virtex440-ml510.dts 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 If I manually remove the # 375 line then that fixes the error (although there is then a subsequent one of the same type). I suppose this is a bug in dtc? It appears to have at least some awareness of these preprocessor line number comments since it manages to report the original source line number. dtc is only able to track line numbers when the native /include/ directive is used. The #include directive doesn't help it. It should be added, but until it is the following patch solves the problem: I've got this patch in my tree. Either Rob or I will push it to Linus in the next few days. Thanks, I'll do something similar in my device-tree.git tree. Ian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: can't access PCIe card under sbc8548
hi, Herrenschmidt Thanks for replying to this topic! That looks more like a HW error to me unless you are hitting completely the wrong system addresses. The HW is OK. If I plug this card into another ppc board: mpc86641-hpcn, it works fine. What would be useful would be to add printk's to check what exact physical address pci_iomap ends up using and whether that matches to the iobase_phys of the PCI bridge + the BAR value of the card. Would you mind telling me at what position should I add the printk? I can only print pci_iomap's return address which is mentioned in the previous mail, it is 0xfc7fc000. The following is part of the linux boot message: PCI host bridge /pcie@e000a000 ranges: MEM 0xa000..0xafff - 0xa000 IO 0xe280..0xea7f - 0x /pcie@e000a000: PCICSRBAR @ 0xfff0 Is 0xe280 the iobase_phys of the PCI bridge? So any suggestion is appreciated! regards, wolfking. -- View this message in context: http://linuxppc.10917.n7.nabble.com/can-t-access-PCIe-card-under-sbc8548-tp71775p71874.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote:
Line 374 is the IDSEL 0x16... line here:
interrupt-map =
/* IRQ mapping for pci slots and ALI M1533
...
* management core also isn't used.
*/
/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
0x3000 0 0 1 xps_intc_0 3 2
0x3000 0 0 2 xps_intc_0 2 2
0x3000 0 0 3 xps_intc_0 5 2
0x3000 0 0 4 xps_intc_0 4 2
Can you show me the original source without mods here, please?
This is Linux v3.10-rc3 arch/powerpc/boot/dts/virtex440-ml510.dts also
attached.
Or is the ... purely elided comments?
Yes.
Which gets preprocessed into:
interrupt-map =
# 375 arch/powerpc/boot/dts/virtex440-ml510.dts
0x3000 0 0 1 xps_intc_0 3 2
0x3000 0 0 2 xps_intc_0 2 2
0x3000 0 0 3 xps_intc_0 5 2
0x3000 0 0 4 xps_intc_0 4 2
dtc is only able to track line numbers when the native /include/
directive is used. The #include directive doesn't help it. It should be
added, but until it is the following patch solves the problem:
It's supposed to do better than that, I think.
This, from dtc-lexer.l
*^#(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
char *line, *tmp, *fn;
/* skip text before line # */
line = yytext;
while (!isdigit(*line))
line++;
/* skip digits in line # */
tmp = line;
while (!isspace(*tmp))
tmp++;
/* NULL-terminate line # */
*tmp = '\0';
/* start of filename */
fn = strchr(tmp + 1, '') + 1;
/* strip trailing from filename */
tmp = strchr(fn, '');
*tmp = 0;
/* -1 since #line is the number of the next line */
srcpos_set_line(xstrdup(fn), atoi(line) - 1);
}
Hrm. Is this a that's not in the kernel's copy yet problem?
Or did this fail to match the offending '# line file' somehow?
(Like, is that '# 375' really in column 1?)
The # is in the first column.
I've attached the actual file.
Ian.
# 1 arch/powerpc/boot/dts/virtex440-ml510.dts
# 1 built-in
# 1 command-line
# 1 arch/powerpc/boot/dts/virtex440-ml510.dts
# 12 arch/powerpc/boot/dts/virtex440-ml510.dts
/dts-v1/;
/ {
#address-cells = 1;
#size-cells = 1;
compatible = xlnx,ml510-ref-design, xlnx,virtex440;
dcr-parent = ppc440_0;
DDR2_SDRAM_DIMM0: memory@0 {
device_type = memory;
reg = 0x0 0x2000 ;
} ;
alias {
ethernet0 = Hard_Ethernet_MAC;
serial0 = RS232_Uart_1;
} ;
chosen {
bootargs = console=ttyS0 root=/dev/ram;
linux,stdout-path = /plb@0/serial@83e0;
} ;
cpus {
#address-cells = 1;
#cpus = 0x1;
#size-cells = 0;
ppc440_0: cpu@0 {
#address-cells = 1;
#size-cells = 1;
clock-frequency = 3;
compatible = PowerPC,440, ibm,ppc440;
d-cache-line-size = 0x20;
d-cache-size = 0x8000;
dcr-access-method = native;
dcr-controller ;
device_type = cpu;
i-cache-line-size = 0x20;
i-cache-size = 0x8000;
model = PowerPC,440;
reg = 0;
timebase-frequency = 3;
xlnx,apu-control = 0x2000;
xlnx,apu-udi-0 = 0x0;
xlnx,apu-udi-1 = 0x0;
xlnx,apu-udi-10 = 0x0;
xlnx,apu-udi-11 = 0x0;
xlnx,apu-udi-12 = 0x0;
xlnx,apu-udi-13 = 0x0;
xlnx,apu-udi-14 = 0x0;
xlnx,apu-udi-15 = 0x0;
xlnx,apu-udi-2 = 0x0;
xlnx,apu-udi-3 = 0x0;
xlnx,apu-udi-4 = 0x0;
xlnx,apu-udi-5 = 0x0;
xlnx,apu-udi-6 = 0x0;
xlnx,apu-udi-7 = 0x0;
xlnx,apu-udi-8 = 0x0;
xlnx,apu-udi-9 = 0x0;
xlnx,dcr-autolock-enable = 0x1;
xlnx,dcu-rd-ld-cache-plb-prio = 0x0;
xlnx,dcu-rd-noncache-plb-prio = 0x0;
xlnx,dcu-rd-touch-plb-prio = 0x0;
xlnx,dcu-rd-urgent-plb-prio = 0x0;
xlnx,dcu-wr-flush-plb-prio = 0x0;
xlnx,dcu-wr-store-plb-prio = 0x0;
xlnx,dcu-wr-urgent-plb-prio = 0x0;
xlnx,dma0-control = 0x0;
xlnx,dma0-plb-prio = 0x0;
xlnx,dma0-rxchannelctrl = 0x101;
xlnx,dma0-rxirqtimer = 0x3ff;
xlnx,dma0-txchannelctrl = 0x101;
xlnx,dma0-txirqtimer = 0x3ff;
xlnx,dma1-control = 0x0;
xlnx,dma1-plb-prio = 0x0;
xlnx,dma1-rxchannelctrl = 0x101;
xlnx,dma1-rxirqtimer = 0x3ff;
xlnx,dma1-txchannelctrl = 0x101;
xlnx,dma1-txirqtimer = 0x3ff;
xlnx,dma2-control = 0x0;
xlnx,dma2-plb-prio = 0x0;
xlnx,dma2-rxchannelctrl = 0x101;
xlnx,dma2-rxirqtimer = 0x3ff;
xlnx,dma2-txchannelctrl = 0x101;
xlnx,dma2-txirqtimer =
Re: DTB build failure due to preproccessing
On Fri, 2013-05-31 at 08:01 -0500, Jon Loeliger wrote: Hrm. Is this a that's not in the kernel's copy yet problem? BTW I'm using dtc.git 4e76ec796c90d44d417f82d9db2d67cfe575f8ed and not the kernel copy. dtc-lexer.l in my HEAD is identical to the current master (2e3fc7e9b3a4722a5500afaa9faf7874c61b2e6a) according to git diff. Ian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
Line 374 is the IDSEL 0x16... line here:
interrupt-map =
/* IRQ mapping for pci slots and ALI M1533
...
* management core also isn't used.
*/
/* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
0x3000 0 0 1 xps_intc_0 3 2
0x3000 0 0 2 xps_intc_0 2 2
0x3000 0 0 3 xps_intc_0 5 2
0x3000 0 0 4 xps_intc_0 4 2
Can you show me the original source without mods here, please?
Or is the ... purely elided comments?
Which gets preprocessed into:
interrupt-map =
# 375 arch/powerpc/boot/dts/virtex440-ml510.dts
0x3000 0 0 1 xps_intc_0 3 2
0x3000 0 0 2 xps_intc_0 2 2
0x3000 0 0 3 xps_intc_0 5 2
0x3000 0 0 4 xps_intc_0 4 2
dtc is only able to track line numbers when the native /include/
directive is used. The #include directive doesn't help it. It should be
added, but until it is the following patch solves the problem:
It's supposed to do better than that, I think.
This, from dtc-lexer.l
*^#(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
char *line, *tmp, *fn;
/* skip text before line # */
line = yytext;
while (!isdigit(*line))
line++;
/* skip digits in line # */
tmp = line;
while (!isspace(*tmp))
tmp++;
/* NULL-terminate line # */
*tmp = '\0';
/* start of filename */
fn = strchr(tmp + 1, '') + 1;
/* strip trailing from filename */
tmp = strchr(fn, '');
*tmp = 0;
/* -1 since #line is the number of the next line */
srcpos_set_line(xstrdup(fn), atoi(line) - 1);
}
Hrm. Is this a that's not in the kernel's copy yet problem?
Or did this fail to match the offending '# line file' somehow?
(Like, is that '# 375' really in column 1?)
Thanks,
jdl
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On 05/31/2013 05:48 AM, Grant Likely wrote: On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell ian.campb...@citrix.com wrote: This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is actually a more general issue: $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost DTC arch/powerpc/boot/virtex440-ml510.dtb Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 make: *** [virtex440-ml510.dtb] Error 2 Line 374 is the IDSEL 0x16... line here: interrupt-map = /* IRQ mapping for pci slots and ALI M1533 ... * management core also isn't used. */ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 Which gets preprocessed into: interrupt-map = # 375 arch/powerpc/boot/dts/virtex440-ml510.dts 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 If I manually remove the # 375 line then that fixes the error (although there is then a subsequent one of the same type). I suppose this is a bug in dtc? It appears to have at least some awareness of these preprocessor line number comments since it manages to report the original source line number. dtc is only able to track line numbers when the native /include/ directive is used. The #include directive doesn't help it. It should be added, but until it is the following patch solves the problem: I've got this patch in my tree. Either Rob or I will push it to Linus in the next few days. g. --- commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37 Author: Grant Likely grant.lik...@linaro.org Date: Fri May 31 12:45:18 2013 +0100 dtc: Suppress cpp linemarker annotations DTC isn't able to parse cpp linemarker annotations, so suppress them in the cpp output by adding the -P flag to the cpp options. That's not true; it explicitly does have code to parse the line markers. I'll have to investigate why it isn't working in this case. If you apply this patch, then anyone who has switched to #include rther than /include/ will get incorrect line numbers in dtc error messages. Admittedly that's a smaller population right now though. Perhaps we should just do a kernel-wide conversion though. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On Fri, May 31, 2013 at 5:04 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 05/31/2013 05:48 AM, Grant Likely wrote: On Fri, 31 May 2013 11:29:30 +0100, Ian Campbell ian.campb...@citrix.com wrote: This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is actually a more general issue: $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb CC scripts/mod/devicetable-offsets.s GEN scripts/mod/devicetable-offsets.h HOSTCC scripts/mod/file2alias.o HOSTLD scripts/mod/modpost DTC arch/powerpc/boot/virtex440-ml510.dtb Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error FATAL ERROR: Unable to parse input tree make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1 make: *** [virtex440-ml510.dtb] Error 2 Line 374 is the IDSEL 0x16... line here: interrupt-map = /* IRQ mapping for pci slots and ALI M1533 ... * management core also isn't used. */ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */ 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 Which gets preprocessed into: interrupt-map = # 375 arch/powerpc/boot/dts/virtex440-ml510.dts 0x3000 0 0 1 xps_intc_0 3 2 0x3000 0 0 2 xps_intc_0 2 2 0x3000 0 0 3 xps_intc_0 5 2 0x3000 0 0 4 xps_intc_0 4 2 If I manually remove the # 375 line then that fixes the error (although there is then a subsequent one of the same type). I suppose this is a bug in dtc? It appears to have at least some awareness of these preprocessor line number comments since it manages to report the original source line number. dtc is only able to track line numbers when the native /include/ directive is used. The #include directive doesn't help it. It should be added, but until it is the following patch solves the problem: I've got this patch in my tree. Either Rob or I will push it to Linus in the next few days. g. --- commit d01dccdcb3ea8233b09efb9c24db9f057fbd3b37 Author: Grant Likely grant.lik...@linaro.org Date: Fri May 31 12:45:18 2013 +0100 dtc: Suppress cpp linemarker annotations DTC isn't able to parse cpp linemarker annotations, so suppress them in the cpp output by adding the -P flag to the cpp options. That's not true; it explicitly does have code to parse the line markers. I'll have to investigate why it isn't working in this case. If you apply this patch, then anyone who has switched to #include rther than /include/ will get incorrect line numbers in dtc error messages. Admittedly that's a smaller population right now though. Perhaps we should just do a kernel-wide conversion though. My mistake. I tested the wrong thing. I've dropped the patch. g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: DTB build failure due to preproccessing
On 05/31/2013 04:29 AM, Ian Campbell wrote:
This affects arch/powerpc/boot/dts/virtex440-ml510.dts but I think it is
actually a more general issue:
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux- virtex440-ml510.dtb
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTLD scripts/mod/modpost
DTC arch/powerpc/boot/virtex440-ml510.dtb
Error: arch/powerpc/boot/dts/virtex440-ml510.dts:374.6-7 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [arch/powerpc/boot/virtex440-ml510.dtb] Error 1
make: *** [virtex440-ml510.dtb] Error 2
...
interrupt-map =
# 375 arch/powerpc/boot/dts/virtex440-ml510.dts
0x3000 0 0 1 xps_intc_0 3 2
0x3000 0 0 2 xps_intc_0 2 2
0x3000 0 0 3 xps_intc_0 5 2
0x3000 0 0 4 xps_intc_0 4 2
I /think/ what's happening here is that dtc's rule for #line parsing
allows the formats:
# LINE FILENAME
or:
#LINE FILENAME FLAGS
where FLAGS is an integer
The lexer rule that optionally consumes flags requires some WS
(white-space) between the filename and flags. It looks like this
whitespace can actually cross a line boundary, so it ends up consuming
the first 0 of the hex constant on the next line, which then leaves
x3000 to be parsed as cell data, which is a syntax error.
You can hack around this for testing by doing one of a few things:
a) Add an extra integer on to the end of the problematic #line directives.
b) Remove the leading 0x from the constants following the #line
directives. I think this will still mean dtc eats the 3000 as part of
the #line directive, but hides the syntax error.
The solution here is to make dtc's #line matching regex:
*^#(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
... use someting other than {WS} in the final instance; some kind of
{WS} that won't match/cross line boundaries. I'll see if I can cook up a
patch for this.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] dtc: Ensure #line directives don't consume data from the next line
From: Stephen Warren swar...@nvidia.com
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex constant 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming integer 1234 as part of the #line processing, thus removing it
from the cell data).
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
Reported-by: Ian Campbell ian.campb...@citrix.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
This is a patch for dtc upstream, in response to thread DTB build
failure due to preproccessing. If/when it's accepted into dtc, I'll
follow up with a kernel patch that makes the same fix.
dtc-lexer.l |2 +-
tests/line_directives.dts | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 254d5af..a3a4c69 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -71,7 +71,7 @@ static int pop_input_file(void);
push_input_file(name);
}
-*^#(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
+*^#(line)?{WS}+[0-9]+{WS}+{STRING}([ \t]+[0-9]+)? {
char *line, *tmp, *fn;
/* skip text before line # */
line = yytext;
diff --git a/tests/line_directives.dts b/tests/line_directives.dts
index e9d0800..046ef37 100644
--- a/tests/line_directives.dts
+++ b/tests/line_directives.dts
@@ -8,4 +8,14 @@
# 6 bar.dts
/ {
+/*
+ * Make sure optional flags don't consume integer data on next line. The issue
+ * was that the {WS} in the trailing ({WS}+[0-9]+)? could cross the * line-
+ * break, and consume the leading 0 of the hex constant, leaving x12345678
+ * to be parsed as a number, which is invalid syntax.
+ */
+ prop1 =
+# 10 qux.dts
+ 0x12345678
+ ;
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dtc: Ensure #line directives don't consume data from the next line
Stephen Warren swar...@wwwdotorg.org writes:
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
I think the other uses of {WS} shouldn't span lines either.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] dtc: Ensure #line directives don't consume data from the next line
On 05/31/2013 11:38 AM, Andreas Schwab wrote:
Stephen Warren swar...@wwwdotorg.org writes:
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
I think the other uses of {WS} shouldn't span lines either.
That is true, but only the optional occurrence /should/ matter. Any
changes to the other occurrences would only affect malformed #line
directives, whereas changing this one occurrence would also affect
well-formed #line directives, due to the optional nature of the trailing
flags field.
Still, it may be reasonable just to change all the occurrences anyway.
Does anyone have a strong opinion either way?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V2] dtc: ensure #line directives don't consume data from the next line
From: Stephen Warren swar...@nvidia.com
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.
Reported-by: Ian Campbell ian.campb...@citrix.com
Signed-off-by: Stephen Warren swar...@nvidia.com
---
v2: Convert all instances of {WS} in the regex.
This is a patch for dtc upstream, in response to thread DTB build
failure due to preproccessing. If/when it's accepted into dtc, I'll
follow up with a kernel patch that makes the same fix.
---
dtc-lexer.l |2 +-
tests/line_directives.dts | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/dtc-lexer.l b/dtc-lexer.l
index 254d5af..3b41bfc 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -71,7 +71,7 @@ static int pop_input_file(void);
push_input_file(name);
}
-*^#(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
+*^#(line)?[ \t]+[0-9]+[ \t]+{STRING}([ \t]+[0-9]+)? {
char *line, *tmp, *fn;
/* skip text before line # */
line = yytext;
diff --git a/tests/line_directives.dts b/tests/line_directives.dts
index e9d0800..046ef37 100644
--- a/tests/line_directives.dts
+++ b/tests/line_directives.dts
@@ -8,4 +8,14 @@
# 6 bar.dts
/ {
+/*
+ * Make sure optional flags don't consume integer data on next line. The issue
+ * was that the {WS} in the trailing ({WS}+[0-9]+)? could cross the * line-
+ * break, and consume the leading 0 of the hex constant, leaving x12345678
+ * to be parsed as a number, which is invalid syntax.
+ */
+ prop1 =
+# 10 qux.dts
+ 0x12345678
+ ;
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/sysfs: disable hotplug for the boot cpu
On Tue, 2013-05-28 at 15:59 +0800, Zhao Chenhui wrote:
Some features depend on the boot cpu, for instance, hibernate/suspend.
So disable hotplug for the boot cpu.
Don't we have code to move the boot CPU around when that happens ?
Ben.
Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com
---
arch/powerpc/kernel/sysfs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index e68a845..294b1c4e 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -655,8 +655,10 @@ static int __init topology_init(void)
* CPU. For instance, the boot cpu might never be valid
* for hotplugging.
*/
- if (ppc_md.cpu_die)
+ if (ppc_md.cpu_die cpu != boot_cpuid)
c-hotpluggable = 1;
+ else
+ c-hotpluggable = 0;
if (cpu_online(cpu) || c-hotpluggable) {
register_cpu(c, cpu);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.10-rc ppc64 corrupts usermem when swapping
On Fri, 2013-05-31 at 14:45 +0530, Aneesh Kumar K.V wrote: The patch you are running on is what I'll send to Linus for 3.10 (+/- cosmetics). Aneesh second patch is a much larger rework which will be needed for THP but that will wait for 3.11. I'm happy for you to test it but I first want to make sure it's solid with the 3.10 fix :-) BTW. One concern I still have is that Hugh identified the bad commit to be: 7e74c3921ad9610c0b49f28b8fc69f7480505841 powerpc: Fix hpte_decode to use the correct decoding for page sizes. However, you introduce the return on HPTE not found earlier, in b1022fbd293564de91596b8775340cf41ad5214c powerpc: Decode the pte-lp-encoding bits correctly. So while I'm still happy with the current band-aid for 3.10 and am about to send it to Linus, the above *does* seem to indicate that there is also something wrong with the Fix hpte_decode... commit, which might not actually get the page size right... Can you investigate ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here are a few more fixes for powerpc 3.10. It's a bit more than I would have liked this late in the game but I suppose that's what happens with a brand new chip generation coming out. A few regression fixes, some last minute fixes for new P8 features such as transactional memory,... There's also one powerpc KVM patch that I requested that adds two missing functions to our in-kernel interrupt controller support which is itself a new 3.10 feature. These are defined by the base hypervisor specification. We didn't implement them originally because Linux doesn't use them but they are simple and I'm not comfortable having a half-implemented interface in 3.10 and having to deal with versionning etc... later when something starts needing those calls. They cannot be emulated in qemu when using in-kernel interrupt controller (not enough shared state). Cheers, Ben. The following changes since commit 58f8bbd2e39c3732c55698494338ee19a92c53a0: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2013-05-28 10:11:34 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 58a032c3b106adcd2b83b7e631de3b79f238cdd2: powerpc/perf: Add missing SIER support (2013-06-01 08:29:29 +1000) Aneesh Kumar K.V (1): powerpc/mm: Always invalidate tlb on hpte invalidate and update Kevin Hao (2): powerpc/pci: Remove the stale comments of pci_process_bridge_OF_ranges powerpc/pci: Remove the unused variables in pci_process_bridge_OF_ranges Michael Ellerman (2): powerpc/perf: Revert to original NO_SIPR logic powerpc/perf: Add missing SIER support Michael Neuling (7): powerpc/tm: Make room for hypervisor in abort cause codes powerpc/tm: Update cause codes documentation powerpc/tm: Abort on emulation and alignment faults powerpc/tm: Move TM abort cause codes to uapi powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions powerpc/pseries: Kill all prefetch streams on context switch powerpc/pseries: Improve stream generation comments in copypage/user Nishanth Aravamudan (1): powerpc/cputable: Fix oprofile_cpu_type on power8 Paul Mackerras (1): powerpc/kvm/book3s: Add support for H_IPOLL and H_XIRR_X in XICS emulation Priyanka Jain (1): powerpc/32bit:Store temporary result in r0 instead of r8 Srivatsa S. Bhat (1): powerpc/pseries: Always enable CONFIG_HOTPLUG_CPU on PSERIES SMP chenhui zhao (1): powerpc/mpic: Fix irq distribution problem when MPIC_SINGLE_DEST_CPU Documentation/powerpc/transactional_memory.txt | 27 +- arch/powerpc/include/asm/hvcall.h |1 + arch/powerpc/include/asm/ppc_asm.h | 11 arch/powerpc/include/asm/processor.h | 13 ++--- arch/powerpc/include/asm/reg.h | 11 arch/powerpc/include/asm/signal.h |3 ++ arch/powerpc/include/asm/tm.h |2 + arch/powerpc/include/uapi/asm/Kbuild |1 + arch/powerpc/include/uapi/asm/tm.h | 18 +++ arch/powerpc/kernel/cputable.c |4 +- arch/powerpc/kernel/entry_32.S |2 +- arch/powerpc/kernel/entry_64.S |7 +++ arch/powerpc/kernel/pci-common.c | 14 + arch/powerpc/kernel/signal.c | 40 +- arch/powerpc/kernel/signal.h |2 +- arch/powerpc/kernel/signal_32.c| 10 +--- arch/powerpc/kernel/signal_64.c| 23 +++- arch/powerpc/kernel/traps.c| 29 ++ arch/powerpc/kvm/book3s_hv.c |2 + arch/powerpc/kvm/book3s_pr_papr.c |2 + arch/powerpc/kvm/book3s_xics.c | 29 ++ arch/powerpc/lib/copypage_power7.S | 19 --- arch/powerpc/lib/copyuser_power7.S | 12 +++-- arch/powerpc/mm/hash_native_64.c | 30 --- arch/powerpc/perf/core-book3s.c| 67 +++- arch/powerpc/platforms/pseries/Kconfig |2 + arch/powerpc/sysdev/mpic.c |4 +- 27 files changed, 261 insertions(+), 124 deletions(-) create mode 100644 arch/powerpc/include/uapi/asm/tm.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On 05/31/2013 01:43:49 AM, Kevin Hao wrote: On Thu, May 30, 2013 at 01:54:59PM -0500, Scott Wood wrote: On 05/30/2013 05:20:34 AM, Kevin Hao wrote: On Tue, May 28, 2013 at 05:52:09PM -0500, Scott Wood wrote: On 05/21/2013 07:04:58 AM, Kevin Hao wrote: It also seems that we don't support ISA on all the current corenet ds boards. So picking a primary bus seems useless, remove that function too. IIRC that was due to some bugs in the PPC PCI code in the absence of any primary bus. Do you know more about these bugs? Not off the top of my head -- either search the archives or ask Ben. fsl_pci_assign_primary() will arbitrarily pick one to be primary if there's no ISA. Have the bugs been fixed? I know there should be some reason that we put the fsl_pci_assign_primary() here. But frankly I am not sure what bugs this workaround try to fix. For these corenet boards picking one to be primary has no effect to the 64bit kernel. And for 32bit kernel, the only effect of this is that isa_io_base is set to the io virtual base of the primary bus. But the isa_io_base only make sense when we do have a isa bus, so that we can access some well-known io ports directly by using outx/inx. But if we don't have isa bus on the board, the value of isa_io_base should make no sense at all. So we really don't need to pick a fake primary bus. Of course I may miss something, correct me if I am wrong. :-) outx/inx can also be used for PCI I/O BARs. Yes, I know there is also PIO. But the value of isa_io_base doesn't have any effect for this. See this e-mail for some of the issues I was referring to with isa_io_base being zero: https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-June/098586.html Reading it again I'm not so sure that the problem is so much that we need a primary, as that somewhat bad things happen on non-primary buses, such as the possibility of assigning a zero BAR. Some hardware (including QEMU's PCI emulation) cares about this, though most doesn't. We only have one PCI bus under QEMU, so when we started picking an arbitrary bus to be primary, the problem went away because there was only one bus and therefore there was no non-primary bus. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Sat, 2013-06-01 at 09:22 +1000, Benjamin Herrenschmidt wrote: Hi Linus ! Here are a few more fixes for powerpc 3.10. It's a bit more than I would have liked this late in the game but I suppose that's what happens with a brand new chip generation coming out. A few regression fixes, some last minute fixes for new P8 features such as transactional memory,... There's also one powerpc KVM patch that I requested that adds two missing functions to our in-kernel interrupt controller support which is itself a new 3.10 feature. These are defined by the base hypervisor specification. We didn't implement them originally because Linux doesn't use them but they are simple and I'm not comfortable having a half-implemented interface in 3.10 and having to deal with versionning etc... later when something starts needing those calls. They cannot be emulated in qemu when using in-kernel interrupt controller (not enough shared state). Just added a last minute patch to fix a typo introducing a breakage in our cputable for Power7+ processors, sorry about that, but the regression it fixes just hurt me :-) Sorry about that.. Cheers, Ben. The following changes since commit 58f8bbd2e39c3732c55698494338ee19a92c53a0: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2013-05-28 10:11:34 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to badec11b645e21acbc2411d7759e3efa559af443: powerpc/cputable: Fix typo on P7+ cputable entry (2013-06-01 09:30:03 +1000) Aneesh Kumar K.V (1): powerpc/mm: Always invalidate tlb on hpte invalidate and update Kevin Hao (2): powerpc/pci: Remove the stale comments of pci_process_bridge_OF_ranges powerpc/pci: Remove the unused variables in pci_process_bridge_OF_ranges Michael Ellerman (2): powerpc/perf: Revert to original NO_SIPR logic powerpc/perf: Add missing SIER support Michael Neuling (7): powerpc/tm: Make room for hypervisor in abort cause codes powerpc/tm: Update cause codes documentation powerpc/tm: Abort on emulation and alignment faults powerpc/tm: Move TM abort cause codes to uapi powerpc/tm: Fix userspace stack corruption on signal delivery for active transactions powerpc/pseries: Kill all prefetch streams on context switch powerpc/pseries: Improve stream generation comments in copypage/user Nishanth Aravamudan (1): powerpc/cputable: Fix oprofile_cpu_type on power8 Paul Mackerras (1): powerpc/kvm/book3s: Add support for H_IPOLL and H_XIRR_X in XICS emulation Priyanka Jain (1): powerpc/32bit:Store temporary result in r0 instead of r8 Srivatsa S. Bhat (1): powerpc/pseries: Always enable CONFIG_HOTPLUG_CPU on PSERIES SMP Will Schmidt (1): powerpc/cputable: Fix typo on P7+ cputable entry chenhui zhao (1): powerpc/mpic: Fix irq distribution problem when MPIC_SINGLE_DEST_CPU Documentation/powerpc/transactional_memory.txt | 27 +- arch/powerpc/include/asm/hvcall.h |1 + arch/powerpc/include/asm/ppc_asm.h | 11 arch/powerpc/include/asm/processor.h | 13 ++--- arch/powerpc/include/asm/reg.h | 11 arch/powerpc/include/asm/signal.h |3 ++ arch/powerpc/include/asm/tm.h |2 + arch/powerpc/include/uapi/asm/Kbuild |1 + arch/powerpc/include/uapi/asm/tm.h | 18 +++ arch/powerpc/kernel/cputable.c |6 +-- arch/powerpc/kernel/entry_32.S |2 +- arch/powerpc/kernel/entry_64.S |7 +++ arch/powerpc/kernel/pci-common.c | 14 + arch/powerpc/kernel/signal.c | 40 +- arch/powerpc/kernel/signal.h |2 +- arch/powerpc/kernel/signal_32.c| 10 +--- arch/powerpc/kernel/signal_64.c| 23 +++- arch/powerpc/kernel/traps.c| 29 ++ arch/powerpc/kvm/book3s_hv.c |2 + arch/powerpc/kvm/book3s_pr_papr.c |2 + arch/powerpc/kvm/book3s_xics.c | 29 ++ arch/powerpc/lib/copypage_power7.S | 19 --- arch/powerpc/lib/copyuser_power7.S | 12 +++-- arch/powerpc/mm/hash_native_64.c | 30 --- arch/powerpc/perf/core-book3s.c| 67 +++- arch/powerpc/platforms/pseries/Kconfig |2 + arch/powerpc/sysdev/mpic.c |4 +- 27 files changed, 262 insertions(+), 125 deletions(-) create mode 100644 arch/powerpc/include/uapi/asm/tm.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] can: flexcan: remove HAVE_CAN_FLEXCAN Kconfig symbol
On Mon, 2013-05-20 at 18:06 +0200, Marc Kleine-Budde wrote:
On 05/17/2013 11:09 AM, Shawn Guo wrote:
On Fri, May 17, 2013 at 10:59:17AM +0200, Marc Kleine-Budde wrote:
This patch removes the Kconfig symbol HAVE_CAN_FLEXCAN from
arch/{arm,powerpc}
and allowing compilation unconditionally on all arm and powerpc platforms.
This brings a bigger compile time coverage and removes the following
dependency
warning found by Arnd Bergmann:
warning: (SOC_IMX28 SOC_IMX25 SOC_IMX35
IMX_HAVE_PLATFORM_FLEXCAN
SOC_IMX53 SOC_IMX6Q) selects HAVE_CAN_FLEXCAN
which has unmet direct dependencies (NET CAN CAN_DEV)
Cc: Arnd Bergmann a...@arndb.de
Cc: Shawn Guo shawn@linaro.org
Acked-by: Shawn Guo shawn@linaro.org
Thanks.
An Acked-by by the powerpc people would be fine. However, if nobody
doesn't object, I'm sending this patch via linux-can and net-next upstream.
Sorry, missed it, if it's still out there, add my
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/12] dma: various minor clean ups for slave drivers
On Thu, May 30, 2013 at 10:47 AM, Vinod Koul vinod.k...@intel.com wrote: On Mon, May 27, 2013 at 03:14:30PM +0300, Andy Shevchenko wrote: Here is a set of small independent patches that clean up or fix minor things across DMA slave drivers. The series looks fine. I am going to wait a day more and apply, pls speak up if you disagree and ack if you agree Looks ok to me. Reminds we can probably take this one step further and provide a generic implementation for the common case. It's just a bit inconsistent though that some engines will poll the completion handler (try to advance the state of the last completed cookie) whereas others just assume things will be completed asynchronously. -- Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/23] powerpc/eeh: Function to tranverse PCI devices
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
For EEH on PowerNV platform, the PCI devices will be probed to
check if they support EEH functionality. Different from the case
of EEH for pSeries platform, we will probe real PCI device instead
of device tree node for EEH capability on PowerNV platform.
The patch introduces function eeh_pci_dev_traverse() to traverse
PCI devices for the indicated PCI bus from top to bottom.
This seems racy vs. hotplug etc... Any reason you can't use
pci_walk_bus() from drivers/pci/bus.c ?
Cheers,
Ben.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h |3 ++
arch/powerpc/platforms/pseries/eeh_dev.c | 35
++
2 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index e32c3c5..eeaeab6 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -183,6 +183,7 @@ static inline void eeh_unlock(void)
#define EEH_MAX_ALLOWED_FREEZES 5
typedef void *(*eeh_traverse_func)(void *data, void *flag);
+typedef void *(*eeh_pci_traverse_func)(struct pci_dev *dev, void *flag);
int eeh_phb_pe_create(struct pci_controller *phb);
int eeh_add_to_parent_pe(struct eeh_dev *edev);
int eeh_rmv_from_parent_pe(struct eeh_dev *edev, int purge_pe);
@@ -191,6 +192,8 @@ void *eeh_pe_dev_traverse(struct eeh_pe *root,
void eeh_pe_restore_bars(struct eeh_pe *pe);
struct pci_bus *eeh_pe_bus_get(struct eeh_pe *pe);
+void eeh_pci_dev_traverse(struct pci_bus *bus,
+ eeh_pci_traverse_func fn, void *flag);
void *eeh_dev_init(struct device_node *dn, void *data);
void eeh_dev_phb_init_dynamic(struct pci_controller *phb);
int __init eeh_ops_register(struct eeh_ops *ops);
diff --git a/arch/powerpc/platforms/pseries/eeh_dev.c
b/arch/powerpc/platforms/pseries/eeh_dev.c
index 1efa28f..12c445d 100644
--- a/arch/powerpc/platforms/pseries/eeh_dev.c
+++ b/arch/powerpc/platforms/pseries/eeh_dev.c
@@ -41,6 +41,41 @@
#include asm/pci-bridge.h
#include asm/ppc-pci.h
+
+/**
+ * eeh_pci_dev_traverse - Traverse PCI devices for the indicated bus
+ * @bus: PCI bus
+ * @fn: callback function
+ * @flag: extra flag
+ *
+ * The function traverses the PCI devices for the indicated PCI bus
+ * from top to bottom fashion until the supplied callback function
+ * returns non-zero value on the specific PCI device.
+ */
+void eeh_pci_dev_traverse(struct pci_bus *bus,
+ eeh_pci_traverse_func fn, void *flag)
+{
+ struct pci_dev *dev;
+ void *ret;
+
+ if (!bus)
+ return;
+
+ /*
+ * We should make sure the parent devices are scanned
+ * prior to the child devices so that the parent PE
+ * could be created before the child PEs.
+ */
+ list_for_each_entry(dev, bus-devices, bus_list) {
+ ret = fn(dev, flag);
+ if (ret)
+ return;
+
+ if (dev-subordinate)
+ eeh_pci_dev_traverse(dev-subordinate, fn, flag);
+ }
+}
+
/**
* eeh_dev_init - Create EEH device according to OF node
* @dn: device node
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/23] powerpc/eeh: Make eeh_phb_pe_get() public
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
While processing EEH event interrupt from P7IOC, we need function
to retrieve the PE according to the indicated PCI host controller
(struct pci_controller). The patch makes function eeh_phb_pe_get()
public so that other source files can call it for that purpose.
Just to make things clear to me... You always have the concept of a
controller PE ? What does it actually correspond to in terms of HW
setting ? Bus 0 ? Bus 0..255 ? IE, A catch all fallback ?
Cheers,
Ben.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h |1 +
arch/powerpc/platforms/pseries/eeh_pe.c |2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index eeaeab6..4b48178 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -185,6 +185,7 @@ static inline void eeh_unlock(void)
typedef void *(*eeh_traverse_func)(void *data, void *flag);
typedef void *(*eeh_pci_traverse_func)(struct pci_dev *dev, void *flag);
int eeh_phb_pe_create(struct pci_controller *phb);
+struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb);
int eeh_add_to_parent_pe(struct eeh_dev *edev);
int eeh_rmv_from_parent_pe(struct eeh_dev *edev, int purge_pe);
void *eeh_pe_dev_traverse(struct eeh_pe *root,
diff --git a/arch/powerpc/platforms/pseries/eeh_pe.c
b/arch/powerpc/platforms/pseries/eeh_pe.c
index fe43d1a..6e3eb43 100644
--- a/arch/powerpc/platforms/pseries/eeh_pe.c
+++ b/arch/powerpc/platforms/pseries/eeh_pe.c
@@ -95,7 +95,7 @@ int eeh_phb_pe_create(struct pci_controller *phb)
* hierarchy tree is composed of PHB PEs. The function is used
* to retrieve the corresponding PHB PE according to the given PHB.
*/
-static struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
+struct eeh_pe *eeh_phb_pe_get(struct pci_controller *phb)
{
struct eeh_pe *pe;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 08/23] powerpc/eeh: Refactor eeh_reset_pe_once()
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
The patch changes the criteria used to judge if the PE has been
resetted successfully. We needn't the PE status is exactly equal
to the combo: (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE).
The comment above doesn't mean anything :-)
I assume you meant to write we shouldn't check that the
returned PE status is exactly equal to the two flags X and Y,
but instead only check that they are both set.
Cheers,
Ben.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/eeh.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c
b/arch/powerpc/platforms/pseries/eeh.c
index 39d2ea6..ffe34c4 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -527,7 +527,6 @@ static void eeh_reset_pe_once(struct eeh_pe *pe)
* Partitionable Endpoint trumps hot-reset.
*/
eeh_pe_dev_traverse(pe, eeh_set_dev_freset, freset);
-
Unrelated churn
if (freset)
eeh_ops-reset(pe, EEH_RESET_FUNDAMENTAL);
else
@@ -565,6 +564,7 @@ static void eeh_reset_pe_once(struct eeh_pe *pe)
*/
int eeh_reset_pe(struct eeh_pe *pe)
{
+ int flags = (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE);
int i, rc;
/* Take three shots at resetting the bus */
@@ -572,7 +572,7 @@ int eeh_reset_pe(struct eeh_pe *pe)
eeh_reset_pe_once(pe);
rc = eeh_ops-wait_state(pe, PCI_BUS_RESET_WAIT_MSEC);
- if (rc == (EEH_STATE_MMIO_ACTIVE | EEH_STATE_DMA_ACTIVE))
+ if ((rc flags) == flags)
return 0;
if (rc 0) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SATA hang on 8315E triggered by heavy flash write?
Shaohui, greetings -- Xie Shaohui-B21989 b21...@freescale.com writes: I found a MPC8315ERDB rev1.0 board and did some tests. I bet that was fun. :) Thanks for going the extra mile and finding that hardware. Were you able to unearth a 8315DS of any sort? First there is no limit speed issue on the board, so it seems it may only happen on the MPC8315DS board. To be clear, the board we're using does boot and run just fine at 3Gbps most of the time; the CONFIG_MPC8315DS fix was one suggested by our vendor, but even then, I suspect it was basically prophylactic. Or, perhaps, it was conflated with the NOR / SATA issue -- see below. Second, the SATA can work well with NOR write operation on the ERDB board. So the two issues happened to you should be board issues. Very possibly! Our vendor has identified at least one possible error with the wiring / routing on this board, and have suggested a hardware modification. Their fix makes sense, but any hardware modification introduces the risk of breaking one of the few prototype boards. Since we're very close to software delivery, and we have a workaround in hand -- namely, don't write the disk during flash operations -- my team has decided that we'll go with the software workaround until initial delivery. We should be able to do this modification and associated testing in mid-July; at that point, I'll report back with our findings. Thanks again for all your help; you and Scott have been extremely helpful and have provided excellent support. Apologies if it turns out that it was all due to a wiring error. :( Best regards, Anthony Foiani ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 16/23] powerpc/eeh: I/O chip PE reset
On Thu, 2013-05-30 at 16:23 +0800, Gavin Shan wrote:
The patch adds the I/O chip backend to do PE reset. For now, we
focus on PCI bus dependent PE. If PHB PE has been put into error
state, the PHB will take complete reset. Besides, the root bridge
will take fundamental or hot reset accordingly if the indicated
PE locates at the toppest of PCI hierarchy tree. Otherwise, the
upstream p2p bridge will take hot reset.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
.../...
+static s64 ioda_eeh_phb_poll(struct pnv_phb *phb)
+{
+ s64 rc = OPAL_HARDWARE;
+
+ while (1) {
+ rc = opal_pci_poll(phb-opal_id);
+ if (rc = 0)
+ break;
+ }
+
+ return rc;
+}
This is rude. It should at the very least cond_resched, but better,
isn't the firmware supposed to return a positive value to indicate
how long to wait for before calling again ? In that case it should
msleep() ...
+static int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
+{
+ struct pnv_phb *phb = hose-private_data;
+ s64 rc = OPAL_HARDWARE;
+
+ pr_debug(%s: Reset PHB#%x, option=%d\n,
+ __func__, hose-global_number, option);
+
+ /* Issue PHB complete reset request */
+ if (option == EEH_RESET_FUNDAMENTAL ||
+ option == EEH_RESET_HOT)
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PHB_COMPLETE,
+ OPAL_ASSERT_RESET);
+ else if (option == EEH_RESET_DEACTIVATE)
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PHB_COMPLETE,
+ OPAL_DEASSERT_RESET);
+ if (rc 0)
+ goto out;
+
+ /*
+ * Poll state of the PHB until the request is done
+ * successfully.
+ */
+ rc = ioda_eeh_phb_poll(phb);
+out:
+ if (rc != OPAL_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int ioda_eeh_root_reset(struct pci_controller *hose, int option)
+{
+ struct pnv_phb *phb = hose-private_data;
+ s64 rc = OPAL_SUCCESS;
+
+ pr_debug(%s: Reset PHB#%x, option=%d\n,
+ __func__, hose-global_number, option);
+
+ /*
+ * During the reset deassert time, we needn't care
+ * the reset scope because the firmware does nothing
+ * for fundamental or hot reset during deassert phase.
+ */
+ if (option == EEH_RESET_FUNDAMENTAL)
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PCI_FUNDAMENTAL_RESET,
+ OPAL_ASSERT_RESET);
+ else if (option == EEH_RESET_HOT)
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PCI_HOT_RESET,
+ OPAL_ASSERT_RESET);
+ else if (option == EEH_RESET_DEACTIVATE)
+ rc = opal_pci_reset(phb-opal_id,
+ OPAL_PCI_HOT_RESET,
+ OPAL_DEASSERT_RESET);
+ if (rc 0)
+ goto out;
+
+ /* Poll state of the PHB until the request is done */
+ rc = ioda_eeh_phb_poll(phb);
+out:
+ if (rc != OPAL_SUCCESS)
+ return -EIO;
+
+ return 0;
+}
+
+static int ioda_eeh_bridge_reset(struct pci_controller *hose,
+ struct pci_dev *dev, int option)
+{
+ u16 ctrl;
+
+ pr_debug(%s: Reset device %04x:%02x:%02x.%01x with option %d\n,
+ __func__, hose-global_number, dev-bus-number,
+ PCI_SLOT(dev-devfn), PCI_FUNC(dev-devfn), option);
+
+ switch (option) {
+ case EEH_RESET_FUNDAMENTAL:
+ case EEH_RESET_HOT:
+ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ break;
+ case EEH_RESET_DEACTIVATE:
+ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ ctrl = ~PCI_BRIDGE_CTL_BUS_RESET;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ break;
+ }
+
+ return 0;
+}
Is there any minimum delay by spec here ? And is there a delay to
respect after the rest or is that handled at the upper level ?
Also, it looks like nothing here checks if the link is coming back
up below the bridge, at what speed etc... this might be something
to add in the future.
+/**
+ * ioda_eeh_reset - Reset the indicated PE
+ * @pe: EEH PE
+ * @option: reset option
+ *
+ * Do reset on the indicated PE. For PCI bus sensitive PE,
+ * we need to reset the parent p2p bridge. The PHB has to
+ * be reinitialized if the p2p bridge is root bridge. For
+ * PCI device sensitive PE, we will try to reset the device
+ * through FLR. For now, we don't have OPAL APIs to do HARD
+ * reset yet, so all reset would be SOFT (HOT) reset.
+ */
+static int ioda_eeh_reset(struct eeh_pe *pe, int option)
+{
+
Re: [PATCH 18/23] powerpc/eeh: PowerNV EEH backends
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote: The patch adds EEH backends for PowerNV platform. It's notable that part of those EEH backends call to the I/O chip dependent backends. Add a check for my new OPALv3 flag before registering since you rely on a whole bunch of new APIs that the current versions of OPAL don't have. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 22/23] powerpc/eeh: Connect EEH error interrupt handle
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote: The EEH error interrupts should have been exported by firmware through device tree. The OS already installed the interrupt handler (opal_interrupt()) for them. The patch checks if we have any existing EEH errors and wakes the kernel thread up to process that if possible. Instead, please create a new notifier that opal interrupt calls whenever the return even state changes and have PCI register with it. Additionally, we want any caller of opal_poll_events() to instead call a wrapper that will also check for event changes and signal clients. Finally, we need a way to disable/enable that notifying via something like an atomic counter (no need to hard synchronize with pending calls) and use it for something like xmon to avoid calling all over the place when xmon polls for console input via udbg for example. This is a bit of work, I can give you a hand with it next week. Cheers, Ben. Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/opal.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c index 628c564..cca78c9 100644 --- a/arch/powerpc/platforms/powernv/opal.c +++ b/arch/powerpc/platforms/powernv/opal.c @@ -18,6 +18,8 @@ #include linux/slab.h #include asm/opal.h #include asm/firmware.h +#include asm/io.h +#include asm/eeh.h #include powernv.h @@ -296,6 +298,10 @@ static irqreturn_t opal_interrupt(int irq, void *data) uint64_t events; opal_handle_interrupt(virq_to_hw(irq), events); +#ifdef CONFIG_EEH + if (events OPAL_EVENT_PCI_ERROR) + pci_err_event(); +#endif /* XXX TODO: Do something with the events */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 23/23] powerpc/eeh: Add debugfs entry to inject errors
On Thu, 2013-05-30 at 16:24 +0800, Gavin Shan wrote:
The patch intends to add debugfs entry powerpc/EEH/PHBx so that
the administrator can inject EEH errors to specified PCI host
bridge for testing purpose.
Use a better naming for the debugfs files. Something like
eeh_err_inject/pci, to be consistent with the general naming
of PHBs in the system.
However, maybe it would be better to instead having something along
the lines of a directory per PHB with a file in it for error injection ?
That way we can stick more things in there that can become handy for
debugging / diagnostics, such as register dumps etc...
Cheers,
Ben.
Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 36
-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index ec5c524..4cc9db7 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -22,6 +22,7 @@
#include linux/bootmem.h
#include linux/delay.h
+#include linux/debugfs.h
#include linux/init.h
#include linux/io.h
#include linux/irq.h
@@ -43,6 +44,29 @@
#include powernv.h
#include pci.h
+static struct dentry *ioda_eeh_dbgfs = NULL;
+
+static int ioda_eeh_dbgfs_set(void *data, u64 val)
+{
+ struct pci_controller *hose = data;
+ struct pnv_phb *phb = hose-private_data;
+
+ out_be64(phb-regs + 0xD10, val);
+ return 0;
+}
+
+static int ioda_eeh_dbgfs_get(void *data, u64 *val)
+{
+ struct pci_controller *hose = data;
+ struct pnv_phb *phb = hose-private_data;
+
+ *val = in_be64(phb-regs + 0xD10);
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(ioda_eeh_dbgfs_ops, ioda_eeh_dbgfs_get,
+ ioda_eeh_dbgfs_set, 0x%llx\n);
+
/**
* ioda_eeh_post_init - Chip dependent post initialization
* @hose: PCI controller
@@ -54,10 +78,20 @@
static int ioda_eeh_post_init(struct pci_controller *hose)
{
struct pnv_phb *phb = hose-private_data;
+ char name[16];
+
+ /* Create EEH debugfs root if possible */
+ if (!ioda_eeh_dbgfs)
+ ioda_eeh_dbgfs = debugfs_create_dir(EEH,
powerpc_debugfs_root);
/* FIXME: Enable it for PHB3 later */
- if (phb-type == PNV_PHB_IODA1)
+ if (phb-type == PNV_PHB_IODA1) {
+ sprintf(name, PHB%d, hose-global_number);
+ debugfs_create_file(name, 0600, ioda_eeh_dbgfs,
+ hose, ioda_eeh_dbgfs_ops);
+
phb-eeh_enabled = 1;
+ }
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/8] Nvram-to-pstore
On Thu, 2013-04-25 at 15:47 +0530, Aruna Balakrishnaiah wrote: Currently the kernel provides the contents of p-series NVRAM only as a simple stream of bytes via /dev/nvram, which must be interpreted in user space by the nvram command in the powerpc-utils package. This patch set exploits the pstore subsystem to expose each partition in NVRAM as a separate file in /dev/pstore. For instance Oops messages will stored in a file named [dmesg-nvram-2]. We will need the same stuff for powernv. This is not a blocker for this patch series which I'm happy to apply (after I give it another round of review, hopefully today) but I would very much like you to, on top of this, start moving some of the basic pseries partition nvram handling to a generic place, along with your pstore bits, and use it on powernv as well. In fact, this applies to at least all the BookS server platforms... Things that come to mind: - nvram_64.c duplicates generic_nvram.c as far as the user accessors are concerned, it should be possible to get rid of code there. Either the arch or the generic one (*) - The nvram partition management should move to generic. While at it factor in the powermac variant (same stuff, mostly duplicated code) - powernv wants all the goodies that pseries has, as does cell. (*) I wonder about that generic stuff... userspace might want to start doing things like resizing the common partition if not big enough etc... For that we might want to add more specific ioctl's. Is anybody other than us using generic_nvram ? I don't like adding ioctl's like that to a generic driver, maybe we could just make it call into something like arch_nvram_ioctl() and have an empty weak variant instead of the current ifdef game. Cheers, Ben. Changes from v2: - Fix renaming of pstore type ids in nvram.c Changes from v1: - Reduce #ifdefs by and remove forward declarations of pstore callbacks - Handle return value of nvram_write_os_partition - Remove empty pstore callbacks and register pstore only when pstore is configured --- Aruna Balakrishnaiah (8): powerpc/pseries: Remove syslog prefix in uncompressed oops text powerpc/pseries: Add version and timestamp to oops header powerpc/pseries: Introduce generic read function to read nvram-partitions powerpc/pseries: Read/Write oops nvram partition via pstore powerpc/pseries: Read rtas partition via pstore powerpc/pseries: Distinguish between a os-partition and non-os partition powerpc/pseries: Read of-config partition via pstore powerpc/pseries: Read common partition via pstore arch/powerpc/platforms/pseries/nvram.c | 353 +++- fs/pstore/inode.c |9 + include/linux/pstore.h |4 3 files changed, 313 insertions(+), 53 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/8] Nvram-to-pstore
On Sat, 2013-06-01 at 14:40 +1000, Benjamin Herrenschmidt wrote: .../... In fact, this applies to at least all the BookS server platforms... Things that come to mind: - nvram_64.c duplicates generic_nvram.c as far as the user accessors are concerned, it should be possible to get rid of code there. Either the arch or the generic one (*) - The nvram partition management should move to generic. While at it factor in the powermac variant (same stuff, mostly duplicated code) - powernv wants all the goodies that pseries has, as does cell. - It's stupid for userspace to re-implement the whole partition scheme, so let's add ioctl's to lookup partitions by name type. We could turn the whole thing into sysfs instead too which might be better (ie a file per partition). (*) I wonder about that generic stuff... userspace might want to start doing things like resizing the common partition if not big enough etc... For that we might want to add more specific ioctl's. Is anybody other than us using generic_nvram ? I don't like adding ioctl's like that to a generic driver, maybe we could just make it call into something like arch_nvram_ioctl() and have an empty weak variant instead of the current ifdef game. Cheers, Ben. Changes from v2: - Fix renaming of pstore type ids in nvram.c Changes from v1: - Reduce #ifdefs by and remove forward declarations of pstore callbacks - Handle return value of nvram_write_os_partition - Remove empty pstore callbacks and register pstore only when pstore is configured --- Aruna Balakrishnaiah (8): powerpc/pseries: Remove syslog prefix in uncompressed oops text powerpc/pseries: Add version and timestamp to oops header powerpc/pseries: Introduce generic read function to read nvram-partitions powerpc/pseries: Read/Write oops nvram partition via pstore powerpc/pseries: Read rtas partition via pstore powerpc/pseries: Distinguish between a os-partition and non-os partition powerpc/pseries: Read of-config partition via pstore powerpc/pseries: Read common partition via pstore arch/powerpc/platforms/pseries/nvram.c | 353 +++- fs/pstore/inode.c |9 + include/linux/pstore.h |4 3 files changed, 313 insertions(+), 53 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 5/8] powerpc/pseries: Read rtas partition via pstore
On Thu, 2013-04-25 at 15:48 +0530, Aruna Balakrishnaiah wrote:
This patch set exploits the pstore subsystem to read details of rtas partition
in NVRAM to a separate file in /dev/pstore. For instance, rtas details will be
stored in a file named [rtas-nvram-4].
.../...
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 75d0176..d7a8fe9 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -35,6 +35,8 @@ enum pstore_type_id {
PSTORE_TYPE_MCE = 1,
PSTORE_TYPE_CONSOLE = 2,
PSTORE_TYPE_FTRACE = 3,
+ /* PPC64 partition types */
+ PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_UNKNOWN = 255
};
Not sure about that list...
What do you mean by RTAS ? The error logs ? What about our common
partition (firmware settings ?). We should probably at least define
a generic PSTORE_TYPE_FIRMWARE for firmware private stuff...
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 5/8] powerpc/pseries: Read rtas partition via pstore
On Sat, 2013-06-01 at 14:49 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-04-25 at 15:48 +0530, Aruna Balakrishnaiah wrote:
This patch set exploits the pstore subsystem to read details of rtas
partition
in NVRAM to a separate file in /dev/pstore. For instance, rtas details will
be
stored in a file named [rtas-nvram-4].
.../...
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 75d0176..d7a8fe9 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -35,6 +35,8 @@ enum pstore_type_id {
PSTORE_TYPE_MCE = 1,
PSTORE_TYPE_CONSOLE = 2,
PSTORE_TYPE_FTRACE = 3,
+ /* PPC64 partition types */
+ PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_UNKNOWN = 255
};
Not sure about that list...
What do you mean by RTAS ? The error logs ? What about our common
partition (firmware settings ?). We should probably at least define
a generic PSTORE_TYPE_FIRMWARE for firmware private stuff...
Scrap it, I just noticed your next patch doing that,... see comment
there.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 8/8] powerpc/pseries: Read common partition via pstore
On Thu, 2013-04-25 at 15:49 +0530, Aruna Balakrishnaiah wrote:
diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
index 8d4fb65..88cc050 100644
--- a/fs/pstore/inode.c
+++ b/fs/pstore/inode.c
@@ -330,6 +330,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname,
u64 id, int count,
case PSTORE_TYPE_PPC_OF:
sprintf(name, of-%s-%lld, psname, id);
break;
Call this powerpc-ofw-... Does it even contain something we use in Linux
at all ? Last I looked we only used the common one right ? Also it's
format afaik is defined in the CHRP bindings so it's not generic OFW
stuff, hence the powerpc prefix.
+ case PSTORE_TYPE_PPC_COMMON:
+ sprintf(name, common-%s-%lld, psname, id);
+ break;
Same deal, call that powerpc-common
case PSTORE_TYPE_UNKNOWN:
sprintf(name, unknown-%s-%lld, psname, id);
break;
diff --git a/include/linux/pstore.h b/include/linux/pstore.h
index 615dc18..656699f 100644
--- a/include/linux/pstore.h
+++ b/include/linux/pstore.h
@@ -38,6 +38,7 @@ enum pstore_type_id {
/* PPC64 partition types */
PSTORE_TYPE_PPC_RTAS= 4,
PSTORE_TYPE_PPC_OF = 5,
+ PSTORE_TYPE_PPC_COMMON = 6,
PSTORE_TYPE_UNKNOWN = 255
};
Do we expose anything else or keep it hidden ?
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc/pseries: Support compression of oops text via pstore
On Fri, 2013-04-26 at 15:26 +0530, Aruna Balakrishnaiah wrote:
The patch set supports compression of oops messages while writing to NVRAM,
this helps in capturing more of oops data to lnx,oops-log. The pstore file
for oops messages will be in decompressed format making it readable.
In case compression fails, the patch takes care of copying the header added
by pstore and last oops_data_sz bytes of big_oops_buf to NVRAM so that we
have recent oops messages in lnx,oops-log.
In case decompression fails, it will result in absence of oops file but still
have files (in /dev/pstore) for other partitions.
Any reason that isn't handled by pstore itself rather than here ? Ie
make a flag indicating that the partition supports compression and have
pstore do it (so we don't compress everything such as ofw common etc...)
Cheers,
Ben.
Signed-off-by: Aruna Balakrishnaiah ar...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/nvram.c | 132
+---
1 file changed, 118 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/nvram.c
b/arch/powerpc/platforms/pseries/nvram.c
index 0159d74..b5ba5e2 100644
--- a/arch/powerpc/platforms/pseries/nvram.c
+++ b/arch/powerpc/platforms/pseries/nvram.c
@@ -539,6 +539,65 @@ static int zip_oops(size_t text_len)
}
#ifdef CONFIG_PSTORE
+/* Derived from logfs_uncompress */
+int nvram_decompress(void *in, void *out, size_t inlen, size_t outlen)
+{
+ int err, ret;
+
+ ret = -EIO;
+ err = zlib_inflateInit(stream);
+ if (err != Z_OK)
+ goto error;
+
+ stream.next_in = in;
+ stream.avail_in = inlen;
+ stream.total_in = 0;
+ stream.next_out = out;
+ stream.avail_out = outlen;
+ stream.total_out = 0;
+
+ err = zlib_inflate(stream, Z_FINISH);
+ if (err != Z_STREAM_END)
+ goto error;
+
+ err = zlib_inflateEnd(stream);
+ if (err != Z_OK)
+ goto error;
+
+ ret = stream.total_out;
+error:
+ return ret;
+}
+
+static int unzip_oops(char *oops_buf, char *big_buf)
+{
+ struct oops_log_info *oops_hdr = (struct oops_log_info *)oops_buf;
+ u64 timestamp = oops_hdr-timestamp;
+ char *big_oops_data = NULL;
+ char *oops_data_buf = NULL;
+ size_t big_oops_data_sz;
+ int unzipped_len;
+
+ big_oops_data = big_buf + sizeof(struct oops_log_info);
+ big_oops_data_sz = big_oops_buf_sz - sizeof(struct oops_log_info);
+ oops_data_buf = oops_buf + sizeof(struct oops_log_info);
+
+ unzipped_len = nvram_decompress(oops_data_buf, big_oops_data,
+ oops_hdr-report_length,
+ big_oops_data_sz);
+
+ if (unzipped_len 0) {
+ pr_err(nvram: decompression failed; returned %d\n,
+ unzipped_len);
+ return -1;
+ }
+ oops_hdr = (struct oops_log_info *)big_buf;
+ oops_hdr-version = OOPS_HDR_VERSION;
+ oops_hdr-report_length = (u16) unzipped_len;
+ oops_hdr-timestamp = timestamp;
+ return 0;
+}
+
static int nvram_pstore_open(struct pstore_info *psi)
{
/* Reset the iterator to start reading partitions again */
@@ -567,6 +626,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
size_t size, struct pstore_info *psi)
{
int rc;
+ unsigned int err_type = ERR_TYPE_KERNEL_PANIC;
struct oops_log_info *oops_hdr = (struct oops_log_info *) oops_buf;
/* part 1 has the recent messages from printk buffer */
@@ -577,8 +637,31 @@ static int nvram_pstore_write(enum pstore_type_id type,
oops_hdr-version = OOPS_HDR_VERSION;
oops_hdr-report_length = (u16) size;
oops_hdr-timestamp = get_seconds();
+
+ if (big_oops_buf) {
+ rc = zip_oops(size);
+ /*
+ * If compression fails copy recent log messages from
+ * big_oops_buf to oops_data.
+ */
+ if (rc != 0) {
+ int hsize = pstore_get_header_size();
+ size_t diff = size - oops_data_sz + hsize;
+
+ if (size oops_data_sz) {
+ memcpy(oops_data, big_oops_buf, hsize);
+ memcpy(oops_data + hsize, big_oops_buf + diff,
+ oops_data_sz - hsize);
+
+ oops_hdr-report_length = (u16) oops_data_sz;
+ } else
+ memcpy(oops_data, big_oops_buf, size);
+ } else
+ err_type = ERR_TYPE_KERNEL_PANIC_GZ;
+ }
+
rc = nvram_write_os_partition(oops_log_partition, oops_buf,
- (int) (sizeof(*oops_hdr) + size), ERR_TYPE_KERNEL_PANIC,
+ (int) (sizeof(*oops_hdr) + oops_hdr-report_length),
Re: [PATCH v3 0/8] Nvram-to-pstore
Another question... Should the core pstore fail to unlink partitions that don't have an -erase callback ? IE. Why would you let anyone erase the OFW common partition for example ? That means that userspace tools can no longer manipulate it but we certainly don't want to remove it from the nvram itself. That leads to a deeper concern. Looking at how efi-pstore works, it looks like they create a file for each var. This looks like something valuable we could do for something like the common partition since typically it's made of name,value pairs. However, pstore is a flat space, while we have patitions which themselves can be organized in name,value pairs (some at least) I wonder if it's time to introduce pstore directories... Or do we stick to our special tools to interpret/change the name,value pairs ? Also do we want to add an ability to resize partitions ? Possibly based on how much is written to them ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2] dtc: ensure #line directives don't consume data from the next line
On Fri, May 31, 2013 at 12:33:04PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.
Reported-by: Ian Campbell ian.campb...@citrix.com
Signed-off-by: Stephen Warren swar...@nvidia.com
Nice catch.
Acked-by: David Gibson da...@gibson.dropbear.id.au
I'll pull it into my github tree. Jon, please either apply directly
or pull from my tree.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
