25 Jan, 2010

1 commit

  • This patch fixes power LED blinking and power-off on DNS-323 rev. B1.

    GPIO pin 3 has to be set to 1 to stop power LED blinking and to allow the LED to be controlled via leds-gpio. This pin has to be also set to 1 for power-off to work.
    To power-off the rev. B1 machine, pin 8 has to be set to 1 and then set to 0 to do actual power-off.

    Tested on my DNS-323 rev. B1

    Signed-off-by: Erik Benada
    Signed-off-by: Nicolas Pitre

    Erik Benada
     

14 Jan, 2010

1 commit


04 Dec, 2009

1 commit

  • That is "success", "unknown", "through", "performance", "[re|un]mapping"
    , "access", "default", "reasonable", "[con]currently", "temperature"
    , "channel", "[un]used", "application", "example","hierarchy", "therefore"
    , "[over|under]flow", "contiguous", "threshold", "enough" and others.

    Signed-off-by: André Goddard Rosa
    Signed-off-by: Jiri Kosina

    André Goddard Rosa
     

09 Sep, 2009

1 commit


11 Aug, 2009

2 commits


15 Jun, 2009

2 commits


09 Jun, 2009

5 commits


04 Jun, 2009

1 commit


23 May, 2009

1 commit


22 May, 2009

1 commit


24 Apr, 2009

1 commit

  • Symbols like SOFT_RESET are way too generic to be exported at large.
    To avoid this, let's move the mbus bridge register defines into a
    separate file and include it where needed. This affects mach-kirkwood,
    mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all
    share code in plat-orion which relies on those defines.

    Some other defines have been moved to narrower scopes, or simply deleted
    when they had no user.

    This fixes compilation problem with mpt2sas on the above listed
    platforms.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     

07 Apr, 2009

2 commits


29 Mar, 2009

1 commit


27 Mar, 2009

2 commits

  • * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6: (1750 commits)
    ixgbe: Allow Priority Flow Control settings to survive a device reset
    net: core: remove unneeded include in net/core/utils.c.
    e1000e: update version number
    e1000e: fix close interrupt race
    e1000e: fix loss of multicast packets
    e1000e: commonize tx cleanup routine to match e1000 & igb
    netfilter: fix nf_logger name in ebt_ulog.
    netfilter: fix warning in ebt_ulog init function.
    netfilter: fix warning about invalid const usage
    e1000: fix close race with interrupt
    e1000: cleanup clean_tx_irq routine so that it completely cleans ring
    e1000: fix tx hang detect logic and address dma mapping issues
    bridge: bad error handling when adding invalid ether address
    bonding: select current active slave when enslaving device for mode tlb and alb
    gianfar: reallocate skb when headroom is not enough for fcb
    Bump release date to 25Mar2009 and version to 0.22
    r6040: Fix second PHY address
    qeth: fix wait_event_timeout handling
    qeth: check for completion of a running recovery
    qeth: unregister MAC addresses during recovery.
    ...

    Manually fixed up conflicts in:
    drivers/infiniband/hw/cxgb3/cxio_hal.h
    drivers/infiniband/hw/nes/nes_nic.c

    Linus Torvalds
     
  • Conflicts:
    drivers/net/wimax/i2400m/usb-notif.c

    David S. Miller
     

25 Mar, 2009

2 commits


24 Mar, 2009

1 commit


22 Mar, 2009

1 commit

  • The initial version of the DSA driver only supported a single switch
    chip per network interface, while DSA-capable switch chips can be
    interconnected to form a tree of switch chips. This patch adds support
    for multiple switch chips on a network interface.

    An example topology for a 16-port device with an embedded CPU is as
    follows:

    +-----+ +--------+ +--------+
    | |eth0 10| switch |9 10| switch |
    | CPU +----------+ +-------+ |
    | | | chip 0 | | chip 1 |
    +-----+ +---++---+ +---++---+
    || ||
    || ||
    ||1000baseT ||1000baseT
    ||ports 1-8 ||ports 9-16

    This requires a couple of interdependent changes in the DSA layer:

    - The dsa platform driver data needs to be extended: there is still
    only one netdevice per DSA driver instance (eth0 in the example
    above), but each of the switch chips in the tree needs its own
    mii_bus device pointer, MII management bus address, and port name
    array. (include/net/dsa.h) The existing in-tree dsa users need
    some small changes to deal with this. (arch/arm)

    - The DSA and Ethertype DSA tagging modules need to be extended to
    use the DSA device ID field on receive and demultiplex the packet
    accordingly, and fill in the DSA device ID field on transmit
    according to which switch chip the packet is heading to.
    (net/dsa/tag_{dsa,edsa}.c)

    - The concept of "CPU port", which is the switch chip port that the
    CPU is connected to (port 10 on switch chip 0 in the example), needs
    to be extended with the concept of "upstream port", which is the
    port on the switch chip that will bring us one hop closer to the CPU
    (port 10 for both switch chips in the example above).

    - The dsa platform data needs to specify which ports on which switch
    chips are links to other switch chips, so that we can enable DSA
    tagging mode on them. (For inter-switch links, we always use
    non-EtherType DSA tagging, since it has lower overhead. The CPU
    link uses dsa or edsa tagging depending on what the 'root' switch
    chip supports.) This is done by specifying "dsa" for the given
    port in the port array.

    - The dsa platform data needs to be extended with information on via
    which port to reach any given switch chip from any given switch chip.
    This info is specified via the per-switch chip data struct ->rtable[]
    array, which gives the nexthop ports for each of the other switches
    in the tree.

    For the example topology above, the dsa platform data would look
    something like this:

    static struct dsa_chip_data sw[2] = {
    {
    .mii_bus = &foo,
    .sw_addr = 1,
    .port_names[0] = "p1",
    .port_names[1] = "p2",
    .port_names[2] = "p3",
    .port_names[3] = "p4",
    .port_names[4] = "p5",
    .port_names[5] = "p6",
    .port_names[6] = "p7",
    .port_names[7] = "p8",
    .port_names[9] = "dsa",
    .port_names[10] = "cpu",
    .rtable = (s8 []){ -1, 9, },
    }, {
    .mii_bus = &foo,
    .sw_addr = 2,
    .port_names[0] = "p9",
    .port_names[1] = "p10",
    .port_names[2] = "p11",
    .port_names[3] = "p12",
    .port_names[4] = "p13",
    .port_names[5] = "p14",
    .port_names[6] = "p15",
    .port_names[7] = "p16",
    .port_names[10] = "dsa",
    .rtable = (s8 []){ 10, -1, },
    },
    },

    static struct dsa_platform_data pd = {
    .netdev = &foo,
    .nr_switches = 2,
    .sw = sw,
    };

    Signed-off-by: Lennert Buytenhek
    Tested-by: Gary Thomas
    Signed-off-by: David S. Miller

    Lennert Buytenhek
     

20 Mar, 2009

2 commits


16 Mar, 2009

1 commit


11 Mar, 2009

1 commit


05 Mar, 2009

1 commit


04 Mar, 2009

1 commit

  • This data should be passed to the xor driver in order to initialize
    the address decoding windows of the xor unit. without this patch, the
    self tests of the xor will fail unless the address decoding windows were
    initialized by the boot loader.

    Signed-off-by: Saeed Bishara
    Signed-off-by: Nicolas Pitre

    Saeed Bishara
     

25 Feb, 2009

3 commits


20 Feb, 2009

1 commit


18 Feb, 2009

1 commit

  • The GPIO interrupts can be configured as either level triggered or edge
    triggered, with a default of level triggered. When an edge triggered
    interrupt is requested, the gpio_irq_set_type method is called which
    currently switches the given IRQ descriptor between two struct irq_chip
    instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
    happens via __setup_irq() which also calls irq_chip_set_defaults() to
    assign default methods to uninitialized ones. The problem is that
    irq_chip_set_defaults() is called before the irq_chip reference is
    switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
    case) with uninitialized methods such as chip->startup() causing a kernel
    oops.

    Many solutions are possible, such as making irq_chip_set_defaults() global
    and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
    before irq_chip_set_defaults() in __setup_irq(). But those require
    modifications to the generic IRQ code which might have adverse effect on
    other architectures, and that would still be a fragile arrangement.
    Manually copying the missing methods from within gpio_irq_set_type()
    would be really ugly and it would break again the day new methods with
    automatic defaults are added.

    A better solution is to have a single irq_chip instance which can deal
    with both edge and level triggered interrupts. It is also a good idea
    to switch the IRQ handler instead, as the edge IRQ handler allows for
    one edge IRQ event to be queued as the IRQ is actually masked only when
    that second IRQ is received, at which point the hardware can queue an
    additional IRQ event, making edge triggered interrupts a bit more
    reliable.

    Tested-by: Martin Michlmayr

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Russell King

    Nicolas Pitre
     

07 Feb, 2009

3 commits