* Re: [PATCH 1/3] Powerpc/4xx: Add suspend and idle support
From: Josh Boyer @ 2010-10-08 13:35 UTC (permalink / raw)
To: Victor Gallardo; +Cc: linuxppc-dev
In-Reply-To: <1286478436-9942-1-git-send-email-vgallardo@apm.com>
On Thu, Oct 07, 2010 at 12:07:16PM -0700, Victor Gallardo wrote:
>Add suspend/resume support for all 4xx compatible CPUs.
>See /sys/power/state for available power states configured in.
>
>Add two different idle states (idle-wait and idle-doze)
>controlled via sysfs. Default is idle-wait.
> cat /sys/devices/system/cpu/cpu0/idle
> [wait] doze
>
>To save additional power, use idle-doze.
> echo doze > /sys/devices/system/cpu/cpu0/idle
> cat /sys/devices/system/cpu/cpu0/idle
> wait [doze]
>
>Signed-off-by: Victor Gallardo <vgallardo@apm.com>
>---
> Documentation/powerpc/dts-bindings/4xx/cpm.txt | 43 +++
> arch/powerpc/Kconfig | 13 +-
> arch/powerpc/platforms/44x/Makefile | 5 +-
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/ppc4xx_cpm.c | 339 ++++++++++++++++++++++++
> 5 files changed, 397 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/4xx/cpm.txt
> create mode 100644 arch/powerpc/sysdev/ppc4xx_cpm.c
>
>diff --git a/Documentation/powerpc/dts-bindings/4xx/cpm.txt b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
>new file mode 100644
>index 0000000..9635df8
>--- /dev/null
>+++ b/Documentation/powerpc/dts-bindings/4xx/cpm.txt
>@@ -0,0 +1,43 @@
>+PPC4xx Clock Power Management (CPM) node
>+
>+Required properties:
>+ - compatible : compatible list, currently only "ibm,cpm"
>+ - dcr-access-method : "native"
>+ - dcr-reg : < DCR register range >
>+
>+Optional properties:
>+ - er-offset : All 4xx SoCs with a CPM controller have
>+ one of two different order for the CPM
>+ registers. Some have the CPM registers
>+ in the following order (ER,FR,SR). The
>+ others have them in the following order
>+ (SR,ER,FR). For the second case set
>+ er-offset = <1>.
>+ - unused-units : specifier consist of one cell. For each
>+ bit in the cell, the corresponding bit
>+ in CPM will be set to turn off unused
>+ devices.
>+ - idle-doze : specifier consist of one cell. For each
>+ bit in the cell, the corresponding bit
>+ in CPM will be set to turn off unused
>+ devices. This is usually just CPM[CPU].
>+ - standby : specifier consist of one cell. For each
>+ bit in the cell, the corresponding bit
>+ in CPM will be set on standby and
>+ restored on resume.
>+ - suspend : specifier consist of one cell. For each
>+ bit in the cell, the corresponding bit
>+ in CPM will be set on suspend (mem) and
>+ restored on resume.
So the difference, from what I can tell, between standby and suspend is
really only what devices are turned off. I don't see any code to put
the DRAM into self-refresh mode, etc. If that is the case, perhaps we
could add a bit of description as to the different kinds of devices that
may be disabled in one mode but not the other.
>+
>+Example:
>+ CPM0: cpm {
>+ compatible = "ibm,cpm";
>+ dcr-access-method = "native";
>+ dcr-reg = <0x160 0x003>;
>+ er-offset = <0>;
>+ unused-units = <0x00000100>;
>+ idle-doze = <0x02000000>;
>+ standby = <0xfeff0000>;
>+ standby = <0xfeff791d>;
One of these two should be illustrating suspend.
josh
^ permalink raw reply
* RTC rtc-cmos.c : Fix warning on PowerPC
From: srikanth krishnakar @ 2010-10-08 12:49 UTC (permalink / raw)
To: Linuxppc-dev, linuxppc-dev; +Cc: Linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 218 bytes --]
Hello,
I noticed a compilation warning of RTC for powerpc. Found the fix existing
for MIPS & not for available for PowerPC.
--
"The Good You Do, The Best You GET"
Regards
Srikanth Krishnakar
**********************
[-- Attachment #1.2: Type: text/html, Size: 276 bytes --]
[-- Attachment #2: 0001-RTC-rtc-cmos.c-Fix-warning-on-PowerPC.patch --]
[-- Type: text/x-patch, Size: 1218 bytes --]
From 8435e5876fc3d629406c63b85bff82c25fc4bf75 Mon Sep 17 00:00:00 2001
From: Srikanth Krishnakar <skrishna@mvista.com>
Date: Fri, 8 Oct 2010 18:07:06 +0530
Subject: [PATCH] RTC: rtc-cmos.c: Fix warning on PowerPC
The following warning is seen while compilation of PowerPC kernel:
CC drivers/rtc/rtc-cmos.o
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes
of RTC+NVRAM address space, not 64 bytes.
Fix it by adding defined(__powerpc__).
Signed-off-by: Srikanth Krishnakar <skrishna@mvista.com>
---
drivers/rtc/rtc-cmos.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 5856167..7e6ce62 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -687,7 +687,8 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
#if defined(CONFIG_ATARI)
address_space = 64;
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) \
- || defined(__sparc__) || defined(__mips__)
+ || defined(__sparc__) || defined(__mips__) \
+ || defined(__powerpc__)
address_space = 128;
#else
#warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes.
--
1.6.3.3.333.gdf68
^ permalink raw reply related
* Re: Parsing a bus fault message?
From: David Hagood @ 2010-10-08 11:16 UTC (permalink / raw)
To: tiejun.chen; +Cc: Scott Wood, linuxppc-dev, Ira W. Snyder
In-Reply-To: <4CAEE2EC.2020103@windriver.com>
On Fri, 2010-10-08 at 17:22 +0800, tiejun.chen wrote:
>
> I think it should be allowed to use two LAWs to map different space for PCIe
> since I ever saw more one LAWs are created for different RAM space.
>
> Sorry for this delay response.
>
> -Tiejun
It's my bad, as I'd worked out the problem: the host root complex had to
be forced to rescan the device and enable bus mastering on that side of
things. Once that happened, I could access PCI space.
I should have posted my success.
^ permalink raw reply
* Re: Parsing a bus fault message?
From: tiejun.chen @ 2010-10-08 9:22 UTC (permalink / raw)
To: david.hagood; +Cc: Scott Wood, linuxppc-dev, Ira W. Snyder
In-Reply-To: <af75f13d9ed8beb29470dffe56d295f5.squirrel@localhost>
david.hagood@gmail.com wrote:
>> Scott Wood wrote:
>> I also meet machine check exception if configure LAW improperly for PCI.
>> (i.e.
>> unmatched PCIe controller id.)
>>
>> From you log looks 0xexxxxxxx should be your PCI space. So you can check
>> if that
>> fall into appropriate LAW configuration. Maybe you can post your boot log
>> and
>> error log here.
>
> Using EP8641A machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfa00000)
> Linux version 2.6.26.2-ep1.10 (SRWhite@WIC-102333) (gcc version 4.0.0
> (DENX ELDK 4.1 4.0.0)) #269 SMP PREEMPT Tue Sep 28 15:48:43 CDT 2010
> Found initrd at 0xcfdfa000:0xcffa9663
> Found legacy serial port 0 for /soc8641@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=500000000, speed=0
> Found legacy serial port 1 for /soc8641@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=500000000, speed=0
> CPU maps initialized for 1 thread per core
> (thread shift is 0)
> console [udbg0] enabled
> Entering add_active_range(0, 0, 262144) 0 entries of 256 used
> EP8641A board from Embedded Planet
> Top of RAM: 0x40000000, Total RAM: 0x40000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0 -> 196608
> Normal 196608 -> 196608
> HighMem 196608 -> 262144
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 262144
> On node 0 totalpages: 262144
> DMA zone: 1536 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 195072 pages, LIFO batch:31
> Normal zone: 0 pages used for memmap
> HighMem zone: 512 pages used for memmap
> HighMem zone: 65024 pages, LIFO batch:15
> Movable zone: 0 pages used for memmap
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 260096
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> ip=10.200.120.158:::255.255.0.0::eth0
> mtdparts=physmap-flash.0:0x1300000(linux)ro,0x6bc0000(jffs),-(rsvd)ro
> mpic: Setting up MPIC " MPIC " version 1.2 at e0040000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency = 125.000000 MHz
> time_init: processor frequency = 1500.000000 MHz
> clocksource: timebase mult[2000000] shift[22] registered
> clockevent: decrementer mult[2000] shift[16] cpu[0]
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> High memory: 262144k
> Memory: 1031248k/1048576k available (3064k kernel code, 16476k reserved,
> 84k data, 149k bss, 164k init)
> Calibrating delay loop... 249.85 BogoMIPS (lpj=499712)
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Synchronizing timebase
> Got ack
> score 299, offset 1000
> score 299, offset 500
> score 299, offset 250
> score 299, offset 125
> score 299, offset 62
> score 297, offset 31
> score -299, offset 15
> score 297, offset 23
> score 253, offset 19
> score -299, offset 17
> score -269, offset 18
> Min 18 (score -269), Max 19 (score 253)
> Final offset: 19 (269/300)
> clockevent: decrementer mult[2000] shift[16] cpu[1]
> Brought up 2 CPUs
> net_namespace: 208 bytes
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> checking if image is initramfs...it isn't (no cpio magic); looks like an
> initrd
> Freeing initrd memory: 1725k freed
> setup_kcore: restrict size=3fffffff
> of-fsl-dma e0021300.dma: Probe the Freescale DMA driver for
> fsl,eloplus-dma controller at e0021300...
> of-fsl-dma-channel e0021100.dma-channe: #0 (fsl,eloplus-dma-channel), irq 20
> of-fsl-dma-channel e0021180.dma-channe: #1 (fsl,eloplus-dma-channel), irq 21
> of-fsl-dma-channel e0021200.dma-channe: #2 (fsl,eloplus-dma-channel), irq 22
> of-fsl-dma-channel e0021280.dma-channe: #3 (fsl,eloplus-dma-channel), irq 23
> Setting up RapidIO peer-to-peer network /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Of-device full name /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000
> fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
> 0x0000000020000000.
> fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54
> fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
> fsl-of-rio e00c0000.rapidio: Hardware port width: 4
> fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
> fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> JFFS2 version 2.2. (NAND) � 2001-2006 Red Hat, Inc.
> msgmni has been set to 1507
> io scheduler noop registered (default)
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 28) is a 16550A
> brd: module loaded
> loop: module loaded
> Gianfar MII Bus: probed
> eth0: Gianfar Ethernet Controller Version 1.2, 00:10:ec:01:1a:d3
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.2, 00:10:ec:81:1a:d3
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> eth2: Gianfar Ethernet Controller Version 1.2, 00:10:ec:41:1a:d3
> eth2: Running with NAPI enabled
> eth2: 256/256 RX/TX BD ring size
> eth3: Gianfar Ethernet Controller Version 1.2, 00:10:ec:c1:1a:d3
> eth3: Running with NAPI enabled
> eth3: 256/256 RX/TX BD ring size
> physmap platform flash device: 08000000 at f8000000
> physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> 3 cmdlinepart partitions found on MTD device physmap-flash.0
> Creating 3 MTD partitions on "physmap-flash.0":
> 0x00000000-0x01300000 : "linux"
> 0x01300000-0x07ec0000 : "jffs"
> 0x07ec0000-0x08000000 : "rsvd"
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> IP-Config: Complete:
> device=eth0, addr=10.200.120.158, mask=255.255.0.0, gw=255.255.255.255,
> host=10.200.120.158, domain=, nis-domain=(none),
> bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 164k init
> PHY: e0024520:10 - Link is Up - 100/Full
> RIO: discover master port 0, RIO0 mport
> rionetlink_init: receive handler registration suceeded!!!!
> rionetlink_init: rio_register_driver suceeded!!!!
>
> Besides, in my setup, there are 2 LAWS programmed to point at the PEX: one
> mapping A0000000 to BFFFFFFF to the PEX, and one mapping E2000000 to
> E2FFFFFF. My code directly scans the LAWS and picks the first one it sees
> mapped to the PEX, so it is picking A00000000, and using that. Is there an
> issue with having 2 LAWs mapping the same device to different locations?
>
I think it should be allowed to use two LAWs to map different space for PCIe
since I ever saw more one LAWs are created for different RAM space.
Sorry for this delay response.
-Tiejun
>
> Being unfortunately a man of many hats, I haven't had a lot of time today
> to work on this particular fire. Hopefully in the next couple of days I
> can get some more time to look into it more.
>
> I do thank all of you for the pointers, and I'll look into them.
>
> (BTW: Anybody near Wichita, and want to earn some extra $$$ helping me out?)
>
>
>
^ permalink raw reply
* Re: P1020RDB PCI-E Interrupt problem
From: tiejun.chen @ 2010-10-08 9:10 UTC (permalink / raw)
To: Fabian Bertholm; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikDsENpooCJZe68_WF4sb5qrQpjFN9ZqanUDMRx@mail.gmail.com>
Fabian Bertholm wrote:
> Hi,
>
> I try to run ath9k on a P1020RDB Freescale board.
> I run into the problem similar to the Bug/Patch here:
> http://patchwork.ozlabs.org/patch/52137/
>
> I get irq 16: nobody cared....
Firstly you should check if 'irq 16' is issue from your PCIe device.
>
> I tried to fix the dts file in the same manner but this does not help.
> Currently I am using 2.6.33.7
>
> Any hints? Anybody?
>
Then if so I think it's unnecessary to add any #interrupt-map on dts since MSI
is used as interrupt mode on P1020RDB, not legacy interrupt. So please remove
all #interrupt-map on both pci nodes, then enable CONFIG_PCI_MSI to build/boot
again.
> The modified pci section from my dts:
>
> pci0: pcie@ffe09000 {
> cell-index = <1>;
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0 0xffe09000 0 0x1000>;
> bus-range = <0 255>;
> ranges = <0x2000000 0x0 0xa0000000 0 0xa0000000 0x0 0x20000000
> 0x1000000 0x0 0x00000000 0 0xffc30000 0x0 0x10000>;
> clock-frequency = <33333333>;
> interrupt-parent = <&mpic>;
> interrupts = <16 2>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0x0 0x0 0x1 &mpic 0x4 0x2
> 0000 0x0 0x0 0x2 &mpic 0x5 0x2
> 0000 0x0 0x0 0x3 &mpic 0x6 0x2
> 0000 0x0 0x0 0x4 &mpic 0x7 0x2
I don't know how you generate these interrupt-map. So even you really want to
use legacy interrupt you should make sure your PCIe bus number/device
number/function number, and actual interrupt number. Especially please check
interrupt trigger sense. Sometimes incorrect sense will issue your PCIe to
receive interrupt storm. As a result no interrupt handler deal with this
spurious interrupt like you saw 'irq 16: nobody cared'.
> >;
> pcie@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> #address-cells = <3>;
> device_type = "pci";
> ranges = <0x2000000 0x0 0xa0000000
> 0x2000000 0x0 0xa0000000
> 0x0 0x20000000
>
> 0x1000000 0x0 0x0
> 0x1000000 0x0 0x0
> 0x0 0x100000>;
> };
> };
>
> pci1: pcie@ffe0a000 {
> cell-index = <2>;
> compatible = "fsl,mpc8548-pcie";
> device_type = "pci";
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> reg = <0 0xffe0a000 0 0x1000>;
> bus-range = <0 255>;
> ranges = <0x2000000 0x0 0xc0000000 0 0xc0000000 0x0 0x20000000
> 0x1000000 0x0 0x00000000 0 0xffc20000 0x0 0x10000>;
> clock-frequency = <33333333>;
> interrupt-parent = <&mpic>;
> interrupts = <16 2>;
> interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
> interrupt-map = <
> /* IDSEL 0x0 */
> 0000 0x0 0x0 0x1 &mpic 0x0 0x1
> 0000 0x0 0x0 0x2 &mpic 0x1 0x1
> 0000 0x0 0x0 0x3 &mpic 0x2 0x1
> 0000 0x0 0x0 0x4 &mpic 0x3 0x1
> >;
>
There are two PCIe controller so you also have to make sure which controller
your device exist.
-Tiejun
> pcie@0 {
> reg = <0x0 0x0 0x0 0x0 0x0>;
> #size-cells = <2>;
> #address-cells = <3>;
> device_type = "pci";
> ranges = <0x2000000 0x0 0xc0000000
> 0x2000000 0x0 0xc0000000
> 0x0 0x20000000
>
> 0x1000000 0x0 0x0
> 0x1000000 0x0 0x0
> 0x0 0x100000>;
> };
> };
>
>
> Best Regards,
> Fabian
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: powerpc, fs_enet: scanning PHY after Linux is up
From: Holger brunck @ 2010-10-08 8:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss, hs, Detlev Zundel, netdev
In-Reply-To: <AANLkTi=GkkD_-Vu-NswNedhgVuPaYePOHWa_2ytQgMf_@mail.gmail.com>
Hi Grant,
On 10/06/2010 06:52 PM, Grant Likely wrote:
> On Wed, Oct 6, 2010 at 3:53 AM, Heiko Schocher <hs@denx.de> wrote:
>>>> So, the question is, is there a possibility to solve this problem?
>>>>
>>>> If there is no standard option, what would be with adding a
>>>> "scan_phy" file in
>>>>
>>>> /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40
>>>> (or better destination?)
>>>>
>>>> which with we could rescan a PHY with
>>>> "echo addr > /proc/device-tree/soc\@f0000000/cpm\@119c0/mdio\@10d40/scan_phy"
>>>> (so there is no need for using of_find_node_by_path(), as we should
>>>> have the associated device node here, and can step through the child
>>>> nodes with "for_each_child_of_node(np, child)" and check if reg == addr)
>>>>
>>>> or shouldn;t be at least, if the phy couldn;t be found when opening
>>>> the port, retrigger a scanning, if the phy now is accessible?
>>>
>>> One option would be to still register a phy_device for each phy
>>> described in the device tree, but defer binding a driver to each phy
>>> that doesn't respond. Then at of_phy_find_device() time, if it
>>
>> Maybe I din;t get the trick, but the problem is, that
>> you can;t register a phy_device in drivers/of/of_mdio.c
>> of_mdiobus_register(), if the phy didn;t respond with the
>> phy_id ... and of_phy_find_device() is not (yet) used in fs_enet
>
> I'm suggesting modifying the phy layer so that it is possible to
> register a phy_device that doesn't (yet) respond.
>
yes this sounds reasonable.
>>> matches with a phy_device that isn't bound to a driver yet, then
>>> re-trigger the binding operation. At which point the phy id can be
>>> probed and the correct driver can be chosen. If binding succeeds,
>>> then return the phy_device handle. If not, then fail as it currently
>>> does.
>>
>> Wouldn;t it be good, just if we need a PHY (on calling fs_enet_open)
>> to look if there is one?
>>
>> Something like that (not tested):
>>
>> in drivers/net/fs_enet/fs_enet-main.c in fs_init_phy()
>> called from fs_enet_open():
>>
>> Do first:
>> phydev = of_phy_find_device(fep->fpi->phy_node);
>>
>> Look if there is a driver (phy_dev->drv == NULL ?)
>>
>> If not, call new function
>> of_mdiobus_register_phy(mii_bus, fep->fpi->phy_node)
>> see below patch for it.
>>
>> If this succeeds, all is OK, and we can use this phy,
>> else ethernet not work.
>
> I don't like this approach because it muddies the concept of which
> device is actually responsible for managing the phys on the bus. Is
> it managed by the mdio bus device or the Ethernet device? It also has
> a potential race condition. Whereas triggering a late driver bind
> will be safe.
>
> Alternately, I'd also be okay with a common method to trigger a
> reprobe of a particular phy from userspace, but I fear that would be a
> significantly more complex solution.
>
>>
>> !!just no idea, how to get mii_bus pointer ...
>
> You'd have to get the parent of the phy node, and then loop over all
> the registered mdio busses looking for a bus that uses that node.
>
you say that you don't like the approach to probe the phy again in fs_enet_open,
but currently I don't understand what would be the alternate trigger point to
rescan the mdio bus?
I made a first patch to enhance the phy_device structure and rescan the mdio bus
at time of fs_enet_open (because I didn't see a better trigger point). The
advantage is that we got the mii_bus pointer and the phy addr stored in the
already created phy device structure and is therefore easy to use. See the patch
below for this modifications. Whats currently missing in the patch is to set the
phy_id if the phy was scanned later after phy_device creation. For the mgcoge
board it seems to solve our problem, but maybe I miss something important.
Best regards
Holger Brunck
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index ec2f503..6bc117f 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -775,7 +774,8 @@ static int fs_enet_open(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
int r;
- int err;
+ int err = 0;
+ u32 phy_id = 0;
/* to initialize the fep->cur_rx,... */
/* not doing this, will cause a crash in fs_enet_rx_napi */
@@ -795,13 +795,23 @@ static int fs_enet_open(struct net_device *dev)
return -EINVAL;
}
- err = fs_init_phy(dev);
- if (err) {
+ if (fep->phydev == NULL)
+ err = fs_init_phy(dev);
+
+ if (!err && (fep->phydev->available == false))
+ r = get_phy_id(fep->phydev->bus, fep->phydev->addr, &phy_id);
+
+ if (err || (phy_id == 0xffffffff)) {
free_irq(fep->interrupt, dev);
if (fep->fpi->use_napi)
napi_disable(&fep->napi);
- return err;
+ if (err)
+ return err;
+ else
+ return -EINVAL;
}
+ else
+ fep->phydev->available = true;
phy_start(fep->phydev);
netif_start_queue(dev);
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index adbc0fd..1f443cb 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -173,6 +173,10 @@ struct phy_device* phy_device_create(struct mii_bus *bus,
int addr, int phy_id)
dev->dev.bus = &mdio_bus_type;
dev->irq = bus->irq != NULL ? bus->irq[addr] : PHY_POLL;
dev_set_name(&dev->dev, PHY_ID_FMT, bus->id, addr);
+ if (phy_id == 0xffffffff)
+ dev->available = false;
+ else
+ dev->available = true;
dev->state = PHY_DOWN;
@@ -232,13 +236,11 @@ struct phy_device * get_phy_device(struct mii_bus *bus,
int addr)
int r;
r = get_phy_id(bus, addr, &phy_id);
- if (r)
- return ERR_PTR(r);
/* If the phy_id is mostly Fs, there is no device there */
- if ((phy_id & 0x1fffffff) == 0x1fffffff)
- return NULL;
-
+ if (((phy_id & 0x1fffffff) == 0x1fffffff) || r)
+ phy_id = 0xffffffff;
+ /* create phy even if the phy is currently not available */
dev = phy_device_create(bus, addr, phy_id);
return dev;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 6a7eb40..12dc3e4 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -303,6 +303,9 @@ struct phy_device {
int link_timeout;
+ /* Flag to support delayed availability */
+ bool available;
+
/*
* Interrupt number for this PHY
* -1 means no interrupt
^ permalink raw reply related
* RE: [PATCH v3 2/7] spi/mpc8xxx: refactor the common code for SPI/eSPI controller
From: Hu Mingkai-B21284 @ 2010-10-08 6:37 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <20101001112212.GA17505@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwOyBa
YW5nIFJveS1SNjE5MTENCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAyLzddIHNwaS9tcGM4eHh4
OiByZWZhY3RvciB0aGUgY29tbW9uIGNvZGUgZm9yIFNQSS9lU1BJDQo+IGNvbnRyb2xsZXINCj4g
DQo+IE9uIFRodSwgU2VwIDMwLCAyMDEwIGF0IDA0OjAwOjQxUE0gKzA4MDAsIE1pbmdrYWkgSHUg
d3JvdGU6DQo+IFsuLi5dDQo+ID4gLXN0YXRpYyB2b2lkIG1wYzh4eHhfc3BpX2NoYW5nZV9tb2Rl
KHN0cnVjdCBzcGlfZGV2aWNlICpzcGkpDQo+ID4gK3N0YXRpYyB2b2lkIGZzbF9zcGlfY2hhbmdl
X21vZGUoc3RydWN0IHNwaV9kZXZpY2UgKnNwaSkNCj4gPiAgew0KPiA+ICAJc3RydWN0IG1wYzh4
eHhfc3BpICptc3BpID0gc3BpX21hc3Rlcl9nZXRfZGV2ZGF0YShzcGktPm1hc3Rlcik7DQo+ID4g
IAlzdHJ1Y3Qgc3BpX21wYzh4eHhfY3MgKmNzID0gc3BpLT5jb250cm9sbGVyX3N0YXRlOw0KPiA+
IC0JX19iZTMyIF9faW9tZW0gKm1vZGUgPSAmbXNwaS0+YmFzZS0+bW9kZTsNCj4gPiArCXN0cnVj
dCBmc2xfc3BpX3JlZyAqcmVnX2Jhc2UgPSAoc3RydWN0IGZzbF9zcGlfcmVnICopbXNwaS0+cmVn
X2Jhc2U7DQo+IA0KPiBObyBuZWVkIGZvciB0aGVzZSB0eXBlIGNhc3RzICh0aGUgc2FtZSBpcyBm
b3IgdGhlIHdob2xlIHBhdGNoKS4NCj4gDQoNCkZpeCBpdC4NCg0KVGhhbmtzLA0KTWluZ2thaQ0K
^ permalink raw reply
* RE: [PATCH v3 3/7] eSPI: add eSPI controller support
From: Hu Mingkai-B21284 @ 2010-10-08 6:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, spi-devel-general
In-Reply-To: <20101001112204.GA16783@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVy
IDAxLCAyMDEwIDc6MjIgUE0NCj4gVG86IEh1IE1pbmdrYWktQjIxMjg0DQo+IENjOiBsaW51eHBw
Yy1kZXZAb3psYWJzLm9yZzsgc3BpLWRldmVsLWdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0
OyBsaW51eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwDQo+
IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMy83XSBlU1BJOiBhZGQgZVNQSSBjb250cm9sbGVyIHN1
cHBvcnQNCj4gDQo+IEhlbGxvIE1pbmdrYWksDQo+IA0KPiBUaGVyZSBhcmUgbW9zdGx5IGNvc21l
dGljIGNvbW1lbnRzIGRvd24gYmVsb3cuDQo+IA0KPiA+ICsJCS8qIHNwaW4gdW50aWwgVFggaXMg
ZG9uZSAqLw0KPiA+ICsJCXdoaWxlICgoKGV2ZW50cyA9IG1wYzh4eHhfc3BpX3JlYWRfcmVnKCZy
ZWdfYmFzZS0+ZXZlbnQpKQ0KPiA+ICsJCQkJCSYgU1BJRV9ORikgPT0gMCkNCj4gPiArCQkJY3B1
X3JlbGF4KCk7DQo+IA0KPiBUaGlzIGlzIGRhbmdlcm91cy4gVGhlcmUncyBhIGhhbmR5IHNwaW5f
ZXZlbnRfdGltZW91dCgpIGluIGFzbS9kZWxheS5oLg0KPiANCg0KV2hlbiB0aW1lb3V0LCBjYW4g
SSB1c2UgcmV0dXJuIGluIHRoZSBpbnRlcnJ1cHQgZnVuY3Rpb24gZGlyZWN0bHkgbGlrZSB0aGlz
Pw0KDQppZiAoIShldmVudHMgJiBTUElFX05GKSkgew0KICAgICAgICBpbnQgcmV0Ow0KICAgICAg
ICAvKiBzcGluIHVudGlsIFRYIGlzIGRvbmUgKi8NCiAgICAgICAgcmV0ID0gc3Bpbl9ldmVudF90
aW1lb3V0KCgoZXZlbnRzID0gbXBjOHh4eF9zcGlfcmVhZF9yZWcoDQogICAgICAgICAgICAgICAg
ICAgICAgICAmcmVnX2Jhc2UtPmV2ZW50KSkgJiBTUElFX05GKSA9PSAwLCAxMDAwLCAwKTsNCiAg
ICAgICAgaWYgKCFyZXQpIHsNCiAgICAgICAgICAgICAgICBkZXZfZXJyKG1zcGktPmRldiwgInRp
cmVkIHdhaXRpbmcgZm9yIFNQSUVfTkZcbiIpOw0KICAgICAgICAgICAgICAgIHJldHVybjsNCiAg
ICAgICAgfQ0KfQ0KDQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBjb25zdCBzdHJ1Y3Qgb2Zf
ZGV2aWNlX2lkIG9mX2ZzbF9lc3BpX21hdGNoW10gPSB7DQo+ID4gKwl7IC5jb21wYXRpYmxlID0g
ImZzbCxtcGM4NTM2LWVzcGkiIH0sDQo+ID4gKwl7fQ0KPiA+ICt9Ow0KPiA+ICtNT0RVTEVfREVW
SUNFX1RBQkxFKG9mLCBvZl9mc2xfZXNwaV9tYXRjaCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgc3Ry
dWN0IG9mX3BsYXRmb3JtX2RyaXZlciBmc2xfZXNwaV9kcml2ZXIgPSB7DQo+ID4gKwkuZHJpdmVy
ID0gew0KPiA+ICsJCS5uYW1lID0gImZzbF9lc3BpIiwNCj4gPiArCQkub3duZXIgPSBUSElTX01P
RFVMRSwNCj4gPiArCQkub2ZfbWF0Y2hfdGFibGUgPSBvZl9mc2xfZXNwaV9tYXRjaCwNCj4gPiAr
CX0sDQo+ID4gKwkucHJvYmUJCT0gb2ZfZnNsX2VzcGlfcHJvYmUsDQo+ID4gKwkucmVtb3ZlCQk9
IF9fZGV2ZXhpdF9wKG9mX2ZzbF9lc3BpX3JlbW92ZSksDQo+ID4gK307DQo+ID4gKw0KPiA+ICtz
dGF0aWMgaW50IF9faW5pdCBmc2xfZXNwaV9pbml0KHZvaWQpIHsNCj4gPiArCXJldHVybiBvZl9y
ZWdpc3Rlcl9wbGF0Zm9ybV9kcml2ZXIoJmZzbF9lc3BpX2RyaXZlcik7DQo+ID4gK30NCj4gPiAr
bW9kdWxlX2luaXQoZnNsX2VzcGlfaW5pdCk7DQo+ID4gKw0KPiA+ICtzdGF0aWMgdm9pZCBfX2V4
aXQgZnNsX2VzcGlfZXhpdCh2b2lkKSB7DQo+ID4gKwlvZl91bnJlZ2lzdGVyX3BsYXRmb3JtX2Ry
aXZlcigmZnNsX2VzcGlfZHJpdmVyKTsNCj4gPiArfQ0KPiA+ICttb2R1bGVfZXhpdChmc2xfZXNw
aV9leGl0KTsNCj4gPiArDQo+ID4gK01PRFVMRV9BVVRIT1IoIk1pbmdrYWkgSHUiKTsNCj4gPiAr
TU9EVUxFX0RFU0NSSVBUSU9OKCJFbmhhbmNlZCBGcmVlc2NhbGUgU1BJIERyaXZlciIpOw0KPiAN
Cj4gVGhpcyBzb3VuZHMgbGlrZSB0aGF0IHRoaXMgaXMgYW4gZW5oYW5jZWQgdmVyc2lvbiBvZiB0
aGUgRnJlZXNjYWxlIFNQSSBkcml2ZXIsDQo+IHdoaWNoIGl0IGlzIG5vdC4gOy0pDQo+IA0KDQpJ
IHF1b3RlZCBmcm9tIHRoZSBVTSwgbWF5YmUgdGhlIGVuaGFuY2VtZW50IGlzIHRoZSBjb250cm9s
bGVyIHRha2VzIG92ZXIgdGhlDQpDUyBzaWduYWwgZnJvbSB0aGUgSFcgcG9pbnQgdmlldy4NCg0K
SSBjaGFuZ2VkIGFsbCB0aGUgb3RoZXIgY29kZSBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50cy4N
Cg0KVGhhbmtzLA0KTWluZ2thaQ0KDQo=
^ permalink raw reply
* Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Kumar Gala @ 2010-10-08 6:11 UTC (permalink / raw)
To: Hu Mingkai-B21284
Cc: David Brownell, linuxppc-dev, linux-mtd, spi-devel-general,
Gala Kumar-B11780
In-Reply-To: <73839B4A0818E747864426270AC332C3057F6138@zmy16exm20.fsl.freescale.net>
On Oct 7, 2010, at 9:15 PM, Hu Mingkai-B21284 wrote:
>>>> Yes, I agree with David on this. If large transfers don't work,
>>>> then it is the SPI master driver that is buggy.
>>>=20
>>> By the way, does this fix your problem?
>>>=20
>>> https://patchwork.kernel.org/patch/184752/
>>=20
>> It shouldn't. AFAIK, eSPI is PIO-only controller, and the overrun fix =
is for the
>> DMA mode.
>>=20
>> Thanks,
>>=20
>> p.s. Btw, in patch 3/7, is_dma_mapped argument of fsl_espi_bufs() is =
unneeded.
>>=20
>=20
> Yes, the is_dma_mapped isn't needed, I'll remove it.
>=20
> Thanks,
> Mingkai
I'd be really nice if we could close on this patchset in time for .37 =
acceptance. I'm guessing that cutoff is quickly approaching.
- k=
^ permalink raw reply
* Re: Problem with Infiniband adapter on IBM p550
From: Benjamin Herrenschmidt @ 2010-10-08 5:45 UTC (permalink / raw)
To: Patrick Finnegan; +Cc: paulus, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1286516470.2463.403.camel@pasglop>
> Ok, so from what I can tell, the driver is unhappy because either BAR 0
> hasn't been assigned a memory resource or the size doesn't match what
> the driver expects.
>
Ooops, accidentally sent too quickly...
>From your OF log I see:
reg 00c10000 00000000 00000000 00000000 00000000
03c10010 00000000 00000000 00000000 00100000
43c10018 00000000 00000000 00000000 00800000
43c10020 00000000 00000000 00000000 08000000
assigned-addresses 83c10020 00000000 e8000000 00000000 08000000
Now, I think this is the problem.
The "assigned-addresses" property seems to indicate that the firmware only
assigned BAR 4 and didn't assign anything to the other ones.
I don't know why, but it definitely looks like a firmware bug to me. On those
machines, PCI resource assignment is under hypervisor control and so Linux
cannot re-assign missing resources itself.
I'll see if I can find a FW person to shed some light on this.
Can you provide me (privately maybe) with the FW version on the machine ?
Cheers,
Ben.
^ permalink raw reply
* Re: Problem with Infiniband adapter on IBM p550
From: Benjamin Herrenschmidt @ 2010-10-08 5:41 UTC (permalink / raw)
To: Patrick Finnegan; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <201010072324.33062.pat@computer-refuge.org>
On Thu, 2010-10-07 at 23:24 -0400, Patrick Finnegan wrote:
> I seem to be running into a problem getting a Mellanox Infinihost
> Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
> Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
> help.
>
> I get the following messages in dmesg:
> [ 4.972548] ib_mthca: Mellanox InfiniBand HCA driver v1.0 (April 4,
> 2008)
> [ 4.972564] ib_mthca: Initializing 0000:c1:00.0
> [ 4.972674] ib_mthca 0000:c1:00.0: Missing DCS, aborting.
Ok, so from what I can tell, the driver is unhappy because either BAR 0
hasn't been assigned a memory resource or the size doesn't match what
the driver expects.
Let's see...
> The problem looks the same as a problem I ran into with OpenFirmware on
> a Sun V880, which was fixed with this patch by Dave Miller:
> http://ns3.spinics.net/lists/linux-rdma/msg01779.html
>
> I spent some time looking at the equivalent function on powerpc, but
> didn't a block of code that looked similar.
I don't think we are hitting the same problem. I believe our code in
that area differs enough.
In your lspci, however, I see:
Memory at <unassigned> (64-bit, non-prefetchable)
Memory at <unassigned> (64-bit, prefetchable)
Which doesn't look good...
>From your OF log
> Any suggestions?
>
> I have dmesg, the dev .properties from openfirmware, and lspci -v from
> the machine:
>
> http://ned.rcac.purdue.edu/p550-ib/dmesg
> http://ned.rcac.purdue.edu/p550-ib/ib-of-device
> http://ned.rcac.purdue.edu/p550-ib/lspci-v
>
> Pat
^ permalink raw reply
* Problem with Infiniband adapter on IBM p550
From: Patrick Finnegan @ 2010-10-08 3:24 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
I seem to be running into a problem getting a Mellanox Infinihost
Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
help.
I get the following messages in dmesg:
[ 4.972548] ib_mthca: Mellanox InfiniBand HCA driver v1.0 (April 4,
2008)
[ 4.972564] ib_mthca: Initializing 0000:c1:00.0
[ 4.972674] ib_mthca 0000:c1:00.0: Missing DCS, aborting.
The problem looks the same as a problem I ran into with OpenFirmware on
a Sun V880, which was fixed with this patch by Dave Miller:
http://ns3.spinics.net/lists/linux-rdma/msg01779.html
I spent some time looking at the equivalent function on powerpc, but
didn't a block of code that looked similar.
Any suggestions?
I have dmesg, the dev .properties from openfirmware, and lspci -v from
the machine:
http://ned.rcac.purdue.edu/p550-ib/dmesg
http://ned.rcac.purdue.edu/p550-ib/ib-of-device
http://ned.rcac.purdue.edu/p550-ib/lspci-v
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
^ permalink raw reply
* Problem with Infiniband adapter on IBM p550
From: Patrick Finnegan @ 2010-10-08 2:57 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
I seem to be running into a problem getting a Mellanox Infinihost
Infiniband adapter working on my IBM p550 (a 9113-550). I'm using
Debian squeeze, and tried upgrading to the 2.6.35.7 kernel without any
help.
I get the following messages in dmesg:
[ 4.972548] ib_mthca: Mellanox InfiniBand HCA driver v1.0 (April 4,
2008)
[ 4.972564] ib_mthca: Initializing 0000:c1:00.0
[ 4.972674] ib_mthca 0000:c1:00.0: Missing DCS, aborting.
The problem looks the same as a problem I ran into with OpenFirmware on
a Sun V880, which was fixed with this patch by Dave Miller:
http://ns3.spinics.net/lists/linux-rdma/msg01779.html
I spent some time looking at the equivalent function on powerpc, but
didn't a block of code that looked similar.
Any suggestions?
I have dmesg, the dev .properties from openfirmware, and lspci -v from
the machine:
http://ned.rcac.purdue.edu/p550-ib/dmesg
http://ned.rcac.purdue.edu/p550-ib/ib-of-device
http://ned.rcac.purdue.edu/p550-ib/lspci-v
Pat
--
Purdue University ITaP/Research Systems -- http://www.rcac.purdue.edu
^ permalink raw reply
* RE: [PATCH v3 5/7] mtd: m25p80: add support to parse the SPI flash's partitions
From: Hu Mingkai-B21284 @ 2010-10-08 2:42 UTC (permalink / raw)
To: Grant Likely
Cc: linuxppc-dev, Gala Kumar-B11780, linux-mtd, Zang Roy-R61911,
spi-devel-general
In-Reply-To: <AANLkTi=eBA+i7kCOrEPao1AXofKUjBQokWLXFpgx3WND@mail.gmail.com>
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of =
Grant
> Likely
> Sent: Friday, October 01, 2010 5:35 AM
> To: Hu Mingkai-B21284
> Cc: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; =
linux-
> mtd@lists.infradead.org; Gala Kumar-B11780; Zang Roy-R61911
> Subject: Re: [PATCH v3 5/7] mtd: m25p80: add support to parse the SPI =
flash's
> partitions
>=20
> On Thu, Sep 30, 2010 at 5:00 PM, Mingkai Hu <Mingkai.hu@freescale.com> =
wrote:
> > Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
> > ---
> > v3:
> > =A0- Move the SPI flash partition code to the probe function.
> >
> > =A0drivers/mtd/devices/m25p80.c | =A0 39 =
+++++++++++++++++++++++++++------------
> > =A01 files changed, 27 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c =
b/drivers/mtd/devices/m25p80.c
> > index 6f512b5..47d53c7 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -772,7 +772,7 @@ static const struct spi_device_id *__devinit
> jedec_probe(struct spi_device *spi)
> > =A0static int __devinit m25p_probe(struct spi_device *spi)
> > =A0{
> > =A0 =A0 =A0 =A0const struct spi_device_id =A0 =A0 =A0*id =3D =
spi_get_device_id(spi);
> > - =A0 =A0 =A0 struct flash_platform_data =A0 =A0 =A0*data;
> > + =A0 =A0 =A0 struct flash_platform_data =A0 =A0 =A0data, *pdata;
> > =A0 =A0 =A0 =A0struct m25p =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
*flash;
> > =A0 =A0 =A0 =A0struct flash_info =A0 =A0 =A0 =A0 =A0 =A0 =A0 *info;
> > =A0 =A0 =A0 =A0unsigned =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0i;
> > @@ -782,13 +782,27 @@ static int __devinit m25p_probe(struct =
spi_device *spi)
> > =A0 =A0 =A0 =A0 * a chip ID, try the JEDEC id commands; they'll work =
for most
> > =A0 =A0 =A0 =A0 * newer chips, even if we don't recognize the =
particular chip.
> > =A0 =A0 =A0 =A0 */
> > - =A0 =A0 =A0 data =3D spi->dev.platform_data;
> > - =A0 =A0 =A0 if (data && data->type) {
> > + =A0 =A0 =A0 pdata =3D spi->dev.platform_data;
> > + =A0 =A0 =A0 if (!pdata && spi->dev.of_node) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 int nr_parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct mtd_partition *parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 struct device_node *np =3D =
spi->dev.of_node;
> > +
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 nr_parts =3D =
of_mtd_parse_partitions(&spi->dev, np, &parts);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (nr_parts) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata =3D &data;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 memset(pdata, 0, =
sizeof(*pdata));
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata->parts =3D =
parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 pdata->nr_parts =3D =
nr_parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
> > + =A0 =A0 =A0 }
>=20
> Yes, this is the correct way to go about adding the partitions.
> However, this patch can be made simpler by not renaming 'data' to
> 'pdata' and by moving the above code down to just before the partition
> information is actually used. in the OF case, only the parts and the
> nr_parts values written into data, and those values aren't used until
> the last part of the probe function.
>=20
> Regardless, in principle this patch is correct:
>=20
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>=20
> > +
> > + =A0 =A0 =A0 if (pdata && pdata->type) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0const struct spi_device_id *plat_id;
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0for (i =3D 0; i < =
ARRAY_SIZE(m25p_ids) - 1; i++) {
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0plat_id =3D =
&m25p_ids[i];
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (strcmp(data->type, =
plat_id->name))
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if =
(strcmp(pdata->type, plat_id->name))
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0continue;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> > @@ -796,7 +810,8 @@ static int __devinit m25p_probe(struct =
spi_device *spi)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (i < ARRAY_SIZE(m25p_ids) - 1)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0id =3D plat_id;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_warn(&spi->dev, =
"unrecognized id %s\n", data-
> >type);
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_warn(&spi->dev, =
"unrecognized id %s\n",
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 pdata->type);
> > =A0 =A0 =A0 =A0}
> >
> > =A0 =A0 =A0 =A0info =3D (void *)id->driver_data;
> > @@ -847,8 +862,8 @@ static int __devinit m25p_probe(struct =
spi_device *spi)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0write_sr(flash, 0);
> > =A0 =A0 =A0 =A0}
> >
> > - =A0 =A0 =A0 if (data && data->name)
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 flash->mtd.name =3D data->name;
> > + =A0 =A0 =A0 if (pdata && pdata->name)
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 flash->mtd.name =3D pdata->name;
> > =A0 =A0 =A0 =A0else
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0flash->mtd.name =3D =
dev_name(&spi->dev);
> >
> > @@ -919,9 +934,9 @@ static int __devinit m25p_probe(struct =
spi_device *spi)
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0part_probes, &parts, 0);
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> >
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (nr_parts <=3D 0 && data && =
data->parts) {
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parts =3D data->parts;
> > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nr_parts =3D =
data->nr_parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (nr_parts <=3D 0 && pdata && =
pdata->parts) {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 parts =3D =
pdata->parts;
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nr_parts =3D =
pdata->nr_parts;
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>=20
> As per my comment earlier; since parts and nr_parts isn't needed
> before this point, this block could simply be:
>=20
> if (nr_parts <=3D 0 && data && data->parts) {
> parts =3D data->parts;
> nr_parts =3D data->nr_parts;
> }
> if (nr_parts <=3D 0 && spi->dev.of_node)
> =A0 =A0 =A0 nr_parts =3D of_mtd_parse_partitions(&spi->dev, np, =
&parts);
>=20
> And most of the other changes to this file goes away. Simpler, yes?
>=20
Yes, you're right, I'll fix it. Also thanks for your suggestion and ACK.
Thanks,
Mingkai
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:15 UTC (permalink / raw)
To: Anton Vorontsov, Grant Likely
Cc: David Brownell, linuxppc-dev, Gala Kumar-B11780, linux-mtd,
spi-devel-general
In-Reply-To: <20100930150633.GA13741@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAzMCwgMjAxMCAxMTowNyBQTQ0KPiBUbzogR3JhbnQgTGlrZWx5DQo+IENjOiBEYXZpZCBC
cm93bmVsbDsgbGludXhwcGMtZGV2QG96bGFicy5vcmc7IEh1IE1pbmdrYWktQjIxMjg0OyBsaW51
eC0NCj4gbXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IEdhbGEgS3VtYXItQjExNzgwOyBzcGktZGV2
ZWwtDQo+IGdlbmVyYWxAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IFN1YmplY3Q6IFJlOiBbUEFU
Q0ggdjMgNi83XSBtdGQ6IG0yNXA4MDogYWRkIGEgcmVhZCBmdW5jdGlvbiB0byByZWFkIHBhZ2Ug
YnkNCj4gcGFnZQ0KPiANCj4gT24gVGh1LCBTZXAgMzAsIDIwMTAgYXQgMTE6NDE6NDBQTSArMDkw
MCwgR3JhbnQgTGlrZWx5IHdyb3RlOg0KPiA+IE9uIFRodSwgU2VwIDMwLCAyMDEwIGF0IDExOjE2
IFBNLCBHcmFudCBMaWtlbHkNCj4gPiA8Z3JhbnQubGlrZWx5QHNlY3JldGxhYi5jYT4gd3JvdGU6
DQo+ID4gPiBPbiBUaHUsIFNlcCAzMCwgMjAxMCBhdCA3OjQ2IFBNLCBEYXZpZCBCcm93bmVsbCA8
ZGF2aWQtYkBwYWNiZWxsLm5ldD4gd3JvdGU6DQo+ID4gPj4NCj4gPiA+PiAtLS0gT24gVGh1LCA5
LzMwLzEwLCBNaW5na2FpIEh1IDxNaW5na2FpLmh1QGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPiA+
ID4+DQo+ID4gPj4+IEZyb206IE1pbmdrYWkgSHUgPE1pbmdrYWkuaHVAZnJlZXNjYWxlLmNvbT4N
Cj4gPiA+Pj4gU3ViamVjdDogW1BBVENIIHYzIDYvN10gbXRkOiBtMjVwODA6IGFkZCBhIHJlYWQg
ZnVuY3Rpb24gdG8gcmVhZA0KPiA+ID4+PiBwYWdlIGJ5IHBhZ2UNCj4gPiA+Pg0KPiA+ID4+IE5B
Sy4NCj4gPiA+Pg0KPiA+ID4+IFdlIHdlbnQgb3ZlciB0aGlzIGJlZm9yZS4NCj4gPiA+DQo+ID4g
PiBZZXMsIEkgYWdyZWUgd2l0aCBEYXZpZCBvbiB0aGlzLiDCoElmIGxhcmdlIHRyYW5zZmVycyBk
b24ndCB3b3JrLA0KPiA+ID4gdGhlbiBpdCBpcyB0aGUgU1BJIG1hc3RlciBkcml2ZXIgdGhhdCBp
cyBidWdneS4NCj4gPg0KPiA+IEJ5IHRoZSB3YXksIGRvZXMgdGhpcyBmaXggeW91ciBwcm9ibGVt
Pw0KPiA+DQo+ID4gaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC8xODQ3NTIvDQo+
IA0KPiBJdCBzaG91bGRuJ3QuIEFGQUlLLCBlU1BJIGlzIFBJTy1vbmx5IGNvbnRyb2xsZXIsIGFu
ZCB0aGUgb3ZlcnJ1biBmaXggaXMgZm9yIHRoZQ0KPiBETUEgbW9kZS4NCj4gDQo+IFRoYW5rcywN
Cj4gDQo+IHAucy4gQnR3LCBpbiBwYXRjaCAzLzcsIGlzX2RtYV9tYXBwZWQgYXJndW1lbnQgb2Yg
ZnNsX2VzcGlfYnVmcygpIGlzIHVubmVlZGVkLg0KPiANCg0KWWVzLCB0aGUgaXNfZG1hX21hcHBl
ZCBpc24ndCBuZWVkZWQsIEknbGwgcmVtb3ZlIGl0Lg0KDQpUaGFua3MsDQpNaW5na2FpDQo=
^ permalink raw reply
* RE: [PATCH v3 6/7] mtd: m25p80: add a read function to read page by page
From: Hu Mingkai-B21284 @ 2010-10-08 2:13 UTC (permalink / raw)
To: David Brownell, linuxppc-dev, spi-devel-general, linux-mtd
Cc: Gala Kumar-B11780, Zang Roy-R61911
In-Reply-To: <841976.76219.qm@web180306.mail.gq1.yahoo.com>
> -----Original Message-----
> From: David Brownell [mailto:david-b@pacbell.net]
> Sent: Thursday, September 30, 2010 6:46 PM
> To: linuxppc-dev@ozlabs.org; spi-devel-general@lists.sourceforge.net; =
linux-
> mtd@lists.infradead.org; Hu Mingkai-B21284
> Cc: Gala Kumar-B11780; Zang Roy-R61911; Hu Mingkai-B21284
> Subject: Re: [PATCH v3 6/7] mtd: m25p80: add a read function to read =
page by
> page
>=20
>=20
> --- On Thu, 9/30/10, Mingkai Hu <Mingkai.hu@freescale.com> wrote:
>=20
> > From: Mingkai Hu <Mingkai.hu@freescale.com>
> > Subject: [PATCH v3 6/7] mtd: m25p80: add a read function to read =
page
> > by page
>=20
> NAK.
>=20
> We went over this before.
>=20
> =A0 The bug is in your SPI master controller driver, and the fix there =
involves
> mapping large reads into multiple smaller reads.=A0 (Example, 128K =
read as two
> 64K reads instead of one of 128K.
>=20
> It's *NEVER* appropriate to commit to patching all upper level drivers =
in order
> to work around bugs in lower level ones.=A0 The set of such upper =
level drivers
> that may need bugfixing is quite large, most will never be used with =
your buggy
> controller driver, and all such patches will need testing (but the =
test
> resources are probably not available).
>=20
> Whatever SPI controller driver you're working with is clearly buggy =
... but not
> unfixably so.
>=20
> DO NOT head down the path of requiring every SPI device driver to =
include
> workarounds for this odd little SPI master driver bug.
>=20
> - Dave
>=20
Thanks for your comments, the controller driver is the proper place to =
handle this, I'll fix it.
Thanks,
Mingkai
^ permalink raw reply
* Re: in_atomic() check in page_cache_get_speculative()
From: Benjamin Herrenschmidt @ 2010-10-08 1:31 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Nick Piggin
In-Reply-To: <20101004153753.2cda1abf@udp111988uds.am.freescale.net>
On Mon, 2010-10-04 at 15:37 -0500, Scott Wood wrote:
> [Updated with Nick's current address; previous one bounced]
>
> On Mon, 4 Oct 2010 15:22:59 -0500
> Scott Wood <scottwood@freescale.com> wrote:
>
> > I'm seeing the in_atomic() check in page_cache_get_speculative()
> > (linux/pagemap.h:138) fail when running e500 KVM with .
>
> Sorry, that should finish as "with CONFIG_DEBUG_VM."
>
> > It's coming
> > from get_user_pages_fast(), from KVM's hva_to_pfn(). This is on kvm.git
> > plus a few local patches that should be completely unrelated, but it
> > looks like this code hasn't changed much in a couple years.
> >
> > Interrupts are disabled by get_user_pages_fast(), but apparently
> > preemption was not separately disabled. The comment in
> > page_cache_get_speculative() says that preemption disabling is done by
> > rcu_read_lock(), and that "this function must be called inside the same
> > rcu_read_lock() section as has been used to lookup the page in the
> > pagecache radix-tree (or page table)".
> >
> > Where is this RCU lock supposed to be acquired? I don't see any RCU in
> > arch/powerpc/mm/gup.c. Is it buried in some macro or function call?
> >
Well, we shouldn't need the rcu lock if interrupts are off, at least
that's my understanding...
Cheers,
Ben.
^ permalink raw reply
* Re: advice on reading a call trace
From: Benjamin Herrenschmidt @ 2010-10-08 1:29 UTC (permalink / raw)
To: Jean-Mickael Guerin; +Cc: linuxppc-dev
In-Reply-To: <4CAAB5F4.9030002@6wind.com>
On Tue, 2010-10-05 at 07:21 +0200, Jean-Mickael Guerin wrote:
> SLUB is turned on, and the oops does not seem to happen when SLAB replaces SLUB.
> I just got lucky with SLAB, or does it sound familiar on ppc?
Nope, they should both work fine. Try enabling SLAB_DEBUG or SLUB_DEBUG
maybe ? You might be having some memory corruption (bad driver ?)
Cheers,
Ben.
> Regards,
> Jean-Mickael
>
> On 10/4/2010 1:24 PM, Jean-Mickael Guerin wrote:
> > Hello,
> > I'm stepping into ppc world and I'd like to know how to read this call trace,
> > I enabled debug options but I'm not able to track the origin of this bug, I mean
> > what happens before handle_page_fault():
> >
> > Unable to handle kernel paging request for data at address 0x00000008
> > Faulting instruction address: 0xc00abcd8
> >
> > [c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
> > [c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
> > [c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
> > [c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
> > Instruction dump:
> > 80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
> > 387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
> > Kernel panic - not syncing: Fatal exception
> >
> > Another one:
> > NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
> > REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
> > MSR: 10029002 CR: 24004442 XER: 00000000
> > DEAR: 00000008, ESR: 00000000
> > TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
> > GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
> > GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
> > GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
> > GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
> > NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
> > LR [c00b6978] valid_swaphandles+0x194/0x1d0
> > Call Trace:
> > [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
> > [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> > [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> > [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> > [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> > Instruction dump:
> > 38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
> > 7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
> > Kernel panic - not syncing: Fatal exception
> > Call Trace:
> > [d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
> > [d6a9dbd0] [c053b780] panic+0x94/0x118
> > [d6a9dc20] [c000d630] die+0x15c/0x1bc
> > [d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
> > [d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
> > [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
> > [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> > [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> > [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> > [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> > Rebooting in 5 seconds..
> >
> > Thanks,
> > Jean-Mickael
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: advice on reading a call trace
From: Benjamin Herrenschmidt @ 2010-10-08 1:28 UTC (permalink / raw)
To: Jean-Mickael Guerin; +Cc: linuxppc-dev
In-Reply-To: <4CA9B967.9060907@6wind.com>
On Mon, 2010-10-04 at 13:24 +0200, Jean-Mickael Guerin wrote:
> Hello,
> I'm stepping into ppc world and I'd like to know how to read this call trace,
> I enabled debug options but I'm not able to track the origin of this bug, I mean
> what happens before handle_page_fault():
>
> Unable to handle kernel paging request for data at address 0x00000008
That's a NULL dereference
> Faulting instruction address: 0xc00abcd8
>
> [c1d0dd40] [c00ab2e4] swapin_readahead+0x34/0xbc
> [c1d0dd80] [c009e91c] handle_mm_fault+0x724/0x9b0
> [c1d0dde0] [c0014e10] do_page_fault+0x2e8/0x55c
> [c1d0df40] [c000fc8c] handle_page_fault+0xc/0x80
I suspect it's userspace before handle_page_fault(). It died with a NULL
deref in the swap code (which is strange... which kernel is this ? Do
you have out of tree patches applied ?)
Cheers,
Ben.
> Instruction dump:
> 80010034 7d435378 bb210014 38210030 7c0803a6 4e800020 7d695b78 4bffff00
> 387a007c 4847616d 38000001 7c00f830 <817b0008> 7d3c0214 7f895840 7f9ee378
> Kernel panic - not syncing: Fatal exception
>
> Another one:
> NIP: c00b6980 LR: c00b6978 CTR: 0f9ffb20
> REGS: d6a9dc60 TRAP: 0300 Not tainted (2.6.34.6-00392-g31e1857)
> MSR: 10029002 CR: 24004442 XER: 00000000
> DEAR: 00000008, ESR: 00000000
> TASK = da6a7440[4915] 'smrd' THREAD: d6a9c000 CPU: 0
> GPR00: 00000008 d6a9dd10 da6a7440 c0738340 00000000 00000000 00000000 00000001
> GPR08: 00000000 00000000 c00b6978 00000000 44004442 10027f04 c077790c d79f94a8
> GPR16: d6a9dd88 c07a0000 d72301f0 d6a9c000 000001ff 00000000 0f9ffb20 da5c6f78
> GPR24: d79f9440 c0738340 d6a9dd48 00000000 07832400 00000001 00000003 07832400
> NIP [c00b6980] valid_swaphandles+0x19c/0x1d0
> LR [c00b6978] valid_swaphandles+0x194/0x1d0
> Call Trace:
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0 (unreliable)
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Instruction dump:
> 38210030 7c0803a6 4e800020 7d695b78 4bffff04 3d20c074 39298300 3b290040
> 7f23cb78 484843a9 38000001 7c00f030 <817b0008> 7d3f0214 7f895840 7ffdfb78
> Kernel panic - not syncing: Fatal exception
> Call Trace:
> [d6a9dba0] [c000765c] show_stack+0x40/0x15c (unreliable)
> [d6a9dbd0] [c053b780] panic+0x94/0x118
> [d6a9dc20] [c000d630] die+0x15c/0x1bc
> [d6a9dc40] [c00155a4] bad_page_fault+0x90/0xc8
> [d6a9dc50] [c001068c] handle_page_fault+0x7c/0x80
> [d6a9dd10] [c00b6978] valid_swaphandles+0x194/0x1d0
> [d6a9dd40] [c00b5a10] swapin_readahead+0x34/0xbc
> [d6a9dd80] [c00a9064] handle_mm_fault+0x7c0/0x868
> [d6a9dde0] [c00158d8] do_page_fault+0x2fc/0x570
> [d6a9df40] [c001061c] handle_page_fault+0xc/0x80
> Rebooting in 5 seconds..
>
> Thanks,
> Jean-Mickael
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: MSI-X vector allocation failure in upstream kernel
From: Benjamin Herrenschmidt @ 2010-10-08 1:26 UTC (permalink / raw)
To: Anirban Chakraborty; +Cc: linuxppc-dev, Michael Ellerman, Ameen Rahman
In-Reply-To: <9101728E-3FFC-457E-AF5B-87B2037FEC32@qlogic.com>
On Tue, 2010-10-05 at 10:18 -0700, Anirban Chakraborty wrote:
> Hi All,
>
> I am trying to test qlcnic driver (for 10Gb QLogic network adapter) on a Power 6 system
> (IBM P 520, System type 8203) with upstream kernel and I do see that the kernel is
> not able to allocate any MSI-X vectors. The driver requests for 4 vectors in pci_enable_msix,
> which returns 2. The driver again attempts, this time for 2 vectors but the kernel can't allocate
> and it returns a value of 0xfffffffd. I upgraded the system FW to 01EL350 (from 01EL340)
> just to make sure if MSI-X is enabled in the system. Is there anything that I am missing?
>
> Any pointers will be highly appreciated.
I think the people who can help you at the moment are on vacation :-)
Can you make sure kernel debug is enabled and you have "debug" on the
kernel command line, and send the full dmesg log of what's going on ?
Hopefully, Michael will be back next week and will be able to have a
look at it.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 14/18] powerpc, of_serial: Endianness issues setting up the serial ports
From: Grant Likely @ 2010-10-07 23:23 UTC (permalink / raw)
To: Ian Munsie
Cc: Michal Simek, Greg Kroah-Hartman, devicetree-discuss,
Sean MacLennan, linux-kernel, Stefan Weil, paulus, Jiri Kosina,
linuxppc-dev, David S. Miller
In-Reply-To: <1285916771-18033-15-git-send-email-imunsie@au1.ibm.com>
On Fri, Oct 01, 2010 at 05:06:07PM +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> The speed and clock of the serial ports is retrieved from the device
> tree in both the PowerPC legacy serial code and the Open Firmware serial
> driver, therefore they need to handle the fact that the device tree is
> always big endian, while the CPU may not be.
>
> Also fix other device tree references in the legacy serial code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
Applied, thanks.
I'm picking up this one because it is also needed by Microblaze.
Michal Simek also posted a patch that does the same thing, but this
one is better so I'm dropping his in favour of this one.
As for the other patches, they all look good to me (at least for the
bits that I care about), but I'll leave them for Ben to pick up so the
series doesn't get too fragmented.
g.
> ---
> arch/powerpc/kernel/legacy_serial.c | 22 +++++++++++-----------
> drivers/serial/of_serial.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
> index c1fd0f9..c834757 100644
> --- a/arch/powerpc/kernel/legacy_serial.c
> +++ b/arch/powerpc/kernel/legacy_serial.c
> @@ -52,14 +52,14 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> phys_addr_t taddr, unsigned long irq,
> upf_t flags, int irq_check_parent)
> {
> - const u32 *clk, *spd;
> + const __be32 *clk, *spd;
> u32 clock = BASE_BAUD * 16;
> int index;
>
> /* get clock freq. if present */
> clk = of_get_property(np, "clock-frequency", NULL);
> if (clk && *clk)
> - clock = *clk;
> + clock = be32_to_cpup(clk);
>
> /* get default speed if present */
> spd = of_get_property(np, "current-speed", NULL);
> @@ -109,7 +109,7 @@ static int __init add_legacy_port(struct device_node *np, int want_index,
> legacy_serial_infos[index].taddr = taddr;
> legacy_serial_infos[index].np = of_node_get(np);
> legacy_serial_infos[index].clock = clock;
> - legacy_serial_infos[index].speed = spd ? *spd : 0;
> + legacy_serial_infos[index].speed = spd ? be32_to_cpup(spd) : 0;
> legacy_serial_infos[index].irq_check_parent = irq_check_parent;
>
> printk(KERN_DEBUG "Found legacy serial port %d for %s\n",
> @@ -168,7 +168,7 @@ static int __init add_legacy_soc_port(struct device_node *np,
> static int __init add_legacy_isa_port(struct device_node *np,
> struct device_node *isa_brg)
> {
> - const u32 *reg;
> + const __be32 *reg;
> const char *typep;
> int index = -1;
> u64 taddr;
> @@ -181,7 +181,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> return -1;
>
> /* Verify it's an IO port, we don't support anything else */
> - if (!(reg[0] & 0x00000001))
> + if (!(be32_to_cpu(reg[0]) & 0x00000001))
> return -1;
>
> /* Now look for an "ibm,aix-loc" property that gives us ordering
> @@ -202,7 +202,7 @@ static int __init add_legacy_isa_port(struct device_node *np,
> taddr = 0;
>
> /* Add port, irq will be dealt with later */
> - return add_legacy_port(np, index, UPIO_PORT, reg[1], taddr,
> + return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]), taddr,
> NO_IRQ, UPF_BOOT_AUTOCONF, 0);
>
> }
> @@ -251,9 +251,9 @@ static int __init add_legacy_pci_port(struct device_node *np,
> * we get to their "reg" property
> */
> if (np != pci_dev) {
> - const u32 *reg = of_get_property(np, "reg", NULL);
> - if (reg && (*reg < 4))
> - index = lindex = *reg;
> + const __be32 *reg = of_get_property(np, "reg", NULL);
> + if (reg && (be32_to_cpup(reg) < 4))
> + index = lindex = be32_to_cpup(reg);
> }
>
> /* Local index means it's the Nth port in the PCI chip. Unfortunately
> @@ -507,7 +507,7 @@ static int __init check_legacy_serial_console(void)
> struct device_node *prom_stdout = NULL;
> int i, speed = 0, offset = 0;
> const char *name;
> - const u32 *spd;
> + const __be32 *spd;
>
> DBG(" -> check_legacy_serial_console()\n");
>
> @@ -547,7 +547,7 @@ static int __init check_legacy_serial_console(void)
> }
> spd = of_get_property(prom_stdout, "current-speed", NULL);
> if (spd)
> - speed = *spd;
> + speed = be32_to_cpup(spd);
>
> if (strcmp(name, "serial") != 0)
> goto not_found;
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2af8fd1..17849dc 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -31,8 +31,8 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->dev.of_node;
> - const unsigned int *clk, *spd;
> - const u32 *prop;
> + const __be32 *clk, *spd;
> + const __be32 *prop;
> int ret, prop_size;
>
> memset(port, 0, sizeof *port);
> @@ -55,23 +55,23 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> /* Check for shifted address mapping */
> prop = of_get_property(np, "reg-offset", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->mapbase += *prop;
> + port->mapbase += be32_to_cpup(prop);
>
> /* Check for registers offset within the devices address range */
> prop = of_get_property(np, "reg-shift", &prop_size);
> if (prop && (prop_size == sizeof(u32)))
> - port->regshift = *prop;
> + port->regshift = be32_to_cpup(prop);
>
> port->irq = irq_of_parse_and_map(np, 0);
> port->iotype = UPIO_MEM;
> port->type = type;
> - port->uartclk = *clk;
> + port->uartclk = be32_to_cpup(clk);
> port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
> /* If current-speed was set, then try not to change it. */
> if (spd)
> - port->custom_divisor = *clk / (16 * (*spd));
> + port->custom_divisor = be32_to_cpup(clk) / (16 * (be32_to_cpup(spd)));
>
> return 0;
> }
> --
> 1.7.1
>
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-10-07 22:10 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, Rina Kagan, linuxppc-dev, Mark Miesfeld,
Ted Chan, Fushen Chen
In-Reply-To: <AANLkTinzG_g2--E5SwzEK6qK8NR+ewWJJU0UXsoWveP6@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:01:33PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We have obtained GPL 2 only header from Synopsis. We have also identified all
> parties that contributed to the code base and contacted them regarding
> license change.
> Any party that we could not reach, we will remove the patch from the submission.
> Let me know if this is sufficient for resubmission.
Yes, that sounds fine, thanks for doing that work.
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-10-07 22:01 UTC (permalink / raw)
To: Greg KH, Rina Kagan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730033632.GB27275@suse.de>
Hi Greg:
We have obtained GPL 2 only header from Synopsis. We have also identified a=
ll
parties that contributed to the code base and contacted them regarding
license change.
Any party that we could not reach, we will remove the patch from the submis=
sion.
Let me know if this is sufficient for resubmission.
Thanks
Feng
On Thu, Jul 29, 2010 at 8:36 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
>> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> >> Hi Greg:
>> >> >>
>> >> >> We will change to a BSD 3 clause license header. Our legal counsel=
is
>> >> >> talking to Synopsis to make this change.
>> >> >
>> >> > Why BSD? ??You do realize what that means when combined within the =
body
>> >> > of the kernel, right?
>> >> >
>> >>
>> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the=
HP
>> >> ?? ?? ?? ?? ?? ??Hil driver.
>> >
>> > What specific driver is this?
>>
>> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> Ok, thanks.
>
> Are you _sure_ that you didn't take any existing GPL code and put it
> into this driver when making it? =C2=A0Did all contributors to the code
> release their contributions under both licenses?
>
>> > And are you sure that all of the contributors to the code agree with
>> > this licensing change? ??Are you going to require contributors to
>> > dual-license their changes?
>> >
>> > If so, why keep it BSD, what does that get you?
>>
>> FKAN: for one thing, to make it future proof on other submissions.
>
> What do you mean by this? =C2=A0What can you do with this code other than=
use
> it on a Linux system? =C2=A0You can't put it into any other operating sys=
tem
> with a different license, can you?
>
>> >> > Are you going to be expecting others to contribute back to the code
>> >> > under this license, or will you accept the fact that future
>> >> > contributions from the community will cause the license to change?
>> >
>> >
>> > You didn't answer this question, which is a very important one before =
I
>> > can accept this driver.
>>
>> FKAN: Yes, all of the above. Our legal is working on that. I thought by =
default
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPL defines the above statement=
.
>
> The GPL does, but as you are trying to dual-license the code, you have
> to be careful about how you accept changes, and under what license.
> It's a lot more work than I think you realize. =C2=A0What process do you =
have
> in place to handle this?
>
>> >> >> We will resubmit once this is in place. Please let me know if you =
have
>> >> >> any additional concerns.
>> >> >
>> >> > My main concern is that you, and everyone else involved in the driv=
er,
>> >> > never considered the license of the code in the first place and exp=
ected
>> >> > the kernel community to accept it as-is, placing the problem on us.
>> >>
>> >> FKAN: Please don't think this is the case, we gone through this exerc=
ise
>> >> ?? ?? ?? ?? ?? with Denx.
>> >
>> > What is "Denx"?
>>
>> FKAN: U-Boot Denx.de
>
> Ah, thanks.
>
>> >> We had legal looking into the header before submission
>> >> ?? ?? ?? ?? ?? to them and the kernel.
>> >
>> > Then what happened here? ??Just curious as to how the driver was publi=
c
>> > for so long before someone realized this.
>> >
>>
>> FKAN: =C2=A0this was few years back. At the time we had the header chang=
ed
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so it was BSD like to be accept=
ed by Denx.
>>
>> >> > What will be done in the future to prevent this from happening agai=
n?
>> >>
>> >> FKAN: agreed, once bitten .... :)
>> >
>> > That didn't answer the question :)
>>
>> FKAN: we have a system of checks for every patch that goes out. I will s=
end
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out a guideline to all reviewer=
to make sure the header
>> follow kernel precedence.
>
> But you took this code from a different vendor, are you able to properly
> identify the code contributions to this base and what license it is
> under and where they got it from?
>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Legal is quite aware of the iss=
ue now too.
>
> As they should be :)
>
> Please reconsider the dual licensing unless you really are ready to
> handle the implications of it.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-07 21:01 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101007152626.4e834d43@udp111988uds.am.freescale.net>
> On Thu, 7 Oct 2010 15:12:26 -0500.
>
> BTW, the MSIs are already described in an msi node in the device tree.
As far as I can tell, ONLY in root complex mode, not in endpoint mode,
which is what I am working with.
What I want is a means by which the system root complex can generate one
or more interrupts INTO the 8641 when it is operating in endpoint mode.
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-07 20:26 UTC (permalink / raw)
To: david.hagood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fe4c3e4086132d746b79670f236302f1.squirrel@localhost>
On Thu, 7 Oct 2010 15:12:26 -0500
<david.hagood@gmail.com> wrote:
> > On Tue, 21 Sep 2010 17:37:15 -0400
> > The MPIC interrupt numberspace in the device tree (which is not
> > virtual; it is a private numberspace to MPIC) is based on the offset of
> > the registers for that interrupt source. External interrupts start at
> > zero (which is valid), internal at 16, and special things like MSIs at
> > higher numbers (I don't think it's quite 256).
>
> OK, so I'm slowly wrapping my head around this (OT: Has anybody considered
> sending this information to the folks doing the Linux Device Drivers
> books? They are just a bit x86 centric right now...).
>
> As I understand, what I have to do is somehow get a device_node *, then
> make a call to irq_of_parse_and_map() to convert that into a system IRQ.
>
> What I am doing right now is:
> device_node *mpic = of_find_node_by_type(0,"open-pic");
> irq = irq_of_parse_and_map(mpic,256);
This is asking for the 256th specifier in the interrupts property in
the mpic node -- not what you want.
Ideally you would have a node for your device with an interrupt
specifier that you could look up with irq_of_parse_and_map(). But if
not, you can use irq_create_mapping() to directly convert an MPIC IRQ
number to a virtual IRQ.
What interrupt are you trying to select with 256? That doesn't look
like a valid MPIC interrupt number.
> 2) How do I know for certain that 256 is the right value for the first MSI
> signaled via MSIR0?
It isn't. The vector/priority register (MSIVPR0) is at offset
0x51c00. Each interrupt source is 32 bytes. The first interrupt
source is at 0x50000.
So the interrupt number is (0x51c00 - 0x50000) / 32 = 224.
BTW, the MSIs are already described in an msi node in the device tree.
Are you trying to do something different with them than PCI MSIs? If
not, is the existing MSI driver not working? If you are trying to do
something different, you should bind to that node yourself and use
irq_of_parse_and_map() on it.
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox