* Re: PCI-PCI bridge scanning broken on 460EX
From: Felix Radensky @ 2010-01-10 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <4B41ADF1.1000400@embedded-sol.com>
Hi, Ben
Felix Radensky wrote:
> Hi, Ben
>
> Adding Feng Kan from AMCC to CC.
>
> Benjamin Herrenschmidt wrote:
>> On Mon, 2009-12-28 at 12:51 +0200, Felix Radensky wrote:
>>
>>> Hi,
>>>
>>> I'm running linux-2.6.33-rc2 on Canyonlands board. When PLX 6254
>>> transparent PCI-PCI
>>> bridge is plugged into PCI slot the kernel simply resets the board
>>> without printing anything
>>> to console. Without PLX bridge kernel boots fine.
>>>
>>
>> Sorry for the late reply...
>>
>
> No need to apologize, I appreciate you help very much.
>
>>
>>> I've tracked down the problem to the following code in
>>> pci_scan_bridge() in drivers/pci/probe.c:
>>>
>>> if (pcibios_assign_all_busses() || broken)
>>> /* Temporarily disable forwarding of the
>>> configuration cycles on all bridges in
>>> this bus segment to avoid possible
>>> conflicts in the second pass between two
>>> bridges programmed with overlapping
>>> bus ranges. */
>>> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
>>> buses & ~0xffffff);
>>>
>>> If test for broken is removed, kernel boots fine, detects the
>>> bridge, but
>>> does not detect the device behind the bridge. The same device plugged
>>> directly into PCI slot is detected correctly.
>>>
>>
>> So we would have a similar mismatch between the initial setup and the
>> kernel... However, I don't quite see yet why the kernel trying to fix
>> it up breaks things, that will need a bit more debugging here...
>>
>> Can you give it a quick try with adding something like :
>>
>> ppc_pci_add_flags(PPC_PCI_REASSIGN_ALL_BUS);
>>
>> Near the end of ppc4xx_pci.c ? It looks like another case of reset
>> not actually resetting bridges (are we not properly doing a fundamental
>> reset ? Stefan what's your take there ?)
>>
>> The above will cause busses to be re-assigned which is risky because it
>> will allow the kernel to assign numbers beyond the limits of what
>> ppc4xx_pci.c supports (see my comments in the thread you quotes).
>>
>> The good thing is that we now have a working fixmap infrastructure, so
>> we could/should just move ppc4xx_pci.c to use that, and just always
>> re-assign busses.
>>
>>
>>> To remind you, tests for broken were added by commit
>>> a1c19894b786f10c76ac40e93c6b5d70c9b946d2,
>>> and were intended to solve device detection problem behind PCI-E
>>> switches, as discussed in this thread:
>>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2008-October/063939.html
>>>
>>
>>
>>> PCI: Probing PCI hardware
>>> pci_bus 0000:00: scanning bus
>>> pci 0000:00:06.0: found [3388:0020] class 000604 header type 01
>>> pci 0000:00:06.0: supports D1 D2
>>> pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot
>>> pci 0000:00:06.0: PME# disabled
>>> pci_bus 0000:00: fixups for bus
>>> pci 0000:00:06.0: scanning behind bridge, config 000000, pass 0
>>> pci 0000:00:06.0: bus configuration invalid, reconfiguring
>>>
>>
>> Ok so we hit a P2P bridge whose primary, secondary and subordinate bus
>> numbers are all 0, which is clearly unconfigured. I think this is the
>> root complex bridge
>>
>>
>>> pci 0000:00:06.0: scanning behind bridge, config 000000, pass 1
>>>
>>
>> Now this is when the bus should be reconfigured (pass 1). Sadly the code
>> doesn't print much debug.
>>
>> Also from that point, it should renumber things and work...
>>
>>> pci_bus 0000:01: scanning bus
>>>
>>
>> Which it does to some extent. It assigned bus number 1 to it afaik so we
>> now start looking below the RC bridge:
>>
>>
>>> pci 0000:01:06.0: found [3388:0020] class 000604 header type 01
>>>
>>
>> Hrm... class PCI bridge, vendor 3388 device 0020, is that your PLX ?
>> It's not the right vendor ID but maybe that's configurable by our OEM or
>> something...
>>
>
> The bridge and its evaluation board were manufactured by HiNT, later
> purchased by PLX.
> 3388:0020 is HiNT HB6 Universal PCI-PCI bridge in transparent mode.
>
>>
>>> pci 0000:01:06.0: supports D1 D2
>>> pci 0000:01:06.0: PME# supported from D0 D1 D2 D3hot
>>> pci 0000:01:06.0: PME# disabled
>>> pci_bus 0000:01: fixups for bus
>>> pci 0000:00:06.0: PCI bridge to [bus 01-ff]
>>> pci 0000:00:06.0: bridge window [io 0x0000-0x0fff]
>>> pci 0000:00:06.0: bridge window [mem 0x00000000-0x000fffff]
>>> pci 0000:00:06.0: bridge window [mem 0x00000000-0x000fffff 64bit
>>> pref]
>>> pci 0000:01:06.0: scanning behind bridge, config ff0100, pass 0
>>>
>>
>> Allright, that's where it gets interesting. It tries to scan behind the
>> bridge. It gets something it doesn't like. IE, it gets a secondary bus
>> number of 1 (what the heck ? I wonder what your firmware does) which
>> Linux is not happy about and decides to renumber it.
>>
>
> U-boot has problems with this bridge as well, so I had to completely
> disable PCI
> support in u-boot to get linux running.
>>
>>> pci 0000:01:06.0: bus configuration invalid, reconfiguring
>>>
>>
>> Now, that's where Linux should have written 000000 to the register,
>> which is what you commented out.
>>
>>
>>> pci 0000:01:06.0: scanning behind bridge, config ff0100, pass 1
>>> pci_bus 0000:01: bus scan returning with max=01
>>> pci_bus 0000:00: bus scan returning with max=01
>>>
>>
>> Because of that commenting out, it doesn't see the config as 000000 and
>> thus doesn't re-assign a bus number in pass 1, so from there you can't
>> see what's behind the bus.
>>
>> So we have two things here:
>>
>> - It seems like the writing of 000000 to the register in pass 0 is
>> causing your crash. Can you verify that ? IE. Can you verify that it's
>> indeed crashing on this specific statement:
>>
>> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
>> buses & ~0xffffff);
>>
>> When writing to the bridge, and that this seems to be causing a hard
>> reboot of the system ?
>>
>
> Yes, this particular statement causes hard reboot. With original
> broken tests restored
> and writing to bridge commented out the system boots. If writing to
> bridge happens
> I get hard reset.
>
>> It might be useful to ask AMCC how that is possible in HW, ie what kind
>> of signal can be causing that. IE, even if the bridge is causing a PCIe
>> error, that should not cause a reboot ... right ?
>>
>
> Feng, can you please comment on this ?
>> - You can test a quick hack workaround which consists of changing:
>>
>> /* Check if setup is sensible at all */
>> - if (!pass &&
>> - if (1 &&
>> ((buses & 0xff) != bus->number || ((buses >> 8) & 0xff) <=
>> bus->number)) {
>> dev_dbg(&dev->dev, "bus configuration invalid,
>> reconfiguring\n");
>> broken = 1;
>> }
>>
>> In -addition- to your commenting out of the broken test. This will
>> cause the
>> second pass to go through the re-assign code path despite the fact
>> that you
>> have not written 000000 to the bus numbers.
>>
>
> With this change and commented out broken test I still get hard reset.
>
> I didn't try adding ppc_pci_add_flags(PPC_PCI_REASSIGN_ALL_BUS)
> If you still want me to try this, please let me know. Should I leave
> broken
> tests enabled in that case ?
>
> Thanks a lot for your help.
>
> Felix.
I now have a custom board with 460EX and the same PLX bridge, running
2.6.23-rc3
Things look better here, as u-boot is now able to properly detect PLX
and device behind
it, but kernel still has problems. First, I'm still getting hard reset on
pci_write_config_dword(dev, PCI_PRIMARY_BUS,
buses & ~0xffffff);
If this line is removed, PLX is detected twice, see below. I also get
hard reset
if pass test is modified as you requested and broken test removed.
Any ideas how to fix this ? I was suspecting PLX evaluation board, but
PLX on our custom board seems to be OK, so it looks like kernel needs
fixing.
PCI: Probing PCI hardware
pci_bus 0000:00: scanning bus
pci 0000:00:02.0: found [3388:0020] class 000604 header type 01
pci 0000:00:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:00:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:00:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.0: PME# disabled
pci_bus 0000:00: fixups for bus
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 0
pci_bus 0000:01: scanning bus
pci 0000:01:02.0: found [3388:0020] class 000604 header type 01
pci 0000:01:02.0: calling pcibios_fixup_resources+0x0/0xf4
pci 0000:01:02.0: calling fixup_ppc4xx_pci_bridge+0x0/0x154
pci 0000:01:02.0: calling quirk_resource_alignment+0x0/0x200
pci 0000:01:02.0: supports D1 D2
pci 0000:01:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:01:02.0: PME# disabled
pci_bus 0000:01: fixups for bus
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:01:02.0: scanning behind bridge, config 010100, pass 0
pci 0000:01:02.0: bus configuration invalid, reconfiguring
pci 0000:01:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:01: bus scan returning with max=01
pci 0000:00:02.0: scanning behind bridge, config 010100, pass 1
pci_bus 0000:00: bus scan returning with max=01
pci 0000:00:02.0: PCI bridge to [bus 01-01]
pci 0000:00:02.0: bridge window [io disabled]
pci 0000:00:02.0: bridge window [mem disabled]
pci 0000:00:02.0: bridge window [mem pref disabled]
pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
pci_bus 0000:00: resource 1 [mem 0xd80000000-0xdffffffff]
Thanks.
Felix.
^ permalink raw reply
* Allocator MAX_ORDER exceeds SECTION_SIZE
From: Michael Buesch @ 2010-01-10 13:31 UTC (permalink / raw)
To: linuxppc-dev
I get the following compilation failure, if 64k pages is selected
on 2.6.32.3 on a PowerMAC config:
include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
Any idea?
--
Greetings, Michael.
^ permalink raw reply
* [PATCH 1/2] pmac-zilog: add platform driver, version 3
From: Finn Thain @ 2010-01-10 16:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-m68k, linuxppc-dev
In-Reply-To: <alpine.LNX.2.00.1001102340340.22574@nippy.intranet>
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
This patch should be applied after "[PATCH 3/13] pmac-zilog: cleanup".
It obsoletes "[PATCH 4/13] pmac-zilog, mac68k: replace mac68k SCC code
with platform device" listed in the linux-ppc patchwork.
Version 2 of this patch adopts Geert's suggestions: make better use of
dev_{dbg,err,info} macros, change platform_driver_register() to
platform_driver_probe(), and use __init and __exit attributes.
Version 3 does not #include <macints.h>.
arch/m68k/configs/mac_defconfig | 5 +
arch/m68k/configs/multi_defconfig | 5 +
drivers/serial/Kconfig | 12 +-
drivers/serial/pmac_zilog.c | 157 +++++++++++++++++++++++++++++++++-----
drivers/serial/pmac_zilog.h | 14 +++
5 files changed, 167 insertions(+), 26 deletions(-)
Index: linux-2.6.31/drivers/serial/Kconfig
===================================================================
--- linux-2.6.31.orig/drivers/serial/Kconfig 2010-01-10 23:38:58.000000000 +1100
+++ linux-2.6.31/drivers/serial/Kconfig 2010-01-10 23:39:02.000000000 +1100
@@ -1079,12 +1079,12 @@ config SERIAL_68360
default y
config SERIAL_PMACZILOG
- tristate "PowerMac z85c30 ESCC support"
- depends on PPC_OF && PPC_PMAC
+ tristate "Mac or PowerMac z85c30 ESCC support"
+ depends on (M68K && MAC) || (PPC_OF && PPC_PMAC)
select SERIAL_CORE
help
This driver supports the Zilog z85C30 serial ports found on
- PowerMac machines.
+ (Power)Mac machines.
Say Y or M if you want to be able to these serial ports.
config SERIAL_PMACZILOG_TTYS
@@ -1109,16 +1109,16 @@ config SERIAL_PMACZILOG_TTYS
unable to use the 8250 module for PCMCIA or other 16C550-style
UARTs.
- Say N unless you need the z85c30 ports on your powermac
+ Say N unless you need the z85c30 ports on your (Power)Mac
to appear as /dev/ttySn.
config SERIAL_PMACZILOG_CONSOLE
- bool "Console on PowerMac z85c30 serial port"
+ bool "Console on Mac or PowerMac z85c30 serial port"
depends on SERIAL_PMACZILOG=y
select SERIAL_CORE_CONSOLE
help
If you would like to be able to use the z85c30 serial port
- on your PowerMac as the console, you can do so by answering
+ on your (Power)Mac as the console, you can do so by answering
Y to this option.
config SERIAL_LH7A40X
Index: linux-2.6.31/arch/m68k/configs/mac_defconfig
===================================================================
--- linux-2.6.31.orig/arch/m68k/configs/mac_defconfig 2010-01-10 23:39:02.000000000 +1100
+++ linux-2.6.31/arch/m68k/configs/mac_defconfig 2010-01-10 23:39:02.000000000 +1100
@@ -701,6 +701,11 @@ CONFIG_VT_HW_CONSOLE_BINDING=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/arch/m68k/configs/multi_defconfig
===================================================================
--- linux-2.6.31.orig/arch/m68k/configs/multi_defconfig 2010-01-10 23:39:02.000000000 +1100
+++ linux-2.6.31/arch/m68k/configs/multi_defconfig 2010-01-10 23:39:02.000000000 +1100
@@ -822,6 +822,11 @@ CONFIG_A2232=y
#
# Non-8250 serial port support
#
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+CONFIG_SERIAL_PMACZILOG=y
+CONFIG_SERIAL_PMACZILOG_TTYS=y
+CONFIG_SERIAL_PMACZILOG_CONSOLE=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
Index: linux-2.6.31/drivers/serial/pmac_zilog.c
===================================================================
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.c 2010-01-10 23:39:02.000000000 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.c 2010-01-11 03:11:55.000000000 +1100
@@ -63,11 +63,17 @@
#include <asm/sections.h>
#include <asm/io.h>
#include <asm/irq.h>
+
+#ifdef CONFIG_PPC_PMAC
#include <asm/prom.h>
#include <asm/machdep.h>
#include <asm/pmac_feature.h>
#include <asm/dbdma.h>
#include <asm/macio.h>
+#else
+#include <linux/platform_device.h>
+#define machine_is_compatible(x) (0)
+#endif
#if defined (CONFIG_SERIAL_PMACZILOG_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
@@ -83,11 +89,9 @@
static char version[] __initdata = "pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)";
MODULE_AUTHOR("Benjamin Herrenschmidt <benh@kernel.crashing.org>");
-MODULE_DESCRIPTION("Driver for the PowerMac serial ports.");
+MODULE_DESCRIPTION("Driver for the Mac and PowerMac serial ports.");
MODULE_LICENSE("GPL");
-#define PWRDBG(fmt, arg...) printk(KERN_DEBUG fmt , ## arg)
-
#ifdef CONFIG_SERIAL_PMACZILOG_TTYS
#define PMACZILOG_MAJOR TTY_MAJOR
#define PMACZILOG_MINOR 64
@@ -341,7 +345,7 @@ static struct tty_struct *pmz_receive_ch
uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
write_zsreg(uap, R1, uap->curregs[R1]);
zssync(uap);
- dev_err(&uap->dev->ofdev.dev, "pmz: rx irq flood !\n");
+ pmz_error("pmz: rx irq flood !\n");
return tty;
}
@@ -746,6 +750,8 @@ static void pmz_break_ctl(struct uart_po
spin_unlock_irqrestore(&port->lock, flags);
}
+#ifdef CONFIG_PPC_PMAC
+
/*
* Turn power on or off to the SCC and associated stuff
* (port drivers, modem, IR port, etc.)
@@ -781,6 +787,15 @@ static int pmz_set_scc_power(struct uart
return delay;
}
+#else
+
+static int pmz_set_scc_power(struct uart_pmac_port *uap, int state)
+{
+ return 0;
+}
+
+#endif /* !CONFIG_PPC_PMAC */
+
/*
* FixZeroBug....Works around a bug in the SCC receving channel.
* Inspired from Darwin code, 15 Sept. 2000 -DanM
@@ -943,9 +958,9 @@ static int pmz_startup(struct uart_port
}
pmz_get_port_A(uap)->flags |= PMACZILOG_FLAG_IS_IRQ_ON;
- if (request_irq(uap->port.irq, pmz_interrupt, IRQF_SHARED, "PowerMac Zilog", uap)) {
- dev_err(&uap->dev->ofdev.dev,
- "Unable to register zs interrupt handler.\n");
+ if (request_irq(uap->port.irq, pmz_interrupt, IRQF_SHARED,
+ "SCC", uap)) {
+ pmz_error("Unable to register zs interrupt handler.\n");
pmz_set_scc_power(uap, 0);
mutex_unlock(&pmz_irq_mutex);
return -ENXIO;
@@ -1185,7 +1200,7 @@ static void pmz_irda_setup(struct uart_p
while ((read_zsreg(uap, R0) & Tx_BUF_EMP) == 0
|| (read_zsreg(uap, R1) & ALL_SNT) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev, "transmitter didn't drain\n");
+ pmz_error("transmitter didn't drain\n");
return;
}
udelay(10);
@@ -1201,7 +1216,7 @@ static void pmz_irda_setup(struct uart_p
read_zsdata(uap);
mdelay(10);
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev, "receiver didn't drain\n");
+ pmz_error("receiver didn't drain\n");
return;
}
}
@@ -1222,8 +1237,7 @@ static void pmz_irda_setup(struct uart_p
t = 5000;
while ((read_zsreg(uap, R0) & Rx_CH_AV) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup timed out on get_version byte\n");
+ pmz_error("irda_setup timed out on get_version byte\n");
goto out;
}
udelay(10);
@@ -1231,8 +1245,7 @@ static void pmz_irda_setup(struct uart_p
version = read_zsdata(uap);
if (version < 4) {
- dev_info(&uap->dev->ofdev.dev, "IrDA: dongle version %d not supported\n",
- version);
+ pmz_info("IrDA: dongle version %d not supported\n", version);
goto out;
}
@@ -1241,19 +1254,17 @@ static void pmz_irda_setup(struct uart_p
t = 5000;
while ((read_zsreg(uap, R0) & Rx_CH_AV) == 0) {
if (--t <= 0) {
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup timed out on speed mode byte\n");
+ pmz_error("irda_setup timed out on speed mode byte\n");
goto out;
}
udelay(10);
}
t = read_zsdata(uap);
if (t != cmdbyte)
- dev_err(&uap->dev->ofdev.dev,
- "irda_setup speed mode byte = %x (%x)\n", t, cmdbyte);
+ pmz_error("irda_setup speed mode byte = %x (%x)\n", t, cmdbyte);
- dev_info(&uap->dev->ofdev.dev, "IrDA setup for %ld bps, dongle version: %d\n",
- *baud, version);
+ pmz_info("IrDA setup for %ld bps, dongle version: %d\n",
+ *baud, version);
(void)read_zsdata(uap);
(void)read_zsdata(uap);
@@ -1402,7 +1413,7 @@ static void pmz_poll_put_char(struct uar
write_zsdata(uap, c);
}
-#endif
+#endif /* CONFIG_CONSOLE_POLL */
static struct uart_ops pmz_pops = {
.tx_empty = pmz_tx_empty,
@@ -1427,6 +1438,8 @@ static struct uart_ops pmz_pops = {
#endif
};
+#ifdef CONFIG_PPC_PMAC
+
/*
* Setup one port structure after probing, HW is down at this point,
* Unlike sunzilog, we don't need to pre-init the spinlock as we don't
@@ -1823,6 +1836,88 @@ next:
return 0;
}
+#else
+
+extern struct platform_device scc_a_pdev, scc_b_pdev;
+
+static int __init pmz_init_port(struct uart_pmac_port *uap)
+{
+ struct resource *r_ports;
+ int irq;
+
+ r_ports = platform_get_resource(uap->node, IORESOURCE_MEM, 0);
+ irq = platform_get_irq(uap->node, 0);
+ if (!r_ports || !irq)
+ return -ENODEV;
+
+ uap->port.mapbase = r_ports->start;
+ uap->port.membase = (unsigned char __iomem *) r_ports->start;
+ uap->port.iotype = UPIO_MEM;
+ uap->port.irq = irq;
+ uap->port.uartclk = ZS_CLOCK;
+ uap->port.fifosize = 1;
+ uap->port.ops = &pmz_pops;
+ uap->port.type = PORT_PMAC_ZILOG;
+ uap->port.flags = 0;
+
+ uap->control_reg = uap->port.membase;
+ uap->data_reg = uap->control_reg + 4;
+ uap->port_type = 0;
+
+ pmz_convert_to_zs(uap, CS8, 0, 9600);
+
+ return 0;
+}
+
+static int __init pmz_probe(void)
+{
+ int err;
+
+ pmz_ports_count = 0;
+
+ pmz_ports[0].mate = &pmz_ports[1];
+ pmz_ports[0].port.line = 0;
+ pmz_ports[0].flags = PMACZILOG_FLAG_IS_CHANNEL_A;
+ pmz_ports[0].node = &scc_a_pdev;
+ err = pmz_init_port(&pmz_ports[0]);
+ if (err)
+ return err;
+ pmz_ports_count++;
+
+ pmz_ports[1].mate = &pmz_ports[0];
+ pmz_ports[1].port.line = 1;
+ pmz_ports[1].flags = 0;
+ pmz_ports[1].node = &scc_b_pdev;
+ err = pmz_init_port(&pmz_ports[1]);
+ if (err)
+ return err;
+ pmz_ports_count++;
+
+ return 0;
+}
+
+static void pmz_dispose_port(struct uart_pmac_port *uap)
+{
+ memset(uap, 0, sizeof(struct uart_pmac_port));
+}
+
+static int __init pmz_attach(struct platform_device *pdev)
+{
+ int i;
+
+ for (i = 0; i < pmz_ports_count; i++)
+ if (pmz_ports[i].node == pdev)
+ return 0;
+ return -ENODEV;
+}
+
+static int __exit pmz_detach(struct platform_device *pdev)
+{
+ return 0;
+}
+
+#endif /* !CONFIG_PPC_PMAC */
+
#ifdef CONFIG_SERIAL_PMACZILOG_CONSOLE
static void pmz_console_write(struct console *con, const char *s, unsigned int count);
@@ -1883,6 +1978,8 @@ err_out:
return rc;
}
+#ifdef CONFIG_PPC_PMAC
+
static struct of_device_id pmz_match[] =
{
{
@@ -1904,6 +2001,18 @@ static struct macio_driver pmz_driver =
.resume = pmz_resume,
};
+#else
+
+static struct platform_driver pmz_driver = {
+ .remove = __exit_p(pmz_detach),
+ .driver = {
+ .name = "scc",
+ .owner = THIS_MODULE,
+ },
+};
+
+#endif /* !CONFIG_PPC_PMAC */
+
static int __init init_pmz(void)
{
int rc, i;
@@ -1942,15 +2051,23 @@ static int __init init_pmz(void)
/*
* Then we register the macio driver itself
*/
+#ifdef CONFIG_PPC_PMAC
return macio_register_driver(&pmz_driver);
+#else
+ return platform_driver_probe(&pmz_driver, pmz_attach);
+#endif
}
static void __exit exit_pmz(void)
{
int i;
+#ifdef CONFIG_PPC_PMAC
/* Get rid of macio-driver (detach from macio) */
macio_unregister_driver(&pmz_driver);
+#else
+ platform_driver_unregister(&pmz_driver);
+#endif
for (i = 0; i < pmz_ports_count; i++) {
struct uart_pmac_port *uport = &pmz_ports[i];
Index: linux-2.6.31/drivers/serial/pmac_zilog.h
===================================================================
--- linux-2.6.31.orig/drivers/serial/pmac_zilog.h 2010-01-10 23:39:02.000000000 +1100
+++ linux-2.6.31/drivers/serial/pmac_zilog.h 2010-01-10 23:39:02.000000000 +1100
@@ -1,7 +1,15 @@
#ifndef __PMAC_ZILOG_H__
#define __PMAC_ZILOG_H__
+#ifdef CONFIG_PPC_PMAC
#define pmz_debug(fmt, arg...) dev_dbg(&uap->dev->ofdev.dev, fmt, ## arg)
+#define pmz_error(fmt, arg...) dev_err(&uap->dev->ofdev.dev, fmt, ## arg)
+#define pmz_info(fmt, arg...) dev_info(&uap->dev->ofdev.dev, fmt, ## arg)
+#else
+#define pmz_debug(fmt, arg...) dev_dbg(&uap->node->dev, fmt, ## arg)
+#define pmz_error(fmt, arg...) dev_err(&uap->node->dev, fmt, ## arg)
+#define pmz_info(fmt, arg...) dev_info(&uap->node->dev, fmt, ## arg)
+#endif
/*
* At most 2 ESCCs with 2 ports each
@@ -17,6 +25,7 @@ struct uart_pmac_port {
struct uart_port port;
struct uart_pmac_port *mate;
+#ifdef CONFIG_PPC_PMAC
/* macio_dev for the escc holding this port (maybe be null on
* early inited port)
*/
@@ -25,6 +34,9 @@ struct uart_pmac_port {
* of "escc" node (ie. ch-a or ch-b)
*/
struct device_node *node;
+#else
+ struct platform_device *node;
+#endif
/* Port type as obtained from device tree (IRDA, modem, ...) */
int port_type;
@@ -55,10 +67,12 @@ struct uart_pmac_port {
volatile u8 __iomem *control_reg;
volatile u8 __iomem *data_reg;
+#ifdef CONFIG_PPC_PMAC
unsigned int tx_dma_irq;
unsigned int rx_dma_irq;
volatile struct dbdma_regs __iomem *tx_dma_regs;
volatile struct dbdma_regs __iomem *rx_dma_regs;
+#endif
struct ktermios termios_cache;
};
^ permalink raw reply
* Re: Allocator MAX_ORDER exceeds SECTION_SIZE
From: Michael Buesch @ 2010-01-10 18:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev
In-Reply-To: <201001101431.10736.mb@bu3sch.de>
On Sunday 10 January 2010 14:31:09 Michael Buesch wrote:
> I get the following compilation failure, if 64k pages is selected
> on 2.6.32.3 on a PowerMAC config:
>
> include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
>
> Any idea?
>
Ok, I figured out that lowering CONFIG_FORCE_MAX_ZONEORDER from 13 to 9
seems to fix the problem.
That error message could really need some improvement and at least a hint on what to do and why.
I'm also wondering, if the kconfig entry for CONFIG_FORCE_MAX_ZONEORDER could
somehow be limited to 9, if 64k pages is enabled.
--
Greetings, Michael.
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Benjamin Herrenschmidt @ 2010-01-10 20:38 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <4B49CE8A.7000609@embedded-sol.com>
On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote:
> I now have a custom board with 460EX and the same PLX bridge, running
> 2.6.23-rc3
> Things look better here, as u-boot is now able to properly detect PLX
> and device behind
> it, but kernel still has problems. First, I'm still getting hard reset on
>
> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
> buses & ~0xffffff);
>
> If this line is removed, PLX is detected twice, see below. I also get
> hard reset
> if pass test is modified as you requested and broken test removed.
>
> Any ideas how to fix this ? I was suspecting PLX evaluation board, but
> PLX on our custom board seems to be OK, so it looks like kernel needs
> fixing.
I have no idea no. It looks like something is wrong with the PLX bridge
but again, I don't know why that would cause the 460EX to hard reset
like that, unless some of the PCIe error handling of the 460 has been
configured to cause such a reset on some kind of errors (which it
shouldn't at least not in host mode).
Can you try instead of writing all the bus number related registers in
one single dword write above, writing them byte by byte ? Which one is
causing the reset ? Does it reset whatever the value you write there
is ?
It looks like something is causing a hard reset as soon as you try to
configure the PLX bridge and without configuring it properly I fail to
see how you'll get things working.
Cheers,
Ben.
^ permalink raw reply
* Re: Allocator MAX_ORDER exceeds SECTION_SIZE
From: Benjamin Herrenschmidt @ 2010-01-10 20:39 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev, linuxppc-dev
In-Reply-To: <201001101915.57627.mb@bu3sch.de>
On Sun, 2010-01-10 at 19:15 +0100, Michael Buesch wrote:
> On Sunday 10 January 2010 14:31:09 Michael Buesch wrote:
> > I get the following compilation failure, if 64k pages is selected
> > on 2.6.32.3 on a PowerMAC config:
> >
> > include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds SECTION_SIZE
> >
> > Any idea?
> >
>
> Ok, I figured out that lowering CONFIG_FORCE_MAX_ZONEORDER from 13 to 9
> seems to fix the problem.
> That error message could really need some improvement and at least a hint on what to do and why.
>
> I'm also wondering, if the kconfig entry for CONFIG_FORCE_MAX_ZONEORDER could
> somehow be limited to 9, if 64k pages is enabled.
There's some stuff in there to try to change the max order but KConfig
never quite get it right I think.
Cheers,
Ben.
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Felix Radensky @ 2010-01-10 21:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <1263155906.724.2.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote:
>
>
>> I now have a custom board with 460EX and the same PLX bridge, running
>> 2.6.23-rc3
>> Things look better here, as u-boot is now able to properly detect PLX
>> and device behind
>> it, but kernel still has problems. First, I'm still getting hard reset on
>>
>> pci_write_config_dword(dev, PCI_PRIMARY_BUS,
>> buses & ~0xffffff);
>>
>> If this line is removed, PLX is detected twice, see below. I also get
>> hard reset
>> if pass test is modified as you requested and broken test removed.
>>
>> Any ideas how to fix this ? I was suspecting PLX evaluation board, but
>> PLX on our custom board seems to be OK, so it looks like kernel needs
>> fixing.
>>
>
> I have no idea no. It looks like something is wrong with the PLX bridge
> but again, I don't know why that would cause the 460EX to hard reset
> like that, unless some of the PCIe error handling of the 460 has been
> configured to cause such a reset on some kind of errors (which it
> shouldn't at least not in host mode).
>
> Can you try instead of writing all the bus number related registers in
> one single dword write above, writing them byte by byte ? Which one is
> causing the reset ? Does it reset whatever the value you write there
> is ?
>
> It looks like something is causing a hard reset as soon as you try to
> configure the PLX bridge and without configuring it properly I fail to
> see how you'll get things working.
>
>
OK, I'll try writing byte by byte. The funny thing is the u-boot also
writes the
same value to PCI_PRIMARY_BUS register and it doesn't cause reset.
Thanks a lot.
Felix.
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Benjamin Herrenschmidt @ 2010-01-10 21:31 UTC (permalink / raw)
To: Felix Radensky; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <4B4A4307.5050704@embedded-sol.com>
> OK, I'll try writing byte by byte. The funny thing is the u-boot also
> writes the
> same value to PCI_PRIMARY_BUS register and it doesn't cause reset.
Maybe the bridge doesn't want to be programmed more than once on these
registers ? In any case, that's very very fishy.... I wonder if the
bridge is causing a PCI reset -upstream- (which would really be a weird
thing to do) and the 460 is turning that into a system reset ? Check if
there are ways to control how the 460 reacts to PCI resets...
In any case, it looks like a fucked up bridge to me. I don't suppose
you've seen anything in the bridge data sheet or errata sheet that could
explain what it's doing ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
From: Benjamin Herrenschmidt @ 2010-01-11 3:02 UTC (permalink / raw)
To: Rob Landley; +Cc: paulus, linuxppc-dev
In-Reply-To: <201001090217.25729.rob@landley.net>
On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
> On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > > Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm)
> > > and I'll leave it to you guys to figure out what this _means_:
> >
> > I've failed to reproduce so far on both a Wallstreet powerbook (similar
> > generation and chipset as your beige G3) and a G5 with an added serial
> > port using current upstream...
> >
> > Can you verify it's still there ? I might be able to reproduce on a
> > Beige G3 as well next week.
>
> It's still there on qemu 0.11.0's "g3beige" emulation when you use
> CONFIG_SERIAL_PMACZILOG as the serial console. (QEMU 0.10.x used a 16550
> serial chip for its g3beige emulation instead of the actual ZILOG one.) Still
> dunno if it's a qemu or bug or a kernel bug, I just know that kernel patch
> fixes it for me, and it comes back without the patch.
>
> I tested 2.6.32. Haven't tried the 2.6.32.3 but don't see why it would change
> this...
Ok so I compiled qemu and things are a bit strange.
How do you get the output of both channels of the serial port with it ?
If I use -nographics, what happens is that OpenBIOS, for some reason,
tells qemu that the console on the second channel of the ESCC.
I see my kernel messages in the console if I do console=ttyPZ0 but the
debug stuff goes where udbg initializes it, which is where OpenBIOS says
the FW console is, which is channel B and I don't know how to "see" that
with qemu.
I do see it crash due to a message from the kernel but I can't get into
xmon which is a pain.
If I modify the kernel to force udbg on channel A (same channel as the
console), then the problem doesn't appear (it doesn't crash) :-)
Cheers
Ben.
^ permalink raw reply
* RE: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
From: Wu Jiajun-B06378 @ 2010-01-11 3:47 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, lsorense, davem, netdev
In-Reply-To: <0A1FE637C2C7E148B9573BB60CC630E56C3E90@zch01exm26.fsl.freescale.net>
=20
'bd =3D=3D ugeth->txBd[txQ]' has two possible statuses: 1)full queue.
2)empty queue.
Removing 'netif_queue_stopped() =3D=3D 0' will make transmitting =
stopping
when the queue is full.=20
I made a new patch for this oops.
>From 726765194352d01dc8ea672d97612589b67cec3f Mon Sep 17 00:00:00 2001
From: Jiajun Wu <b06378@freescale.com>
Date: Mon, 11 Jan 2010 10:57:22 +0800
Subject: [PATCH] ucc_geth: Fix empty TX queue processing
Signed-off-by: Jiajun Wu <b06378@freescale.com>
---
drivers/net/ucc_geth.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index f982220..34345f0 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3576,17 +3576,17 @@ static int ucc_geth_tx(struct net_device *dev,
u8 txQ)
while ((bd_status & T_R) =3D=3D 0) {
struct sk_buff *skb;
=20
+ skb =3D ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
+
/* BD contains already transmitted buffer. */
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
=20
- if ((bd =3D=3D ugeth->txBd[txQ]) &&
(netif_queue_stopped(dev) =3D=3D 0))
+ if ((bd =3D=3D ugeth->txBd[txQ]) && (skb =3D=3D NULL))
break;
=20
dev->stats.tx_packets++;
=20
- skb =3D ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
-
if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN
&&
skb_recycle_check(skb,
=20
ugeth->ug_info->uf_info.max_rx_buf_length +
--=20
1.5.6.3
-----Original Message-----
From: linuxppc-dev-bounces+b13201=3Dfreescale.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+b13201=3Dfreescale.com@lists.ozlabs.org] On
Behalf Of Anton Vorontsov
Sent: Thursday, December 24, 2009 11:31 PM
To: David Miller
Cc: linuxppc-dev@ozlabs.org; netdev@vger.kernel.org; Lennart Sorensen
Subject: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
-----------
Following oops was seen with the ucc_geth driver:
Unable to handle kernel paging request for data at address 0x00000058
Faulting instruction address: 0xc024f2fc
Oops: Kernel access of bad area, sig: 11 [#1] [...] NIP [c024f2fc]
skb_recycle_check+0x14/0x100 LR [e30aa0a4] ucc_geth_poll+0xd8/0x4e0
[ucc_geth_driver] Call Trace:
[df857d50] [c000b03c] __ipipe_grab_irq+0x3c/0xa4 (unreliable)
[df857d60] [e30aa0a4] ucc_geth_poll+0xd8/0x4e0 [ucc_geth_driver]
[df857dd0] [c0258cf8] net_rx_action+0xf8/0x1b8 [df857e10] [c0032a38]
__do_softirq+0xb8/0x13c [df857e60] [c00065cc] do_softirq+0xa0/0xac
[...]
This is because ucc_geth_tx() tries to process an empty queue when
queues are logically stopped. Stopping the queues doesn't disable
polling, and since nowadays ucc_geth_tx() is actually called from the
polling routine, the oops above might pop up.
Fix this by removing 'netif_queue_stopped() =3D=3D 0' check.
Reported-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Tested-by: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Stable <stable@vger.kernel.org> [2.6.32]
---
drivers/net/ucc_geth.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index
afaf088..0f8c99e 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3273,7 +3273,7 @@ static int ucc_geth_tx(struct net_device *dev, u8
txQ)
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
=20
- if ((bd =3D=3D ugeth->txBd[txQ]) &&
(netif_queue_stopped(dev) =3D=3D 0))
+ if (bd =3D=3D ugeth->txBd[txQ]) /* queue empty? */
break;
=20
dev->stats.tx_packets++;
--
1.6.3.3
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply related
* [PATCH] pmac_zilog: Workaround problem due to interrupt on closed port
From: Benjamin Herrenschmidt @ 2010-01-11 3:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Miller, Rob Landley
It seems that in qemu, we can see an interrupt in R3 despite the
fact that it's masked in W1. The chip doesn't actually issue an
interrupt, but we can "see" it when taking an interrupt for the
other channel. This may be a qemu bug ... or not, so let's be
safe and avoid calling into the UART layer when that happens which
woulc cause a crash.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
David: This would affect sunzilog as well I believe. I'm not sure
if it's a bug in qemu emulation of the ESCC or if a real ESCC can
show it so I decided to be safe :-) The ESCC doc I have doesn't
appear to specify whether the interrupt status bits in R3 are
prior or post masking by W1. I can reproduce that by having the
kernel low level "udbg" debug console on channel B and the main
console on channel A (which is itself an uncommon setup).
diff --git a/drivers/serial/pmac_zilog.c b/drivers/serial/pmac_zilog.c
index 0700cd1..683e66f 100644
--- a/drivers/serial/pmac_zilog.c
+++ b/drivers/serial/pmac_zilog.c
@@ -411,6 +411,17 @@ static void pmz_transmit_chars(struct uart_pmac_port *uap)
goto ack_tx_int;
}
+ /* Under some circumstances, we see interrupts reported for
+ * a closed channel. The interrupt mask in R1 is clear, but
+ * R3 still signals the interrupts and we see them when taking
+ * an interrupt for the other channel (this could be a qemu
+ * bug but since the ESCC doc doesn't specify precsiely whether
+ * R3 interrup status bits are masked by R1 interrupt enable
+ * bits, better safe than sorry). --BenH.
+ */
+ if (!ZS_IS_OPEN(uap))
+ goto ack_tx_int;
+
if (uap->port.x_char) {
uap->flags |= PMACZILOG_FLAG_TX_ACTIVE;
write_zsdata(uap, uap->port.x_char);
--
1.6.3.3
^ permalink raw reply related
* RE: fsldma: cleanup driver and fix async_tx compatibility
From: Dudhat Dipen-B09055 @ 2010-01-11 5:47 UTC (permalink / raw)
To: Dudhat Dipen-B09055, Ira W. Snyder, dan.j.williams
Cc: herbert, Suresh Vishnu-B05022, Tabi Timur-B04825, linuxppc-dev,
Gupta Maneesh-B18878, Li Yang-R58472
In-Reply-To: <1262326246-936-1-git-send-email-iws@ovro.caltech.edu>
Hi Ira,
I have tested your patches with async DMA memcpy support. Though I
haven't captured the improvement figures.
It works fine for RAID5 memcpy offload as interrupts are coming for
separate DMA channels while I have ran IOZONE onto RAID partition.
Regards,
Dipen
=20
-----Original Message-----
From: Dudhat Dipen-B09055=20
Sent: Tuesday, January 05, 2010 11:38 AM
To: 'Ira W. Snyder'; dan.j.williams@intel.com
Cc: galak@kernel.crashing.org; herbert@gondor.apana.org.au; Tabi
Timur-B04825; linuxppc-dev@ozlabs.org; Suresh Vishnu-B05022; Gupta
Maneesh-B18878; Li Yang-R58472
Subject: RE: fsldma: cleanup driver and fix async_tx compatibility
Hi Ira,
I will test it on 85xx hardware and let you know once done.
Thanks
Dipen
=20
-----Original Message-----
From: Ira W. Snyder [mailto:iws@ovro.caltech.edu]
Sent: Friday, January 01, 2010 11:41 AM
To: dan.j.williams@intel.com
Cc: galak@kernel.crashing.org; herbert@gondor.apana.org.au; Tabi
Timur-B04825; linuxppc-dev@ozlabs.org; Suresh Vishnu-B05022; Dudhat
Dipen-B09055; Gupta Maneesh-B18878; Li Yang-R58472
Subject: fsldma: cleanup driver and fix async_tx compatibility
This patch series cleans up the Freescale DMAEngine driver, including
verifying the locking and making sure that all code paths are correct.
There were a few places that seemed suspicious, and they have been
fixed.
I have written a quick memory->memory DMAEngine test driver, and the
performance is identical before and after my changes (<0.1% change). I
measured both setting up the DMA operation (via
device_prep_dma_interrupt() and device_prep_dma_memcpy()) and the actual
DMA transfer itself.
As an added bonus, the interrupt load is measurably reduced. My test
driver transfers 32MB as 32x 1MB chunks + 1 interrupt descriptor, using
the functions noted above. Previous to this patch series, 31 interrupts
were generated. After this patch series, only a single interrupt is
generated for the whole transaction.
Some testing on 85xx/86xx hardware would be appreciated. Also, some
testing by the users attempting to use async_tx and talitos to handle
RAID offload would be great as well.
Documentation/powerpc/dts-bindings/fsl/dma.txt | 17 +-
drivers/dma/fsldma.c | 1036
++++++++++++------------
drivers/dma/fsldma.h | 35 +-
3 files changed, 556 insertions(+), 532 deletions(-)
Thanks,
Ira
^ permalink raw reply
* RE: [PATCH 2/2] Adding PCI-E MSI support for PowerPC 460SX SOC.
From: Tirumala Reddy Marri @ 2010-01-11 6:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, writetomarri, linuxppc-dev
In-Reply-To: <1262586327.2173.365.camel@pasglop>
UGxlYXNlIHNlZSBteSBhbnN3ZXJzIGluIGxpbmUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBCZW5qYW1pbiBIZXJyZW5zY2htaWR0IFttYWlsdG86YmVuaEBrZXJuZWwuY3Jh
c2hpbmcub3JnXSANClNlbnQ6IFN1bmRheSwgSmFudWFyeSAwMywgMjAxMCAxMDoyNSBQTQ0KVG86
IFRpcnVtYWxhIFJlZGR5IE1hcnJpDQpDYzogandib3llckBsaW51eC52bmV0LmlibS5jb207IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eHBwYy1kZXZAb3psYWJzLm9yZzsgd3Jp
dGV0b21hcnJpQHlhaG9vLmNvbQ0KU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIEFkZGluZyBQQ0kt
RSBNU0kgc3VwcG9ydCBmb3IgUG93ZXJQQyA0NjBTWCBTT0MuDQoNCk9uIFdlZCwgMjAwOS0xMi0y
MyBhdCAyMzoyOCAtMDgwMCwgdG1hcnJpQGFtY2MuY29tIHdyb3RlOg0KPiBGcm9tOiBUaXJ1bWFs
YSBNYXJyaSA8dG1hcnJpQGFtY2MuY29tPg0KPiANCj4gDQo+IFNpZ25lZC1vZmYtYnk6IFRpcnVt
YWxhIE1hcnJpIDx0bWFycmlAYW1jYy5jb20+DQo+IC0tLQ0KPiAJV2hlbiA0NjBTWCBjb25maWd1
cmVkIGFzIHJvb3QgYXMgYSBlbmQgcG9pbnQgRTEwMDAoSW50ZWxsIEV0aGVybmV0IGNhcmQpDQo+
IAl3YXMgcGx1Z2dlZCBpbnRvIHRoZSBvbmUgb2YgdGhlIFBDSS1FIHBvcnRzLiBJIHdhcyBhYmxl
IHRvIHJ1biB0aGUgdHJhZmZpYw0KPiAJd2l0aCBNU0kgaW50ZXJydXB0cy4NCg0KPlNvIGJlZm9y
ZSBJIGV2ZW4gYWNrIG9yIG5hY2sgdGhhdCBwYXRjaCwgSSBuZWVkIHRvIGJldHRlciB1bmRlcnN0
YW5kIGhvdw0KPnlvdXIgSFcgd29ya3MuIEkndmUgcmVhZCB0aGUgZG9jIG9mIHRoZSA0NjBFWCB0
d2ljZSBhbmQgc3RpbGwgZG9uJ3QNCj5xdWl0ZSBnZXQgaXQgOi0pDQoNCj5TbyBteSB1bmRlcnN0
YW5kaW5nIHNvIGZhciBpcyB0aGF0IHdoZW4gcmVjZXB0aW9uIG9mIE1TSXMgaXMgZW5hYmxlZCwN
Cj53cml0ZXMgdG8gc29tZSBtYWdpYyBhZGRyZXNzIGluIHRoZSBmaXJzdCAxSyBvZiBCQVIwIGFy
ZSBpbnRlcnByZXRlZCBhZA0KPk1TSXMuIFRoZSBNU0kgaW50ZXJydXB0IHZhbHVlIChsb3cgMTYg
Yml0cyBvZiB0aGUgMzItYml0IHN0b3JlIGluIGxpdHRsZQ0KPmVuZGlhbikgaXMgdGh1cyBpbnRl
cnByZXRlZCBhcyBhbiBpbnRlcnJ1cHQgbnVtYmVyIGFuZCBzZW5kIHRvIHRoZSBVSUMuDQoNCj5J
cyB0aGF0IGNvcnJlY3QgPw0KDQpNYXJyaTogWW91IGFyZSBzb21ld2hhdCByaWdodC4gVGhlcmUg
YXJlIHR3byB3YXlzIHRvIGNhdXNlIHRoZSBpbnRlcnJ1cHRzLiANCkluIGZpcnN0IGNhc2UgTVNJ
IGlzIGdlbmVyYXRlZCB0byByb290IGNvbXBsZXggYnkgd3JpdGluZyB0byBhIEFkZHJlc3MgcmVn
aW9uIA0KZnJvbSBFbmRwb2ludCB3aGljaCBpcyBtYXBwZWQgdG8gcm9vdC1jb21wbGV4IHNpZGUg
TVNJIEFyZWEuIA0KCQkJCQkJCQlJbiBzZWNvbmQgY2FzZSByb290IGNvbXBsZXgNCndyaXRlcyB0
aGUgNjRiaXQgTVNJIGFkZHJlc3MgYW5kIGRhdGEgcGF0dGVybiBpbiB0aGUgRW5kcG9pbnQgY29u
ZmlndXJhdGlvbg0Kc3BhY2UuIFRoZW4gZW5kcG9pbnQgc2lkZSBjcHUgd2lsbCB3cml0ZSB0byBy
ZWdpc3RlciBpbiB0aGUgUENJLUUgaW50ZXJydXB0IA0KaGFuZGxlciByZWdpc3RlciBNU0lBU1Mo
TVNJIHNvZnR3YXJlIGFzc2VydCApLCB0aGlzIHdvdWxkIHRyaWdnZXIgYSBtZW1vcnkgDQp3cml0
ZSB0cmFuc2FjdGlvbiBvbiB0aGUgUENJLUUgYnVzIHdpdGggYWRkcmVzcyBmcm9tIHRoZSBjb25m
aWcgc3BhY2UgYW5kIGRhdGENCmZyb20gZGF0YSByZWdpc3Rlci4gQXMgc29vbiBhcyB0aGlzIHRy
YW5zIGFjdGlvbiBjb21lcyBvbiB0aGUgQlVTIFBDSS1FIGhhbmRsZXINCm9uIHJvb3QgY29tcGxl
eCBzbm9vcHMgZm9yIHRoaXMgYWRkcmVzcyBhbmQgY2hlY2tzIGFnYWluc3QgdGhlIGRhdGEgcmVj
ZWl2ZWQuDQpJZiBpdCBtYXRjaGVzIGl0IHdvdWxkIGNhdXNlIGFwcHJvcHJpYXRlIGludGVycnVw
dCBudW1iZXIgYmFzZWQgb24gdGhlIGRhdGEgDQpSZWNlaXZlZC4gRm9yIGV4YW1wbGUgZm9yIGlu
dGVycnVwdCAxICwgZGF0YSB3b3VsZCBiZSAweDQ0NDQwMDAwIGFuZCBpbnRlcnJ1cHQNCjIgZGF0
YSB3b3VsZCBiZSAweDQ0NDQwMDAxIC4NCg0KDQo+Tm93LCB3aGljaCBVSUMgPyBUaGVyZSBhcmUg
YXQgbGVhc3QgMyBpbiB0aGUgNDYwRVggZm9yIGV4YW1wbGUgOi0pDQpNYXJyaTogRWFjaCBvZiA0
IE1TSSBpcyBtYXBwZWQgdG8gVUlDMCAxMiwxMywxNCAmIDE1IGludGVycnVwdCBudW1iZXJzDQoN
Cj5BbHNvLCBVSUNzIGhhdmUgYSBsaW1pdGVkIGFtb3VudCBvZiBpbnB1dHMgYW5kIEkgZG9uJ3Qg
c2VlIG1hbnkNCj5pbnRlcnJ1cHQgc291cmNlcyAicmVzZXJ2ZWQiIGZvciB1c2UgYXMgTVNJcywg
Y2FuIHlvdSBlbmxpZ2h0ZW4gbWUgYSBiaXQNCj5tb3JlIG9uIGhvdyB5b3UgZ2V0IHRvIGNob29z
ZSBhbiBpbnRlcnJ1cHQgc291cmNlIHRvIHVzZSBhcyBNU0kgPw0KDQpNYXJyaTogVGhlcmUgYXJl
IDQgTUlTJ3Mgb3IgMTUgTVNJLVggaW50ZXJydXB0cyBjYW4gYmUgZW5hYmxlZC4gRWFjaCBNU0kg
aXMgaGFyZA0KV2lyZWQgdG8gVUlDMCAxMiB0byAxNS4gRm9yIE1TSS1YIFVJQy0zIDEyIHRvIDI3
Lg0KDQo+T3IgaXMgdGhlcmUgc29tZSB0cmFuc2xhdGlvbiBkb25lID8gSUUuIEluIHRoZSA0NjBF
WCBtYW51YWwsIHRoZXJlIHNlZW0NCj50byBiZSBzcGVjaWZpYyBpbnRlcnJ1cHQgbnVtYmVycyBk
ZWRpY2F0ZWQgdG8gUENJMCBNU0kgMCwgMSAyIGFuZCAzDQo+c3ByZWFkIGJldHdlZW4gVUlDMCBh
bmQgVUlDMSwgYW5kIGEgYmxvY2sgb2YgOCBpbnRlcnJ1cHRzIGluIFVJQzMNCj5yZXNlcnZlZCBm
b3IgUENJLUUgTVNJcy4gSXMgdGhlcmUgYSByZW51bWJlcmluZyBkb25lIGluIEhXIGhlcmUgPw0K
DQoNCg0KPklFLiBZb3VyIHRhYmxlIHNob3dzIGZvciA0NjBFWCBmb3IgZXhhbXBsZSB0aGF0IFBD
SS1FIE1TSSAyIGlzIFVJQzMNCj5pbnB1dCAyNi4gRG8gSSBuZWVkIHRodXMgdG8gcHJvZ3JhbSB0
aGUgZGV2aWNlIHRvIHdyaXRlIGEgIjIiIGluIHRoZSBNU0kNCm1lc3NhZ2Ugb3IgIjI2IiB0byBo
aXQgdGhhdCBpbnRlcnJ1cHQgPw0KDQo+SUUuIEFyZSB5b3UgcnVubmluZyB0aGUgaW5wdXQgbWVz
c2FnZSB0aHJvdWdoIGEgYmluYXJ5IGRlY29kZXIgdGhhdCB0aGVuDQo+c3ByZWFkcyBpbnRvIHZh
cmlvdXMgVUlDIGlucHV0IGxpbmVzID8NCg0KDQpNYXJyaTogWWVzIGVhY2ggTVNJIGlzIGhhcmQg
d2lyZWQgdG8gZGlmZmVyZW50IGludGVycnVwdCBudW1iZXIgaW4gVUlDIHJlZ2lzdGVycy4NCk1J
UyBpbnRlcnJ1cHQgbnVtYmVyIHRvIFVJQyBpcyBub3QgcHJvZ3JhbW1hYmxlIC4gSXQgaXMgZml4
ZWQuDQoNCg0KPk5vdyBzb21lIGNvbW1lbnRzOg0KDQoNCj4gZGlmZiAtLWdpdCBhL2FyY2gvcG93
ZXJwYy9ib290L2R0cy9yZWR3b29kLmR0cyBiL2FyY2gvcG93ZXJwYy9ib290L2R0cy9yZWR3b29k
LmR0cw0KPiBpbmRleCA4MTYzNmMwLi42YzIwZmFmIDEwMDY0NA0KPiAtLS0gYS9hcmNoL3Bvd2Vy
cGMvYm9vdC9kdHMvcmVkd29vZC5kdHMNCj4gKysrIGIvYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL3Jl
ZHdvb2QuZHRzDQo+IEBAIC0zNTcsNiArMzU3LDIxIEBADQo+ICAJCQkJMHgwIDB4MCAweDAgMHgz
ICZVSUMzIDB4YSAweDQgLyogc3dpenpsZWQgaW50IEMgKi8NCj4gIAkJCQkweDAgMHgwIDB4MCAw
eDQgJlVJQzMgMHhiIDB4NCAvKiBzd2l6emxlZCBpbnQgRCAqLz47DQo+ICAJCX07DQo+ICsgIAkJ
TVNJOiBwcGM0eHgtbXNpQDQwMDMwMDAwMCB7DQo+ICsgIAkJCWNvbXBhdGlibGUgPSAiYW1jYyxw
cGM0eHgtNDYwc3gtbXNpIiwgInBwYzR4eC1tc2kiOw0KPiArICAJCQlyZWcgPSA8IDB4NCAweDAw
MzAwMDAwIDB4MTAwDQo+ICsgIAkJCQkweDQgMHgwMDMwMDAwMCAweDEwMD47DQo+ICsgIAkJCXNk
ci1iYXNlID0gPDB4M0IwPjsNCj4gKyAgCQkJaW50ZXJydXB0cyA9PDAgMSAyIDM+Ow0KPiArICAJ
CQlpbnRlcnJ1cHQtcGFyZW50ID0gPCZNU0k+Ow0KPiArICAJCQkjaW50ZXJydXB0LWNlbGxzID0g
PDE+Ow0KPiArICAJCQkjYWRkcmVzcy1jZWxscyA9IDwwPjsNCj4gKyAgCQkJI3NpemUtY2VsbHMg
PSA8MD47DQo+ICsgIAkJCWludGVycnVwdC1tYXAgPSA8MCAmVUlDMCAweEMgMQ0KPiArICAJCQkJ
MSAmVUlDMCAweDBEIDENCj4gKyAgCQkJCTIgJlVJQzAgMHgwRSAxDQo+ICsgIAkJCQkzICZVSUMw
IDB4MEYgMT47DQo+ICsgIAkJfTsNCg0KPldvdyAhIFRoYXQncyB0aGUgbW90aGVyIG9mIGFsbCBk
ZXZpY2UtdHJlZSBoYWNrcyA6LSkgU28geW91IGFyZSB1c2luZw0KPnRoZSAiaW50ZXJydXB0cyIg
cHJvcGVydHkgb2YgdGhlIE1TSSBub2RlIHRvIHJlcHJlc2VudCB0aGUgTVNJDQo+aW50ZXJydXB0
cyB5b3UgaGFuZCBvdXQsIGFuZCB5b3UgbWFrZSBpdCBpdHMgb3duIGludGVycnVwdC1wYXJlbnQs
IHVzaW5nDQo+YW4gaW50ZXJydXB0LW1hcCBpbiBpdHNlbGYgdG8gY29udmVydCB0aGVtIGludG8g
VUlDIGludGVycnVwdHMgOi0pDQo+U25lYWt5Li4uIEhlbGwsIGl0IHdpbGwgd29yayBzbyB3aHkg
bm90ID8NCg0KDQpNYXJyaTogQlRXIHRoZXJlIGFyZSBzb21lIG90aGVyIHByb2Nlc3NvcnMgdXNp
bmcgdGhlIHNpbWlsYXIgd2F5Lg0KDQoNCj4gK3N0YXRpYyBzdHJ1Y3QgcHBjNHh4X21zaSAqcHBj
NHh4X21zaTsNCj4gKw0KPiArc3RydWN0IHBwYzR4eF9tc2lfZmVhdHVyZSB7DQo+ICsJdTMyIHBw
YzR4eF9waWNfaXA7DQo+ICsJdTMyIG1zaWlyX29mZnNldDsNCj4gK307DQo+ICsNCj4gK3N0YXRp
YyBpbnQgcHBjNHh4X21zaV9pbml0X2FsbG9jYXRvcihzdHJ1Y3QgcHBjNHh4X21zaSAqbXNpX2Rh
dGEpDQo+ICt7DQo+ICsJaW50IHJjOw0KPiArDQo+ICsJcmMgPSBtc2lfYml0bWFwX2FsbG9jKCZt
c2lfZGF0YS0+Yml0bWFwLCBOUl9NU0lfSVJRUywNCj4gKwkJCQltc2lfZGF0YS0+aXJxaG9zdC0+
b2Zfbm9kZSk7DQo+ICsJaWYgKHJjKQ0KPiArCQlyZXR1cm4gcmM7DQo+ICsJcmMgPSBtc2lfYml0
bWFwX3Jlc2VydmVfZHRfaHdpcnFzKCZtc2lfZGF0YS0+Yml0bWFwKTsNCj4gKwlpZiAocmMgPCAw
KSB7DQo+ICsJCW1zaV9iaXRtYXBfZnJlZSgmbXNpX2RhdGEtPmJpdG1hcCk7DQo+ICsJCXJldHVy
biByYzsNCj4gKwl9DQo+ICsJcmV0dXJuIDA7DQo+ICt9DQoNCj5PayBzbyBoZXJlIEkgc3RhcnQg
aGF2aW5nIHByb2JsZW1zIDotKSBGaXJzdCB5b3UgYWxsb2NhdGUgYSBiaXRtYXAgZm9yDQo+dGhl
IE1TSXMgb2YgYSBmaXhlZCBudW1iZXIsIGRlc3BpdGUgdGhlIGZhY3QgdGhhdCB0aGVyZSBzZWVt
IHRvIGJlIGENCj5kaWZmZXJlbnQgbnVtYmVyIG9mIE1TSXMgc3VwcG9ydGVkIGRlcGVuZGluZyBv
biB3aGF0IHBhcnQvYnJpZGdlIHlvdSBhcmUNCj51c2luZy4gVGhlbiwgeW91IHRyeSB0byBjYWxs
IG1zaV9iaXRtYXBfcmVzZXJ2ZV9kdF9od2lycXMoKS4uLiB3aHkNCj50aGF0ID8gVGhpcyBpcyBt
ZWFudCB0byBiZSB1c2VkIHdoZW4geW91IGRvbid0IGtub3cgd2hhdCBpbnRlcnJ1cHQNCj5udW1i
ZXJzIGFyZSByZXNlcnZlZCBmb3IgdXNlIGJ5IE1TSXMgaW4geW91ciBzeXN0ZW0sIGl0J3MgYSBi
aXQgZmlzaHkgdG8NCj5iZSBob25lc3QsIHdlIHVzZSBpdCBvbiBwb3dlcm1hYyBtb3N0bHkgOi0p
DQoNCk1hcnJpOiBQcm9iYWJseSB5b3UgYXJlIHJpZ2h0LiBMZXQgbWUgdHJ5IHRha2UgdGhpcyBv
dXQuIA0KDQo+ICtzdGF0aWMgdm9pZCBwcGM0eHhfbXNpX2Nhc2NhZGUodW5zaWduZWQgaW50IGly
cSwgc3RydWN0IGlycV9kZXNjICpkZXNjKQ0KPiArew0KPiArCXVuc2lnbmVkIGludCBjYXNjYWRl
X2lycTsNCj4gKwlzdHJ1Y3QgcHBjNHh4X21zaSAqbXNpX2RhdGEgPSBwcGM0eHhfbXNpOw0KPiAr
CWludCBtc2lyX2luZGV4ID0gLTE7DQo+ICsNCj4gKwlyYXdfc3Bpbl9sb2NrKCZkZXNjLT5sb2Nr
KTsNCj4gKwlpZiAoZGVzYy0+Y2hpcC0+bWFza19hY2spIHsNCj4gKwkJZGVzYy0+Y2hpcC0+bWFz
a19hY2soaXJxKTsNCj4gKwl9IGVsc2Ugew0KPiArCQlkZXNjLT5jaGlwLT5tYXNrKGlycSk7DQo+
ICsJCWRlc2MtPmNoaXAtPmFjayhpcnEpOw0KPiArCX0NCj4gKw0KPiArCWlmICh1bmxpa2VseShk
ZXNjLT5zdGF0dXMgJiBJUlFfSU5QUk9HUkVTUykpDQo+ICsJCWdvdG8gdW5sb2NrOw0KPiArDQo+
ICsJbXNpcl9pbmRleCA9IChpbnQpZGVzYy0+aGFuZGxlcl9kYXRhOw0KPiArDQo+ICsJaWYgKG1z
aXJfaW5kZXggPj0gTlJfTVNJX0lSUVMpDQo+ICsJCWNhc2NhZGVfaXJxID0gTk9fSVJROw0KPiAr
DQo+ICsJZGVzYy0+c3RhdHVzIHw9IElSUV9JTlBST0dSRVNTOw0KPiArDQo+ICsJY2FzY2FkZV9p
cnEgPSBpcnFfbGluZWFyX3Jldm1hcChtc2lfZGF0YS0+aXJxaG9zdCwgbXNpcl9pbmRleCk7DQo+
ICsJaWYgKGNhc2NhZGVfaXJxICE9IE5PX0lSUSkNCj4gKwkJZ2VuZXJpY19oYW5kbGVfaXJxKGNh
c2NhZGVfaXJxKTsNCj4gKwlkZXNjLT5zdGF0dXMgJj0gfklSUV9JTlBST0dSRVNTOw0KPiArDQo+
ICsJaWYgKCEoZGVzYy0+c3RhdHVzICYgSVJRX0RJU0FCTEVEKSAmJiBkZXNjLT5jaGlwLT51bm1h
c2spDQo+ICsJCWRlc2MtPmNoaXAtPnVubWFzayhpcnEpOw0KPiArdW5sb2NrOg0KPiArCXJhd19z
cGluX3VubG9jaygmZGVzYy0+bG9jayk7DQo+ICt9DQoNCj5Ob3csIHRoYXQncyByZWFsbHkgYSB3
ZWlyZCBpZGVhLiBXaHkgYXJlIHlvdSBtYWtpbmcgaXQgYSBjYXNjYWRlZA0KPmludGVycnVwdCBj
b250cm9sbGVyID8gVGhhdCBpcyBqdXN0IGdyYXR1aXRvdXMgb3ZlcmhlYWQuIFlvdSBjb3VsZCBo
YXZlDQo+dGhlIE1TSSBoYW5kbGluZyBkaXJlY3RseSBoYW5kIG91dCB0aGUgYXBwcm9wcmlhdGUg
VUlDIGludGVycnVwdHMgYW5kDQo+aGF2ZSB0aGVtIGNhbGwgZGlyZWN0bHkgaW50byB0aGUgZHJp
dmVyLiBUaGUgYWJvdmUgYWRkcyBzaWduaWZpY2FudA0KPm92ZXJoZWFkIHRvIE1TSSBwcm9jZXNz
aW5nLg0KTWFycmk6IExldCBtZSB0aGluayBtb3JlIGFib3V0IHRoaXMuDQoNCj4gK3N0YXRpYyB2
b2lkIHBwYzR4eF9jb21wb3NlX21zaV9tc2coc3RydWN0IHBjaV9kZXYgKnBkZXYsIGludCBod2ly
cSwNCj4gKwkJCQkJc3RydWN0IG1zaV9tc2cgKm1zZykNCj4gK3sNCj4gKwlzdHJ1Y3QgcHBjNHh4
X21zaSAqbXNpX2RhdGEgPSBwcGM0eHhfbXNpOw0KPiArDQo+ICsJbXNnLT5hZGRyZXNzX2xvID0g
bXNpX2RhdGEtPm1zaV9hZGRyX2xvOw0KPiArCW1zZy0+YWRkcmVzc19oaSA9IG1zaV9kYXRhLT5t
c2lfYWRkcl9oaTsNCj4gKwltc2ctPmRhdGEgPSBod2lycTsNCj4gK30NCj4gKw0KPiAraW50IHBw
YzR4eF9zZXR1cF9tc2lfaXJxcyhzdHJ1Y3QgcGNpX2RldiAqZGV2LCBpbnQgbnZlYywgaW50IHR5
cGUpDQo+ICt7DQo+ICsJc3RydWN0IG1zaV9kZXNjICplbnRyeTsNCj4gKwlpbnQgcmMsIGh3aXJx
Ow0KPiArCXVuc2lnbmVkIGludCB2aXJxOw0KPiArCXN0cnVjdCBtc2lfbXNnIG1zZzsNCj4gKwlz
dHJ1Y3QgcHBjNHh4X21zaSAqbXNpX2RhdGEgPSBwcGM0eHhfbXNpOw0KPiArDQo+ICsNCj4gKwls
aXN0X2Zvcl9lYWNoX2VudHJ5KGVudHJ5LCAmZGV2LT5tc2lfbGlzdCwgbGlzdCkgew0KPiArCQlo
d2lycSA9IG1zaV9iaXRtYXBfYWxsb2NfaHdpcnFzKCZtc2lfZGF0YS0+Yml0bWFwLCAxKTsNCj4g
KwkJaWYgKGh3aXJxIDwgMCkgew0KPiArCQkJcmMgPSBod2lycTsNCj4gKwkJCWRldl9lcnIoJmRl
di0+ZGV2LCAiJXM6IGZhaWwgYWxsb2NhdGluZyBtc2lcDQo+ICsJCQkJCWludGVycnVwdFxuIiwJ
X19mdW5jX18pOw0KPiArCQkJZ290byBvdXRfZnJlZTsNCj4gKwkJfQ0KPiArDQo+ICsJCXByX2Rl
YnVnKEtFUk5fSU5GTyJtaXMgaXMgJXBcbiIsIG1zaV9kYXRhLT5pcnFob3N0KTsNCj4gKwkJdmly
cSA9IGlycV9jcmVhdGVfbWFwcGluZyhtc2lfZGF0YS0+aXJxaG9zdCwgaHdpcnEpOw0KPiArCQlp
ZiAodmlycSA9PSBOT19JUlEpIHsNCj4gKwkJCWRldl9lcnIoJmRldi0+ZGV2LCAiJXM6IGZhaWwg
bWFwcGluZyBpcnFcbiIsIF9fZnVuY19fKTsNCj4gKwkJCXJjID0gLUVOT1NQQzsNCj4gKwkJCWdv
dG8gb3V0X2ZyZWU7DQo+ICsJCX0NCj4gKw0KPiArCQlzZXRfaXJxX21zaSh2aXJxLCBlbnRyeSk7
DQo+ICsJCXBwYzR4eF9jb21wb3NlX21zaV9tc2coZGV2LCBod2lycSwgJm1zZyk7DQo+ICsJCXdy
aXRlX21zaV9tc2codmlycSwgJm1zZyk7DQo+ICsJfQ0KPiArDQo+ICsJcmV0dXJuIDA7DQo+ICtv
dXRfZnJlZToNCj4gKwlyZXR1cm4gcmM7DQo+ICt9DQoNCj5TaW1pbGFyIGhlcmUuIFlvdSBjcmVh
dGUgdGhpcyB3aG9sZSBsYXllciBvZiBzZWNvbmRhcnkgaW50ZXJydXB0IGhvc3QNCj53aGlsZSB5
b3UgY291bGQganVzdCBoYW5kIG91dCBleGlzdGluZyBVSUMgaW50ZXJydXB0cyBubyA/DQpNYXJy
aTogTGV0IG1lIHRoaW5rIG1vcmUgaGVyZSB0b28uDQogDQogLi4uLy4uLg0KDQo+ICsNCj4gK3N0
YXRpYyBpbnQgX19kZXZpbml0IHBwYzR4eF9tc2lfcHJvYmUoc3RydWN0IG9mX2RldmljZSAqZGV2
LA0KPiArCQkJCQljb25zdCBzdHJ1Y3Qgb2ZfZGV2aWNlX2lkICptYXRjaCkNCj4gK3sNCj4gKwlz
dHJ1Y3QgcHBjNHh4X21zaSAqbXNpOw0KPiArCXN0cnVjdCByZXNvdXJjZSByZXMsIHJtc2k7DQo+
ICsJaW50IGksIGNvdW50Ow0KPiArCWludCByYzsNCj4gKwlpbnQgdmlydF9tc2lyOw0KPiArCWNv
bnN0IHUzMiAqcDsNCj4gKwljb25zdCB1MzIgKnNkcl9iYXNlOw0KPiArCXUzMiAqbXNpX3ZpcnQg
PSBOVUxMOw0KPiArCWRtYV9hZGRyX3QgbXNpX3BoeXM7DQo+ICsNCj4gKw0KPiArCW1zaSA9IGt6
YWxsb2Moc2l6ZW9mKHN0cnVjdCBwcGM0eHhfbXNpKSwgR0ZQX0tFUk5FTCk7DQo+ICsJaWYgKCFt
c2kpIHsNCj4gKwkJZGV2X2VycigmZGV2LT5kZXYsICJObyBtZW1vcnkgZm9yIE1TSSBzdHJ1Y3R1
cmVcbiIpOw0KPiArCQlyYyA9IC1FTk9NRU07DQo+ICsJCWdvdG8gZXJyb3Jfb3V0Ow0KPiArCX0N
Cj4gKw0KPiArCW1zaS0+aXJxaG9zdCA9IGlycV9hbGxvY19ob3N0KGRldi0+bm9kZSwgSVJRX0hP
U1RfTUFQX0xJTkVBUiwNCj4gKwkJCQkgICAgICBOUl9NU0lfSVJRUywgJnBwYzR4eF9tc2lfaG9z
dF9vcHMsIDApOw0KPiArCWlmIChtc2ktPmlycWhvc3QgPT0gTlVMTCkgew0KPiArCQlkZXZfZXJy
KCZkZXYtPmRldiwgIk5vIG1lbW9yeSBmb3IgTVNJIGlycWhvc3RcbiIpOw0KPiArCQlyYyA9IC1F
Tk9NRU07DQo+ICsJCWdvdG8gZXJyb3Jfb3V0Ow0KPiArCX0NCg0KPlNhbWUgY29tbWVudCwgaWUs
IHdoeSBhIHNlcGFyYXRlIGlycSBob3N0ID8NCk1hcnJpOiBPayBJIHdpbGwgY2hlY2sgdGhpcyBv
bmUuDQo+ICsNCj4gKwkvKiBHZXQgTVNJIHJhbmdlcyAqLw0KPiArCXJjID0gb2ZfYWRkcmVzc190
b19yZXNvdXJjZShkZXYtPm5vZGUsIDAsICZybXNpKTsNCj4gKwlpZiAocmMpIHsNCj4gKwkJZGV2
X2VycigmZGV2LT5kZXYsICIlcyByZXNvdXJjZSBlcnJvciFcbiIsDQo+ICsJCQkJZGV2LT5ub2Rl
LT5mdWxsX25hbWUpOw0KPiArCQlnb3RvIGVycm9yX291dDsNCj4gKwl9DQo+ICsNCj4gKw0KPiAr
CS8qIEdldCB0aGUgTVNJIHJlZyBiYXNlICovDQo+ICsJcmMgPSBvZl9hZGRyZXNzX3RvX3Jlc291
cmNlKGRldi0+bm9kZSwgMSwgJnJlcyk7DQo+ICsJaWYgKHJjKSB7DQo+ICsJCWRldl9lcnIoJmRl
di0+ZGV2LCAiJXMgcmVzb3VyY2UgZXJyb3IhXG4iLA0KPiArCQkJCWRldi0+bm9kZS0+ZnVsbF9u
YW1lKTsNCj4gKwkJZ290byBlcnJvcl9vdXQ7DQo+ICsJfQ0KPiArCS8qIEdldCB0aGUgc2RyLWJh
c2UgKi8NCj4gKwlzZHJfYmFzZSA9ICh1MzIgKilvZl9nZXRfcHJvcGVydHkoZGV2LT5ub2RlLCAi
c2RyLWJhc2UiLCBOVUxMKTsNCj4gKwlpZiAoc2RyX2Jhc2UgPT0gTlVMTCkgew0KPiArCQlkZXZf
ZXJyKCZkZXYtPmRldiwgIiVzIHJlc291cmNlIGVycm9yIVxuIiwNCj4gKwkJCQlkZXYtPm5vZGUt
PmZ1bGxfbmFtZSk7DQo+ICsJCWdvdG8gZXJyb3Jfb3V0Ow0KPiArCX0NCj4gKwltc2ktPnNkcl9i
YXNlID0gKnNkcl9iYXNlOw0KPiArCW10ZGNyaShTRFIwLCBtc2ktPnNkcl9iYXNlLCByZXMuc3Rh
cnQgPj4gMzIpOw0KPiArCW10ZGNyaShTRFIwLCBtc2ktPnNkcl9iYXNlICsgMSwgcmVzLnN0YXJ0
ICYgMHhGRkZGRkZGRik7DQo+ICsJbXNpLT5tc2lfcmVncyA9IGlvcmVtYXAocmVzLnN0YXJ0LCBy
ZXMuZW5kIC0gcmVzLnN0YXJ0ICsgMSk7DQo+ICsJaWYgKCFtc2ktPm1zaV9yZWdzKSB7DQo+ICsJ
CWRldl9lcnIoJmRldi0+ZGV2LCAiaW9yZW1hcCBwcm9ibGVtIGZhaWxlZFxuIik7DQo+ICsJCWdv
dG8gZXJyb3Jfb3V0Ow0KPiArCX0NCj4gKwkvKiBNU0kgcmVnaW9uIGFsd2F5cyBtYXBwZWQgaW4g
NEdCIHJlZ2lvbiovDQo+ICsJbXNpLT5tc2lfYWRkcl9oaSA9IDB4MDsNCj4gKwltc2lfdmlydCA9
IGRtYV9hbGxvY19jb2hlcmVudCgmZGV2LT5kZXYsIDY0LCAmbXNpX3BoeXMsDQo+ICsJCQlHRlBf
S0VSTkVMKTsNCj4gKwlpZiAobXNpX3ZpcnQgPT0gTlVMTCkgew0KPiArCQlkZXZfZXJyKCZkZXYt
PmRldiwgIk5vIG1lbW9yeSBmb3IgTVNJIG1lbSBzcGFjZVxuIik7DQo+ICsJCXJjID0gLUVOT01F
TTsNCj4gKwkJZ290byBlcnJvcl9vdXQ7DQo+ICsJfQ0KPiArCW1zaS0+bXNpX2FkZHJfbG8gPSAo
dTMyKW1zaV9waHlzOw0KDQo+Tm93LCB3aGF0IGlzIHRoZSBhYm92ZSBmb3IgPyBBcmUgdGhlIE1T
SSB3cml0ZXMgZG9uZSBieSB0aGUgZGV2aWNlDQo+YWN0dWFsbHkgaGl0dGluZyBtZW1vcnkgYXMg
d2VsbCA/IEkgd291bGQgaGF2ZSBleHBlY3RlZCB0aGVtIHRvIGJlDQo+ZmlsdGVyZWQgYnkgdGhl
IGJyaWRnZSBvbiB0aGUgd2F5IHVwLCBhcmUgdGhleSBub3QgPw0KDQo+SSBzdXBwb3NlIGl0IGdp
dmVzIHlvdSBhIGNoZWFwIHdheSB0byBvYnRhaW4gYSBiaXQgb2YgdW51c2VkIGFkZHJlc3MNCj5z
cGFjZS4uLg0KTWFycmk6ICBQQ0ktRSBpbnRlcnJ1cHQgaGFuZGxlciBuZWVkcyBhbiBhZGRyZXNz
IHJlZ2lvbiB3aGVyZSBpdCBjYW4gc25vb3AgDQpUaGUgYWRkcmVzcyBhbmQgZGF0YSB0byBjYXVz
ZSBhcHByb3ByaWF0ZSBNU0kuDQoNCj4gKwkvKiBQcm9nYW0gdGhlIEludGVycnVwdCBoYW5kbGVy
IFRlcm1pbmF0aW9uIGFkZHIgcmVnaXN0ZXJzICovDQo+ICsJb3V0X2JlMzIobXNpLT5tc2lfcmVn
cyArIFBFSUhfVEVSTUFESCwgbXNpLT5tc2lfYWRkcl9oaSk7DQo+ICsJb3V0X2JlMzIobXNpLT5t
c2lfcmVncyArIFBFSUhfVEVSTUFETCwgbXNpLT5tc2lfYWRkcl9sbyk7DQo+ICsNCj4gKwkvKiBQ
cm9ncmFtIE1TSSBFeHBlY3RlZCBkYXRhIGFuZCBNYXNrIGJpdHMgKi8NCj4gKwlvdXRfYmUzMiht
c2ktPm1zaV9yZWdzICsgUEVJSF9NU0lFRCwgTVNJX0RBVEFfUEFUVEVSTik7DQo+ICsJb3V0X2Jl
MzIobXNpLT5tc2lfcmVncyArIFBFSUhfTVNJTUssIE1TSV9EQVRBX1BBVFRFUk4pOw0KDQo+Q2Fu
IHlvdSB0ZWxsIG1lIGEgYml0IG1vcmUgYWJvdXQgd2hhdCB0aGUgYWJvdmUgaXMgYWJvdXQgPw0K
TWFycmk6IEFzIEkgcHJldmlvdXNseSBzYWlkIFBDSS1FIGludGVycnVwdCBoYW5kbGVyIHNub29w
cyBzeXN0ZW0gYnVzDQpGb3IgY2VydGFpbiBhZGRyZXNzIGFuZCBkYXRhLCB0aGlzIGFkZHJlc3Mg
Y291bGQgYmUgY2FsbGluZyBpbiB0aGUgDQpERFIgbWVtb3J5IHJlZ2lvbiAuIFdoZXJlIEREUiBj
b250cm9sbGVyIGNhbiBxdWV1ZSBjb21tYW5kcyBhbmQgc29tZSB0aW1lcyANClRoaXMgbWlnaHQg
Y2F1c2UgZGVsYXkgaW4gQUNLLiBUaGlzIHdpbGwgdGVybWluYXRlIHRoZSB3cml0ZSB0cmFuc2Fj
dGlvbg0KQW5kIHNlbmRzIGltbWVkaWF0ZSBBQ0suDQoNCj5BbHNvLCBpdCBsb29rcyBsaWtlIHlv
dXIgY29kZSB3b3VsZCB3b3JrIGZvciBvdGhlciBTb0NzIGxpa2UgNDYwRVgNCj5ldGMuLi4gYnkg
anVzdCB1cGRhdGluZyB0aGUgLmR0cyByaWdodCA/IENhcmUgdG8gdXBkYXRlIGEgZmV3IG1vcmUN
Cj5ib2FyZHMgc28gSSBjYW4gdGVzdCBvbiBteSBjYW55b25sYW5kcyA/IDotKQ0KDQpJbiB0aGUg
bmV4dCBwYXRjaCBJIHdpbGwgdHJ5IGFkZCB0aGUgNDYwRXgoQ2FueW9ubGFuZHMgc3VwcG9ydCB0
b28pDQoNCg0KUmVnYXJkcywNCk1hcnJpDQo=
^ permalink raw reply
* Re: [PATCH] Re: ZILOG serial port broken in 2.6.32
From: Rob Landley @ 2010-01-11 7:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: paulus, linuxppc-dev
In-Reply-To: <1263178936.724.91.camel@pasglop>
On Sunday 10 January 2010 21:02:16 Benjamin Herrenschmidt wrote:
> On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
> > On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > > > Ok, here's the fix. It's not the _right_ fix, but it Works For Me
> > > > (tm) and I'll leave it to you guys to figure out what this _means_:
> > >
> > > I've failed to reproduce so far on both a Wallstreet powerbook (similar
> > > generation and chipset as your beige G3) and a G5 with an added serial
> > > port using current upstream...
> > >
> > > Can you verify it's still there ? I might be able to reproduce on a
> > > Beige G3 as well next week.
> >
> > It's still there on qemu 0.11.0's "g3beige" emulation when you use
> > CONFIG_SERIAL_PMACZILOG as the serial console. (QEMU 0.10.x used a 16550
> > serial chip for its g3beige emulation instead of the actual ZILOG one.)
> > Still dunno if it's a qemu or bug or a kernel bug, I just know that
> > kernel patch fixes it for me, and it comes back without the patch.
> >
> > I tested 2.6.32. Haven't tried the 2.6.32.3 but don't see why it would
> > change this...
>
> Ok so I compiled qemu and things are a bit strange.
>
> How do you get the output of both channels of the serial port with it ?
>
> If I use -nographics, what happens is that OpenBIOS, for some reason,
> tells qemu that the console on the second channel of the ESCC.
Instead of "-nographic", you could try "-serial stdio" instead?
> I see my kernel messages in the console if I do console=ttyPZ0 but the
> debug stuff goes where udbg initializes it, which is where OpenBIOS says
> the FW console is, which is channel B and I don't know how to "see" that
> with qemu.
I'm just trying to get a serial console, which is why I'm booting the sucker
with:
qemu-system-ppc -M g3beige -nographic -no-reboot -kernel zImage-powerpc -hda
image-powerpc.sqf -append "root=/dev/hda rw init=/usr/sbin/init.sh panic=1
PATH=/usr/bin console=ttyS0"
I didn't even know there were more debug messages...
I have CONFIG_SERIAL_PMACZILOG_TTYS=y of course:
pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
ttyS0 at MMIO 0x80813020 (irq = 16) is a Z85c30 ESCC - Serial port
ttyS1 at MMIO 0x80813000 (irq = 17) is a Z85c30 ESCC - Serial port
CONFIG_SERIO=y
CONFIG_SERIAL_PMACZILOG=y
CONFIG_SERIAL_PMACZILOG_TTYS=y
CONFIG_SERIAL_PMACZILOG_CONSOLE=y
> I do see it crash due to a message from the kernel but I can't get into
> xmon which is a pain.
Does the -serial stdio thing help?
(I know to switch between screens in the qemu x11 window, it's ctrl-alt-number
(so ctrl-alt-1, ctrl-alt-2, and so on. I really don't use 'em much, though.)
> If I modify the kernel to force udbg on channel A (same channel as the
> console), then the problem doesn't appear (it doesn't crash) :-)
You can attach gdb to qemu via the "qemu -s" option and then in gdb use the
"target remote" stuff like you would with gdbserver. It acts a bit like you've
connected it to a jtag through openocd, if that helps...
(I know qemu has many, many options I don't really use much.)
> Cheers
> Ben.
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* Re: [PATCH] pmac_zilog: Workaround problem due to interrupt on closed port
From: Rob Landley @ 2010-01-11 8:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, David Miller
In-Reply-To: <1263181902.724.94.camel@pasglop>
On Sunday 10 January 2010 21:51:42 Benjamin Herrenschmidt wrote:
> It seems that in qemu, we can see an interrupt in R3 despite the
> fact that it's masked in W1. The chip doesn't actually issue an
> interrupt, but we can "see" it when taking an interrupt for the
> other channel. This may be a qemu bug ... or not, so let's be
> safe and avoid calling into the UART layer when that happens which
> woulc cause a crash.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Rob Landley <rob@landley.net>
Tested it, and it worked for me.
Thanks,
Rob
--
Latency is more important than throughput. It's that simple. - Linus Torvalds
^ permalink raw reply
* RE: PCI-PCI bridge scanning broken on 460EX
From: Stef van Os @ 2010-01-11 9:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stefan Roese, Feng Kan
In-Reply-To: <1263159117.724.15.camel@pasglop>
Hello=20Felix,
I=20had=20a=20problem=20similar=20to=20this=20on=20the=20440GX,=20the=20P=
CI=20code=20was=20not
sending=20type=201=20transactions=20when=20scanning=20behind=20bridges.=
=20Perhaps=20you
could=20try=20this:
Index:=20linux/arch/powerpc/sysdev/ppc4xx_pci.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
---=20linux/arch/powerpc/sysdev/ppc4xx_pci.c=20=20=20=20=20=20(revision=
=2026)
+++=20linux/arch/powerpc/sysdev/ppc4xx_pci.c=20=20=20=20=20=20(revision=
=2027)
@@=20-569,7=20+569,7=20@@
=20=20=20=20=20=20=20=20hose->last_busno=20=3D=20bus_range=20?=20bus_rang=
e[1]=20:=200xff;
=20=20=20=20=20=20=20=20/*=20Setup=20config=20space=20*/
-=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
0);
+=20=20=20=20=20=20=20setup_indirect_pci(hose,=20rsrc_cfg.start,=20rsrc_c=
fg.start=20+=200x4,
PPC_INDIRECT_TYPE_SET_CFG_TYPE);
=20=20=20=20=20=20=20=20/*=20Disable=20all=20windows=20*/
=20=20=20=20=20=20=20=20writel(0,=20reg=20+=20PCIX0_POM0SA);
With=20kind=20regards=20/=20Met=20vriendelijke=20groet,
Stef=20van=20Os
Prodrive=20B.V.=20
-----Original=20Message-----
From:=20linuxppc-dev-bounces+stef.van.os=3Dprodrive.nl@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+stef.van.os=3Dprodrive.nl@lists.ozlabs.org]
On=20Behalf=20Of=20Benjamin=20Herrenschmidt
Sent:=20zondag=2010=20januari=202010=2022:32
To:=20Felix=20Radensky
Cc:=20linuxppc-dev@ozlabs.org;=20Stefan=20Roese;=20Feng=20Kan
Subject:=20Re:=20PCI-PCI=20bridge=20scanning=20broken=20on=20460EX
>=20OK,=20I'll=20try=20writing=20byte=20by=20byte.=20The=20funny=20thing=
=20is=20the=20u-boot=20also=20
>=20writes=20the=20same=20value=20to=20PCI_PRIMARY_BUS=20register=20and=
=20it=20doesn't=20cause
>=20reset.
Maybe=20the=20bridge=20doesn't=20want=20to=20be=20programmed=20more=20tha=
n=20once=20on=20these
registers=20?=20In=20any=20case,=20that's=20very=20very=20fishy....=20I=
=20wonder=20if=20the
bridge=20is=20causing=20a=20PCI=20reset=20-upstream-=20(which=20would=20r=
eally=20be=20a=20weird
thing=20to=20do)=20and=20the=20460=20is=20turning=20that=20into=20a=20sys=
tem=20reset=20?=20Check=20if
there=20are=20ways=20to=20control=20how=20the=20460=20reacts=20to=20PCI=
=20resets...
In=20any=20case,=20it=20looks=20like=20a=20fucked=20up=20bridge=20to=20me=
.=20I=20don't=20suppose
you've=20seen=20anything=20in=20the=20bridge=20data=20sheet=20or=20errata=
=20sheet=20that=20could
explain=20what=20it's=20doing=20?
Cheers,
Ben.
_______________________________________________
Linuxppc-dev=20mailing=20list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Disclaimer:=20The=20information=20contained=20in=20this=20email,=20includ=
ing=20any=20attachments=20is=20
confidential=20and=20is=20for=20the=20sole=20use=20of=20the=20intended=20=
recipient(s).=20Any=20unauthorized=20
review,=20use,=20disclosure=20or=20distribution=20is=20prohibited.=20If=
=20you=20are=20not=20the=20intended=20
recipient,=20please=20notify=20the=20sender=20immediately=20by=20replying=
=20to=20this=20message=20and=20
destroy=20all=20copies=20of=20this=20message=20and=20any=20attachments.
^ permalink raw reply
* Re: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
From: Anton Vorontsov @ 2010-01-11 10:52 UTC (permalink / raw)
To: Wu Jiajun-B06378; +Cc: linuxppc-dev, lsorense, davem, netdev
In-Reply-To: <100CB1A1877FF245BDB7AF83A0E73FFE26BE4D@zch01exm28.fsl.freescale.net>
On Mon, Jan 11, 2010 at 11:47:37AM +0800, Wu Jiajun-B06378 wrote:
>
> 'bd == ugeth->txBd[txQ]' has two possible statuses: 1)full queue.
> 2)empty queue.
> Removing 'netif_queue_stopped() == 0' will make transmitting stopping
> when the queue is full.
>
> I made a new patch for this oops.
[...]
> + if ((bd == ugeth->txBd[txQ]) && (skb == NULL))
> break;
Hm. I wonder why do we need the 'bd == ugeth->txBd[txQ]' check
at all? The null skb will cause a kernel oops anyway.
I think the patch below should be sufficient for the fix.
Can you try it? Or if you tell me how to reproduce the issue
you observe, I can try it myself.
Thanks a lot!
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 41ad2f3..a1a6d06 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3279,13 +3279,12 @@ static int ucc_geth_tx(struct net_device *dev, u8 txQ)
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
- if (bd == ugeth->txBd[txQ]) /* queue empty? */
+ skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
+ if (!skb)
break;
dev->stats.tx_packets++;
- skb = ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
-
if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN &&
skb_recycle_check(skb,
ugeth->ug_info->uf_info.max_rx_buf_length +
^ permalink raw reply related
* Re: [PATCHv2] spi_mpc8xxx: fix WARN_ON on remove after 4c1fba44296
From: Anton Vorontsov @ 2010-01-11 10:57 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell
In-Reply-To: <1262859837-11311-1-git-send-email-jacmet@sunsite.dk>
On Thu, Jan 07, 2010 at 11:23:57AM +0100, Peter Korsgaard wrote:
> Commit 4c1fba44296 (Add support for QE DMA mode and CPM1/CPM2 chips)
> added unconditional calls to _cpm_init() / _cpm_free() from
> probe()/remove(), but only checked if we're actually using CPM mode
> in _init(), causing the WARN_ON in mpc8xxx_spi_free_dummy_rx() for !CPM.
>
> Fix it by adding the same check in _cpm_free() as well.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Grant, can you please push it for 2.6.33?
Thanks!
> ---
> drivers/spi/spi_mpc8xxx.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> Changes since v1:
> Fix return statement, mpc8xxx_spi_cpm_free() has void return type.
> diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
> index 1fb2a6e..674e7a2 100644
> --- a/drivers/spi/spi_mpc8xxx.c
> +++ b/drivers/spi/spi_mpc8xxx.c
> @@ -946,6 +946,9 @@ static void mpc8xxx_spi_cpm_free(struct mpc8xxx_spi *mspi)
> {
> struct device *dev = mspi->dev;
>
> + if (!(mspi->flags & SPI_CPM_MODE))
> + return;
> +
> dma_unmap_single(dev, mspi->dma_dummy_rx, SPI_MRBLR, DMA_FROM_DEVICE);
> dma_unmap_single(dev, mspi->dma_dummy_tx, PAGE_SIZE, DMA_TO_DEVICE);
> cpm_muram_free(cpm_muram_offset(mspi->tx_bd));
> --
> 1.6.5
>
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: PCI-PCI bridge scanning broken on 460EX
From: Felix Radensky @ 2010-01-11 11:48 UTC (permalink / raw)
To: Stef van Os; +Cc: Stefan Roese, Feng Kan, linuxppc-dev
In-Reply-To: <4CD35CD1F8085945B597F80EEC89421303B8AD0C@exc01.bk.prodrive.nl>
Hi Stef,
Stef van Os wrote:
> Hello Felix,
>
> I had a problem similar to this on the 440GX, the PCI code was not
> sending type 1 transactions when scanning behind bridges. Perhaps you
> could try this:
>
> Index: linux/arch/powerpc/sysdev/ppc4xx_pci.c
> ===================================================================
> --- linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 26)
> +++ linux/arch/powerpc/sysdev/ppc4xx_pci.c (revision 27)
> @@ -569,7 +569,7 @@
> hose->last_busno = bus_range ? bus_range[1] : 0xff;
>
> /* Setup config space */
> - setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4,
> 0);
> + setup_indirect_pci(hose, rsrc_cfg.start, rsrc_cfg.start + 0x4,
> PPC_INDIRECT_TYPE_SET_CFG_TYPE);
>
> /* Disable all windows */
> writel(0, reg + PCIX0_POM0SA);
>
>
>
> With kind regards / Met vriendelijke groet,
>
> Stef van Os
>
> Prodrive B.V.
>
>
>
I think you patch is a valid one, and should be applied, but
unfortunately it doesn't fix by problem.
BTW, in u-boot transaction type bit is set correctly.
Felix.
^ permalink raw reply
* RE: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
From: Wu Jiajun-B06378 @ 2010-01-11 11:52 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, lsorense, davem, netdev
In-Reply-To: <20100111105248.GA28580@oksana.dev.rtsoft.ru>
Yes,'if (!skb)' is enough.
You can reproduce transmitting stopping if you use 'if ((bd =3D=3D =
ugeth->txBd[txQ])' and run ipforwarding with MTU=3D64 1Gbps =
100%linerate.
-----Original Message-----
From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
Sent: 2010=C4=EA1=D4=C211=C8=D5 18:53
To: Wu Jiajun-B06378
Cc: linuxppc-dev@ozlabs.org; netdev@vger.kernel.org; =
lsorense@csclub.uwaterloo.ca; davem@davemloft.net
Subject: Re: [PATCH 1/3] ucc_geth: Fix empty TX queue processing
On Mon, Jan 11, 2010 at 11:47:37AM +0800, Wu Jiajun-B06378 wrote:
> =20
> 'bd =3D=3D ugeth->txBd[txQ]' has two possible statuses: 1)full queue.
> 2)empty queue.
> Removing 'netif_queue_stopped() =3D=3D 0' will make transmitting =
stopping=20
> when the queue is full.
>=20
> I made a new patch for this oops.
[...]
> + if ((bd =3D=3D ugeth->txBd[txQ]) && (skb =3D=3D NULL))
> break;
Hm. I wonder why do we need the 'bd =3D=3D ugeth->txBd[txQ]' check at =
all? The null skb will cause a kernel oops anyway.
I think the patch below should be sufficient for the fix.
Can you try it? Or if you tell me how to reproduce the issue you =
observe, I can try it myself.
Thanks a lot!
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c index =
41ad2f3..a1a6d06 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -3279,13 +3279,12 @@ static int ucc_geth_tx(struct net_device *dev, =
u8 txQ)
/* Handle the transmitted buffer and release */
/* the BD to be used with the current frame */
=20
- if (bd =3D=3D ugeth->txBd[txQ]) /* queue empty? */
+ skb =3D ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
+ if (!skb)
break;
=20
dev->stats.tx_packets++;
=20
- skb =3D ugeth->tx_skbuff[txQ][ugeth->skb_dirtytx[txQ]];
-
if (skb_queue_len(&ugeth->rx_recycle) < RX_BD_RING_LEN &&
skb_recycle_check(skb,
ugeth->ug_info->uf_info.max_rx_buf_length +
^ permalink raw reply
* [PATCH 0/8] Update to GE powerpc/86xx based boards.
From: Martyn Welch @ 2010-01-11 12:23 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
The following series implements some minor fixes and updates to the GE
SBC310, SBC610 and PPC9A
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply
* [PATCH 1/8] powerpc/86xx: Add MSI section to GE SBC310 DTS
From: Martyn Welch @ 2010-01-11 12:23 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <20100111121622.8306.87501.stgit@ES-J7S4D2J.amer.consind.ge.com>
Add the MSI section to the DTS file for the GE SBC310.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc310.dts | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index 820c2b3..8ea8d4a 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -338,6 +338,22 @@
device_type = "open-pic";
};
+ msi@41600 {
+ compatible = "fsl,mpc8641-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0
+ 0xe1 0
+ 0xe2 0
+ 0xe3 0
+ 0xe4 0
+ 0xe5 0
+ 0xe6 0
+ 0xe7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
global-utilities@e0000 {
compatible = "fsl,mpc8641-guts";
reg = <0xe0000 0x1000>;
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply related
* [PATCH 2/8] powerpc/86xx: Fix GE SBC310 XMC site support
From: Martyn Welch @ 2010-01-11 12:23 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <20100111121622.8306.87501.stgit@ES-J7S4D2J.amer.consind.ge.com>
From: Malcolm Crossley <malcolm.crossley2@gefanuc.com>
Correction to interrupt map mask for GE SBC310 XMC site and addition of
alias.
Signed-off-by: Malcolm Crossley <malcolm.crossley2@gefanuc.com>
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc310.dts | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc310.dts b/arch/powerpc/boot/dts/gef_sbc310.dts
index 8ea8d4a..8e4efff 100644
--- a/arch/powerpc/boot/dts/gef_sbc310.dts
+++ b/arch/powerpc/boot/dts/gef_sbc310.dts
@@ -32,6 +32,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
+ pci1 = &pci1;
};
cpus {
@@ -374,7 +375,7 @@
clock-frequency = <33333333>;
interrupt-parent = <&mpic>;
interrupts = <0x18 0x2>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
interrupt-map = <
0x0000 0x0 0x0 0x1 &mpic 0x0 0x2
0x0000 0x0 0x0 0x2 &mpic 0x1 0x2
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply related
* [PATCH 3/8] powerpc/86xx: Add MSI section to GE SBC610 DTS
From: Martyn Welch @ 2010-01-11 12:23 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <20100111121622.8306.87501.stgit@ES-J7S4D2J.amer.consind.ge.com>
From: Malcolm Crossley <malcolm.crossley2@gefanuc.com>
Add the MSI section to the DTS file for the GE SBC610.
Signed-off-by: Malcolm Crossley <malcolm.crossley2@gefanuc.com>
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 30911ad..78c336f 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -305,6 +305,22 @@
device_type = "open-pic";
};
+ msi@41600 {
+ compatible = "fsl,mpc8641-msi", "fsl,mpic-msi";
+ reg = <0x41600 0x80>;
+ msi-available-ranges = <0 0x100>;
+ interrupts = <
+ 0xe0 0
+ 0xe1 0
+ 0xe2 0
+ 0xe3 0
+ 0xe4 0
+ 0xe5 0
+ 0xe6 0
+ 0xe7 0>;
+ interrupt-parent = <&mpic>;
+ };
+
global-utilities@e0000 {
compatible = "fsl,mpc8641-guts";
reg = <0xe0000 0x1000>;
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply related
* [PATCH 4/8] powerpc: Basic flash support for GE SBC610
From: Martyn Welch @ 2010-01-11 12:23 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
In-Reply-To: <20100111121622.8306.87501.stgit@ES-J7S4D2J.amer.consind.ge.com>
Support for the SBC610 VPX Single Board Computer from GE (PowerPC MPC8641D).
This patch adds basic support for the on-board flash.
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
arch/powerpc/boot/dts/gef_sbc610.dts | 50 ++++++++++++++++++++----
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 23 +++++++----
2 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_sbc610.dts b/arch/powerpc/boot/dts/gef_sbc610.dts
index 78c336f..bb70600 100644
--- a/arch/powerpc/boot/dts/gef_sbc610.dts
+++ b/arch/powerpc/boot/dts/gef_sbc610.dts
@@ -75,14 +75,48 @@
interrupts = <19 2>;
interrupt-parent = <&mpic>;
- ranges = <0 0 0xff000000 0x01000000 // 16MB Boot flash
- 1 0 0xe8000000 0x08000000 // Paged Flash 0
- 2 0 0xe0000000 0x08000000 // Paged Flash 1
- 3 0 0xfc100000 0x00020000 // NVRAM
- 4 0 0xfc000000 0x00008000 // FPGA
- 5 0 0xfc008000 0x00008000 // AFIX FPGA
- 6 0 0xfd000000 0x00800000 // IO FPGA (8-bit)
- 7 0 0xfd800000 0x00800000>; // IO FPGA (32-bit)
+ ranges = <0 0 0xff000000 0x01000000 // 16MB Boot flash
+ 1 0 0xe8000000 0x08000000 // Paged Flash 0
+ 2 0 0xe0000000 0x08000000 // Paged Flash 1
+ 3 0 0xfc100000 0x00020000 // NVRAM
+ 4 0 0xfc000000 0x00008000 // FPGA
+ 5 0 0xfc008000 0x00008000 // AFIX FPGA
+ 6 0 0xfd000000 0x00800000 // IO FPGA (8-bit)
+ 7 0 0xfd800000 0x00800000>; // IO FPGA (32-bit)
+
+ /* flash@0,0 is a mirror of part of the memory in flash@1,0
+ flash@0,0 {
+ compatible = "gef,sbc610-firmware-mirror", "cfi-flash";
+ reg = <0x0 0x0 0x1000000>;
+ bank-width = <4>;
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "firmware";
+ reg = <0x0 0x1000000>;
+ read-only;
+ };
+ };
+ */
+
+ flash@1,0 {
+ compatible = "gef,sbc610-paged-flash", "cfi-flash";
+ reg = <0x1 0x0 0x8000000>;
+ bank-width = <4>;
+ device-width = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ partition@0 {
+ label = "user";
+ reg = <0x0 0x7800000>;
+ };
+ partition@7800000 {
+ label = "firmware";
+ reg = <0x7800000 0x800000>;
+ read-only;
+ };
+ };
nvram@3,0 {
device_type = "nvram";
diff --git a/arch/powerpc/configs/86xx/gef_sbc610_defconfig b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
index 1975d41..9284f04 100644
--- a/arch/powerpc/configs/86xx/gef_sbc610_defconfig
+++ b/arch/powerpc/configs/86xx/gef_sbc610_defconfig
@@ -623,7 +623,7 @@ CONFIG_MTD_CONCAT=y
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
-# CONFIG_MTD_OF_PARTS is not set
+CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set
#
@@ -643,13 +643,9 @@ CONFIG_MTD_BLOCK=y
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
-# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
-CONFIG_MTD_CFI_ADV_OPTIONS=y
-# CONFIG_MTD_CFI_NOSWAP is not set
-# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
-CONFIG_MTD_CFI_LE_BYTE_SWAP=y
-# CONFIG_MTD_CFI_GEOMETRY is not set
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
@@ -660,7 +656,6 @@ CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
-# CONFIG_MTD_OTP is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
# CONFIG_MTD_CFI_STAA is not set
@@ -1682,7 +1677,17 @@ CONFIG_MISC_FILESYSTEMS=y
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
-# CONFIG_JFFS2_FS is not set
+CONFIG_JFFS2_FS=y
+CONFIG_JFFS2_FS_DEBUG=0
+CONFIG_JFFS2_FS_WRITEBUFFER=y
+# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
+# CONFIG_JFFS2_SUMMARY is not set
+# CONFIG_JFFS2_FS_XATTR is not set
+# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
+CONFIG_JFFS2_ZLIB=y
+# CONFIG_JFFS2_LZO is not set
+CONFIG_JFFS2_RTIME=y
+# CONFIG_JFFS2_RUBIN is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd, |Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 927559189
^ permalink raw reply related
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