* Re: Leds
From: Marco Stornelli @ 2008-02-08 10:43 UTC (permalink / raw)
To: LinuxPPC-Embedded
In-Reply-To: <20080208112002.42a15c0d@seasc0532.dyn.rnd.as.sw.ericsson.se>
Simon Kagstrom ha scritto:
> Hi Marco,
>
> On Fri, 08 Feb 2008 11:02:16 +0100
> Marco Stornelli <marco.stornelli@coritel.it> wrote:
>
>> how can specify a led device in a dts file? These leds are connected
>> with gpio to the microprocessor. I can't find anything like a led node
>> in the dts files of the other boards. Have you got any suggestions?
>
> Although I'm not sure if it's the "standard" way, we just added a
> "home-made" node like this:
>
> resetLED@c0018000 {
> device_type = "leds";
> compatible = "reset-leds";
> reg = <c0018000 00008000>;
> };
>
> and then just get the info in the probe function for the led driver
> we placed in drivers/leds/:
>
> /* Get device info from OF tree */
> np = of_find_compatible_node(NULL, "leds", "reset-leds");
> if (!np) {
> dev_err(&pdev->dev, "Could not find device tree node for reset-leds\n");
> goto error_classdev;
> }
>
> if (of_address_to_resource(np, 0, &res)) {
> dev_err(&pdev->dev, "Could not convert reset-leds device tree address\n");
> of_node_put(np);
> goto error_classdev;
> }
> ...
>
> At least this was all the information we needed from the device tree.
>
> // Simon
>
Thanks. In this case where have you added the device registration? In
the probe function? Have you registered the driver with
of_register_platform_driver()?
^ permalink raw reply
* Re: Leds
From: Simon Kagstrom @ 2008-02-08 10:20 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47AC28A8.5030609@coritel.it>
Hi Marco,
On Fri, 08 Feb 2008 11:02:16 +0100
Marco Stornelli <marco.stornelli@coritel.it> wrote:
> how can specify a led device in a dts file? These leds are connected
> with gpio to the microprocessor. I can't find anything like a led node
> in the dts files of the other boards. Have you got any suggestions?
Although I'm not sure if it's the "standard" way, we just added a
"home-made" node like this:
resetLED@c0018000 {
device_type = "leds";
compatible = "reset-leds";
reg = <c0018000 00008000>;
};
and then just get the info in the probe function for the led driver
we placed in drivers/leds/:
/* Get device info from OF tree */
np = of_find_compatible_node(NULL, "leds", "reset-leds");
if (!np) {
dev_err(&pdev->dev, "Could not find device tree node for reset-leds\n");
goto error_classdev;
}
if (of_address_to_resource(np, 0, &res)) {
dev_err(&pdev->dev, "Could not convert reset-leds device tree address\n");
of_node_put(np);
goto error_classdev;
}
...
At least this was all the information we needed from the device tree.
// Simon
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: David Gibson @ 2008-02-08 11:02 UTC (permalink / raw)
To: Grant Likely; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080202065517.12920.20235.stgit@trillian.secretlab.ca>
On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
[snip]
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> + unsigned long r6, unsigned long r7)
> +{
> + const u32 *na, *ns, *reg, *timebase;
> + u64 memsize64;
> + int node, size, i;
> +
> + /* Allocate initial heap for probing the tree */
> + simple_alloc_init(initial_heap, sizeof(initial_heap), 32, 64);
> +
> + /* Make sure FDT blob is sane */
> + if (fdt_check_header(_dtb_start) != 0)
> + fatal("Invalid device tree blob\n");
I think most of these fatal()s are pretty pointless. This is
platform_init(), so the console won't even have been initialized to
actually print any of the messages. Precisely because this is
simpleboot, in which every bit of information the wrapper has comes
from teh device tree, if the provided blob is so bad as to fail these
basic tests, we're totally stuffed anyway. It'll take a hardware
debugger to track down, and I don't think the fatal()s will actually
help much at that point.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Leds
From: Simon Kagstrom @ 2008-02-08 11:26 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47AC324D.1050503@coritel.it>
On Fri, 08 Feb 2008 11:43:25 +0100
Marco Stornelli <marco.stornelli@coritel.it> wrote:
> > Although I'm not sure if it's the "standard" way, we just added a
> > "home-made" node like this:
> >
> > resetLED@c0018000 {
> > device_type = "leds";
> > compatible = "reset-leds";
> > reg = <c0018000 00008000>;
> > };
> >
> Thanks. In this case where have you added the device registration? In
> the probe function? Have you registered the driver with
> of_register_platform_driver()?
We put it in the module init function and registered it as a platform
device:
static int __init led_init(void)
{
int ret;
ret = platform_driver_register(&led_driver);
if (ret < 0)
return -ENODEV;
pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0);
if (IS_ERR(pdev)) {
ret = PTR_ERR(pdev);
platform_driver_unregister(&led_driver);
}
return ret;
}
And just use the device tree stuff to read out the device address. The
driver itself is quite similar to other led drivers found in the same
directory, so you can probably base your work on those.
This was for kernel 2.6.21, I'm not sure if these things have changed
for newer kernels (although I would guess most of it is the same).
// Simon
^ permalink raw reply
* Re: [RFC][POWERPC] bootwrapper: Add a firmware-independent simpleboot target.
From: Grant Likely @ 2008-02-08 14:07 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, jwboyer, scottwood,
stephen.neuendorffer
In-Reply-To: <20080208110219.GC27955@localhost.localdomain>
On Feb 8, 2008 4:02 AM, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Feb 01, 2008 at 11:55:42PM -0700, Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> > + /* Make sure FDT blob is sane */
> > + if (fdt_check_header(_dtb_start) != 0)
> > + fatal("Invalid device tree blob\n");
>
> I think most of these fatal()s are pretty pointless. This is
> platform_init(), so the console won't even have been initialized to
> actually print any of the messages. Precisely because this is
> simpleboot, in which every bit of information the wrapper has comes
> from teh device tree, if the provided blob is so bad as to fail these
> basic tests, we're totally stuffed anyway. It'll take a hardware
> debugger to track down, and I don't think the fatal()s will actually
> help much at that point.
heh; very true. I'll kill them.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [Virtex 4 PPC] Problem mountin rootfs via NFS
From: IngoM @ 2008-02-08 14:11 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
in the meantime, I get up my toolchain and an linux-kernel from xilinx
git-repository.
Hardware is an FX12 Mini-Module form AVNET, standard design with LL-TEMAC,
EDK 9.2.
Kernel boots fine till he try to mount his rootfs via NFS. NFS is working
correctly, probed with some other maschines. Some times kernel can mount
NFS, somtimes kernel panics trying this.
I already try some additional parameters found here on the list like
"tcp,no_lock" but didn't help. Also probed direct connection, connection via
a 100 MBit switch. No success.
Another thing I tried is set ip=dhcp, the device find our DHCP-Server and
gets an address. So I think network should ok, but where comes the NFS
trouble from?
Best Regards,
Ingo Maindorfer
The boot messages from console:
loaded at: 00400000 0052E19C
board data at: 0052C120 0052C19C
relocated to: 0040409C 00404118
zimage at: 00404F13 0052BDE3
avail ram: 0052F000 02000000
Linux/PPC load: console=ttyUL0,19200
ip=10.82.2.234:10.82.2.103:10.82.2.4:255.255.255.0
nfsroot=10.82.2.103:/tftpboot
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.24-rc8-xlnx-g8a6d0b1a-dirty (ingo@messstrecke) (gcc
version 3.4.5) #24 PREEMPT Fri Feb 8 14:21:06 CET 2008
Xilinx Generic PowerPC board support package (Xilinx ML40
Zone PFN ranges:ilinx_lltemac.0:
DMA 0 -> 8192
Normal 8192 -> 8192lTemac: Dma base address: phy:
HighMem 8192 -> 81927c
Movable zone start PFN for each node
et
XLlTemac: buffer descriptor s
early_node_map[1] active PFN ranges_table+0x64/0xe44 (order: 0, 40
0: 0 -> 8192
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128
with kmalloc<6>XLlTemac: (buffer_descriptor
Kernel command line: console=ttyUL0,19200
ip=10.82.2.234:10.82.2.103:10.82.2.4:255.255.255.0
nfsroot=10.82.2.103:/tftpboot
_init) phy: 0x1c98000, virt: 0xc1c98000, size: 0x8000
TCP estab
Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
XTemac: PHY detected at address 4.
PID hash table entries: 128 (order: 7, 512 bytes)
eth0: Dropping NETIF_F_SG sin
Memory: 29820k available (1940k kernel code, 600k data, 104k init, 0k
highmem)
eth0: XLlTemac: allocating interrupt 1 f
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1,
Nodes=1LlTemac:
eth0: XLlTemac: Not able to set the speed to 1000 (st
Mount-cache hash table entries: 512
net_namespace: 64 bytesLlTemac: We renegotiate
NET: Registered protocol family 16
Registering device uartlite:0ltemac.0: eth0:
Registering device xilinx_lltemac:0mac: speed set to 100Mb/s 0xC3Send
NET: Registered protocol family 2
TCP reno registeredmac: allocating int
sysctl table check failed: /kernel/l2cr .1.31 Missing strategy4k init
eth0: XLlTemac:
Call Trace:o
[c1c0fe60] [c0008e68] show_stack+0x40/0x194 (unreliable)sole.
IP-Con
[c1c0fe90] [c0036414] set_fail+0x68/0x80nk carrier restored.
[c1c0feb0] [c0036a2c] sysctl_check_table+0x600/0x77c
-- Entering main() --ask=255.255.255.0, gw
[c1c0fef0] [c0036a14] sysctl_c
[c1c0fff0] [c0004e78] kernel_thread+0x44/0x60ver=1
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).rnel memory: 104k i
io scheduler noop registeredLinux/PPC load: console=ttyU
io scheduler cfq registered (default).82.2.4:255.25e to open an initial co
uartlite.0: ttyUL0 at MMIO 0x84000003 (irq = 3) is a uartlite
Lookin
console [ttyUL0] enabled82.2.75:/tftpboot82.
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
DMA 0 -> 819210.82.2
Built 1
XLlTemac: Allocating DMA descriptors with kmalloc<6>XLlTemac:
(buffer_descriptor_init) phy: 0x1c90000, virt: 0xc1c90000, size: 0x800
55.255.255.0 nfsroot=10.82.2.75:/tftpboot######################
0
XTemac: PHY detected at address 4. #0 at 0x81800000 mapped to 0xFDFF
eth0: Dropping NETIF_F_SG since no checksum feature.
PID
xilinx_lltemac xilinx_lltemac.0: eth0: Xilinx TEMAC a
RPC: Registered udp transport module.AC
RPC: Registered tcp transport module.s: 2048 (order: 1, 8192 bytes)8192
eth0: XLlTemac: allocating interrupt 0 for dma mode tx.
eth0: XLlTemac: allocating interrupt 1 for dma mode rx.
eth0: XLlTemac: We renegotiated the speed to: 1000
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
IP-Config: Complete:
device=eth0, addr=10.82.2.234, mask=255.255.255.0, gw=10.82.2.4,
host=10.82.2.234, domain=, nis-domain=(none),
bootserver=10.82.2.103, rootserver=10.82.2.103, rootpath=
Looking up port of RPC 100003/2 on 10.82.2.103
Looking up port of RPC 100005/1 on 10.82.2.103
VFS: Mounted root (nfs filesystem) readonly.
Freeing unused kernel memory: 104k init
Warning: unable to open an initial console.
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 not responding, still trying
nfs: server 10.82.2.103 OK
nfs: server 10.82.2.103 OK
wireshark spite out this (.103 NFS-Server, .234 Xilinx):
"22","7.482314000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
25), FH:0xb29d0d7b Offset:16384 Count:4096 TotalCount:4096"
"23","7.482411000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #25]"
"24","7.482416000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #25]"
"25","7.482418000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
22)"
"26","8.581527000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
29), FH:0xb29d0d7b Offset:8192 Count:4096 TotalCount:4096"
"27","8.581608000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #29]"
"28","8.581612000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #29]"
"29","8.581615000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
26)"
"30","8.585120000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
33), FH:0xb29d0d7b Offset:12288 Count:4096 TotalCount:4096"
"31","8.585160000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #33]"
"32","8.585164000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #33]"
"33","8.585166000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
30)"
"34","8.593065000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission of
#22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"35","8.593109000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #37]"
"36","8.593113000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #37]"
"37","8.593115000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"38","8.607327000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply In
39), FH:0xb29d0d7b Offset:20480 Count:896 TotalCount:896"
"39","8.607363000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call In
38)"
"54","10.807186000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #38]V2 READ Call (Reply In 39), FH:0xb29d0d7b Offset:20480 Count:896
TotalCount:896"
"55","10.807248000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#39]V2 READ Reply (Call In 38)"
"60","13.012339000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"61","13.012483000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #63]"
"62","13.012489000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #63]"
"63","13.012492000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"65","14.111614000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"66","14.111699000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #68]"
"67","14.111705000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #68]"
"68","14.111707000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"71","16.311259000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #22]V2 READ Call (Reply In 25), FH:0xb29d0d7b Offset:16384 Count:4096
TotalCount:4096"
"72","16.311360000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #74]"
"73","16.311366000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #74]"
"74","16.311368000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#25]V2 READ Reply (Call In 22)"
"75","16.322672000","10.82.2.234","10.82.2.103","NFS","V2 GETATTR Call
(Reply In 76), FH:0x00bdec42"
"76","16.322705000","10.82.2.103","10.82.2.234","NFS","V2 GETATTR Reply
(Call In 75)"
"77","16.326131000","10.82.2.234","10.82.2.103","NFS","V2 LOOKUP Call (Reply
In 78), DH:0x529ded7b/libc.so.6"
"78","16.326167000","10.82.2.103","10.82.2.234","NFS","V2 LOOKUP Reply (Call
In 77), FH:0x569de97b"
"79","16.329608000","10.82.2.234","10.82.2.103","NFS","V2 READLINK Call
(Reply In 80), FH:0x569de97b"
"80","16.329654000","10.82.2.103","10.82.2.234","NFS","V2 READLINK Reply
(Call In 79) Path:libc-2.3.6.so"
"81","16.332969000","10.82.2.234","10.82.2.103","NFS","V2 LOOKUP Call (Reply
In 82), DH:0x529ded7b/libc-2.3.6.so"
"82","16.332993000","10.82.2.103","10.82.2.234","NFS","V2 LOOKUP Reply (Call
In 81), FH:0x529ded7b"
"83","16.336586000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply
In 86), FH:0x529ded7b Offset:0 Count:4096 TotalCount:4096"
"84","16.336620000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #86]"
"85","16.336625000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #86]"
"86","16.336627000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call
In 83)"
"87","16.336815000","10.82.2.234","10.82.2.103","NFS","V2 READ Call (Reply
In 90), FH:0x529ded7b Offset:4096 Count:4096 TotalCount:4096"
"88","16.336845000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=0) [Reassembled in #90]"
"89","16.336850000","10.82.2.103","10.82.2.234","IP","Fragmented IP protocol
(proto=UDP 0x11, off=1480) [Reassembled in #90]"
"90","16.336852000","10.82.2.103","10.82.2.234","NFS","V2 READ Reply (Call
In 87)"
"168","31.034419000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #83]V2 READ Call (Reply In 86), FH:0x529ded7b Offset:0 Count:4096
TotalCount:4096"
"169","31.034530000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=0) [Reassembled in #171]"
"170","31.034535000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=1480) [Reassembled in #171]"
"171","31.034537000","10.82.2.103","10.82.2.234","NFS","[RPC duplicate of
#86]V2 READ Reply (Call In 83)"
"193","32.133681000","10.82.2.234","10.82.2.103","NFS","[RPC retransmission
of #87]V2 READ Call (Reply In 90), FH:0x529ded7b Offset:4096 Count:4096
TotalCount:4096"
"194","32.133823000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=0) [Reassembled in #196]"
"195","32.133828000","10.82.2.103","10.82.2.234","IP","Fragmented IP
protocol (proto=UDP 0x11, off=1480) [Reassembled in #196]"
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Problem-mountin-rootfs-via-NFS-tp15355858p15355858.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] MTD support for the AMCC Taishan
From: Stefan Roese @ 2008-02-08 14:27 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <120203530465-git-send-email-kaloz@openwrt.org>
On Sunday 03 February 2008, Imre Kaloz wrote:
> Signed-off-by: Imre Kaloz <kaloz@openwrt.org>
> ---
> arch/powerpc/boot/dts/taishan.dts | 33 +++++++++++-
> arch/powerpc/configs/taishan_defconfig | 89
> ++++++++++++++++++++++++++++++-- 2 files changed, 116 insertions(+), 6
> deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/taishan.dts
> b/arch/powerpc/boot/dts/taishan.dts index 0706a4a..28c14dd 100644
> --- a/arch/powerpc/boot/dts/taishan.dts
> +++ b/arch/powerpc/boot/dts/taishan.dts
> @@ -174,7 +174,38 @@
> interrupts = <5 4>;
> interrupt-parent = <&UIC1>;
>
> - /* TODO: Add other EBC devices */
> + nor_flash@0,0 {
> + compatible = "cfi-flash";
> + bank-width = <4>;
> + device-width = <2>;
> + reg = <0 000000 4000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "kernel";
> + reg = <0 180000>;
> + };
> + partition@180000 {
> + label = "root";
> + reg = <180000 200000>;
> + };
> + partition@380000 {
> + label = "user";
> + reg = <380000 3a80000>;
> + };
> + partition@3e00000 {
> + label = "kozio";
> + reg = <3e00000 140000>;
> + };
Please remove the kozio partition from this list. It's not used/supported
anymore.
Thanks.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
^ permalink raw reply
* Re: [PATCH] MTD support for the AMCC Taishan
From: Stefan Roese @ 2008-02-08 14:32 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <200802081527.28771.sr@denx.de>
On Friday 08 February 2008, Stefan Roese wrote:
> > + partition@380000 {
> > + label = "user";
> > + reg = <380000 3a80000>;
> > + };
> > + partition@3e00000 {
> > + label = "kozio";
> > + reg = <3e00000 140000>;
> > + };
>
> Please remove the kozio partition from this list. It's not used/supported
> anymore.
And please extend the "user" partition accordingly.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 05/18] ide: factor out cable detection from ide_init_port()
From: Sergei Shtylyov @ 2008-02-08 17:18 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004455.17746.44570.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> * Factor out cable detection from ide_init_port() to ide_port_cable_detect().
> * Move ide_port_cable_detect() call to ide_device_add_all().
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 08/18] ide: move ide_port_setup_devices() call to ide_device_add_all()
From: Sergei Shtylyov @ 2008-02-08 17:20 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004516.17746.18498.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> Add ide_cfg_mtx lock/unlock to ide_port_setup_devices() and then move
> ide_port_setup_devices() call from init_irq() to ide_device_add_all().
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 02/18] ide: fix ide_find_port()
From: Sergei Shtylyov @ 2008-02-08 17:23 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004434.17746.33986.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> * Instead of checking for '->io_ports[IDE_DATA_OFFSET] == 0' check for
> '->chipset == ide_unknown' when looking for an empty ide_hwifs[] slot.
> * Do ide-pnp initialization after ide-generic when IDE is built-in
> (ide-pnp is the only user of ide_find_port() which needs such fixup).
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Paul Jackson @ 2008-02-08 18:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linuxppc-dev, paulus, akpm, tglx
In-Reply-To: <alpine.LFD.1.00.0802071449240.2896@woody.linux-foundation.org>
Linus wrote:
> Please, when mentioning hex numbers, also do the one-liner shortlog.
> ...
> without _requiring_ people to be git users to get the gist of the
> matter, ok?
Thanks for sticking up for us git-challenged contributors.
Can anyone point me at instructions providing the shortest
path for getting from one of those git hex numbers to the
log or change it represents, for non-git users?
Or do those instructions begin with a first step of:
1. become a git user
2. ...
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
^ permalink raw reply
* Re: [PATCH] Fix powerpc vdso clock_getres().
From: Sean MacLennan @ 2008-02-08 18:16 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Thomas Gleixner, Paul Mackerras
In-Reply-To: <20080207064750.GG6887@bakeyournoodle.com>
Tony Breeds wrote:
> Since implementing highres timers on powerpc the clock_getres syscall
> has reported different resolutions due to the vdso using the a low res
> value. In the patch d7f71674ad7c3c4467e48f6ab9e85516dae2720
> ([POWERPC] Use a sensible default for clock_getres() in the VDSO), the
> powerpc vdso was updated to use the correct value.
>
> This fix doesn't work on older compilers. Below is a fix for powerpc,
> that introduces a new (generic) #define MONOTONIC_RES_NSEC which is
> equal to the 64 value stored in KTIME_MONOTONIC_RES.
>
Just a confirmation that this patch fixed my compile issue. And I was
using gcc-4.0.0.
Thanks,
Sean
^ permalink raw reply
* Re: [PATCH] [POWERPC] Xilinx: hwicap driver
From: Randy Dunlap @ 2008-02-08 16:49 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev, jirislaby, linux-kernel
In-Reply-To: <20080208021747.92253161805C@mail10-sin.bigfish.com>
On Thu, 7 Feb 2008 18:17:41 -0800 Stephen Neuendorffer wrote:
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 1 +
> drivers/char/xilinx_hwicap/Makefile | 7 +
> drivers/char/xilinx_hwicap/buffer_icap.c | 380 ++++++++++++
> drivers/char/xilinx_hwicap/buffer_icap.h | 57 ++
> drivers/char/xilinx_hwicap/fifo_icap.c | 381 ++++++++++++
> drivers/char/xilinx_hwicap/fifo_icap.h | 62 ++
> drivers/char/xilinx_hwicap/xilinx_hwicap.c | 923 ++++++++++++++++++++++++++++
> drivers/char/xilinx_hwicap/xilinx_hwicap.h | 193 ++++++
> 9 files changed, 2011 insertions(+), 0 deletions(-)
> create mode 100644 drivers/char/xilinx_hwicap/Makefile
> create mode 100644 drivers/char/xilinx_hwicap/buffer_icap.c
> create mode 100644 drivers/char/xilinx_hwicap/buffer_icap.h
> create mode 100644 drivers/char/xilinx_hwicap/fifo_icap.c
> create mode 100644 drivers/char/xilinx_hwicap/fifo_icap.h
> create mode 100644 drivers/char/xilinx_hwicap/xilinx_hwicap.c
> create mode 100644 drivers/char/xilinx_hwicap/xilinx_hwicap.h
>
> diff --git a/drivers/char/xilinx_hwicap/buffer_icap.c b/drivers/char/xilinx_hwicap/buffer_icap.c
> new file mode 100644
> index 0000000..dfea2bd
> --- /dev/null
> +++ b/drivers/char/xilinx_hwicap/buffer_icap.c
> @@ -0,0 +1,380 @@
> +/**
> + * buffer_icap_get_status: Get the contents of the status register.
> + * @parameter base_address: is the base address of the device
> + *
Hi,
For this function and many others in these source files:
Please see Documentation/kernel-doc-nano-HOWTO.txt for the correct
kernel-doc notation format.
If you have questions or need help, please ask.
Hints:
a. function name & short description: separate name & description with '-'
b. parameters are listed as: @base_address: (without "parameter")
> + * The status register contains the ICAP status and the done bit.
> + *
> + * D8 - cfgerr
> + * D7 - dalign
> + * D6 - rip
> + * D5 - in_abort_l
> + * D4 - Always 1
> + * D3 - Always 1
> + * D2 - Always 1
> + * D1 - Always 1
> + * D0 - Done bit
> + **/
> +static inline u32 buffer_icap_get_status(void __iomem *base_address)
> +{
> + return in_be32(base_address + XHI_STATUS_REG_OFFSET);
> +}
> diff --git a/drivers/char/xilinx_hwicap/xilinx_hwicap.h b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> new file mode 100644
> index 0000000..5718679
> --- /dev/null
> +++ b/drivers/char/xilinx_hwicap/xilinx_hwicap.h
> @@ -0,0 +1,193 @@
> +#ifndef XILINX_HWICAP_H_ /* prevent circular inclusions */
> +#define XILINX_HWICAP_H_ /* by using protection macros */
> +
> +#include <linux/types.h>
> +#include <linux/cdev.h>
> +#include <linux/version.h>
> +#include <linux/platform_device.h>
> +
> +#include <asm/io.h>
> +
> +struct hwicap_drvdata {
BTW, you can also use kernel-doc for structs, unions, & enums.
> + u32 write_buffer_in_use; /* Always in [0,3] */
> + u8 write_buffer[4];
> + u32 read_buffer_in_use; /* Always in [0,3] */
> + u8 read_buffer[4];
> + resource_size_t mem_start;/* phys. address of the control registers */
> + resource_size_t mem_end; /* phys. address of the control registers */
> + resource_size_t mem_size;
> + void __iomem *base_address;/* virt. address of the control registers */
> +
> + struct device *dev;
> + struct cdev cdev; /* Char device structure */
> + dev_t devt;
> +
> + const struct hwicap_driver_config *config;
> + const struct config_registers *config_regs;
> + void *private_data;
> + bool is_open;
> + struct mutex sem;
> +};
> +
> +struct hwicap_driver_config {
> + int (*get_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
> + u32 size);
> + int (*set_configuration)(struct hwicap_drvdata *drvdata, u32 *data,
> + u32 size);
> + void (*reset)(struct hwicap_drvdata *drvdata);
> +};
> +
> +/* Number of times to poll the done regsiter */
> +#define XHI_MAX_RETRIES 10
---
~Randy
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Olof Johansson @ 2008-02-08 18:21 UTC (permalink / raw)
To: Paul Jackson
Cc: linux-kernel, linuxppc-dev, paulus, tglx, Linus Torvalds, akpm
In-Reply-To: <20080208120623.3ad74e3a.pj@sgi.com>
On Fri, Feb 08, 2008 at 12:06:23PM -0600, Paul Jackson wrote:
> Linus wrote:
> > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > ...
> > without _requiring_ people to be git users to get the gist of the
> > matter, ok?
>
>
> Thanks for sticking up for us git-challenged contributors.
>
> Can anyone point me at instructions providing the shortest
> path for getting from one of those git hex numbers to the
> log or change it represents, for non-git users?
>
> Or do those instructions begin with a first step of:
>
> 1. become a git user
> 2. ...
Does this count?
1. Go to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
2. Enter the SHA string in the 'search' field at the top right
-Olo
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Harvey Harrison @ 2008-02-08 18:20 UTC (permalink / raw)
To: Paul Jackson
Cc: linux-kernel, linuxppc-dev, paulus, akpm, Linus Torvalds, tglx
In-Reply-To: <20080208120623.3ad74e3a.pj@sgi.com>
On Fri, 2008-02-08 at 12:06 -0600, Paul Jackson wrote:
> Linus wrote:
> > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > ...
> > without _requiring_ people to be git users to get the gist of the
> > matter, ok?
>
>
> Thanks for sticking up for us git-challenged contributors.
>
> Can anyone point me at instructions providing the shortest
> path for getting from one of those git hex numbers to the
> log or change it represents, for non-git users?
>
Replace <SHA> as needed:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=<SHA>
Harvey
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Olof Johansson @ 2008-02-08 18:23 UTC (permalink / raw)
To: Paul Jackson
Cc: linux-kernel, linuxppc-dev, paulus, tglx, Linus Torvalds, akpm
In-Reply-To: <20080208182154.GA10295@lixom.net>
On Fri, Feb 08, 2008 at 12:21:54PM -0600, Olof Johansson wrote:
> On Fri, Feb 08, 2008 at 12:06:23PM -0600, Paul Jackson wrote:
> > Linus wrote:
> > > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > > ...
> > > without _requiring_ people to be git users to get the gist of the
> > > matter, ok?
> >
> >
> > Thanks for sticking up for us git-challenged contributors.
> >
> > Can anyone point me at instructions providing the shortest
> > path for getting from one of those git hex numbers to the
> > log or change it represents, for non-git users?
> >
> > Or do those instructions begin with a first step of:
> >
> > 1. become a git user
> > 2. ...
>
> Does this count?
>
> 1. Go to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
> 2. Enter the SHA string in the 'search' field at the top right
Ack, that just found the commit that referred to it, not the original
one. My bad.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=<hex value>
Will bring it up though.
-Olof
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Simon Holm Thøgersen @ 2008-02-08 18:31 UTC (permalink / raw)
To: Paul Jackson
Cc: linux-kernel, linuxppc-dev, paulus, akpm, Linus Torvalds, tglx
In-Reply-To: <20080208120623.3ad74e3a.pj@sgi.com>
fre, 08 02 2008 kl. 12:06 -0600, skrev Paul Jackson:
> Linus wrote:
> > Please, when mentioning hex numbers, also do the one-liner shortlog.
> > ...
> > without _requiring_ people to be git users to get the gist of the
> > matter, ok?
>
>
> Thanks for sticking up for us git-challenged contributors.
>
> Can anyone point me at instructions providing the shortest
> path for getting from one of those git hex numbers to the
> log or change it represents, for non-git users?
Use gitweb [1], Linus' tree is here [2]. Just search for the hex.
[1] http://git.kernel.org/
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
Simon Holm Thøgersen
^ permalink raw reply
* Re: [PATCH] Fix compilation of powerpc asm-offsets.c with old gcc
From: Paul Jackson @ 2008-02-08 18:39 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-kernel, linuxppc-dev, paulus, tglx, torvalds, akpm,
Harvey Harrison
In-Reply-To: <20080208182343.GB10295@lixom.net>
Thanks, Olof and Harvey.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=
Just what I was looking for.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.940.382.4214
^ permalink raw reply
* RE: [Virtex 4 PPC] Problem mountin rootfs via NFS
From: Sugathan, Rupesh @ 2008-02-08 18:27 UTC (permalink / raw)
To: IngoM, linuxppc-embedded
in the meantime, I get up my toolchain and an linux-kernel from xilinx
git-repository.
Hardware is an FX12 Mini-Module form AVNET, standard design with
LL-TEMAC, EDK 9.2.
Kernel boots fine till he try to mount his rootfs via NFS. NFS is
working correctly, probed with some other maschines. Some times kernel
can mount NFS, somtimes kernel panics trying this.
I already try some additional parameters found here on the list like
"tcp,no_lock" but didn't help. Also probed direct connection, connection
via a 100 MBit switch. No success.
Another thing I tried is set ip=3Ddhcp, the device find our DHCP-Server
and gets an address. So I think network should ok, but where comes the
NFS trouble from?
=20
Do you have a 'console' device file set up in your NFS rootfilesystem?=20
Thanks
--
Rupesh Sugathan
^ permalink raw reply
* APU FPU in Virtex ppc405
From: A. Nolson @ 2008-02-08 18:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have just heard that Xilinx has freed the FPU module for the PPC
architecture in EDK9.2i. WIll I be able to make it work with my
Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
Will it be just a matter of integrating it with the XPS BSP?I make an
extensive use of floating point in my applications and this will be
really useful.
Thanks for your help.
^ permalink raw reply
* RE: [Virtex 4 PPC] Problem mountin rootfs via NFS
From: IngoM @ 2008-02-08 19:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <EE63F03D9E04774997AEBCD21FC77F25190363@ccomm-ex1.ccomm.com>
Dear Rupesh,
Sugathan, Rupesh wrote:
>
>
> <snip>
>
>
> Do you have a 'console' device file set up in your NFS rootfilesystem?
>
>
no, I don't think so. When I'm back in office Monday morning I'll looking
into detail for you.
But the error seems to be some low-level network issue: sometimes kernel can
mount NFS, sometimes not and so on.
Best Regards,
Ingo
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Problem-mountin-rootfs-via-NFS-tp15355858p15361890.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 5/5] Tsi108_eth: Add ethtool support
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Add ethtool support to tsi108_eth network driver.
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
17:10:53.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
18:09:43.000000000 -0500
@@ -36,6 +36,7 @@
#include <linux/net.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
+#include <linux/ethtool.h>
#include <linux/skbuff.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
@@ -1519,12 +1520,46 @@ static void tsi108_init_mac(struct net_d
TSI_WRITE(TSI108_EC_INTMASK, ~0);
}
=20
+static int tsi108_get_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data =3D netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+=09
+ spin_lock_irqsave(&data->txlock, flags);
+ rc =3D mii_ethtool_gset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+
+ return rc;
+}
+
+static int tsi108_set_settings(struct net_device *dev, struct
ethtool_cmd *cmd)
+{
+ struct tsi108_prv_data *data =3D netdev_priv(dev);
+ unsigned long flags;
+ int rc;
+
+ spin_lock_irqsave(&data->txlock, flags);
+ rc =3D mii_ethtool_sset(&data->mii_if, cmd);
+ spin_unlock_irqrestore(&data->txlock, flags);
+=09
+ return rc;
+}
+
static int tsi108_do_ioctl(struct net_device *dev, struct ifreq *rq,
int cmd)
{
struct tsi108_prv_data *data =3D netdev_priv(dev);
+ if (!netif_running(dev))
+ return -EINVAL;
return generic_mii_ioctl(&data->mii_if, if_mii(rq), cmd, NULL);
}
=20
+static const struct ethtool_ops tsi108_ethtool_ops =3D {
+ .get_link =3D ethtool_op_get_link,
+ .get_settings =3D tsi108_get_settings,
+ .set_settings =3D tsi108_set_settings,
+};
+
static int
tsi108_init_one(struct platform_device *pdev)
{
@@ -1589,6 +1624,7 @@ tsi108_init_one(struct platform_device *
dev->get_stats =3D tsi108_get_stats;
netif_napi_add(dev, &data->napi, tsi108_poll, 64);
dev->do_ioctl =3D tsi108_do_ioctl;
+ dev->ethtool_ops =3D &tsi108_ethtool_ops;
=20
/* Apparently, the Linux networking code won't use
scatter-gather
* if the hardware doesn't do checksums. However, it's faster
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 4/5] Tsi108_eth: fix link recovery after disconnect
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with link recovery after connection was lost.
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
16:16:00.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
16:57:41.000000000 -0500
@@ -338,22 +338,21 @@ static void tsi108_check_phy(struct net_
=20
TSI_WRITE(TSI108_MAC_CFG2, mac_cfg2_reg);
TSI_WRITE(TSI108_EC_PORTCTRL, portctrl_reg);
+ }
=20
- if (data->link_up =3D=3D 0) {
- /* The manual says it can take 3-4 usecs
for the speed change
- * to take effect.
- */
- udelay(5);
-
- spin_lock(&data->txlock);
- if (is_valid_ether_addr(dev->dev_addr)
&& data->txfree)
- netif_wake_queue(dev);
+ if (data->link_up =3D=3D 0) {
+ /* The manual says it can take 3-4 usecs for the
speed change
+ * to take effect.
+ */
+ udelay(5);
=20
- data->link_up =3D 1;
- spin_unlock(&data->txlock);
- }
- }
+ spin_lock(&data->txlock);
+ if (is_valid_ether_addr(dev->dev_addr) &&
data->txfree)
+ netif_wake_queue(dev);
=20
+ data->link_up =3D 1;
+ spin_unlock(&data->txlock);
+ }
} else {
if (data->link_up =3D=3D 1) {
netif_stop_queue(dev);
@@ -1267,12 +1266,11 @@ static void tsi108_init_phy(struct net_d
* PHY_STAT register before the link up status bit is set.
*/
=20
- data->link_up =3D 1;
+ data->link_up =3D 0;
=20
while (!((phyval =3D tsi108_read_mii(data, MII_BMSR)) &
BMSR_LSTATUS)) {
if (i++ > (MII_READ_DELAY / 10)) {
- data->link_up =3D 0;
break;
}
spin_unlock_irqrestore(&phy_lock, flags);
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 2/5] Tsi108_eth: fix detection of 1000Mb mode
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with detection of 1000Mb speed.=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
15:09:19.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:34:12.000000000 -0500
@@ -1287,6 +1287,7 @@ static void tsi108_init_phy(struct net_d
spin_lock_irqsave(&phy_lock, flags);
}
=20
+ data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok =3D 1;
data->init_media =3D 1;
@@ -1584,7 +1585,6 @@ tsi108_init_one(struct platform_device *
data->mii_if.phy_id =3D einfo->phy;
data->mii_if.phy_id_mask =3D 0x1f;
data->mii_if.reg_num_mask =3D 0x1f;
- data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
=20
data->phy =3D einfo->phy;
data->phy_type =3D einfo->phy_type;
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ 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