* Re: Module with 36K relocation entries
From: Nathan Lynch @ 2007-11-01 23:57 UTC (permalink / raw)
To: Medve Emilian-EMMEDVE1; +Cc: linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174CC98@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 wrote:
>
> I have module with 36K relocation entries (I know, I know, how could
> that be...) and the count_relocs() function takes ~17 seconds to crunch
> through the relocation table from the .rela.text section. I don't think
> I can reduce the number of entries in the relocation table (can I?) so
> I'm thinking at improving the performance of count_relocs() (currently
> O(n^2)). Does anybody have a simpler idea? Does anyone have any
> constructive suggestion on how to improve the situation?
This seems to come up every few months. There was a patch submitted
here:
http://ozlabs.org/pipermail/linuxppc-dev/2007-June/037641.html
^ permalink raw reply
* Module with 36K relocation entries
From: Medve Emilian-EMMEDVE1 @ 2007-11-01 23:34 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I have module with 36K relocation entries (I know, I know, how could
that be...) and the count_relocs() function takes ~17 seconds to crunch
through the relocation table from the .rela.text section. I don't think
I can reduce the number of entries in the relocation table (can I?) so
I'm thinking at improving the performance of count_relocs() (currently
O(n^2)). Does anybody have a simpler idea? Does anyone have any
constructive suggestion on how to improve the situation?
Thank you,
Emil.
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-01 21:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, netdev
In-Reply-To: <20071101160709.7e7c0181@weaponx.rchland.ibm.com>
On Thursday 01 November 2007, Josh Boyer wrote:
> > > - if (dev->type != RGMII_AXON)
> > > - return;
> > > -
> > > mutex_lock(&dev->lock);
> >
> > That will break 440GX boards that need to use the RGMII for data and the
> > ZMII for MDIO.
> >
> > You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
> > instead and set that for 405EX as well instead.
>
> And perhaps adding a comment about that since the meaning of that code
> isn't very obvious. That way people that aren't the original author
> of the driver don't get confused again.
Will do. I'll send a fixed version tomorrow.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Josh Boyer @ 2007-11-01 21:07 UTC (permalink / raw)
To: benh; +Cc: netdev, Stefan Roese, linuxppc-dev
In-Reply-To: <1193949421.6541.10.camel@pasglop>
On Fri, 02 Nov 2007 07:37:01 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2007-11-01 at 15:54 +0100, Stefan Roese wrote:
> > This patch adds support for the 405EX to the new EMAC driver.
> >
> > Tested on AMCC Kilauea.
>
> .../...
>
> > diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> > index de41695..e393f68 100644
> > --- a/drivers/net/ibm_newemac/rgmii.c
> > +++ b/drivers/net/ibm_newemac/rgmii.c
> > @@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
> >
> > RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
> >
> > - if (dev->type != RGMII_AXON)
> > - return;
> > -
> > mutex_lock(&dev->lock);
>
> That will break 440GX boards that need to use the RGMII for data and the
> ZMII for MDIO.
>
> You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
> instead and set that for 405EX as well instead.
And perhaps adding a comment about that since the meaning of that code
isn't very obvious. That way people that aren't the original author
of the driver don't get confused again.
josh
^ permalink raw reply
* Kernel malloc buffers how to make contiguous in user space?
From: Dave Cogley @ 2007-11-01 21:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]
Hello,
I am using a scatter gather DMA operation provided on the PPC44EPx to handle
a large data move of 2MB from sixteen 128k kmalloc buffers. I have sixteen
scatter / gather descriptors pointing to the allocated memory which will be
transferred to a peripheral on the EBC. This all appears to be setup and
working correctly. Now I want to provide these 16 kmalloc buffers to a user
space process and make them all appear as a contiguous 2MB buffer.
When the handler is called pageptr appears to be a valid page but the kernel
traps with "Bad page state" "Trying to fix it up, but a reboot is needed"
when returned from the handler. Am I missing something required to modify
the page state for the requested page? Am I even handling the nopage
request correctly? I notice the nopage handler gets called for every 4096
byte page it is trying to map. How do I map my 128k memory area into the 4k
page requests? Is there example code somewhere that demonstrates using a
contiguous memory buffer in user space when it is comprised of multiple
buffers in the kernel space?
First I am allocating 16 buffers using kmalloc:
#define DMABLOCKSIZE 1024 * 128
for (I = 0; I < 16; i++)
{
device->dma_buf[i] = kmalloc(DMABLOCKSIZE, GFP_DMA |
GFP_KERNEL);
sgl->phyaddress = virt_to_phys(device->dma_buf[i]);
}
Then I am doing the following in the nopage handler:
page* nopage_handler(struct vma, ul address, int* type)
{
unsigned long physaddr = address - vma->start;
int index = physaddr / DMABLOCKSIZE;
int off = physaddr % DMABLOCKSIZE;
struct page* pageptr = virt_to_page(device->dma_buf[index] +
off);
get_page(pageptr);
if (type)
*type = VM_FAULT_MINOR;
return pageptr;
}
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #2: Type: text/html, Size: 8883 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Benjamin Herrenschmidt @ 2007-11-01 20:37 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200711011554.04935.sr@denx.de>
On Thu, 2007-11-01 at 15:54 +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver.
>
> Tested on AMCC Kilauea.
.../...
> diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
> index de41695..e393f68 100644
> --- a/drivers/net/ibm_newemac/rgmii.c
> +++ b/drivers/net/ibm_newemac/rgmii.c
> @@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
>
> RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
>
> - if (dev->type != RGMII_AXON)
> - return;
> -
> mutex_lock(&dev->lock);
That will break 440GX boards that need to use the RGMII for data and the
ZMII for MDIO.
You may want to change the name RGMII_AXON something like RGMII_HAS_MDIO
instead and set that for 405EX as well instead.
Ben.
^ permalink raw reply
* Re:
From: Grant Likely @ 2007-11-01 19:07 UTC (permalink / raw)
To: Mead, Joseph; +Cc: linuxppc-embedded
In-Reply-To: <D1AFFAE2CC4BD54CA4C1543CFF4A4FCC59788F@exchangemb3.bnl.gov>
On 11/1/07, Mead, Joseph <mead@bnl.gov> wrote:
>
>
>
>
> I am using a Xilinx ML403 board and created a custom IP that connects to =
the
> PLB bus. The PLB bus is 64 bits wide. To communicate with the custom =
IP
> I have been using iowrite32() and ioread32() function calls to grab 32 bi=
ts
> at a time. Is it possible to grab the full 64 bits in one transfer? I
> don't see an iowrite64() or ioread64() function=85
Not really, at least not for non-cachable regions. The ppc405 is a 32
bit machine and if it is doing non-cached reads then it will do
individual 32 bit transactions. You could enable cache on the region,
but if it is accessing device registers then that is probably not what
you want (because there is no cache coherency between your device and
the 405).
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* bad gunzip
From: Pagnotta, Chris @ 2007-11-01 18:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
I am having difficulty uncompressing the ramdisk. The ramdisk does uncompress
when I do not have FCC disabled in the kernel and it comes up to the prompt.
I cannot see how leaving at an option in .config would affect the ramdisk
from uncompressing.
I noticed that the code just hangs in huft_build in lib/inflate.c
(i.e. just a infinite loop).
Has someone else has seen this?
I added some debug info, which is illustrated in the output below.
## Booting image at fc800000 ...
Image Name: Kernel 1.0.0-Wed Oct 31 1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 954708 Bytes = 932.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at fca00000 ...
Image Name: Good Ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1663803 Bytes = 1.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 00e69000, end 00fff33b ... OK
Linux version 2.6.19.2 (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #39 Wed Oct 31 14:53:16 PDT 2007
memsize 0x2000000
bus freq 0x3ef1480
cpm freq 0x7de2900
brg freq 0xfbc520
vco 0xfbc5200
baudrate 0x2580
Zone PFN ranges:
DMA 0 -> 8192
Normal 8192 -> 8192
early_node_map[1] active PFN ranges
0: 0 -> 8192
preempt_disable()
build_all_zonelists()
Built 1 zonelists. Total pages: 8128
page_alloc_init()
Kernel command line: console=ttyCPM0,9600 root=/dev/ram
parse_early_param()
trap_init()
rcu_init()
init_IRQ()
pidhash_init()
PID hash table entries: 128 (order: 7, 512 bytes)
init_timers()
hrtimers_init()
softirq_init()
timekeeping_init()
cpm_uart: console: compat mode
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
cpuset_init_early()
mem_init()
Memory: 28816k available (1540k kernel code, 404k data, 96k init, 0k highmem)
kmem_cache_init()
calibrate_delay()
pidmap_init()
pgtable_cache_init()
Mount-cache hash table entries: 512
signals_init()
lock_kernel()
cpuset_init_smp()
populate_rootfs()
inflate complete
checking if image is initramfs...
inflate complete
it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1624k freed
do_basic_setup()
init_workqueues()
usermodehelper_init()
driver_init()
sysctl_init()
do_initcalls()
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 256 (order: -2, 1024 bytes)
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 512 (order: -1, 2048 bytes)
TCP: Hash tables configured (established 1024 bind 512)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: CPM driver $Revision: 0.02 $
cpm_uart: WARNING: no UART devices found on platform bus!
cpm_uart: the driver will guess configuration, but this mode is no longer supported.
ttyCPM0 at MMIO 0xf0011a20 (irq = 41) is a CPM UART
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: FCC ENET Version 0.3, 00:20:7b:80:45:04
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
prepare_namespace()
RAMDISK: Compressed image found at block 0
number blocks 0
[-- Attachment #2: Type: text/html, Size: 4757 bytes --]
^ permalink raw reply
* (no subject)
From: Mead, Joseph @ 2007-11-01 18:18 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
I am using a Xilinx ML403 board and created a custom IP that connects to
the PLB bus. The PLB bus is 64 bits wide. To communicate with the
custom IP I have been using iowrite32() and ioread32() function calls to
grab 32 bits at a time. Is it possible to grab the full 64 bits in one
transfer? I don't see an iowrite64() or ioread64() function...
Thanks,
Joe
[-- Attachment #2: Type: text/html, Size: 2028 bytes --]
^ permalink raw reply
* Re: reboot of mpc8270 sometimes fails
From: Theo Gjaltema @ 2007-11-01 18:02 UTC (permalink / raw)
To: matvejchikov; +Cc: linuxppc-embedded
In-Reply-To: <8496f91a0710311314k3dd90e12t670e2405fcaa0725@mail.gmail.com>
Hi!
I solved our problem a different way: I added a reset of the CPM just
before calling te m8260_gorom().
The effect is that the message "rebooting" which was often followed by a
strange character is now cut short ("reboo"), but uboot is always
comming up afterwards. I've tested this by adding a "reboot" command in
an S script in rc3.d. The system with the unpatched kernel failed
aboutonce every 30 times it rebooted, with the patch it continued
rebooting correctly for 3 days (then I stopped the tests by hand).
The code for rebooting the CPM was obtained from the freescale manuals
of the mpc8270.
Anyone interested in the actual patch?
Theo.
Matvejchikov Ilya schreef:
> Hi!
>
> I thik that m8260_restart in 2.4 kernel is broken. Try to get it from
> the 2.6 kernel, or look at this.
>
> /* The 8260 has an internal 1-second timer update register that
> @@ -112,21 +123,16 @@ m8260_get_rtc_time(void)
> static void
> m8260_restart(char *cmd)
> {
> - extern void m8260_gorom(bd_t *bi, uint addr);
> - uint startaddr;
> -
> - /* Most boot roms have a warmstart as the second instruction
> - * of the reset vector. If that doesn't work for you, change this
> - * or the reboot program to send a proper address.
> - */
> - startaddr = 0xff000104;
> -
> - if (cmd != NULL) {
> - if (!strncmp(cmd, "startaddr=", 10))
> - startaddr = simple_strtoul(&cmd[10], NULL, 0);
> - }
> -
> - m8260_gorom((unsigned int)__pa(__res), startaddr);
> + __volatile__ unsigned char dummy;
> +
> + local_irq_disable();
> + ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= 0x00000001;
> +
> + /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
> + mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
> + dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
> + printk("Restart failed\n");
> + while (1) ;
> }
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* serial GDBServer PPC405 problems
From: khollan @ 2007-11-01 16:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi everyone
I want to thank everyone for all of my problems so far, you have been a
great help.
Im trying to get a debug session with gdbserver over a serial connection on
my Xilinx ML410 using a uartlite set at Baud 115200. When I issue the
command on the target "./gdbserver /dev/ttyUL1 test" I get this error:
Remote debugging using /dev/ttyUL1
readchar: Socet operation on non-socket
Remote Side has terminated connection. GDBserver will reopen connection.
This error just repeats until I kill the process. I know that gdbserver
works because debugging over TCP works fine.
Thanks for your help
--
View this message in context: http://www.nabble.com/serial-GDBServer-PPC405--problems-tf4732593.html#a13532592
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] net: Add 405EX support to new EMAC driver
From: Stefan Roese @ 2007-11-01 14:54 UTC (permalink / raw)
To: netdev; +Cc: linuxppc-dev
This patch adds support for the 405EX to the new EMAC driver.
Tested on AMCC Kilauea.
Signed-off-by: Stefan Roese <sr@denx.de>
---
drivers/net/ibm_newemac/core.c | 3 ++-
drivers/net/ibm_newemac/rgmii.c | 6 ------
2 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index 0de3aa2..fd0a585 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2466,7 +2466,8 @@ static int __devinit emac_init_config(struct emac_instance *dev)
if (of_device_is_compatible(np, "ibm,emac4"))
dev->features |= EMAC_FTR_EMAC4;
if (of_device_is_compatible(np, "ibm,emac-axon")
- || of_device_is_compatible(np, "ibm,emac-440epx"))
+ || of_device_is_compatible(np, "ibm,emac-440epx")
+ || of_device_is_compatible(np, "ibm,emac-405ex"))
dev->features |= EMAC_FTR_HAS_AXON_STACR
| EMAC_FTR_STACR_OC_INVERT;
if (of_device_is_compatible(np, "ibm,emac-440spe"))
diff --git a/drivers/net/ibm_newemac/rgmii.c b/drivers/net/ibm_newemac/rgmii.c
index de41695..e393f68 100644
--- a/drivers/net/ibm_newemac/rgmii.c
+++ b/drivers/net/ibm_newemac/rgmii.c
@@ -140,9 +140,6 @@ void rgmii_get_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "get_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
- return;
-
mutex_lock(&dev->lock);
fer = in_be32(&p->fer);
@@ -161,9 +158,6 @@ void rgmii_put_mdio(struct of_device *ofdev, int input)
RGMII_DBG2(dev, "put_mdio(%d)" NL, input);
- if (dev->type != RGMII_AXON)
- return;
-
fer = in_be32(&p->fer);
fer &= ~(0x00080000u >> input);
out_be32(&p->fer, fer);
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* [PATCH 2/2] 4xx: Add EMAC support to Kilauea defconfig
From: Stefan Roese @ 2007-11-01 14:50 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/configs/kilauea_defconfig | 98 ++++++++++++++++---------------
1 files changed, 51 insertions(+), 47 deletions(-)
diff --git a/arch/powerpc/configs/kilauea_defconfig b/arch/powerpc/configs/kilauea_defconfig
index fd1c530..f75a62b 100644
--- a/arch/powerpc/configs/kilauea_defconfig
+++ b/arch/powerpc/configs/kilauea_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.23-rc9
-# Thu Oct 11 19:05:15 2007
+# Linux kernel version: 2.6.24-rc1
+# Thu Nov 1 15:15:23 2007
#
# CONFIG_PPC64 is not set
@@ -68,6 +68,10 @@ CONFIG_POSIX_MQUEUE=y
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_CGROUPS is not set
+CONFIG_FAIR_GROUP_SCHED=y
+CONFIG_FAIR_USER_SCHED=y
+# CONFIG_FAIR_CGROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
@@ -134,6 +138,7 @@ CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_KILAUEA=y
# CONFIG_WALNUT is not set
# CONFIG_XILINX_VIRTEX_GENERIC_BOARD is not set
+CONFIG_405EX=y
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
# CONFIG_PPC_I8259 is not set
@@ -154,6 +159,7 @@ CONFIG_KILAUEA=y
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
+CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
@@ -175,6 +181,7 @@ CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
+# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
@@ -198,10 +205,6 @@ CONFIG_ZONE_DMA=y
# CONFIG_PCI_DOMAINS is not set
# CONFIG_PCI_SYSCALL is not set
# CONFIG_ARCH_SUPPORTS_MSI is not set
-
-#
-# PCCARD (PCMCIA/CardBus) support
-#
# CONFIG_PCCARD is not set
#
@@ -215,7 +218,7 @@ CONFIG_ZONE_DMA=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START=0xc0000000
-CONFIG_TASK_SIZE=0x80000000
+CONFIG_TASK_SIZE=0xc0000000
CONFIG_CONSISTENT_START=0xff100000
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD=0x00400000
@@ -252,6 +255,7 @@ CONFIG_IP_PNP_BOOTP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
@@ -277,10 +281,6 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
-
-#
-# QoS and/or fair queueing
-#
# CONFIG_NET_SCHED is not set
#
@@ -309,6 +309,7 @@ CONFIG_DEFAULT_TCP_CONG="cubic"
#
# Generic Driver Options
#
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
@@ -336,6 +337,7 @@ CONFIG_MTD_BLOCK=m
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
#
# RAM/ROM/Flash chip drivers
@@ -425,7 +427,22 @@ CONFIG_NETDEVICES=y
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
-# CONFIG_NET_ETHERNET is not set
+# CONFIG_VETH is not set
+# CONFIG_PHYLIB is not set
+CONFIG_NET_ETHERNET=y
+# CONFIG_MII is not set
+CONFIG_IBM_NEW_EMAC=y
+CONFIG_IBM_NEW_EMAC_RXB=256
+CONFIG_IBM_NEW_EMAC_TXB=256
+CONFIG_IBM_NEW_EMAC_POLL_WEIGHT=32
+CONFIG_IBM_NEW_EMAC_RX_COPY_THRESHOLD=256
+CONFIG_IBM_NEW_EMAC_RX_SKB_HEADROOM=0
+CONFIG_IBM_NEW_EMAC_DEBUG=y
+# CONFIG_IBM_NEW_EMAC_ZMII is not set
+CONFIG_IBM_NEW_EMAC_RGMII=y
+# CONFIG_IBM_NEW_EMAC_TAH is not set
+CONFIG_IBM_NEW_EMAC_EMAC4=y
+# CONFIG_B44 is not set
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
@@ -485,7 +502,6 @@ CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
-# CONFIG_WATCHDOG is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_NVRAM is not set
# CONFIG_GEN_RTC is not set
@@ -502,6 +518,13 @@ CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_HWMON is not set
+# CONFIG_WATCHDOG is not set
+
+#
+# Sonics Silicon Backplane
+#
+CONFIG_SSB_POSSIBLE=y
+# CONFIG_SSB is not set
#
# Multifunction device drivers
@@ -518,16 +541,15 @@ CONFIG_LEGACY_PTY_COUNT=256
#
# Graphics support
#
+# CONFIG_VGASTATE is not set
+# CONFIG_VIDEO_OUTPUT_CONTROL is not set
+# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
-# CONFIG_VGASTATE is not set
-# CONFIG_VIDEO_OUTPUT_CONTROL is not set
-# CONFIG_FB is not set
-# CONFIG_FB_IBM_GXT4500 is not set
#
# Sound
@@ -540,19 +562,6 @@ CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_RTC_CLASS is not set
#
-# DMA Engine support
-#
-# CONFIG_DMA_ENGINE is not set
-
-#
-# DMA Clients
-#
-
-#
-# DMA Devices
-#
-
-#
# Userspace I/O
#
# CONFIG_UIO is not set
@@ -604,7 +613,6 @@ CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLB_PAGE is not set
-CONFIG_RAMFS=y
# CONFIG_CONFIGFS_FS is not set
#
@@ -624,10 +632,7 @@ CONFIG_CRAMFS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
-
-#
-# Network File Systems
-#
+CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
@@ -653,15 +658,7 @@ CONFIG_SUNRPC=y
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
-
-#
-# Native Language Support
-#
# CONFIG_NLS is not set
-
-#
-# Distributed Lock Manager
-#
# CONFIG_DLM is not set
# CONFIG_UCC_SLOW is not set
@@ -680,16 +677,16 @@ CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
-
-#
-# Instrumentation Support
-#
+CONFIG_INSTRUMENTATION=y
# CONFIG_PROFILING is not set
+# CONFIG_KPROBES is not set
+# CONFIG_MARKERS is not set
#
# Kernel hacking
#
# CONFIG_PRINTK_TIME is not set
+CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
@@ -713,9 +710,12 @@ CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
+# CONFIG_DEBUG_SG is not set
CONFIG_FORCED_INLINING=y
+# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_FAULT_INJECTION is not set
+# CONFIG_SAMPLES is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
@@ -728,6 +728,7 @@ CONFIG_FORCED_INLINING=y
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
+# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
@@ -747,6 +748,7 @@ CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not set
+# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
@@ -760,10 +762,12 @@ CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
+# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
+# CONFIG_CRYPTO_AUTHENC is not set
CONFIG_CRYPTO_HW=y
# CONFIG_PPC_CLOCK is not set
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-11-01 14:57 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <4729E897.1070400@harris.com>
On Thu, 01 Nov 2007 10:54:15 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> Is this something anyone can do? I tried:
>
> git pull
> master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
> for-2.6.24
>
> but it asks me for a password. I'd like to be able to follow your
> development branch, so I can contribute patches where appropriate.
Ah. No, you'd have to have an account on master.kernel.org for that
specific pull request to work. Anonymous pulls should work with:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
as the URL instead.
josh
^ permalink raw reply
* Re: Please pull from 'for-2.6.24' branch of 4xx tree
From: Steven A. Falco @ 2007-11-01 14:54 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071101081057.46a9bfdd@weaponx.rchland.ibm.com>
Is this something anyone can do? I tried:
git pull
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git
for-2.6.24
but it asks me for a password. I'd like to be able to follow your
development branch, so I can contribute patches where appropriate.
Steve
Josh Boyer wrote:
> Hi Paul,
>
> Please pull from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
>
> to pick up a few items for 2.6.24. Mostly bugfixes, but also some
> documentation updates and a few bootwrapper changes. Particularly important
> is the TLB flushing fix from Ben.
>
> josh
>
> Benjamin Herrenschmidt (2):
> [POWERPC] 4xx: Fix 4xx flush_tlb_page()
> [POWERPC] 4xx: Deal with 44x virtually tagged icache
>
> Grant Likely (5):
> [POWERPC] bootwrapper: Allow wrapper script to execute verbosely
> [POWERPC] bootwrapper: Bail from script if any command fails
> [POWERPC] Device tree bindings for Xilinx devices
> [POWERPC] Uartlite: speed up console output
> [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
>
> Roel Kluin (1):
> [POWERPC] allocation fix in ppc/platforms/4xx/luan.c
>
> Steven A. Falco (1):
> [POWERPC] 4xx: Fix Walnut DTS interrupt property
>
> Valentine Barshak (1):
> [POWERPC] 4xx: Workaround for the 440EP(x)/GR(x) processors identical PVR
>
> Documentation/powerpc/booting-without-of.txt | 261 ++++++++++++++++++++++++++
> arch/powerpc/boot/dts/walnut.dts | 4 +-
> arch/powerpc/boot/wrapper | 32 ++--
> arch/powerpc/kernel/cputable.c | 36 +++-
> arch/powerpc/kernel/entry_32.S | 23 +++
> arch/powerpc/kernel/misc_32.S | 32 +++-
> arch/powerpc/kernel/prom.c | 12 ++
> arch/powerpc/mm/40x_mmu.c | 17 +-
> arch/powerpc/mm/44x_mmu.c | 1 +
> arch/powerpc/mm/fault.c | 2 +-
> arch/powerpc/mm/mmu_decl.h | 4 +-
> arch/ppc/kernel/entry.S | 23 +++
> arch/ppc/kernel/misc.S | 31 +++-
> arch/ppc/mm/44x_mmu.c | 1 +
> arch/ppc/mm/4xx_mmu.c | 17 +-
> arch/ppc/mm/fault.c | 2 +-
> arch/ppc/mm/mmu_decl.h | 4 +-
> arch/ppc/platforms/4xx/ebony.c | 2 +-
> arch/ppc/platforms/4xx/luan.c | 7 +-
> arch/ppc/platforms/4xx/ocotea.c | 2 +-
> arch/ppc/platforms/4xx/taishan.c | 2 +-
> drivers/serial/uartlite.c | 10 +-
> include/asm-powerpc/pgtable-ppc32.h | 13 ++
> include/asm-powerpc/tlbflush.h | 12 +-
> 24 files changed, 472 insertions(+), 78 deletions(-)
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* [PATCH 1/2] 4xx: Add 405EX CPU type needed for EMAC support on Kilauea
From: Stefan Roese @ 2007-11-01 14:50 UTC (permalink / raw)
To: linuxppc-dev
For EMAC support, 405EX needs to be defined to enable the corresponding
EMAC features (IBM_NEW_EMAC_EMAC4, etc.).
Signed-off-by: Stefan Roese <sr@denx.de>
---
A small new EMAC patch will follow in a short while, to enable
405EX support in the driver.
arch/powerpc/platforms/40x/Kconfig | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index 8f6699f..3ece0fd 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -33,6 +33,7 @@ config KILAUEA
bool "Kilauea"
depends on 40x
default n
+ select 405EX
help
This option enables support for the AMCC PPC405EX evaluation board.
@@ -105,6 +106,11 @@ config 405GP
config 405EP
bool
+config 405EX
+ bool
+ select IBM_NEW_EMAC_EMAC4
+ select IBM_NEW_EMAC_RGMII
+
config 405GPR
bool
--
1.5.3.4.498.g9c514
^ permalink raw reply related
* Re: libfdt as its own repo and submodule of dtc?
From: Jon Loeliger @ 2007-11-01 14:04 UTC (permalink / raw)
To: David Gibson; +Cc: linux-ppc list, Jerry Van Baren
In-Reply-To: <20071031225624.GB16119@localhost.localdomain>
On Wed, 2007-10-31 at 17:56, David Gibson wrote:
> I'm not too keen on using a git feature that's more recent than the
> git in most distros.
I'm going to consider this argument null and void on two fronts:
You don't use git for patch generation and submission anyway.
The Linux Community happily embraced and used early
versions of git, installing it themselves if needed,
long before it was available in _any_ distro.
Thanks,
jdl
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Dale Farnsworth @ 2007-11-01 13:46 UTC (permalink / raw)
To: tnt; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <52304.213.186.37.16.1193915988.squirrel@www.opensources.be>
Sylvain Munaut wrote:
> > Valentine Barshak wrote:
> >> Rework ohci-ppc-of driver to use big-endian property instead of
> >> ohci-be/ohci-le compatible strings. Also remove unnecessary
> >> user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
> >> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
> >> and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
>
> I don't find those options useless. If you think the defauts are not the
> best change them but I find these options relevant. You don't always want
> the support for BE on PPC ... if the only controller you have is pci ...
> or if you're on a soc that use little endian ...
USB_OHCI_LITTLE_ENDIAN and USB_OHCI_BIG_ENDIAN are useful and I
don't see anyone wanting to remove them. However, if all of the
chips supported by the ohci-ppc-of driver are big-endian, then
USB_OHCI_HCD_PPC_OF_LE and USB_OHCI_HCD_PPC_OF_BE are not needed.
Just select USB_OHCI_BIG_ENDIAN when the ohci-ppc-of driver is
selected, in the same way that we always select USB_OHCI_LITTLE_ENDIAN
when the ohci-pci driver is selected.
-Dale
^ permalink raw reply
* Please pull from 'for-2.6.24' branch of 4xx tree
From: Josh Boyer @ 2007-11-01 13:10 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
to pick up a few items for 2.6.24. Mostly bugfixes, but also some
documentation updates and a few bootwrapper changes. Particularly important
is the TLB flushing fix from Ben.
josh
Benjamin Herrenschmidt (2):
[POWERPC] 4xx: Fix 4xx flush_tlb_page()
[POWERPC] 4xx: Deal with 44x virtually tagged icache
Grant Likely (5):
[POWERPC] bootwrapper: Allow wrapper script to execute verbosely
[POWERPC] bootwrapper: Bail from script if any command fails
[POWERPC] Device tree bindings for Xilinx devices
[POWERPC] Uartlite: speed up console output
[POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
Roel Kluin (1):
[POWERPC] allocation fix in ppc/platforms/4xx/luan.c
Steven A. Falco (1):
[POWERPC] 4xx: Fix Walnut DTS interrupt property
Valentine Barshak (1):
[POWERPC] 4xx: Workaround for the 440EP(x)/GR(x) processors identical PVR
Documentation/powerpc/booting-without-of.txt | 261 ++++++++++++++++++++++++++
arch/powerpc/boot/dts/walnut.dts | 4 +-
arch/powerpc/boot/wrapper | 32 ++--
arch/powerpc/kernel/cputable.c | 36 +++-
arch/powerpc/kernel/entry_32.S | 23 +++
arch/powerpc/kernel/misc_32.S | 32 +++-
arch/powerpc/kernel/prom.c | 12 ++
arch/powerpc/mm/40x_mmu.c | 17 +-
arch/powerpc/mm/44x_mmu.c | 1 +
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 4 +-
arch/ppc/kernel/entry.S | 23 +++
arch/ppc/kernel/misc.S | 31 +++-
arch/ppc/mm/44x_mmu.c | 1 +
arch/ppc/mm/4xx_mmu.c | 17 +-
arch/ppc/mm/fault.c | 2 +-
arch/ppc/mm/mmu_decl.h | 4 +-
arch/ppc/platforms/4xx/ebony.c | 2 +-
arch/ppc/platforms/4xx/luan.c | 7 +-
arch/ppc/platforms/4xx/ocotea.c | 2 +-
arch/ppc/platforms/4xx/taishan.c | 2 +-
drivers/serial/uartlite.c | 10 +-
include/asm-powerpc/pgtable-ppc32.h | 13 ++
include/asm-powerpc/tlbflush.h | 12 +-
24 files changed, 472 insertions(+), 78 deletions(-)
^ permalink raw reply
* Re: dtc: Move tree checking code to checks.c
From: Jon Loeliger @ 2007-11-01 13:08 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071101054926.GC18744@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> This patch moves the dtc code for checking the device tree its
> processing into a new checks.c. The tree accessor functions from
> livetree.c which the checks use are exported and added to dtc.h.
>
> Another small step towards a flexible checking architecture.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: libfdt: Handle v16 and re-ordered trees for r/w
From: Jon Loeliger @ 2007-11-01 13:08 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20071101003731.GG16119@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Currently all the read/write functions in libfdt require that the
> given tree be v17, and further, that the tree has the memory
> reservation block, structure block and strings block stored in that
> physical order.
>
> This patch eases these constraints, by making fdt_open_int() reorder
> the blocks, and/or convert the tree to v17, so that it will then be
> ready for the other read-write functions.
>
> It also extends fdt_pack() to actually remove any gaps between blocks
> that might be present.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
jdl
^ permalink raw reply
* Re: [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: Valentine Barshak @ 2007-11-01 12:44 UTC (permalink / raw)
To: tnt; +Cc: linux-usb-devel, linuxppc-dev
In-Reply-To: <52304.213.186.37.16.1193915988.squirrel@www.opensources.be>
tnt@blacksnow.net wrote:
>>> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
>>> and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
>
> I don't find those options useless. If you think the defauts are not the
> best change them but I find these options relevant. You don't always want
> the support for BE on PPC ... if the only controller you have is pci ...
> or if you're on a soc that use little endian ...
If I have just a pci controller, and don't expect to to find/use the
built-in one, why should I need the ohci-ppc-of driver then?
I'm not aware of a soc that uses little endian, but I think that LE/BE
still shouldn't be selected manually. It should be autoselected then,
the same way we select LE for PCI for example.
>
> Do we really need to stop supporting the old values right now ?
I've resubmitted the patches with the old mpc52xx bindings support.
Keeping old ohci-be/le stuff along with the new bindings doesn't look
good to me. However, I think we can live with the old ones and maybe
find a better way for OF ohci support later.
>
> IMHO, Changing to the usb-ohci with a property sounds fine to me if you
> really want to but don't drop support for the old values. They are not
> "bad". Change the dts to reflect the fact that the new "way" is preferred
> and a comment somewhere in the code and that should be fine.
OK
> Sylvain
>
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH v4] FEC - fast ethernet controller for mpc52xx
From: tnt @ 2007-11-01 11:31 UTC (permalink / raw)
To: Domen Puncer; +Cc: netdev, linuxppc-dev, Jeff Garzik
In-Reply-To: <20071025141035.GG3369@nd47.coderock.org>
> + while (bcom_buffer_done(priv->tx_dmatsk)) {
> + struct sk_buff *skb;
> + skb = bcom_retrieve_buffer(priv->tx_dmatsk, NULL, NULL);
> + /* Here (and in rx routines) would be a good place for
> + * dma_unmap_single(), but bcom doesn't return bcom_bd of the
> + * finished transfer, and _unmap is empty on this platfrom.
> + */
> +
Of course bestcomm let's you get back the bcom_bd ... What do you think
your second NULL parameter is for ?
Give it a pointer to a bcom_bd * and it will fill your pointer for you to
point to the bd you just got back.
Sylvain
^ permalink raw reply
* Re: PPC405GP Walnut irq patch
From: Josh Boyer @ 2007-11-01 12:23 UTC (permalink / raw)
To: Steven A. Falco; +Cc: linuxppc-dev
In-Reply-To: <4728C0F5.80304@harris.com>
On Wed, 31 Oct 2007 13:52:53 -0400
"Steven A. Falco" <sfalco@harris.com> wrote:
> > Could you redo the patch with just this bit and send it again?
> >
> > josh
> >
>
> Ok - this one is based off the Linus tree, and follows your style of one
> interrupt per line, with a comment indicating which one it is.
Looks good. Thanks!
josh
>
> Signed-off-by: Steve Falco <sfalco at harris.com>
>
>
>
> diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
> index fa681f5..754fa39 100644
> --- a/arch/powerpc/boot/dts/walnut.dts
> +++ b/arch/powerpc/boot/dts/walnut.dts
> @@ -122,7 +122,9 @@
> device_type = "network";
> compatible = "ibm,emac-405gp", "ibm,emac";
> interrupt-parent = <&UIC0>;
> - interrupts = <9 4 f 4>;
> + interrupts = <
> + f 4 /* Ethernet */
> + 9 4 /* Ethernet Wake Up */>;
> local-mac-address = [000000000000]; /* Filled in by zImage */
> reg = <ef600800 70>;
> mal-device = <&MAL>;
^ permalink raw reply
* Re: [PATCH 1/2] USB: Rework OHCI PPC OF for new bindings
From: tnt @ 2007-11-01 11:19 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <471FC191.6020704@genesi-usa.com>
> Valentine Barshak wrote:
>> Rework ohci-ppc-of driver to use big-endian property instead of
>> ohci-be/ohci-le compatible strings. Also remove unnecessary
>> user-selectable USB_OHCI_HCD_PPC_OF_LE/BE stuff, because
>> USB_OHCI_BIG_ENDIAN_DESC/MMIO should always be enabled for ppc
>> and USB_OHCI_LITTLE_ENDIAN is selected for USB_OHCI_HCD_PCI by default.
I don't find those options useless. If you think the defauts are not the
best change them but I find these options relevant. You don't always want
the support for BE on PPC ... if the only controller you have is pci ...
or if you're on a soc that use little endian ...
> Can we just make sure real quickly that the changing of compatibles
> doesn't break existing, not-easily-flashable firmwares?
I tend to agree with Matt here.
Do we really need to stop supporting the old values right now ?
IMHO, Changing to the usb-ohci with a property sounds fine to me if you
really want to but don't drop support for the old values. They are not
"bad". Change the dts to reflect the fact that the new "way" is preferred
and a comment somewhere in the code and that should be fine.
Sylvain
^ 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