linux-toradex.git/drivers/net/ethernet, branch v3.9.4

3c59x: fix PCI resource management

2013-05-19T18:38:37+00:00

[ Upstream commit 4b264a1676e70dc656ba53a8cac690f2d4b65f4e ]

The driver wrongly claimed I/O ports at an address returned by pci_iomap() --
even if it was passed an MMIO address.  Fix this by claiming/releasing all PCI
resources in the PCI driver's probe()/remove() methods instead and get rid of
'must_free_region' flag weirdness (why would Cardbus claim anything for us?).

Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

3c59x: fix freeing nonexistent resource on driver unload

2013-05-19T18:38:37+00:00

[ Upstream commit c81400be716aa4c76f6ebf339ba94358dbbf6da6 ]

When unloading the driver that drives an EISA board, a message similar to the
following one is displayed:

Trying to free nonexistent resource <0000000000013000-000000000001301f>

Then an user is unable to reload the driver because the resource it requested in
the previous load hasn't been freed. This happens most probably due to a typo in
vortex_eisa_remove() which calls release_region() with 'dev->base_addr'  instead
of 'edev->base_addr'...

Reported-by: Matthew Whitehead 
Tested-by: Matthew Whitehead 
Signed-off-by: Sergei Shtylyov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

3c509.c: call SET_NETDEV_DEV for all device types (ISA/ISAPnP/EISA)

2013-05-19T18:38:34+00:00

[ Upstream commit 3b54912f9cd167641b91d4a697bd742f70e534fe ]

The venerable 3c509 driver only sets its device parent in one case, the ISAPnP one.
It does this with the SET_NETDEV_DEV function. It should register with the device
hierarchy in two additional cases: standard (non-PnP) ISA and EISA.

- Currently they appear here:
/sys/devices/virtual/net/eth0 (standard ISA)
/sys/devices/virtual/net/eth1 (EISA)

- Rather, they should instead be here:
/sys/devices/isa/3c509.0/net/eth0 (standard ISA)
/sys/devices/pci0000:00/0000:00:07.0/00:04/net/eth1 (EISA)

Tested on ISA and EISA boards.

Signed-off-by: Matthew Whitehead 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sfc: Fix naming of MTD partitions for FPGA bitfiles

2013-05-19T18:38:33+00:00

[ Upstream commit 89cc80a44b7c320e08599cb86f6aef0ead8986a1 ]

efx_mcdi_get_board_cfg() uses a buffer for the firmware response that
is only large enough to hold subtypes for the originally defined set
of NVRAM partitions.  Longer responses are truncated, and we may read
off the end of the buffer when copying out subtypes for additional
partitions.  In particular, this can result in the MTD partition for
an FPGA bitfile being named e.g. 'eth5 sfc_fpga:00' when it should be
'eth5 sfc_fpga:01'.  This means the firmware update tool (sfupdate)
can't tell which bitfile should be written to the partition.

Correct the response buffer size.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tile: support new Tilera hypervisor

2013-05-19T18:38:28+00:00

commit c539914dcd9a68c63305e055b14115a6a19578a8 upstream.

The Tilera hypervisor shipped in releases up through MDE 4.1 launches
the client operating system (i.e. Linux) at privilege level 1 (PL1).
Starting with MDE 4.2, as part of the work to enable KVM, the
Tilera hypervisor launches Linux at PL2 instead.

This commit makes the KERNEL_PL option default to 2 for tilegx, while
still saying at 1 for tilepro, which doesn't have an updated hypervisor.
It also explains how and when you might want to choose another value.
In addition, we change a small buglet in the on-chip Ethernet driver,
where we were failing to use the KERNEL_PL constant in an API call.

To make the transition cleaner, this change also provides the updated
hv_init() API for the new hypervisor that supports announcing Linux's
compiled-in PL, so the hypervisor can generate a suitable error in the
case of a mismatched hypervisor and Linux binary.

Signed-off-by: Chris Metcalf 
Signed-off-by: Greg Kroah-Hartman

r8169: fix 8168evl frame padding.

2013-05-11T14:18:23+00:00

commit e5195c1f31f399289347e043d6abf3ffa80f0005 upstream.

Signed-off-by: Stefan Bader 
Acked-by: Francois Romieu 
Cc: hayeswang 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net/eth/ibmveth: Fixup retrieval of MAC address

2013-05-11T14:18:20+00:00

commit 13f85203e1060da83d9ec1c1c5a63343eaab8de4 upstream.

Some ancient pHyp versions used to create a 8 bytes local-mac-address
property in the device-tree instead of a 6 bytes one for veth.

The Linux driver code to deal with that is an insane hack which also
happens to break with some choices of MAC addresses in qemu by testing
for a bit in the address rather than just looking at the size of the
property.

Sanitize this by doing the latter instead.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

e1000e: fix numeric overflow in phc settime method

2013-05-08T03:33:14+00:00

commit 73e3dd6b45c4c870fc2641eb04c24e3f12dab1e0 upstream.

The PTP Hardware Clock settime function in the e1000e driver
computes nanoseconds from a struct timespec. The code converts the
seconds field .tv_sec by multiplying it with NSEC_PER_SEC. However,
both operands are of type long, resulting in an unintended overflow.
The patch fixes the issue by using the helper function from time.h.

Signed-off-by: Richard Cochran 
Tested-by: Aaron Brown 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

ixgbe: fix EICR write in ixgbe_msix_other

2013-05-08T03:33:14+00:00

commit d87d830720a1446403ed38bfc2da268be0d356d1 upstream.

Previously, the ixgbe_msix_other was writing the full 32bits of the set
interrupts, instead of only the ones which the ixgbe_msix_other is
handling. This resulted in a loss of performance when the X540's PPS feature is
enabled due to sometimes clearing queue interrupts which resulted in the driver
not getting the interrupt for cleaning the q_vector rings often enough. The fix
is to simply mask the lower 16bits off so that this handler does not write them
in the EICR, which causes them to remain high and be properly handled by the
clean_rings interrupt routine as normal.

Signed-off-by: Jacob Keller 
Tested-by: Phil Schmitt 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

gianfar: do not advertise any alarm capability.

2013-05-08T03:33:07+00:00

commit cd4baaaa04b4aaa3b0ec4d13a6f3d203b92eadbd upstream.

An early draft of the PHC patch series included an alarm in the
gianfar driver. During the review process, the alarm code was dropped,
but the capability removal was overlooked. This patch fixes the issue
by advertising zero alarms.

This patch should be applied to every 3.x stable kernel.

Signed-off-by: Richard Cochran 
Reported-by: Chris LaRocque 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman