01 Jun, 2017

1 commit

  • These support the flat device tree. We want to use the dev_read_..()
    prefix for functions that support both flat tree and live tree. So rename
    the existing functions to avoid confusion.

    In the end we will have:

    1. dev_read_addr...() - works on devices, supports flat/live tree
    2. devfdt_get_addr...() - current functions, flat tree only
    3. of_get_address() etc. - new functions, live tree only

    All drivers will be written to use 1. That function will in turn call
    either 2 or 3 depending on whether the flat or live tree is in use.

    Note this involves changing some dead code - the imx_lpi2c.c file.

    Signed-off-by: Simon Glass

    Simon Glass
     

08 Feb, 2017

1 commit

  • At present devices use a simple integer offset to record the device tree
    node associated with the device. In preparation for supporting a live
    device tree, which uses a node pointer instead, refactor existing code to
    access this field through an inline function.

    Signed-off-by: Simon Glass

    Simon Glass
     

08 Jan, 2016

1 commit

  • Introduced in 45b4773 (net/arp: account for ARP delay, avoid duplicate packets on timeout)

    Check the arp timeout and adjust the timeout start time before the call
    to eth_recv() so that the sandbox driver has the opportunity to adjust
    the sandbox timer after the new start time has been recorded.

    Also, change the adjustment amount by 11 seconds instead of exactly the
    10 seconds that the ping timout is expecting since the timeout check is
    looking for the time elapsed to be greater than but not equal to the
    specified delay.

    Signed-off-by: Joe Hershberger
    Reviewed-by: Stefan Brüns
    Acked-by: Simon Glass

    Joe Hershberger
     

22 Jul, 2015

1 commit

  • Some devices can take a long time to work out whether they have a new packet
    or now. For example the ASIX USB Ethernet dongle can take 5 seconds to do
    this, since it waits until it gets a new packet on the wire before allowing
    the USB bulk read packet to be submitted.

    At present with driver mode the Ethernet receive code reads 32 packets. This
    can take a very long time if we must wait for all 32 packets. The old code
    (before driver model) worked by reading a single set of packets from the USB
    device, then processing all the packets with in. It would be nice to use
    the same behaviour with driver model.

    Add a flag to the receive method which indicates that the driver should try
    to find a packet if available, by consulting the hardware. When the flag is
    not set, it should just return any packet data it has already received. If
    there is none, it should return -EAGAIN so that the loop will terminate.

    Signed-off-by: Simon Glass

    Simon Glass
     

06 May, 2015

1 commit


19 Apr, 2015

4 commits