Skip to content

L
linux-davinci
Switch branch/tag
  1. 31 Oct, 2008 10 commits
    • Trent Piepho's avatar
      gianfar: Don't reset TBI<->SerDes link if it's already up · bdb59f94
      Trent Piepho authored 
      The link may be up already via the chip's reset strapping, or though action
of U-Boot, or from the last time the interface was brought up.  Resetting
the link causes it to go down for several seconds.  This can significantly
increase the time from power-on to DHCP completion and a device being
accessible to the network.
Signed-off-by: default avatarTrent Piepho <tpiepho@freescale.com>
Acked-by: default avatarAndy Fleming <afleming@freescale.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      bdb59f94
    • Trent Piepho's avatar
      gianfar: Fix race in TBI/SerDes configuration · c132419e
      Trent Piepho authored 
      The init_phy() function attaches to the PHY, then configures the
SerDes<->TBI link (in SGMII mode).  The TBI is on the MDIO bus with the PHY
(sort of) and is accessed via the gianfar's MDIO registers, using the
functions gfar_local_mdio_read/write(), which don't do any locking.

The previously attached PHY will start a work-queue on a timer, and
probably an irq handler as well, which will talk to the PHY and thus use
the MDIO bus.  This uses phy_read/write(), which have locking, but not
against the gfar_local_mdio versions.

The result is that PHY code will try to use the MDIO bus at the same time
as the SerDes setup code, corrupting the transfers.

Setting up the SerDes before attaching to the PHY will insure that there is
no race between the SerDes code and *our* PHY, but doesn't fix everything.
Typically the PHYs for all gianfar devices are on the same MDIO bus, which
is associated with the first gianfar device.  This means that the first
gianfar's SerDes code could corrupt the MDIO transfers for a different
gianfar's PHY.

The lock used by phy_read/write() is contained in the mii_bus structure,
which is pointed to by the PHY.  This is difficult to access from the
gianfar drivers, as there is no link between a gianfar device and the
mii_bus which shares the same MDIO registers.  As far as the device layer
and drivers are concerned they are two unrelated devices (which happen to
share registers).

Generally all gianfar devices' PHYs will be on the bus associated with the
first gianfar.  But this might not be the case, so simply locking the
gianfar's PHY's mii bus might not lock the mii bus that the SerDes setup
code is going to use.

We solve this by having the code that creates the gianfar platform device
look in the device tree for an mdio device that shares the gianfar's
registers.  If one is found the ID of its platform device is saved in the
gianfar's platform data.

A new function in the gianfar mii code, gfar_get_miibus(), can use the bus
ID to search through the platform devices for a gianfar_mdio device with
the right ID.  The platform device's driver data is the mii_bus structure,
which the SerDes setup code can use to lock the current bus.
Signed-off-by: default avatarTrent Piepho <tpiepho@freescale.com>
CC: Andy Fleming <afleming@freescale.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      c132419e
    • David Brownell's avatar
      at91_ether: request/free GPIO for PHY interrupt · 71527ef4
      David Brownell authored 
      When the at91_ether driver is using a GPIO for its PHY interrupt,
be sure to request (and later, if needed, free) that GPIO.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      71527ef4
    • Chunbo Luo's avatar
      amd8111e: fix dma_free_coherent context · e83603fd
      Chunbo Luo authored 
      Acoording commit aa24886e,
dma_free_coherent() need irqs enabled.

This patch fix following warning messages:

WARNING: at linux/arch/x86/kernel/pci-dma.c:376 dma_free_coherent+0xaa/0xb0()

Call Trace:
 [<ffffffff8023f80f>] warn_on_slowpath+0x5f/0x90
 [<ffffffff80496ffa>] ? __kfree_skb+0x3a/0xa0
 [<ffffffff802a4723>] ? discard_slab+0x23/0x40
 [<ffffffff8021274a>] dma_free_coherent+0xaa/0xb0
 [<ffffffff8043668f>] amd8111e_close+0x10f/0x1b0
 [<ffffffff8049f3ae>] dev_close+0x5e/0xb0
 [<ffffffff8049efa1>] dev_change_flags+0xa1/0x1e0
 [<ffffffff806b2171>] ic_close_devs+0x36/0x4e
 [<ffffffff806b29ee>] ip_auto_config+0x581/0x10f3
 [<ffffffff803a6e19>] ? kobject_add+0x69/0x90
 [<ffffffff803a698a>] ? kobject_get+0x1a/0x30
 [<ffffffff803a785b>] ? kobject_uevent+0xb/0x10
 [<ffffffff803a6c62>] ? kset_register+0x52/0x60
 [<ffffffff803a6f9b>] ? kset_create_and_add+0x6b/0xa0
 [<ffffffff804e2e74>] ? tcp_ca_find+0x24/0x50
 [<ffffffff806b246d>] ? ip_auto_config+0x0/0x10f3
 [<ffffffff8020903c>] _stext+0x3c/0x150
 [<ffffffff802772d3>] ? register_irq_proc+0xd3/0xf0
 [<ffffffff802f0000>] ? mb_cache_create+0x80/0x1f0
 [<ffffffff80688693>] kernel_init+0x141/0x1b8
 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8
 [<ffffffff8020d609>] child_rip+0xa/0x11
 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8
 [<ffffffff80688552>] ? kernel_init+0x0/0x1b8
 [<ffffffff8020d5ff>] ? child_rip+0x0/0x11
Signed-off-by: default avatarChunbo Luo <chunbo.luo@windriver.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      e83603fd
    • Jay Cliburn's avatar
      atl1: fix vlan tag regression · dc5596d9
      Jay Cliburn authored 
      Commit 401c0aab introduced a regression
in the atl1 driver by storing the VLAN tag in the wrong TX descriptor
field.

This patch causes the VLAN tag to be stored in its proper location.
Tested-by: default avatarRamon Casellas <ramon.casellas@cttc.es>
Signed-off-by: default avatarJay Cliburn <jacliburn@bellsouth.net>
Cc: stable@kernel.org
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      dc5596d9
    • Mike Frysinger's avatar
      SMC91x: delete unused local variable "lp" · 51ac3bef
      Mike Frysinger authored 
      Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      51ac3bef
    • Brice Goglin's avatar
      myri10ge: fix stop/go mmio ordering · 6824a105
      Brice Goglin authored 
      Use mmiowb() to ensure "stop" and "go" commands are sent in order on ia64.
Signed-off-by: default avatarBrice Goglin <brice@myri.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      6824a105
    • Andy Gospodarek's avatar
      bonding: fix panic when taking bond interface down before removing module · ce39a800
      Andy Gospodarek authored 
      A panic was discovered with bonding when using mode 5 or 6 and trying to
remove the slaves from the bond after the interface was taken down.
When calling 'ifconfig bond0 down' the following happens:

    bond_close()
        bond_alb_deinitialize()
            tlb_deinitialize()
		kfree(bond_info->tx_hashtbl)
                bond_info->tx_hashtbl = NULL

Unfortunately if there are still slaves in the bond, when removing the
module the following happens:

    bonding_exit()
        bond_free_all()
            bond_release_all()
                bond_alb_deinit_slave()
                    tlb_clear_slave()
                        tx_hash_table = BOND_ALB_INFO(bond).tx_hashtbl
			u32 next_index = tx_hash_table[index].next

As you might guess we panic when trying to access a few entries into the
table that no longer exists.

I experimented with several options (like moving the calls to
tlb_deinitialize somewhere else), but it really makes the most sense to
be part of the bond_close routine.  It also didn't seem logical move
tlb_clear_slave around too much, so the simplest option seems to add a
check in tlb_clear_slave to make sure we haven't already wiped the
tx_hashtbl away before searching for all the non-existent hash-table
entries that used to point to the slave as the output interface.
Signed-off-by: default avatarAndy Gospodarek <andy@greyhouse.net>
Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      ce39a800
    • Jay Vosburgh's avatar
      bonding: Clean up resource leaks · a434e43f
      Jay Vosburgh authored 
      This patch reworks the resource free logic performed at the time
a bonding device is released.  This (a) closes two resource leaks, one
for workqueues and one for multicast lists, and (b) improves commonality
of code between the "destroy one" and "destroy all" paths by performing
final free activity via destructor instead of explicitly (and differently)
in each path.

"Sean E. Millichamp" <sean@bruenor.org> reported the workqueue
leak, and included a different patch.
Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      a434e43f
    • Jay Vosburgh's avatar
      bonding: fix miimon failure counter · fba4acda
      Jay Vosburgh authored 
      During the rework of the mii monitor for:

  commit f0c76d61
  Author: Jay Vosburgh <fubar@us.ibm.com>
  Date:   Wed Jul 2 18:21:58 2008 -0700

    bonding: refactor mii monitor

I left out the increment of the link failure counter.  This
patch corrects that omission.
Signed-off-by: default avatarJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      fba4acda
  3. 28 Oct, 2008 3 commits
  5. 27 Oct, 2008 23 commits
  7. 26 Oct, 2008 4 commits