Mike Frysinger wrote:
> On Tuesday, March 01, 2011 03:34:38 Michal Simek wrote:
>> Mike Frysinger wrote:
>>> On Tuesday, March 01, 2011 03:00:47 Michal Simek wrote:
>>>> If both functions should return 0 then any code should check it and all
>>>> others drivers should be fixed.
>>> i agree, but that doesnt mean new code should knowingly be left broken
>> I agree that make no sense do not fix it right now.
>
> err, your new driver should return the correct values. what higher levels do
> or do not check does not matter, and whether other drivers do it correctly
> does not matter.
Comment below.
>
>>>> ep93xx_eth.c returns also 1.
>>>> Anyway if is number of registered devices, "1" should means one
>>>> registered device. If zero means one registered device then please
>>>> point me to that documentation.
>>> the change hasnt been ported to all drivers yet. but new drivers should
>>> be doing it as i described.
>> How does it look like phy lib u-boot support?
>
> i dont know what you mean ... how is phylib relevant to this ? or are you
> just asking in general ?
Ben wanted to create general phy lib support and remove all phy specific things
from net drivers.
I hope you see that connection because there is also phy part.
If phy lib support is in progress (which probably not) then I would change the
driver to support it.
>
>>> also, you should change the "hang()" to "return 0" in the init func.
>> Are you sure return 0 which should mean success. Anything different from 0
>> seems to me relevant.
>
> as i said, the initialize function is not returning "success" or "failure".
> it is returning "# of devices registered". if you cannot register any, you
> should return 0. having the boot process fail because of network issues
> doesnt make much sense when u-boot can do quite a lot without the network.
> including updating itself via other means.
Interesting.
1. you talked about hang() in initialize function(not dev->init) and for me
xilinx_axiemac_initialize
Initialize function is called from board_eth_init which is called from
eth_initialize(eth.c)
There is this part of code
if (board_eth_init != __def_eth_init) {
if (board_eth_init(bis) < 0)
printf("Board Net Initialization Failed\n");
If initialization failed the return value is < 0.
That's why hang() should be changed to return -1 and doesn't matter how many
device there are.
If you write:
>>> also, you should change the "hang()" to "return 0" in the init func.
(hang is only in xilinx_axiemac_initialize) and should be changed which I agree.
If you propose any change which I should do, I expect that if you are focus on
blackfin that you
have done that changes in all blackfin eth drivers. For example in bfin_mac.c
where hang is also used.
>
>> I maintain emaclite driver and none tell me this that's why the process is
>> so slow. I believe if you release that documentation, which you are
>> talking about, then others will clean/test their drivers.
>
> the behavior i describe isnt a decision i made. it was made by the previous
> net maintainer and agreed upon by others in the discussion.
Ok. If that decision was made than I expect that should be written somewhere in
doc.
I know it is boring to write any documentation but I expect that if any
decision was made then is
common that general code will be changed. The changes can be from top to down.
If general eth code
checks return values then driver which returns wrong return codes won't work.
I am not arguing that my driver shouldn't return correct values!!! That's not
my point.
If you start arguing that my driver has some faults, I am open to fix it and I
really appreciate
your comments.
I think it is good time to summarize all that changes we discuss: (Please
correct it if you think
that it is wrong). (Our communication is getting messy a little bit)
1. hang() -> return -1
2. driver initialize function (setup dev functions, driver name, priv, etc)
return -1 - if initialize failed
return 0 - on success
3. dev->init
return -1 - if init failed
return 0 - on success
(here you are saying should be return # of devices)
4. dev->recv
return -1 - failed
return 0 - packet not received
return >0 - success - packet lenght
5. dev->send
return -1 - failed
return 0 - success
6. dev->write_hwaddr
return -1 - failed
return 0 - success
Thanks,
Michal
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
