artup
the device can no longer receive packets because the hardware filter is
still programmed to the old MAC.
This patch moves the writing of the hardware address from eth_initialize
(board startup) to eth_init (just before actually using the network).
Signed-off-by: Ingo van Lil
---
net/eth.c | 13
Currently the ethernet MAC address is read from the 'ethaddr'
environment variable into the dev->enetaddr field each time the network
hardware is initialized, but it is written to the actual hardware only
once at board startup. When 'ethaddr' is set or changed after startup
the device can no longer
On 11/22/2009 11:25 PM, Wolfgang Denk wrote:
> Could you please rebase it against the "next" branch and resubmit it?
There you are. This time I compile-tested it (MAKEALL) for ppc and arm.
Some boards did not build (several PPC builds died with "Error:
Unrecognized opcode: `mullhw'", several AR
() function which takes care of
resetting the watchdog before calling an architecture-specific
__udelay().
Signed-off-by: Ingo van Lil
---
board/armltd/integrator/timer.c |2 +-
board/freescale/mpc8313erdb/sdram.c |2 +-
cpu/arm1136/mx31/timer.c|2 +-
cpu/arm1136/omap24xx
() function which takes care of
resetting the watchdog before calling an architecture-specific
__udelay().
Signed-off-by: Ingo van Lil
---
board/armltd/integrator/timer.c |2 +-
cpu/arm1136/mx31/timer.c|2 +-
cpu/arm1136/omap24xx/timer.c|2 +-
cpu/arm1176/s3c64xx/timer.c
On 10/04/2009 01:29 AM, Wolfgang Denk wrote:
> No, not an exception, but the reference implementation. I cannot help
> it that most other architectures / SoCs don;t care much.
Well, if such an uncommon side-effect is expected of a function with a
well-known name it should at least be prominently
On 10/02/2009 01:06 PM, Stefan Roese wrote:
>> The CFI driver does not reset the device's watchdog, so long-running
>> flash operations will cause the watchdog timer to expire. A comment in
>> flash_status_check() suggests that udelay() is expected to reset the
>> watchdog, but I can't find any ar
The CFI driver does not reset the device's watchdog, so long-running
flash operations will cause the watchdog timer to expire. A comment in
flash_status_check() suggests that udelay() is expected to reset the
watchdog, but I can't find any architecture where it does.
Signed-off-by: In
8 matches
Mail list logo
