* burst
From: Wojciech Kromer @ 2005-07-28 11:03 UTC (permalink / raw)
To: linuxppc-embedded
How to enable burst acces for external device?
What i did:
- program UPMx with correct cycles
- setup ORx BRx, and not set BI (BurstInhibit)
- done opremap instead of opremap_nocache
An no burst acces is done.
Do I have to do DMA transfers?
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860board)
From: FCG WANG Baohua @ 2005-07-28 10:08 UTC (permalink / raw)
To: Esben Nielsen, Frank; +Cc: linuxppc-embedded
Dear Esben:
Thanks for your advice. I guess the vxworks 5.3.1 can process the ELF =
format.=20
Can you tell me "the link address of the VxWorks kernel ELF file" ?=20
Someone said that "make sure the Linux kernel is linked at that same =
address".
Other one said to use zImage of kernel instead of ELF "vmlinux" image, =
have you tested using zImage on vxWorks?=20
=20
Can you give me some step tips when processing your 5.5 bootloader ?
need to revise the entry points? using the 0x200000 original addresss =
of linux kernel ?=20
The serial port print what info after "starting at 0x200000 ...." ?=20
=20
thanks a lot!
=20
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: Esben Nielsen [mailto:simlo@phys.au.dk]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C228=C8=D5 15:47
=CA=D5=BC=FE=C8=CB: Frank
=B3=AD=CB=CD: FCG WANG Baohua; linuxppc-embedded@ozlabs.org
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader
(PPC860board)
On Wed, 27 Jul 2005, Frank wrote:
>=20
>=20
> --- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
>=20
> > Dear All:
> > I want to boot a linux 2.4.25 kernel under vxworks
> > bootloader. When I using flat mode(0x200000 --> 0x10000)
> > kernel uncompressed ELF format ( vmlinux ),
> > and download it using TFTP of vxworks, it print the "starting
> > at 0x1000 ...." and freeze. No input or output on serial
> > port.
> > The version of vxworks is 5.3.1.=20
> > can you give me some detail advice or give me a tool to slove
> > it? thanks !
I have done it on a MPC5200 with a vxWorks 5.5 bootsector with ethernet
support: I just boot over FTP. Give it the Linux kernel in elf-format,=20
the bootsector doesn't care, _what_ the code actually is, it just loads
and run it.=20
For vxWorks <=3D 5.4 I believe coff is used instead of elf - at least on
some architectures. Then you have a problem, because the kernel isn't
compiled to coff :-(
Esben
>=20
> Do what I did:
> Replace the vxWorks rom with you u-boot and you can boot Linux
> or vxWorks with the same bootloader.
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around=20
> http://mail.yahoo.com=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: CPM MCC sample driver?
From: Alex Zeffertt @ 2005-07-28 9:41 UTC (permalink / raw)
To: bbosch; +Cc: linuxppc-embedded
In-Reply-To: <17127.49093.492554.638213@waldo.lisle.iphase.com>
On Wed, 27 Jul 2005 12:09:25 -0500
bbosch@iphase.com wrote:
> A couple of years ago, Adam Kaczynski announced a sample MCC HDLC and
> Transparent mode driver. Both the URL Adam posted and Adam's email
> address are no longer valid. Is this code or any other Linux MCC
> driver available anywhere? I need to develop an MCC driver for a
> project I am working on and it would be very helpful to have an
> example to start with.
>
I'm not sure what you mean by MCC. I've got an PQI SCC tranparent mode driver which implements a
character device for reading from/writing to a PCM bus. I wrote it a couple of years ago and tested
it using an external loopback - but I've never used it in anger. Would this be useful to you?
Alex
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Jörn Engel @ 2005-07-28 9:18 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Netdev, linuxppc-embedded, Francois Romieu
In-Reply-To: <1122500059.28777@shark.he.net>
On Wed, 27 July 2005 14:34:19 -0700, Randy Dunlap wrote:
> >
> > Ok, here I won't agree to disagree with you. !foo as a check for
> > NULL is a reasonable idea, but not my style. If that's the preferred
> > style for the kernel, I will do that.
> >
> > But (var == constant) is a style that asks for errors. By putting
> > the constant first in these checks, you never run the risk of leaving
> > a bug like this:
> >
> > if (dev = NULL)
> > ...
> >
> > This kind of error is quite frustrating to detect, and the eye will
> > often miss it when scanning for errors. If you follow constant ==
> > var, though, then the bug looks like this:
> >
> > if (NULL = dev)
> >
> > which is instantly caught by the compiler.
> >
> > Just my 32 cents
>
> Yes, we know about that argument. :)
The counter-argument basically goes like this:
1. All relevant compilers (GCC) warn on "if (dev = NULL)", so you will
only miss the bug if you ignore compiler warnings. Ignoring compiler
warnings is not generally endorsed by the kernel crowd.
2. Very hard to read, "if (NULL = dev)" is. Reversing the order is a
fun thing to do for small green characters in fantasy and scifi
stories and fairly popular in peotry as well. But understanding the
meaning of reverse order sentences takes more time. In the kernel,
peer review is an important aspect and making the code hard to read
hurts peer review.
And maybe you can add another one:
3. Im my personal experience, reverse order comparisons were a good
indicator of buggy code.
Jörn
--
Schrödinger's cat is <BLINK>not</BLINK> dead.
-- Illiad
^ permalink raw reply
* Re : custom ads8272 board PCI interrupt no response
From: Sam Song @ 2005-07-28 8:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050727135233.7367.qmail@web15803.mail.cnb.yahoo.com>
Sam Song <samlinuxppc@yahoo.com.cn> wrote:
> Hi all,
>
> A PCI interrupt probelm confused me when porting
> 2.6.13-rc3 on a custom 8248 board. There was a
> Gb ethernet RTL8110S on board with IDSEL AD25 and
> IRQ3. So I made some changes as follows:
>
> --- linux-2.6.13-rc3/arch/ppc/platforms/pq2ads.h
> +++ linux-2.6.13-rc3-sam/arch/ppc/platforms/pq2ads.h
> @@ -74,11 +78,11 @@
> -#define PCI_INT_TO_SIU SIU_INT_IRQ2
> +#define PCI_INT_TO_SIU SIU_INT_IRQ3
Ummm, not the case. ADS8272 uses a CPLD PCI interrupt
controller which takes up IRQ2. No need to me:-)
> --- linux-2.6.13-rc3/arch/ppc/syslib/m82xx_pci.c
> +++ linux-2.6.13-rc3-sam/arch/ppc/syslib/m82xx_pci.c
> @@ -60,12 +60,20 @@
> * A B C D
> */
> {
> +#if 0
> { PIRQA, PIRQB, PIRQC, PIRQD },/* IDSEL 22 - PCI
>
> slot 0 */
> { PIRQD, PIRQA, PIRQB, PIRQC }, /* IDSEL 23 -
> PCI
> slot 1 */
> { PIRQC, PIRQD, PIRQA, PIRQB }, /* IDSEL 24 -
> PCI
> slot 2 */
> +#else
> + {22, 22, 22, 22},/* IDSEL 22/IRQ4-PCI slot 0-USB
> */
> + {23, 23, 23, 23},/* IDSEL 23/IRQ5-PCI slot 1-IDE
> */
> + {24, 24, 0, 0},/* IDSEL 24 - PCI slot # - NULL
> */
> + {25, 25, 25, 25},/* IDSEL 25/IRQ3-PCI slot 2- Gb
> */
Set IRQ3 in the last line as 21 to assign the IRQ3
to Gb ethernet.
> Gb interrupt remained unchangable in the whole test
> process. I could ping target itself but not for
> outside machine. So I suspect this result was due to
> PCI interrupt setting but don't know where the
> probelm is. Any idea?
Well, I finally masked pq2ads interrupt irq init and
adjusted SIUMCR IRQ3 setting correctly. Then
everything went as smoothly as clockwork.
Sorry to bother here:-)
Sam
__________________________________________________
赶快注册雅虎超大容量免费邮箱?
http://cn.mail.yahoo.com
^ permalink raw reply
* Re: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: Esben Nielsen @ 2005-07-28 7:47 UTC (permalink / raw)
To: Frank; +Cc: FCG WANG Baohua, linuxppc-embedded
In-Reply-To: <20050728042840.36296.qmail@web32203.mail.mud.yahoo.com>
On Wed, 27 Jul 2005, Frank wrote:
>
>
> --- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
>
> > Dear All:
> > I want to boot a linux 2.4.25 kernel under vxworks
> > bootloader. When I using flat mode(0x200000 --> 0x10000)
> > kernel uncompressed ELF format ( vmlinux ),
> > and download it using TFTP of vxworks, it print the "starting
> > at 0x1000 ...." and freeze. No input or output on serial
> > port.
> > The version of vxworks is 5.3.1.
> > can you give me some detail advice or give me a tool to slove
> > it? thanks !
I have done it on a MPC5200 with a vxWorks 5.5 bootsector with ethernet
support: I just boot over FTP. Give it the Linux kernel in elf-format,
the bootsector doesn't care, _what_ the code actually is, it just loads
and run it.
For vxWorks <= 5.4 I believe coff is used instead of elf - at least on
some architectures. Then you have a problem, because the kernel isn't
compiled to coff :-(
Esben
>
> Do what I did:
> Replace the vxWorks rom with you u-boot and you can boot Linux
> or vxWorks with the same bootloader.
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: platform/board removal update
From: Pantelis Antoniou @ 2005-07-28 6:29 UTC (permalink / raw)
To: 'Aristeu Sergio Rozanski Filho'
Cc: linuxppc-dev list, Embedded PPC Linux list
In-Reply-To: <20050727214600.GB30557@cathedrallabs.org>
'Aristeu Sergio Rozanski Filho' wrote:
>>8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
>>that its working fine.
>>
>>The fix will be pushed upstream ASAP.
>>
>>BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to
>>test all supported PHY's on the new driver.
>>
>>Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
>>by Panto's driver again? We should build a list of those and ask around for
>>testers.
>
> I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
> is change fec_8xx to use this abstraction layer and then look for
> testers. what you think?
>
There's a fs_enet driver in the works which will use Andy's work.
Please refrain from doing anything :)
Regards
Pantelis
^ permalink raw reply
* 答复: ?-?¤: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 5:12 UTC (permalink / raw)
To: Frank; +Cc: linuxppc-embedded
RGVhciBGcmFuazoNCiAgSG93IGNhbiBJIHJldmlzZSB0aGUgYWRkcmVzcyBvZiBsaW5rZWQgdG8g
Ym9vdCBpbiBVLUJvb3QgTWFrZWZpbGUgb3IgY29uZmlnIGZpbGUgPyBUaGFua3MgIQ0KICBJIHVz
ZSB0aGUgbWtpbWFnZSB1dGlsaXR5IG9mIFBQQ0Jvb3QgdG8gcmVsb2NhdGUgdGhlIGVudHJ5IHBv
aW50IHRvIDB4MTAwMCwgYnV0IEkgc3RpbGwgZ2V0IHRoZSANCiAic3RhcnRpbmcgYXQgMHgyODAw
MDAuLi4uLiIuIEhvdyB0byBtYWtlIGl0IGVmZmVjdD8gVGhhbmtzICENCg0KDQotLS0tLeWOn+Wn
i+mCruS7ti0tLS0tDQrlj5Hku7bkuro6IEZyYW5rIFttYWlsdG86ZnJhbm5rX20xQHlhaG9vLmNv
bV0NCuWPkemAgeaXtumXtDogMjAwNeW5tDfmnIgyOOaXpSAxMjo1Nw0K5pS25Lu25Lq6OiBGQ0cg
V0FORyBCYW9odWENCuS4u+mimDogUmU6ID8tP8KkOiBIb3cgdG8gbG9hZCBhIGxpbnV4IGtlcm5l
bCB1bmRlciB2eHdvcmtzIGJvb3Rsb2FkZXIgKFBQQzg2MCBib2FyZCkNCg0KDQpTb3JyeSwNCkJ1
dCB5b3Ugd2lsbCBoYXZlIHRvIHJlY29tcGlsZSB1LWJvb3QgYXQgdGhhdCBhZGRyZXNzLiBJdCdz
DQpvcmlnaW5hbGx5IGNvbXBpbGVkIGFuZCBsaW5rZWQgdG8gYm9vdCBhdCAweGZmZjAwMTAwLiBJ
IGRvbid0DQprbm93IHdoYXQgeW91IGhhdmUgdG8gZG8gd2l0aCB2eFdvcmtzIHJvbS4uLg0KDQot
LS0gRkNHIFdBTkcgQmFvaHVhIDxCYW9odWEuV0FOR0BhbGNhdGVsLXNiZWxsLmNvbS5jbj4gd3Jv
dGU6DQoNCj4gRGVhciBGcmFuazoNCj4gIEkgY2Fubm90IHJlcGxhY2UgdGhlIHZ4V29ya3MgYm9v
dHJvbSBiZWNhdXNlIEkgaGF2ZSBubyBzb3VyY2UNCj4gYW5kIGJpbiBmaWxlcyBvZiB2eHdvcmtz
IGJvb3Rsb2FkZXIsIEkgaGF2ZSBldmVuIG5vIHRoZSANCj4gIGhhcmR3YXJlIGRpYWdyYW0gcmVz
b3VyY2Ugb2YgbXkgUFBDIDg2MCBib2FyZC4gIElmIEkgd3JpdGUNCj4gdGhlIFUtQm9vdCBpbnRv
IHRoZSByb20sIEkgbW9zdCBwb3NzaWJsZSBjYW5ub3QgYm9vdHVwIHRoZQ0KPiBib2FyZC4NCj4g
IEhvdyB0byBkb3dubG9hZCB0aGUgVS1Cb290IGludG8gUkFNIGRpcmVjdGx5IHVzaW5nIHRoZQ0K
PiB2eFdvcmtzIGJvb3Rsb2FkZXIsIEkgdHJpZWQgdG8gbG9hZCB0aGUgVS1Cb290IEVMRiBpbWFn
ZSBidXQNCj4gZ2V0IHRoZSBzYW1lIA0KPiAgcmVzdWx0ICJzdGFydGluZyBhdCAweDI4MDAwMCAu
Li4iIHRoZW4gbm8gcmVzcG9uc2UgZnJvbSB0aGUNCj4gc2VyaWFsIGNvbnNvbGUuDQo+ICBUaGUg
b25seSB0aGluZyBJIGNhbiBkbyBpcyB1c2UgdnhXb3JrcyBURlRQIHRvIGRvd25sb2FkIHRoZQ0K
PiBFTEYgaW1hZ2UgZm9yIGxpbnV4IGtlcm5lbCBvciBVLUJvb3QgaW50byBSQU0uIA0KPiAgIENh
biB5b3UgdGVsbCBtZSBob3cgdG8gc2xvdmUgdGhlICBVLUJvb3QgInN0YXJ0aW5nIGF0DQo+IDB4
MjgwMDAwIC4uLiIgIHByb2JsZW0gPyB0aGFua3MhDQo+ICAgDQo+IA0KPiAtLS0tLcOlxb3FuMOl
wqfigLnDqeKAmsKuw6TCu8K2LS0tLS0NCj4gw6XCj+KAmMOkwrvCtsOkwrrCujogRnJhbmsgW21h
aWx0bzpmcmFubmtfbTFAeWFob28uY29tXQ0KPiDDpcKP4oCYw6nigqzCgcOm4oCUwrbDqeKAlOKA
sjogMjAwNcOlwrnigLI3w6bFk8uGMjjDpuKAlO+/pSAxMjoyOQ0KPiDDpuKAncK2w6TCu8K2w6TC
usK6OiBGQ0cgV0FORyBCYW9odWE7IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCj4gw6TC
uMK7w6nvv6DLnDogUmU6IEhvdyB0byBsb2FkIGEgbGludXgga2VybmVsIHVuZGVyIHZ4d29ya3MN
Cj4gYm9vdGxvYWRlciAoUFBDODYwIGJvYXJkKQ0KPiANCj4gDQo+IA0KPiANCj4gLS0tIEZDRyBX
QU5HIEJhb2h1YSA8QmFvaHVhLldBTkdAYWxjYXRlbC1zYmVsbC5jb20uY24+IHdyb3RlOg0KPiAN
Cj4gPiBEZWFyIEFsbDoNCj4gPiAgIEkgd2FudCB0byBib290IGEgbGludXggMi40LjI1IGtlcm5l
bCB1bmRlciB2eHdvcmtzDQo+ID4gYm9vdGxvYWRlci4gV2hlbiBJIHVzaW5nIGZsYXQgbW9kZSgw
eDIwMDAwMCAtLT4gIDB4MTAwMDApDQo+ID4ga2VybmVsICB1bmNvbXByZXNzZWQgRUxGIGZvcm1h
dCAoIHZtbGludXggKSwNCj4gPiAgYW5kIGRvd25sb2FkIGl0IHVzaW5nIFRGVFAgb2Ygdnh3b3Jr
cywgaXQgcHJpbnQgdGhlDQo+ICJzdGFydGluZw0KPiA+IGF0IDB4MTAwMCAuLi4uIiBhbmQgIGZy
ZWV6ZS4gIE5vIGlucHV0IG9yIG91dHB1dCBvbiBzZXJpYWwNCj4gPiBwb3J0Lg0KPiA+ICBUaGUg
dmVyc2lvbiBvZiB2eHdvcmtzIGlzIDUuMy4xLiANCj4gPiAgY2FuIHlvdSBnaXZlIG1lIHNvbWUg
ZGV0YWlsIGFkdmljZSBvciBnaXZlIG1lIGEgdG9vbCB0bw0KPiBzbG92ZQ0KPiA+IGl0PyB0aGFu
a3MgIQ0KPiANCj4gRG8gd2hhdCBJIGRpZDoNCj4gUmVwbGFjZSB0aGUgdnhXb3JrcyByb20gd2l0
aCB5b3UgdS1ib290IGFuZCB5b3UgY2FuIGJvb3QgTGludXgNCj4gb3IgdnhXb3JrcyB3aXRoIHRo
ZSBzYW1lIGJvb3Rsb2FkZXIuDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiBEbyBZb3UgWWFob28hPw0KPiBUaXJlZCBvZiBzcGFtPyAg
WWFob28hIE1haWwgaGFzIHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbg0KPiBhcm91bmQgDQo+IGh0
dHA6Ly9tYWlsLnlhaG9vLmNvbSANCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQpUaXJlZCBvZiBzcGFtPyAg
WWFob28hIE1haWwgaGFzIHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbiBhcm91bmQgDQpodHRwOi8v
bWFpbC55YWhvby5jb20gDQo=
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 4:49 UTC (permalink / raw)
To: Frank, linuxppc-embedded
RGVhciBGcmFuazoNCiBJIGNhbm5vdCByZXBsYWNlIHRoZSB2eFdvcmtzIGJvb3Ryb20gYmVjYXVz
ZSBJIGhhdmUgbm8gc291cmNlIGFuZCBiaW4gZmlsZXMgb2Ygdnh3b3JrcyBib290bG9hZGVyLCBJ
IGhhdmUgZXZlbiBubyB0aGUgDQogaGFyZHdhcmUgZGlhZ3JhbSByZXNvdXJjZSBvZiBteSBQUEMg
ODYwIGJvYXJkLiAgSWYgSSB3cml0ZSB0aGUgVS1Cb290IGludG8gdGhlIHJvbSwgSSBtb3N0IHBv
c3NpYmxlIGNhbm5vdCBib290dXAgdGhlIGJvYXJkLg0KIEhvdyB0byBkb3dubG9hZCB0aGUgVS1C
b290IGludG8gUkFNIGRpcmVjdGx5IHVzaW5nIHRoZSB2eFdvcmtzIGJvb3Rsb2FkZXIsIEkgdHJp
ZWQgdG8gbG9hZCB0aGUgVS1Cb290IEVMRiBpbWFnZSBidXQgZ2V0IHRoZSBzYW1lIA0KIHJlc3Vs
dCAic3RhcnRpbmcgYXQgMHgyODAwMDAgLi4uIiB0aGVuIG5vIHJlc3BvbnNlIGZyb20gdGhlIHNl
cmlhbCBjb25zb2xlLg0KIFRoZSBvbmx5IHRoaW5nIEkgY2FuIGRvIGlzIHVzZSB2eFdvcmtzIFRG
VFAgdG8gZG93bmxvYWQgdGhlIEVMRiBpbWFnZSBmb3IgbGludXgga2VybmVsIG9yIFUtQm9vdCBp
bnRvIFJBTS4gDQogIENhbiB5b3UgdGVsbCBtZSBob3cgdG8gc2xvdmUgdGhlICBVLUJvb3QgInN0
YXJ0aW5nIGF0IDB4MjgwMDAwIC4uLiIgIHByb2JsZW0gPyB0aGFua3MhDQogIA0KDQotLS0tLeWO
n+Wni+mCruS7ti0tLS0tDQrlj5Hku7bkuro6IEZyYW5rIFttYWlsdG86ZnJhbm5rX20xQHlhaG9v
LmNvbV0NCuWPkemAgeaXtumXtDogMjAwNeW5tDfmnIgyOOaXpSAxMjoyOQ0K5pS25Lu25Lq6OiBG
Q0cgV0FORyBCYW9odWE7IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcNCuS4u+mimDogUmU6
IEhvdyB0byBsb2FkIGEgbGludXgga2VybmVsIHVuZGVyIHZ4d29ya3MgYm9vdGxvYWRlciAoUFBD
ODYwIGJvYXJkKQ0KDQoNCg0KDQotLS0gRkNHIFdBTkcgQmFvaHVhIDxCYW9odWEuV0FOR0BhbGNh
dGVsLXNiZWxsLmNvbS5jbj4gd3JvdGU6DQoNCj4gRGVhciBBbGw6DQo+ICAgSSB3YW50IHRvIGJv
b3QgYSBsaW51eCAyLjQuMjUga2VybmVsIHVuZGVyIHZ4d29ya3MNCj4gYm9vdGxvYWRlci4gV2hl
biBJIHVzaW5nIGZsYXQgbW9kZSgweDIwMDAwMCAtLT4gIDB4MTAwMDApDQo+IGtlcm5lbCAgdW5j
b21wcmVzc2VkIEVMRiBmb3JtYXQgKCB2bWxpbnV4ICksDQo+ICBhbmQgZG93bmxvYWQgaXQgdXNp
bmcgVEZUUCBvZiB2eHdvcmtzLCBpdCBwcmludCB0aGUgInN0YXJ0aW5nDQo+IGF0IDB4MTAwMCAu
Li4uIiBhbmQgIGZyZWV6ZS4gIE5vIGlucHV0IG9yIG91dHB1dCBvbiBzZXJpYWwNCj4gcG9ydC4N
Cj4gIFRoZSB2ZXJzaW9uIG9mIHZ4d29ya3MgaXMgNS4zLjEuIA0KPiAgY2FuIHlvdSBnaXZlIG1l
IHNvbWUgZGV0YWlsIGFkdmljZSBvciBnaXZlIG1lIGEgdG9vbCB0byBzbG92ZQ0KPiBpdD8gdGhh
bmtzICENCg0KRG8gd2hhdCBJIGRpZDoNClJlcGxhY2UgdGhlIHZ4V29ya3Mgcm9tIHdpdGggeW91
IHUtYm9vdCBhbmQgeW91IGNhbiBib290IExpbnV4DQpvciB2eFdvcmtzIHdpdGggdGhlIHNhbWUg
Ym9vdGxvYWRlci4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCkRvIFlvdSBZYWhvbyE/DQpUaXJlZCBvZiBzcGFtPyAgWWFob28hIE1haWwgaGFz
IHRoZSBiZXN0IHNwYW0gcHJvdGVjdGlvbiBhcm91bmQgDQpodHRwOi8vbWFpbC55YWhvby5jb20g
DQo=
^ permalink raw reply
* Re: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: Frank @ 2005-07-28 4:28 UTC (permalink / raw)
To: FCG WANG Baohua, linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E8652D4@ydmail.sbell.com.cn>
--- FCG WANG Baohua <Baohua.WANG@alcatel-sbell.com.cn> wrote:
> Dear All:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial
> port.
> The version of vxworks is 5.3.1.
> can you give me some detail advice or give me a tool to slove
> it? thanks !
Do what I did:
Replace the vxWorks rom with you u-boot and you can boot Linux
or vxWorks with the same bootloader.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-28 4:16 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Dear All:
I want to boot a linux 2.4.25 kernel under vxworks bootloader. When I using flat mode(0x200000 --> 0x10000) kernel uncompressed ELF format ( vmlinux ),
and download it using TFTP of vxworks, it print the "starting at 0x1000 ...." and freeze. No input or output on serial port.
The version of vxworks is 5.3.1.
can you give me some detail advice or give me a tool to slove it? thanks !
[-- Attachment #2: Type: text/html, Size: 1168 bytes --]
^ permalink raw reply
* using bestcomm
From: 钟磊 @ 2005-07-28 3:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 401 bytes --]
Hi all:
In my embeded linux directory , I found the bestcomm API (ELDK\ppc_82xx\usr\src\linuxppc_2_4_devel
\arch\ppc\5xxx_io\bestcomm\capi)
But I don't know how to use the API to handle my task which is to transfer a block of data from the FPGA's internal RAM to the PowerPC MPC5200.
Pls give me a simple example of how to use the bestcomm to transfer data from FPGA
Thanks
zhonglei
[-- Attachment #2: Type: text/html, Size: 938 bytes --]
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-27 23:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Gala Kumar K.-galak, linuxppc-embedded
In-Reply-To: <20050727125746.54329281.akpm@osdl.org>
On Jul 27, 2005, at 2:57 PM, Andrew Morton wrote:
> Kumar Gala <galak@freescale.com> wrote:
>
>>
>> The following board ports are no longer maintained or have become
>> obsolete:
>>
>> adir
>> ash
>> beech
>> cedar
>> ep405
>> k2
>> mcpn765
>> menf1
>> oak
>> pcore
>> rainier
>> redwood
>> sm850
>> spd823ts
>>
>> We are there for removing support for them.
>>
>
> I'll merge all these into -mm for now, but will hold off sending
> any of
> them upstream pending confirmation of which patches we really want to
> proceed with.
Sounds good. We will get to some resolution on the ep405 which seems
the be the only system that people are making noise on today.
- kumar
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-27 23:34 UTC (permalink / raw)
To: Matt Porter
Cc: Andrew Morton, linux-kernel, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <20050727101502.B1114@cox.net>
On Jul 27, 2005, at 12:15 PM, Matt Porter wrote:
> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
>
>> On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
>>
>>> Kumar, I thought that we had some volunteers to take care of some of
>>> those. I know that I still care about ep405, and I'm willing to
>>>
> maintain
>
>>> the code.
>>>
>>
>> Well, it has been almost two months since Kumar asked about
>>
> maintenance
>
>> for this board. Nothing happened since then.
>>
>> Why is it not fixed yet? Please, send a patch which fixes it. This is
>> the _best_ way to keep this board in the tree, not some empty
>> maintenance _promises_.
>>
>
> When we recover our history from the linuxppc-2.4/2.5 trees we can
> show exactly how long it's been since anybody touched ep405.
>
> Quick googling shows that it's been almost 2 years since the last
> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
> Last ep405-related commits are more than 2 years ago.
So we are ok with it being removed. This seems to be the only board
port that I removed that has caused any noise.
- kumar
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Andrew Morton @ 2005-07-27 23:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <17128.4407.838024.111955@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> wrote:
>
> Andrew Morton writes:
>
> > Matt Porter <mporter@kernel.crashing.org> wrote:
> > >
> > > +static u64 dma_mask = 0xffffffffULL;
> >
> > I'm sure you're totally uninterested in this, but the above will probably
> > generate warnings on (say) ppc64, where u64 is implemented as unsigned
> > long.
> >
> > I usually chuck a simple `-1' in there and the compiler always gets it
> > right, regardless of signedness and size and architecture.
>
> Umm, I think we actually want 2^32-1 not -1, don't we?
Doh. Cant coun't.
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Paul Mackerras @ 2005-07-27 22:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <20050727131857.78a56972.akpm@osdl.org>
Andrew Morton writes:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > +static u64 dma_mask = 0xffffffffULL;
>
> I'm sure you're totally uninterested in this, but the above will probably
> generate warnings on (say) ppc64, where u64 is implemented as unsigned
> long.
>
> I usually chuck a simple `-1' in there and the compiler always gets it
> right, regardless of signedness and size and architecture.
Umm, I think we actually want 2^32-1 not -1, don't we? In which case
I think Matt's code is what we have to have.
I tried a little test compile with gcc 4.0 with -m64 -Wall and it
didn't generate a warning with the 0xffffffffULL constant.
Paul.
^ permalink raw reply
* Re: platform/board removal update
From: 'Aristeu Sergio Rozanski Filho' @ 2005-07-27 21:46 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-dev list, Embedded PPC Linux list
In-Reply-To: <20050726100500.GB28003@dmt.cnet>
> 8xx_io/fec.c is still using v2.4's workqueue infrastructure but other than
> that its working fine.
>
> The fix will be pushed upstream ASAP.
>
> BTW, we should schedule 8xx_io/fec.c for removal, but before that we ought to
> test all supported PHY's on the new driver.
>
> Aris was talking to me about this on OLS. Aris, what are the PHY's not supported
> by Panto's driver again? We should build a list of those and ask around for
> testers.
I think that with Andy Fleming's PHY abstraction layer, the best thing to be done
is change fec_8xx to use this abstraction layer and then look for
testers. what you think?
--
Aristeu
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Randy Dunlap @ 2005-07-27 21:34 UTC (permalink / raw)
To: Andy Fleming, Randy Dunlap, Francois Romieu, Netdev,
linuxppc-embedded
> On Jul 27, 2005, at 13:08, Randy Dunlap wrote:
>
> >
> >
> >> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
> >>
> >>
> >>
> >>>> +int mdiobus_register(struct mii_bus *bus)
> >>>> +{
> >>>> + int i;
> >>>> + int err = 0;
> >>>> +
> >>>> + spin_lock_init(&bus->mdio_lock);
> >>>> +
> >>>> + if (NULL == bus || NULL == bus->name ||
> >>>> + NULL == bus->read ||
> >>>> + NULL == bus->write)
> >>>>
> >>>>
> >>>
> >>> Be spartan:
> >>> if (!bus || !bus->name || !bus->read || !bus->write)
> >>>
> >>
> >>
> >> I think we have to agree to disagree here. I could be convinced, but
> >> I'm partial to using NULL explicitly.
> >>
> >
> > But there are 2 issues here (at least). One is to use NULL or
> > not. The other is using (constant == var) or (var == constant).
> >
> > It's not described in CodingStlye afaik, but most recent email
> > on the subject strongly prefers (var == constant) [in my
> > unscientific survey -- of bits in my head].
> >
> > So using the suggested style will fix both of these. :)
>
>
> Ok, here I won't agree to disagree with you. !foo as a check for
> NULL is a reasonable idea, but not my style. If that's the preferred
> style for the kernel, I will do that.
>
> But (var == constant) is a style that asks for errors. By putting
> the constant first in these checks, you never run the risk of leaving
> a bug like this:
>
> if (dev = NULL)
> ...
>
> This kind of error is quite frustrating to detect, and the eye will
> often miss it when scanning for errors. If you follow constant ==
> var, though, then the bug looks like this:
>
> if (NULL = dev)
>
> which is instantly caught by the compiler.
>
> Just my 32 cents
Yes, we know about that argument. :)
> >>>> + /* Otherwise, we allocate the device, and initialize the
> >>>> + * default values */
> >>>> + dev = kmalloc(sizeof(*dev), GFP_KERNEL);
> >>>> +
> >>>> + if (NULL == dev) {
> >>>> + errno = -ENOMEM;
> >>>> + return NULL;
> >>>> + }
> >>>> +
> >>>> + memset(dev, 0, sizeof(*dev));
> >>>>
> >>>>
> >>>
> >>> The kernel provides kcalloc.
> >>>
> >>
> >>
> >> I went looking for it, and found it in fs/cifs/misc.c. I'm hesitant
> >> to link to a function defined in the filesystem code just to save 1
> >> line of code
> >>
> >
> > It's more global than that.
>
>
> Should we move the function, then, to include/linux/slab.h? Or
> somewhere else?
It's there, like Francois said. Get use a current tree.
---
~Randy
^ permalink raw reply
* Re: [PATCH][1/3] ppc32: add 440ep support
From: Andrew Morton @ 2005-07-27 20:18 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <11224856623638@foobar.com>
Matt Porter <mporter@kernel.crashing.org> wrote:
>
> +static u64 dma_mask = 0xffffffffULL;
I'm sure you're totally uninterested in this, but the above will probably
generate warnings on (say) ppc64, where u64 is implemented as unsigned
long.
I usually chuck a simple `-1' in there and the compiler always gets it
right, regardless of signedness and size and architecture.
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Andrew Morton @ 2005-07-27 19:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0507271029480.12237@nylon.am.freescale.net>
Kumar Gala <galak@freescale.com> wrote:
>
> The following board ports are no longer maintained or have become
> obsolete:
>
> adir
> ash
> beech
> cedar
> ep405
> k2
> mcpn765
> menf1
> oak
> pcore
> rainier
> redwood
> sm850
> spd823ts
>
> We are there for removing support for them.
I'll merge all these into -mm for now, but will hold off sending any of
them upstream pending confirmation of which patches we really want to
proceed with.
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Francois Romieu @ 2005-07-27 19:56 UTC (permalink / raw)
To: Andy Fleming; +Cc: Netdev, Randy Dunlap, linuxppc-embedded
In-Reply-To: <EDA214E7-5655-4900-AF1A-FC736681DC74@freescale.com>
Andy Fleming <afleming@freescale.com> :
[kcalloc]
> Should we move the function, then, to include/linux/slab.h? Or
> somewhere else?
It is already in mm/slab.c
[rc = request_irq(...)]
It appears in drivers/net/*c. Jeff Garzik used to suggest something
similar but it does not matter as long as you do not need to return
an error status (KERN_ERR is probably a bit too strong then).
[initialization of struct phy_setting settings]
#define NITZ(d,t,s) { .speed = s, .duplex = d, .setting = t }
static struct phy_setting settings[] = {
NITZ(DUPLEX_FULL, SUPPORTED_10000baseT_Full, 10000),
NITZ(DUPLEX_FULL, SUPPORTED_1000baseT_Full, SPEED_1000),
NITZ(DUPLEX_HALF, SUPPORTED_1000baseT_Half, SPEED_1000),
NITZ(DUPLEX_FULL, SUPPORTED_100baseT_Full, SPEED_100),
NITZ(DUPLEX_HALF, SUPPORTED_100baseT_Half, SPEED_100),
NITZ(DUPLEX_FULL, SUPPORTED_10baseT_Full, SPEED_10),
NITZ(DUPLEX_HALF, SUPPORTED_10baseT_Half, SPEED_10),
};
#undef NITZ
--
Ueimor
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Andy Fleming @ 2005-07-27 18:46 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Netdev, linuxppc-embedded, Francois Romieu
In-Reply-To: <1122487708.20267@shark.he.net>
On Jul 27, 2005, at 13:08, Randy Dunlap wrote:
>
>
>> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
>>
>>
>>
>>>> +int mdiobus_register(struct mii_bus *bus)
>>>> +{
>>>> + int i;
>>>> + int err = 0;
>>>> +
>>>> + spin_lock_init(&bus->mdio_lock);
>>>> +
>>>> + if (NULL == bus || NULL == bus->name ||
>>>> + NULL == bus->read ||
>>>> + NULL == bus->write)
>>>>
>>>>
>>>
>>> Be spartan:
>>> if (!bus || !bus->name || !bus->read || !bus->write)
>>>
>>
>>
>> I think we have to agree to disagree here. I could be convinced, but
>> I'm partial to using NULL explicitly.
>>
>
> But there are 2 issues here (at least). One is to use NULL or
> not. The other is using (constant == var) or (var == constant).
>
> It's not described in CodingStlye afaik, but most recent email
> on the subject strongly prefers (var == constant) [in my
> unscientific survey -- of bits in my head].
>
> So using the suggested style will fix both of these. :)
Ok, here I won't agree to disagree with you. !foo as a check for
NULL is a reasonable idea, but not my style. If that's the preferred
style for the kernel, I will do that.
But (var == constant) is a style that asks for errors. By putting
the constant first in these checks, you never run the risk of leaving
a bug like this:
if (dev = NULL)
...
This kind of error is quite frustrating to detect, and the eye will
often miss it when scanning for errors. If you follow constant ==
var, though, then the bug looks like this:
if (NULL = dev)
which is instantly caught by the compiler.
Just my 32 cents
>
>
>>>> + /* Otherwise, we allocate the device, and initialize the
>>>> + * default values */
>>>> + dev = kmalloc(sizeof(*dev), GFP_KERNEL);
>>>> +
>>>> + if (NULL == dev) {
>>>> + errno = -ENOMEM;
>>>> + return NULL;
>>>> + }
>>>> +
>>>> + memset(dev, 0, sizeof(*dev));
>>>>
>>>>
>>>
>>> The kernel provides kcalloc.
>>>
>>
>>
>> I went looking for it, and found it in fs/cifs/misc.c. I'm hesitant
>> to link to a function defined in the filesystem code just to save 1
>> line of code
>>
>
> It's more global than that.
Should we move the function, then, to include/linux/slab.h? Or
somewhere else?
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Randy Dunlap @ 2005-07-27 18:08 UTC (permalink / raw)
To: Andy Fleming, Francois Romieu, Netdev, linuxppc-embedded
> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
>
>
> >> +int mdiobus_register(struct mii_bus *bus)
> >> +{
> >> + int i;
> >> + int err = 0;
> >> +
> >> + spin_lock_init(&bus->mdio_lock);
> >> +
> >> + if (NULL == bus || NULL == bus->name ||
> >> + NULL == bus->read ||
> >> + NULL == bus->write)
> >>
> >
> > Be spartan:
> > if (!bus || !bus->name || !bus->read || !bus->write)
>
>
> I think we have to agree to disagree here. I could be convinced, but
> I'm partial to using NULL explicitly.
But there are 2 issues here (at least). One is to use NULL or
not. The other is using (constant == var) or (var == constant).
It's not described in CodingStlye afaik, but most recent email
on the subject strongly prefers (var == constant) [in my
unscientific survey -- of bits in my head].
So using the suggested style will fix both of these. :)
> >> + /* Otherwise, we allocate the device, and initialize the
> >> + * default values */
> >> + dev = kmalloc(sizeof(*dev), GFP_KERNEL);
> >> +
> >> + if (NULL == dev) {
> >> + errno = -ENOMEM;
> >> + return NULL;
> >> + }
> >> +
> >> + memset(dev, 0, sizeof(*dev));
> >>
> >
> > The kernel provides kcalloc.
>
>
> I went looking for it, and found it in fs/cifs/misc.c. I'm hesitant
> to link to a function defined in the filesystem code just to save 1
> line of code
It's more global than that.
~Randy
^ permalink raw reply
* RE: MPC885 - USB HCI drivers.
From: Bastos Fernandez Alexandre @ 2005-07-27 18:08 UTC (permalink / raw)
To: 'Pantelis Antoniou', Bryan O'Donoghue; +Cc: linuxppc-embedded
Guys,
Finally, was the patch submitted to the list?
I have searched deeply both ozlabs and gmane, but I couldn't
find it ...
I have been disconnected from the list for several weeks (wedding holidays
:-) )
so I am a bit unplugged with all this stuff.
By now, I would apprece a lot this usb host driver for 82xx.
Thanks,
Alex BASTOS
> -----Original Message-----
> From: Pantelis Antoniou [SMTP:panto@intracom.gr]
> Sent: Tuesday, May 17, 2005 11:45 AM
> To: Bryan O'Donoghue
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC885 - USB HCI drivers.
>
> Bryan O'Donoghue wrote:
> > Pantelis Antoniou wrote:
> >
> >
> >>Well I have USB host drivers for both 8xx & 82xx working.
> >
> >
> > Speaking of which... would it not be a good idea, to get these comitted
> > to the 2.6 tree... at some stage ... at least to stop people
> > periodically posting to this list... saying "Dear all have spent 2
> > months, writing code for m8xx_hci drivers", when it's a needless
> > replication of effort ?
> >
>
> Well, they are too hideous for human eyes :)
>
> >
> >>However I use them connected to a specific peripheral
> >>so I don't know how well they fare when used as a PC
> >>style USB host controller.
> >
> >
> > Also, one easy way to find out, how well or badly said code performs, in
> > hetrogenous environments, is to... suck it and see.
> >
> > As I was attempting to intimate above, I'm sure there'd be a legion of
> > eager people to debug, modify and recode such drivers, if there lived in
> > an obvious place... in the 2.6 tree.
> >
> > Just my EUR0.02.
> >
>
> Also they're 2.4 only :)
>
> I'll try to clean them up and post them sometime this week.
>
> But I don't have time left to hack them for 2.6. I'll need
> vict^H^H^Holunteers to do it...
>
> Regards
>
> Pantelis
>
>
> > --
> >
> > Best,
> > Bryan
> >
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [RFC PATCH 1/4] PHY Abstraction Layer III (now with more splitiness)
From: Andy Fleming @ 2005-07-27 18:01 UTC (permalink / raw)
To: Francois Romieu; +Cc: Netdev, linuxppc-embedded
In-Reply-To: <20050725210646.GA17828@electric-eye.fr.zoreil.com>
On Jul 25, 2005, at 16:06, Francois Romieu wrote:
[snip]
>
>> +config DAVICOM_PHY
>> + bool "Drivers for Davicom PHYs"
>> + depends on PHYLIB
>> + ---help---
>> + Currently supports dm9161e and dm9131
>>
> [snip]
Yeah, I resisted splitting the patch up for this reason. Suffice it
to say, you have to apply patch #2 to not break everything.
Splitting the PHY driver code from the PHY layer is just for
"convenience"
>> +int mdiobus_register(struct mii_bus *bus)
>> +{
>> + int i;
>> + int err = 0;
>> +
>> + spin_lock_init(&bus->mdio_lock);
>> +
>> + if (NULL == bus || NULL == bus->name ||
>> + NULL == bus->read ||
>> + NULL == bus->write)
>>
>
> Be spartan:
> if (!bus || !bus->name || !bus->read || !bus->write)
I think we have to agree to disagree here. I could be convinced, but
I'm partial to using NULL explicitly.
>> +
>> +/* Convenience function to print out the current phy status
>> + */
>> +void phy_print_status(struct phy_device *phydev)
>> +{
>> + pr_info("%s: Link is %s", phydev->dev.bus_id,
>> + phydev->link ? "Up" : "Down");
>> + if (phydev->link)
>> + printk(" - %d/%s", phydev->speed,
>>
>
> Missing KERN_SOMETHING in the printk.
Actually, KERN_SOMETHING would muck up the line, and make it look
like this:
phy0:0: Link is Up<3> - 1000/Full
That's why it's like that.
>> +/* A mapping of all SUPPORTED settings to speed/duplex */
>> +static struct phy_setting settings[] = {
>> + { .speed = 10000, .duplex = DUPLEX_FULL,
>> + .setting = SUPPORTED_10000baseT_Full,
>> + },
>> + { .speed = SPEED_1000, .duplex = DUPLEX_FULL,
>> + .setting = SUPPORTED_1000baseT_Full,
>> + },
>> + { .speed = SPEED_1000, .duplex = DUPLEX_HALF,
>> + .setting = SUPPORTED_1000baseT_Half,
>> + },
>> + { .speed = SPEED_100, .duplex = DUPLEX_FULL,
>> + .setting = SUPPORTED_100baseT_Full,
>> + },
>> + { .speed = SPEED_100, .duplex = DUPLEX_HALF,
>> + .setting = SUPPORTED_100baseT_Half,
>> + },
>> + { .speed = SPEED_10, .duplex = DUPLEX_FULL,
>> + .setting = SUPPORTED_10baseT_Full,
>> + },
>> + { .speed = SPEED_10, .duplex = DUPLEX_HALF,
>> + .setting = SUPPORTED_10baseT_Half,
>> + },
>> +};
>>
>
> Would you veto some macro to initialise this array ?
Depends on the macro. :) I'm not keen on writing it, but I would
support one that:
a) works
b) Isn't uglier than the current solution. :)
>> +static inline int phy_find_setting(int speed, int duplex)
>> +{
>> + int idx = 0;
>> +
>> + while (idx < MAX_NUM_SETTINGS &&
>> + (settings[idx].speed != speed ||
>> + settings[idx].duplex != duplex))
>> + idx++;
>>
>
> "for" loop in disguise ?
Well.... I think it falls into the gray area. It's searching until
it finds something, which implies "while" to me. Really it's more of
a while...until. Of course, a for loop could be used, but I often
worry about using a for loop's iterator variable outside of the
loop. I will change to ARRAY_SIZE, though.
>
>
>> +
>> + return idx < MAX_NUM_SETTINGS ? idx : MAX_NUM_SETTINGS - 1;
>>
>
> Ok (dunno if "idx % MAX_NUM_SETTINGS" is more idiomatic or not).
That would be completely different. The current code makes sure
that, if no valid match was found, the last value in the array is
returned. Using % would result in the first value being returned. I
was defaulting to the lowest setting.
>> +int phy_start_interrupts(struct phy_device *phydev)
>> +{
>> + int err = 0;
>> +
>> + INIT_WORK(&phydev->phy_queue, phy_change, phydev);
>> +
>> + if (request_irq(phydev->irq, phy_interrupt,
>> + SA_SHIRQ,
>> + "phy_interrupt",
>> + phydev) < 0) {
>>
>
> Please, don't do that :o(
>
> err = request_irq(phydev->irq, phy_interrupt, SA_SHIRQ,
> "phy_interrupt", phydev);
> if (err < 0)
> ...
I did a cursory search, and didn't find any other drivers which use
this method. Which is the method preferred in Linux?
>> + printk(KERN_ERR "%s: Can't get IRQ %d (PHY)\n",
>> + phydev->bus->name,
>> + phydev->irq);
>> + phydev->irq = PHY_POLL;
>> + return 0;
>>
>
> The description of the function says "Returns 0 on success".
Failing to request the IRQ does not result in failure of the
function. It falls back to polling, instead.
However, it can fail if phy_enable_interrupts() fails, which would
happen if a hardware issue occurred.
>> + /* Otherwise, we allocate the device, and initialize the
>> + * default values */
>> + dev = kmalloc(sizeof(*dev), GFP_KERNEL);
>> +
>> + if (NULL == dev) {
>> + errno = -ENOMEM;
>> + return NULL;
>> + }
>> +
>> + memset(dev, 0, sizeof(*dev));
>>
>
> The kernel provides kcalloc.
I went looking for it, and found it in fs/cifs/misc.c. I'm hesitant
to link to a function defined in the filesystem code just to save 1
line of code
I agree with all the other suggestions, and will implement them.
^ 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