* Re: [PATCH] USB_DR host support for FSL MPC831x
From: Scott Wood @ 2007-07-17 16:47 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Greg KH, linuxppc-dev
In-Reply-To: <20070717005832.23019.99739.stgit@localhost.localdomain>
On Tue, Jul 17, 2007 at 04:58:32AM +0400, Vitaly Bordug wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 1b351dc..c330e79 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -90,6 +90,7 @@
> interrupt-parent = < &ipic >;
> interrupts = <26 8>;
> phy_type = "utmi_wide";
> + control_init = <00000280>; // UTMI ext 48 MHz clk
fsl,usb-control-init, please.
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 099aff6..994a127 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -925,7 +925,7 @@ MODULE_LICENSE ("GPL");
> #define PCI_DRIVER ehci_pci_driver
> #endif
>
> -#ifdef CONFIG_MPC834x
> +#if defined(CONFIG_MPC834x) || defined(CONFIG_PPC_MPC831x)
> #include "ehci-fsl.c"
> #define PLATFORM_DRIVER ehci_fsl_driver
> #endif
It'd be better to define a CONFIG_FSL_EHCI and have the 834x and 831x
configs enable it.
-Scott
^ permalink raw reply
* Re: [PATCH] POWERPC: add support of the GiGE switch for mpc8313RDB via fixed PHY
From: Scott Wood @ 2007-07-17 16:43 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717004936.21700.67900.stgit@localhost.localdomain>
This just comments on code style, not semantics... I agree with Segher
that this isn't the way to do it.
On Tue, Jul 17, 2007 at 04:49:37AM +0400, Vitaly Bordug wrote:
> +#if defined(CONFIG_FIXED_MII_1000_FDX)
> +
> +static int fixed_set_link (void)
> +{
> + struct fixed_info *phyinfo = fixed_mdio_get_phydev(0); /* only one fixed phy on this platform */
Line length.
> + for (np = NULL, i = 0;
> + (np = of_find_compatible_node(np, "mdio", "gianfar")) != NULL;
> + i++) {
Can't we just initialize np and i above, and use a while loop?
> + memset(&res, 0, sizeof(res));
Not necessary.
> + ret = of_address_to_resource(np, 0, &res);
> + if (ret)
> + return ret;
> + child = of_find_compatible_node(np, "ethernet-phy","fixed");
Space after comma.
> + if (!child)
> + return -ENXIO;
> + id = (u32*)of_get_property(child, "reg", NULL);
Cast not required.
> + if (!id)
> + return -ENXIO;
> + break;
Why are you using a loop at all if there's a break at the end and no
continue?
> + }
> + snprintf(phydev->dev.bus_id, BUS_ID_SIZE, PHY_ID_FMT, res.start, *id);
Only one space before res.start.
> + memset(phyinfo->regs,0xff,sizeof(phyinfo->regs[0])*phyinfo->regs_num);
Spaces after commas.
-Scott
^ permalink raw reply
* Re: PS3 Storage Driver O_DIRECT issue
From: Geoff Levand @ 2007-07-17 16:40 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, James E.J. Bottomley, Olaf Hering, linux-scsi,
Alessandro Rubini, linux-kernel, linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.62.0707131532350.18802@pademelon.sonytel.be>
Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Olaf Hering wrote:
>> This driver (or the generic PS3 code) has appearently problems with
>> O_DIRECT.
>> glibc aborts parted because the malloc metadata get corrupted. While it
>> is reproducible, the place where it crashes changes with every version
>> of the debug attempt.
>> I dont have a handle right now, all I know is that the metadata after a
>> malloc area get overwritten with zeros.
>>
>>
>> Can you have a look at this?
>> parted /dev/ps3da
>> print (a few times)
>
> I can't seem to reproduce this with parted 1.7.1-5.1 (from Debian
> etch/lenny/sid) and kernel 2.6.22-g77320894.
Hi.
I found this happens on Fedora 7:
[root@ps3-nfs ~]# uname -a
Linux ps3-nfs 2.6.22-ps3-linux-dev-g4d898766-dirty #1 SMP Wed Jul 11 13:29:46 PDT 2007 ppc64 ppc64 ppc64 GNU/Linux
[root@ps3-nfs ~]# parted --version
parted (GNU parted) 1.8.6
Here is the error message from parted:
Command History:
print
Error: SEGV_MAPERR (Address not mapped to object)
Backtrace has 20 calls on stack:
20: /usr/lib/libparted-1.8.so.6(ped_assert+0xb0) [0xfb7ea50]
19: parted [0x1000c6dc]
18: [0x100350]
17: [(nil)]
16: /lib/libc.so.6 [0xfdcfe64]
15: /lib/libc.so.6 [0xfdd0b34]
14: /lib/libc.so.6(__libc_memalign+0xec) [0xfdd1e1c]
13: /lib/libc.so.6(posix_memalign+0xbc) [0xfdd207c]
12: /usr/lib/libparted-1.8.so.6 [0xfb8f42c]
11: /usr/lib/libparted-1.8.so.6(ped_device_read+0x164) [0xfb7f5f4]
10: /usr/lib/libparted-1.8.so.6(ped_geometry_read+0x16c) [0xfb89a5c]
9: /usr/lib/libparted-1.8.so.6 [0xfba739c]
8: /usr/lib/libparted-1.8.so.6(ped_file_system_probe_specific+0x104) [0xfb80d04]
7: /usr/lib/libparted-1.8.so.6(ped_file_system_probe+0xec) [0xfb8134c]
6: /usr/lib/libparted-1.8.so.6 [0xfbbcc38]
5: /usr/lib/libparted-1.8.so.6 [0xfbbcfb4]
4: /usr/lib/libparted-1.8.so.6(ped_disk_new+0xc0) [0xfb88bf0]
3: parted [0x10006e00]
2: parted(command_run+0x1c) [0x10004d8c]
1: parted(interactive_mode+0x134) [0x1000e4b4]
Aborted
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Segher Boessenkool @ 2007-07-17 16:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <1184689617.15570.1.camel@weaponx.rchland.ibm.com>
>>> + flash@ff800000 {
>>> + device_type = "rom";
>>
>> I'm sure you know I find this "rom" binding to be crap.
>> However, I didn't yet write up the "cfi" binding, so I
>> can't complain ;-)
>
> Not all chips are CFI compliant.
I know :-)
> Be sure to write up the "jedec"
It's in the pipeline, it's quite a bit more complicated
than CFI though.
> and "nand" bindings while you're at it ;)
NAND is pure hell :-(
Segher
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-17 16:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann, David Gibson
In-Reply-To: <B07FAF3D-A8F4-45F5-8EEF-4506F4A31DF2@kernel.crashing.org>
>>> Way back when, I distinctly recall aborting my plans to implement
>>> per-page exec on 40x, precisely because of executables like this.
>>
>> I noticed some comments to that effect in the BookE code,
>> yes. It seems userland has been fixed enough that you
>> could think about enabling it again FWIW.
>
> Did I miss the posting of the patch with the fix?
glibc-2.2 seems to be the last "bad" one. We are at
glibc-2.6 or so nowadays...
Segher
^ permalink raw reply
* Re: [PATCH] POWERPC: Added RTC support for mpc8313RDB and utilize "clock-frequency"
From: Scott Wood @ 2007-07-17 16:36 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070717004913.21682.50282.stgit@localhost.localdomain>
On Tue, Jul 17, 2007 at 04:49:13AM +0400, Vitaly Bordug wrote:
> + np = of_find_node_by_type(NULL, "cpu");
> + if (np != 0) {
> + const unsigned int *fp =
> + get_property(np, "clock-frequency", NULL);
> + if (fp != 0)
> + loops_per_jiffy = *fp / HZ;
> + else
> + loops_per_jiffy = 50000000 / HZ;
> + of_node_put(np);
> + }
This is not necessary. It's only used for /proc/cpuinfo (delays are done
using tb_ticks_per_usec), and it'll be overwritten by the generic
calibrate_delay() anyway.
We should be removing this from board files that have it, not adding it
to ones that don't.
> +#if defined (CONFIG_SENSORS_DS1337) && defined (CONFIG_I2C)
> +
> +extern int ds1337_do_command(int id, int cmd, void *arg);
> +extern spinlock_t rtc_lock;
> +#define DS1337_GET_DATE 0
> +#define DS1337_SET_DATE 1
> +
> +static void mpc8313rdb_get_rtc_time(struct rtc_time *tm)
> +{
> + int result;
> +
> + result = ds1337_do_command(0, DS1337_GET_DATE, tm);
> +
> + if (result == 0)
> + result = mktime(tm->tm_year, tm->tm_mon, tm->tm_mday, tm->tm_hour, tm->tm_min, tm->tm_sec);
> +}
> +
> +static int mpc8313rdb_set_rtc_time(struct rtc_time *tm)
> +{
> + int result;
> +
> + result = ds1337_do_command(0, DS1337_SET_DATE, tm);
> +
> + return result;
> +}
> +
> +static int __init rtc_hookup(void)
> +{
> + ppc_md.get_rtc_time = mpc8313rdb_get_rtc_time;
> + ppc_md.set_rtc_time = mpc8313rdb_set_rtc_time;
> + return 0;
> +}
> +late_initcall(rtc_hookup);
> +#endif
Please don't do this; drivers/i2c/chips/ds1337.c is deprecated. You
should be using the RTC-class driver in drivers/rtc/rtc-ds1307.c, which
has a non-device-specific API that can be used.
The ppc_md RTC functions should really just go away, though -- setting
the clock on bootup can be done by generic code, and periodically
updating the RTC when using NTP can be done from userspace.
-Scott
^ permalink raw reply
* Re: [PATCH 3/3] 82xx: SBCPQ2 board platform support
From: Segher Boessenkool @ 2007-07-17 16:30 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1184679661.18501.41.camel@mark>
>>>>> + np = of_find_compatible_node(NULL, "cpm-pic", "CPM2");
>>>>> + if (np == NULL) {
>>>>> + printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
>>>>> + return;
>>>>> + }
>>>>
>>>> This looks like your device tree is wrong. Shouldn't the interrupt
>>>> controller have device_type="interrupt-controller" and a specific
>>>> compatible property instead of having the name in the device_type?
So, I looked it up :-)
The device_type should specify the specific interrupt
controller programming model, because a real OF typically
needs to know the meaning of the interrupt specifiers;
also, when the interrupt binding recommended practice
isn't used, it is needed to know the #interrupt-cells
(which is implicit from the device_type in that case).
If there is no defined binding for your interrupt
controller, just don't put a device_type in your tree at
all, for flat device trees.
>>> Here, I just copy the codes from mpc82xx_ads, is there anything
>>> wrong?
>>
>> I just checked the Recommended Practice document for interrupt
>> mapping
>> and it seems that it's ok. The interrupt controller needs to have
>> an property named "interrupt-controller", but does not need a
>> specific
>> device_type. So it appears to be correct here.
Please also look at the base specifications, not just
the imap thing. But you reached the correct conclusion.
Segher
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Kumar Gala @ 2007-07-17 16:30 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann, David Gibson
In-Reply-To: <4CB813ED-9D8B-4A32-B4AC-65D27741D46C@kernel.crashing.org>
On Jul 17, 2007, at 10:18 AM, Segher Boessenkool wrote:
>>>>> Yeah. Giving the warning is a good thing though.
>>>>
>>>> No, it isn't; it's just noise, if we're not ever going to do
>>>> anything
>>>> to prevent the behaviour - and we can't.
>>>
>>> The same userland code will not run correctly on PPC64 or BookE
>>> systems. Is that not a reason to warn?
>>
>> Way back when, I distinctly recall aborting my plans to implement
>> per-page exec on 40x, precisely because of executables like this.
>
> I noticed some comments to that effect in the BookE code,
> yes. It seems userland has been fixed enough that you
> could think about enabling it again FWIW.
Did I miss the posting of the patch with the fix?
- k
^ permalink raw reply
* Re: Machine check exception. 2.6.20 powerpc tree.
From: Kumar Gala @ 2007-07-17 16:29 UTC (permalink / raw)
To: Ramirez-Ortiz, Jorge; +Cc: linuxppc-embedded
In-Reply-To: <35786B99AB3FDC45A8215724617919730136DA91@gbrwgceumf01.eu.xerox.net>
On Jul 17, 2007, at 9:21 AM, Ramirez-Ortiz, Jorge wrote:
> Running our multithreaded application on ppc8548 (E500 core) =20
> generates a machine check exception when trying to access some =20
> ASIC=92s registers mapped on the PCI space (This application maps a =20=
> PCI device to access its registers)
>
>
>
> machine_check_exception: task my_process, MCSR=3D0x10008, =
NIP=3D0x10153530
>
> Machine check in user mode.
>
> Caused by (from MCSR=3D10008): Guarded Load or Cache-Inhibited stwcx.
>
> Bus - Read Data Bus Error
>
>
>
> Here is the assembly dump of the region of code containing the =20
> offending instruction in user-space, with SRR0 pointing us at =20
> 0x10153530 when the exception is raised:
>
>
>
> 0x10153528 <_ZN2vk7in_le32EPVKj+16>: lwz r0,8(r31)
>
> 0x1015352c <_ZN2vk7in_le32EPVKj+20>: lwz r9,8(r31)
>
> 0x10153530 <_ZN2vk7in_le32EPVKj+24>: lwbrx r0,0,r0
>
> 0x10153534 <_ZN2vk7in_le32EPVKj+28>: twi 0,r0,0
>
> 0x10153538 <_ZN2vk7in_le32EPVKj+32>: isync
Can you get the code to dump the value of r0. I'm wondering if =20
you're really getting a read data bus error due to the fact that r0 =20
is pointing to a PCI address that doesn't have a device that will =20
respond.
- k
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Josh Boyer @ 2007-07-17 16:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <630B6BC9-389F-4F5C-AE8F-9C3131C4543E@kernel.crashing.org>
On Tue, 2007-07-17 at 16:57 +0200, Segher Boessenkool wrote:
>
> > + flash@ff800000 {
> > + device_type = "rom";
>
> I'm sure you know I find this "rom" binding to be crap.
> However, I didn't yet write up the "cfi" binding, so I
> can't complain ;-)
Not all chips are CFI compliant. Be sure to write up the "jedec" and
"nand" bindings while you're at it ;)
josh
^ permalink raw reply
* Re: [PATCH 1/3] 82xx: some 82xx platform hook functions can be shared by different boards
From: Scott Wood @ 2007-07-17 16:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707170259.47098.arnd@arndb.de>
On Tue, Jul 17, 2007 at 02:59:46AM +0200, Arnd Bergmann wrote:
> This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
> comes from a platform specific header file, so you can not
> use these definitions in platform independent code without
> breaking multiplatform kernels.
My patchset just drops the vendor field, and uses ppc_md.name for the
machine name. The vendor name can be included in the latter.
> I know you're just moving that code, but it looks horribly wrong
> nonetheless. cpm2_immr is an __iomem variable, so you must not
> dereference it but instead should use the in_8() macro to
> access it.
>
> Once you get that right, you don't need the volatile variable
> any more.
My patchset addresses this.
-Scott
^ permalink raw reply
* [PATCH] iommu virtual merge no longer experimental
From: Linas Vepstas @ 2007-07-17 16:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Benjamin Herrenschmidt, Arnd Bergmann, Tim Schimke
Per conversations with BenH, iommu virtual merging should no longer
be considered to be an "experimental" feature. In particular,
CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/Kconfig | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/Kconfig 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/Kconfig 2007-07-17 11:08:18.000000000 -0500
@@ -430,16 +430,17 @@ config MATH_EMULATION
instructions to run.
config IOMMU_VMERGE
- bool "Enable IOMMU virtual merging (EXPERIMENTAL)"
- depends on EXPERIMENTAL && PPC64
- default n
+ bool "Enable IOMMU virtual merging"
+ depends on PPC64
+ default y
help
Cause IO segments sent to a device for DMA to be merged virtually
by the IOMMU when they happen to have been allocated contiguously.
This doesn't add pressure to the IOMMU allocator. However, some
drivers don't support getting large merged segments coming back
- from *_map_sg(). Say Y if you know the drivers you are using are
- properly handling this case.
+ from *_map_sg().
+
+ Most drivers don't have this problem; it is safe to say Y here.
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Scott Wood @ 2007-07-17 16:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200707171618.54903.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
>
>>>Well, AFAICS, all of them currently use scc. The 8xx platforms don't
>>>even build correctly in the mainline kernel, so I guess it would
>>>be good to change them to also list fsl,cpm-smc in the compatible
>>>property.
>>
>>That probably could be done by another series of patches, and I really
>>don't want to introduce those kinds of patches in my BSP patches. I
>>don't know if the 8xx/82xx series patches from Scott Wood will cover
>>this issue or not.
>
>
> I guess he can best answer that himself. Scott, what are your plans
> to deal with the different types of cpm ports?
My patchset converts the CPM enet and serial drivers to of platform
devices when CONFIG_PPC_MERGE is defined, and signficantly overhauls the
device tree binding. A 885 CPM UART would have a compatible like this:
compatible = "fsl,mpc885-smc-uart", "fsl,cpm1-smc-uart",
"fsl,cpm1-uart", "fsl,cpm-smc-uart", "fsl,cpm-uart";
-Scott
^ permalink raw reply
* Re: Linuxppc-embedded Digest, Vol 35, Issue 33
From: Scott Wood @ 2007-07-17 16:02 UTC (permalink / raw)
To: suresh suresh; +Cc: linuxppc-embedded, Siva Prasad
In-Reply-To: <e5eb93010707162259l2e78c524s32ff260b3d930bdb@mail.gmail.com>
suresh suresh wrote:
> MPC8280 has internal memory space which contains Dualport(Dp) RAM. In the
> DpRAM we allocate some tables and these has to store pointer of the buffers
> which are allocated in external memory. Core will use this pointer to
> access
> the buffers, basically these buffers are used for DMA.
>
> Using IMMR register we can get physical address of the internal memory. Now
> can I store the address return by the kmalloc() function? or I should
> convert it into physical?
Yes, you need to convert it to physical. As I said earlier, use the DMA
mapping API (described in Documentation/DMA-mapping.txt) to do so.
Specifically, look at the dma_map_single() function.
-Scott
^ permalink raw reply
* Re: [PATCH 1/4] Add DMA sector to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-07-17 15:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Wei.Zhang
In-Reply-To: <18076.42297.26124.137770@cargo.ozlabs.ibm.com>
>> The device tree describes _all_ hardware in the system,
>> not just the things that are somewhat harder to probe
>> for.
>
> Actually, for embedded systems, the device tree is really only
> required to describe the things that it's useful for the Linux kernel
> to know.
Sure, for example it could provide a "SoC" node with only
an address range, and not describe all the devices on that
SoC separately. It still describes all of the hardware,
not in quite so much detail though. It also won't get all
the benefits of using the OF device tree, but that is a
trade off, for each group to decide on their own.
> The point of the device tree for embedded systems is to provide
> configuration information, not to be able to claim compliance with
> some set of legalistic requirements. :)
Well, if you use some certain binding, you better use it
correctly, no? Ill-defined and ill-used interfaces aren't
the nicest thing to deal with.
> I think in some cases we have gone a little over the top in trying to
> put everything in the device tree, in fact. Ultimately I think it has
> to be up to the more experienced embedded developers to say how much
> detail in the device tree is actually helpful and how much is dead
> weight.
Yes, more complex device bindings need a lot of time to get
right, and need a lot of input from all parties using it.
In general, it is better to leave out things from a binding
until it is very clear it is needed and is the right thing
to do.
Segher
^ permalink raw reply
* Re: [PATCH] USB_DR host support for FSL MPC831x
From: Kumar Gala @ 2007-07-17 15:34 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Greg KH, linuxppc-dev
In-Reply-To: <20070717185229.0f66e227@vitb.ru.mvista.com>
On Jul 17, 2007, at 9:52 AM, Vitaly Bordug wrote:
> On Tue, 17 Jul 2007 20:18:35 +0800
> "Li Yang-r58472" <LeoLi@freescale.com> wrote:
>
>> Hi Vitaly,
>>
>> I believe that your patch is addresses by my patch in 2.6.23 queue:
>> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/
>> 2.6/2.6.22/usb-
>> ehci_fsl-update-for-mpc831x-support.patch
>>
> okay, nm then. I'll revalidate with these 2 patches
> and come up with something ontop if it won't work.
>
FYI, Leo's patches are now in Linus's tree.
- k
^ permalink raw reply
* Re: [PATCH] Change the pci express controller node name from pci to pcie
From: Segher Boessenkool @ 2007-07-17 15:22 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184643035.23157.3.camel@localhost.localdomain>
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Change the pci express controller node name from pci
> to pcie in device tree.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
Looks good, thanks!
Segher
^ permalink raw reply
* [PATCH 4/4] ibmveth: Add ethtool driver stats hooks
From: Brian King @ 2007-07-17 15:18 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 +++++++++++++++++++++++++++++++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_driver_stats 2007-07-12 09:39:23.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:39:23.000000000 -0500
@@ -115,6 +115,28 @@ MODULE_VERSION(ibmveth_driver_version);
module_param_named(csum_offload, ibmveth_csum_offload, uint, 0);
MODULE_PARM_DESC(csum_offload, "Checksum offload (0/1). Default: 1");
+struct ibmveth_stat {
+ char name[ETH_GSTRING_LEN];
+ int offset;
+};
+
+#define IBMVETH_STAT_OFF(stat) offsetof(struct ibmveth_adapter, stat)
+#define IBMVETH_GET_STAT(a, off) *((u64 *)(((unsigned long)(a)) + off))
+
+struct ibmveth_stat ibmveth_stats[] = {
+ { "replenish_task_cycles", IBMVETH_STAT_OFF(replenish_task_cycles) },
+ { "replenish_no_mem", IBMVETH_STAT_OFF(replenish_no_mem) },
+ { "replenish_add_buff_failure", IBMVETH_STAT_OFF(replenish_add_buff_failure) },
+ { "replenish_add_buff_success", IBMVETH_STAT_OFF(replenish_add_buff_success) },
+ { "rx_invalid_buffer", IBMVETH_STAT_OFF(rx_invalid_buffer) },
+ { "rx_no_buffer", IBMVETH_STAT_OFF(rx_no_buffer) },
+ { "tx_multidesc_send", IBMVETH_STAT_OFF(tx_multidesc_send) },
+ { "tx_linearized", IBMVETH_STAT_OFF(tx_linearized) },
+ { "tx_linearize_failed", IBMVETH_STAT_OFF(tx_linearize_failed) },
+ { "tx_map_failed", IBMVETH_STAT_OFF(tx_map_failed) },
+ { "tx_send_failed", IBMVETH_STAT_OFF(tx_send_failed) }
+};
+
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
{
@@ -756,6 +778,32 @@ static u32 ibmveth_get_rx_csum(struct ne
return adapter->rx_csum;
}
+static void ibmveth_get_strings(struct net_device *dev, u32 stringset, u8 *data)
+{
+ int i;
+
+ if (stringset != ETH_SS_STATS)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++, data += ETH_GSTRING_LEN)
+ memcpy(data, ibmveth_stats[i].name, ETH_GSTRING_LEN);
+}
+
+static int ibmveth_get_stats_count(struct net_device *dev)
+{
+ return ARRAY_SIZE(ibmveth_stats);
+}
+
+static void ibmveth_get_ethtool_stats(struct net_device *dev,
+ struct ethtool_stats *stats, u64 *data)
+{
+ int i;
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ for (i = 0; i < ARRAY_SIZE(ibmveth_stats); i++)
+ data[i] = IBMVETH_GET_STAT(adapter, ibmveth_stats[i].offset);
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
@@ -766,7 +814,10 @@ static const struct ethtool_ops netdev_e
.get_rx_csum = ibmveth_get_rx_csum,
.set_rx_csum = ibmveth_set_rx_csum,
.get_tso = ethtool_op_get_tso,
- .get_ufo = ethtool_op_get_ufo
+ .get_ufo = ethtool_op_get_ufo,
+ .get_strings = ibmveth_get_strings,
+ .get_stats_count = ibmveth_get_stats_count,
+ .get_ethtool_stats = ibmveth_get_ethtool_stats
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
diff -puN drivers/net/ibmveth.h~ibmveth_ethtool_driver_stats drivers/net/ibmveth.h
_
^ permalink raw reply
* Re: [PATCH] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Segher Boessenkool @ 2007-07-17 15:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <20070717024246.GA6482@localhost.localdomain>
>>>> Yeah. Giving the warning is a good thing though.
>>>
>>> No, it isn't; it's just noise, if we're not ever going to do
>>> anything
>>> to prevent the behaviour - and we can't.
>>
>> The same userland code will not run correctly on PPC64 or BookE
>> systems. Is that not a reason to warn?
>
> Way back when, I distinctly recall aborting my plans to implement
> per-page exec on 40x, precisely because of executables like this.
I noticed some comments to that effect in the BookE code,
yes. It seems userland has been fixed enough that you
could think about enabling it again FWIW.
Segher
^ permalink raw reply
* [PATCH 3/4] ibmveth: Add ethtool TSO handlers
From: Brian King @ 2007-07-17 15:18 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-07-12 09:39:20.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:39:20.000000000 -0500
@@ -764,7 +764,9 @@ static const struct ethtool_ops netdev_e
.get_tx_csum = ethtool_op_get_tx_csum,
.set_tx_csum = ibmveth_set_tx_csum,
.get_rx_csum = ibmveth_get_rx_csum,
- .set_rx_csum = ibmveth_set_rx_csum
+ .set_rx_csum = ibmveth_set_rx_csum,
+ .get_tso = ethtool_op_get_tso,
+ .get_ufo = ethtool_op_get_ufo
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
_
^ permalink raw reply
* [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-07-17 15:17 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
In-Reply-To: <11846854701127-patch-mail.ibm.com>
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 120 +++++++++++++++++++++++++++++++-
linux-2.6-bjking1/drivers/net/ibmveth.h | 1
2 files changed, 119 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-07-12 09:36:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:41:15.000000000 -0500
@@ -644,12 +644,127 @@ static u32 netdev_get_link(struct net_de
return 1;
}
+static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data)
+ adapter->rx_csum = 1;
+ else {
+ adapter->rx_csum = 0;
+ dev->features &= ~NETIF_F_IP_CSUM;
+ }
+}
+
+static void ibmveth_set_tx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data) {
+ dev->features |= NETIF_F_IP_CSUM;
+ adapter->rx_csum = 1;
+ } else
+ dev->features &= ~NETIF_F_IP_CSUM;
+}
+
+static int ibmveth_set_csum_offload(struct net_device *dev, u32 data,
+ void (*done) (struct net_device *, u32))
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ union ibmveth_illan_attributes set_attr, clr_attr, ret_attr;
+ long ret;
+ int rc1 = 0, rc2 = 0;
+ int restart = 0;
+
+ if (netif_running(dev)) {
+ restart = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(dev);
+ adapter->pool_config = 0;
+ }
+
+ set_attr.desc = 0;
+ clr_attr.desc = 0;
+
+ if (data)
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+ else
+ clr_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(adapter->vdev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ ret = h_illan_attributes(adapter->vdev->unit_address, clr_attr.desc,
+ set_attr.desc, &ret_attr.desc);
+
+ if (ret != H_SUCCESS) {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld\n", data, ret);
+
+ ret = h_illan_attributes(adapter->vdev->unit_address,
+ set_attr.desc, clr_attr.desc, &ret_attr.desc);
+ } else
+ done(dev, data);
+ } else {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld ret_attr=%lx\n", data, ret, ret_attr.desc);
+ }
+
+ if (restart)
+ rc2 = ibmveth_open(dev);
+
+ return rc1 ? rc1 : rc2;
+}
+
+static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data && adapter->rx_csum)
+ return 0;
+ if (!data && !adapter->rx_csum)
+ return 0;
+
+ return ibmveth_set_csum_offload(dev, data, ibmveth_set_rx_csum_flags);
+}
+
+static int ibmveth_set_tx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ int rc = 0;
+
+ if (data && (dev->features & NETIF_F_IP_CSUM))
+ return 0;
+ if (!data && !(dev->features & NETIF_F_IP_CSUM))
+ return 0;
+
+ if (data && !adapter->rx_csum)
+ rc = ibmveth_set_csum_offload(dev, data, ibmveth_set_tx_csum_flags);
+ else
+ ibmveth_set_tx_csum_flags(dev, data);
+
+ return rc;
+}
+
+static u32 ibmveth_get_rx_csum(struct net_device *dev)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ return adapter->rx_csum;
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
.get_link = netdev_get_link,
.get_sg = ethtool_op_get_sg,
.get_tx_csum = ethtool_op_get_tx_csum,
+ .set_tx_csum = ibmveth_set_tx_csum,
+ .get_rx_csum = ibmveth_get_rx_csum,
+ .set_rx_csum = ibmveth_set_rx_csum
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@ -1108,9 +1223,10 @@ static int __devinit ibmveth_probe(struc
ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
&ret_attr.desc);
- if (ret == H_SUCCESS)
+ if (ret == H_SUCCESS) {
+ adapter->rx_csum = 1;
netdev->features |= NETIF_F_IP_CSUM;
- else
+ } else
ret = h_illan_attributes(dev->unit_address, set_attr.desc,
0, &ret_attr.desc);
}
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool 2007-07-12 09:36:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-12 09:36:01.000000000 -0500
@@ -140,6 +140,7 @@ struct ibmveth_adapter {
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
int pool_config;
+ int rx_csum;
/* adapter specific stats */
u64 replenish_task_cycles;
_
^ permalink raw reply
* [PATCH 1/4] ibmveth: Enable TCP checksum offload
From: Brian King @ 2007-07-17 15:17 UTC (permalink / raw)
To: santil; +Cc: linuxppc-dev, rcjenn, brking, netdev
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yielded a ~30% increase
in throughput. This feature is enabled by default on systems that
support it, but can be disabled with a module option.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 58 ++++++++++++++++++++++++++++++++
linux-2.6-bjking1/drivers/net/ibmveth.h | 41 +++++++++++++++++++++-
2 files changed, 97 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload 2007-07-12 08:27:47.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-12 09:35:55.000000000 -0500
@@ -47,6 +47,8 @@
#include <linux/mm.h>
#include <linux/ethtool.h>
#include <linux/proc_fs.h>
+#include <linux/in.h>
+#include <linux/ip.h>
#include <asm/semaphore.h>
#include <asm/hvcall.h>
#include <asm/atomic.h>
@@ -103,12 +105,15 @@ static struct proc_dir_entry *ibmveth_pr
static const char ibmveth_driver_name[] = "ibmveth";
static const char ibmveth_driver_string[] = "IBM i/pSeries Virtual Ethernet Driver";
+static unsigned int ibmveth_csum_offload = 1;
#define ibmveth_driver_version "1.03"
MODULE_AUTHOR("Santiago Leon <santil@us.ibm.com>");
MODULE_DESCRIPTION("IBM i/pSeries Virtual Ethernet Driver");
MODULE_LICENSE("GPL");
MODULE_VERSION(ibmveth_driver_version);
+module_param_named(csum_offload, ibmveth_csum_offload, uint, 0);
+MODULE_PARM_DESC(csum_offload, "Checksum offload (0/1). Default: 1");
/* simple methods of getting data from the current rxq entry */
static inline int ibmveth_rxq_pending_buffer(struct ibmveth_adapter *adapter)
@@ -131,6 +136,11 @@ static inline int ibmveth_rxq_frame_leng
return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].length);
}
+static inline int ibmveth_rxq_csum_good(struct ibmveth_adapter *adapter)
+{
+ return (adapter->rx_queue.queue_addr[adapter->rx_queue.index].csum_good);
+}
+
/* setup the initial settings for a buffer pool */
static void ibmveth_init_buffer_pool(struct ibmveth_buff_pool *pool, u32 pool_index, u32 pool_size, u32 buff_size, u32 pool_active)
{
@@ -684,6 +694,24 @@ static int ibmveth_start_xmit(struct sk_
desc[0].fields.length, DMA_TO_DEVICE);
desc[0].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ ip_hdr(skb)->protocol != IPPROTO_TCP && skb_checksum_help(skb)) {
+ ibmveth_error_printk("tx: failed to checksum packet\n");
+ tx_dropped++;
+ goto out;
+ }
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ unsigned char *buf = skb_transport_header(skb) + skb->csum_offset;
+
+ desc[0].fields.no_csum = 1;
+ desc[0].fields.csum_good = 1;
+
+ /* Need to zero out the checksum */
+ buf[0] = 0;
+ buf[1] = 0;
+ }
+
if(dma_mapping_error(desc[0].fields.address)) {
ibmveth_error_printk("tx: unable to map initial fragment\n");
tx_map_failed++;
@@ -702,6 +730,10 @@ static int ibmveth_start_xmit(struct sk_
frag->size, DMA_TO_DEVICE);
desc[curfrag+1].fields.length = frag->size;
desc[curfrag+1].fields.valid = 1;
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ desc[curfrag+1].fields.no_csum = 1;
+ desc[curfrag+1].fields.csum_good = 1;
+ }
if(dma_mapping_error(desc[curfrag+1].fields.address)) {
ibmveth_error_printk("tx: unable to map fragment %d\n", curfrag);
@@ -792,7 +824,11 @@ static int ibmveth_poll(struct net_devic
} else {
int length = ibmveth_rxq_frame_length(adapter);
int offset = ibmveth_rxq_frame_offset(adapter);
+ int csum_good = ibmveth_rxq_csum_good(adapter);
+
skb = ibmveth_rxq_get_buffer(adapter);
+ if (csum_good)
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
ibmveth_rxq_harvest_buffer(adapter);
@@ -962,8 +998,10 @@ static void ibmveth_poll_controller(stru
static int __devinit ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id)
{
int rc, i;
+ long ret;
struct net_device *netdev;
struct ibmveth_adapter *adapter = NULL;
+ union ibmveth_illan_attributes set_attr, ret_attr;
unsigned char *mac_addr_p;
unsigned int *mcastFilterSize_p;
@@ -1058,6 +1096,26 @@ static int __devinit ibmveth_probe(struc
ibmveth_debug_printk("registering netdev...\n");
+ if (ibmveth_csum_offload) {
+ ret = h_illan_attributes(dev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ set_attr.desc = 0;
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
+ &ret_attr.desc);
+
+ if (ret == H_SUCCESS)
+ netdev->features |= NETIF_F_IP_CSUM;
+ else
+ ret = h_illan_attributes(dev->unit_address, set_attr.desc,
+ 0, &ret_attr.desc);
+ }
+ }
+
rc = register_netdev(netdev);
if(rc) {
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload 2007-07-12 08:27:47.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-12 09:32:54.000000000 -0500
@@ -67,6 +67,21 @@ static inline long h_send_logical_lan(un
return rc;
}
+static inline long h_illan_attributes(unsigned long unit_address,
+ unsigned long reset_mask, unsigned long set_mask,
+ unsigned long *ret_attributes)
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL_BUFSIZE];
+
+ rc = plpar_hcall(H_ILLAN_ATTRIBUTES, retbuf, unit_address,
+ reset_mask, set_mask);
+
+ *ret_attributes = retbuf[0];
+
+ return rc;
+}
+
#define h_multicast_ctrl(ua, cmd, mac) \
plpar_hcall_norets(H_MULTICAST_CTRL, ua, cmd, mac)
@@ -144,7 +159,9 @@ struct ibmveth_adapter {
struct ibmveth_buf_desc_fields {
u32 valid : 1;
u32 toggle : 1;
- u32 reserved : 6;
+ u32 reserved : 4;
+ u32 no_csum : 1;
+ u32 csum_good : 1;
u32 length : 24;
u32 address;
};
@@ -154,10 +171,30 @@ union ibmveth_buf_desc {
struct ibmveth_buf_desc_fields fields;
};
+struct ibmveth_illan_attributes_fields {
+ u32 reserved;
+ u32 reserved2 : 18;
+ u32 csum_offload_padded_pkt_support : 1;
+ u32 reserved3 : 1;
+ u32 trunk_priority : 4;
+ u32 reserved4 : 5;
+ u32 tcp_csum_offload_ipv6 : 1;
+ u32 tcp_csum_offload_ipv4 : 1;
+ u32 active_trunk : 1;
+};
+
+union ibmveth_illan_attributes {
+ u64 desc;
+ struct ibmveth_illan_attributes_fields fields;
+};
+
struct ibmveth_rx_q_entry {
u16 toggle : 1;
u16 valid : 1;
- u16 reserved : 14;
+ u16 reserved : 4;
+ u16 no_csum : 1;
+ u16 csum_good : 1;
+ u16 reserved2 : 8;
u16 offset;
u32 length;
u64 correlator;
_
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 14:22 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <3D0E2A2D-9ADE-4931-9C73-8E65550C728F@kernel.crashing.org>
On Tuesday 17 July 2007, Segher Boessenkool wrote:
> > If the compatible property contains "fsl,cpm-smc\0cpm_uart", you =A0
> > can scan for
> > either of them. The loop will iterate over all cpm_uart compatible =A0
> > devices,
> > while the later test will look for an fsl,cpm-smc compatible device.
>=20
> Well, "fsl,cpm-uart" (note the two differences), but yes.
My point was about the 'smc' part that needs to be added, so I guess
if we want to have that in there, it should be "fsl,cpm-smc-uart"
really, and "fsl,cpm-scc-uart", respectively.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Segher Boessenkool @ 2007-07-17 15:12 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev, paulus, Arnd Bergmann
In-Reply-To: <1184680385.18501.51.camel@mark>
> but, the current situation is that: in all DTS files that are using
> smc
> or scc as uart device, all device node definitions have the same
> "compatible" property -- "cpm_uart"
>
> So what I do here is just following the upstream source tree.
True enough. OTOH, it doesn't help to continue supporting
the "bad old stuff", esp. if new extra workarounds are
needed for it.
Segher
^ permalink raw reply
* Re: [PATCH 2/3] 82xx: Parse SMC serial device node in DTS
From: Arnd Bergmann @ 2007-07-17 14:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1184682576.18501.62.camel@mark>
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> > Well, AFAICS, all of them currently use scc. The 8xx platforms don't
> > even build correctly in the mainline kernel, so I guess it would
> > be good to change them to also list fsl,cpm-smc in the compatible
> > property.
>
> That probably could be done by another series of patches, and I really
> don't want to introduce those kinds of patches in my BSP patches. I
> don't know if the 8xx/82xx series patches from Scott Wood will cover
> this issue or not.
I guess he can best answer that himself. Scott, what are your plans
to deal with the different types of cpm ports?
Arnd <><
^ 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