linux-stable.git/drivers/net, branch v3.18.52

e1000e: fix call to do_div() to use u64 arg

2017-05-08T05:44:12+00:00

commit 30544af5483755b11bb5924736e9e0b45ef0644a upstream.

We were using s64 for lat_ns (latency nano-second value) since in
our calculations a negative value could be a resultant.  For negative
values, we then assign lat_ns to be zero, so the value passed to
do_div() was never negative, but do_div() expects the argument type
to be u64, so do a cast to resolve a compile warning seen on
PowerPC.

CC: Yanjiang Jin 
CC: Yanir Lubetkin 
Reported-by: Yanjiang Jin 
Signed-off-by: Jeff Kirsher 
Tested-by: Aaron Brown 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

cpumask_set_cpu_local_first => cpumask_local_spread, lament

2017-05-08T05:44:12+00:00

commit f36963c9d3f6f415732710da3acdd8608a9fa0e5 upstream.

da91309e0a7e (cpumask: Utility function to set n'th cpu...) created a
genuinely weird function.  I never saw it before, it went through DaveM.
(He only does this to make us other maintainers feel better about our own
mistakes.)

cpumask_set_cpu_local_first's purpose is say "I need to spread things
across N online cpus, choose the ones on this numa node first"; you call
it in a loop.

It can fail.  One of the two callers ignores this, the other aborts and
fails the device open.

It can fail in two ways: allocating the off-stack cpumask, or through a
convoluted codepath which AFAICT can only occur if cpu_online_mask
changes.  Which shouldn't happen, because if cpu_online_mask can change
while you call this, it could return a now-offline cpu anyway.

It contains a nonsensical test "!cpumask_of_node(numa_node)".  This was
drawn to my attention by Geert, who said this causes a warning on Sparc.
It sets a single bit in a cpumask instead of returning a cpu number,
because that's what the callers want.

It could be made more efficient by passing the previous cpu rather than
an index, but that would be more invasive to the callers.

[backporting for 3.18: only two callers exist, otherwise no change.
 The same warning shows up for "!cpumask_of_node()", and I thought
 about just addressing the warning, but using the whole fix seemed
 better in the end as one of the two callers also lacks the error
 handling]

Fixes: da91309e0a7e8966d916a74cce42ed170fde06bf
Signed-off-by: Rusty Russell  (then rebased)
Tested-by: Amir Vadai 
Acked-by: Amir Vadai 
Acked-by: David S. Miller 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

net: tg3: avoid uninitialized variable warning

2017-05-08T05:44:10+00:00

commit e434e04110704eb91acfecbd0fb8ca8e2da9c29b upstream.

The tg3_set_eeprom() function correctly initializes the 'start' variable,
but gcc generates a false warning:

drivers/net/ethernet/broadcom/tg3.c: In function 'tg3_set_eeprom':
drivers/net/ethernet/broadcom/tg3.c:12057:4: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]

I have not come up with a way to restructure the code in a way that
avoids the warning without making it less readable, so this adds an
initialization for the declaration to shut up that warning.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

mlx5: avoid build warnings on 32-bit

2017-05-08T05:44:09+00:00

commit 065bd8c28ba37d04c9a5b732173c1508954b1f58 upstream.

The mlx5 driver passes a string pointer in through a 'u64' variable,
which on 32-bit machines causes a build warning:

drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field':
drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:303:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

The code is in fact safe, so we can shut up the warning by adding
extra type casts.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: phy: handle state correctly in phy_stop_machine

2017-05-08T05:44:08+00:00

[ Upstream commit 49d52e8108a21749dc2114b924c907db43358984 ]

If the PHY is halted on stop, then do not set the state to PHY_UP.  This
ensures the phy will be restarted later in phy_start when the machine is
started again.

Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
Signed-off-by: Nathan Sullivan 
Signed-off-by: Brad Mouring 
Acked-by: Xander Huff 
Acked-by: Kyle Roeschley 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: tulip: turn compile-time warning into dev_warn()

2017-04-30T03:49:16+00:00

commit de92718883ddbcd11b738d36ffcf57617b97fa12 upstream.

The tulip driver causes annoying build-time warnings for allmodconfig
builds for all recent architectures:

dec/tulip/winbond-840.c:910:2: warning: #warning Processor architecture undefined
dec/tulip/tulip_core.c:101:2: warning: #warning Processor architecture undefined!

This is the last remaining warning for arm64, and I'd like to get rid of
it. We don't really know the cache line size, architecturally it would
be at least 16 bytes, but all implementations I found have 64 or 128
bytes. Configuring tulip for 32-byte lines as we do on ARM32 seems to
be the safe but slow default, and nobody who cares about performance these
days would use a tulip chip anyway, so we can just use that.

To save the next person the job of trying to find out what this is for
and picking a default for their architecture just to kill off the warning,
I'm now removing the preprocessor #warning and turning it into a pr_warn
or dev_warn that prints the equivalent information when the driver gets
loaded.

Signed-off-by: Arnd Bergmann 
Acked-by: Grant Grundler 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

hostap: avoid uninitialized variable use in hfa384x_get_rid

2017-04-30T03:49:16+00:00

commit 48dc5fb3ba53b20418de8514700f63d88c5de3a3 upstream.

The driver reads a value from hfa384x_from_bap(), which may fail,
and then assigns the value to a local variable. gcc detects that
in in the failure case, the 'rlen' variable now contains
uninitialized data:

In file included from ../drivers/net/wireless/intersil/hostap/hostap_pci.c:220:0:
drivers/net/wireless/intersil/hostap/hostap_hw.c: In function 'hfa384x_get_rid':
drivers/net/wireless/intersil/hostap/hostap_hw.c:842:5: warning: 'rec' may be used uninitialized in this function [-Wmaybe-uninitialized]
  if (le16_to_cpu(rec.len) == 0) {

This restructures the function as suggested by Russell King, to
make it more readable and get more reliable error handling, by
handling each failure mode using a goto.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

net: vxge: avoid unused function warnings

2017-04-30T03:49:16+00:00

commit 57e7c8cef224af166b8ec932b5e383641418c005 upstream.

When CONFIG_PCI_MSI is disabled, we get warnings about unused functions
in the vxge driver:

drivers/net/ethernet/neterion/vxge/vxge-main.c:2121:13: warning: 'adaptive_coalesce_tx_interrupts' defined but not used [-Wunused-function]
drivers/net/ethernet/neterion/vxge/vxge-main.c:2149:13: warning: 'adaptive_coalesce_rx_interrupts' defined but not used [-Wunused-function]

We could add another #ifdef here, but it's nicer to avoid those warnings
for good by converting the existing #ifdef to if(IS_ENABLED()), which has
the same effect but provides better compile-time coverage in general,
and lets the compiler understand better when the function is intentionally
unused.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

brcmfmac: avoid gcc-5.1 warning

2017-04-30T03:49:16+00:00

commit 22f44150aad7a1d6b074ab6cf59abee61c7187c6 upstream.

gcc-5.0 gained a new warning in the fwsignal portion of the brcmfmac
driver:

drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c: In function 'brcmf_fws_txs_process':
drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized]

This is a false positive, and marking the brcmf_fws_hanger_poppkt function
as 'static inline' makes the warning go away. I have checked the object
file output and while a little code gets moved around, the size of
the binary remains identical.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman

net: ti: cpmac: Fix compiler warning due to type confusion

2017-04-30T03:49:15+00:00

commit 2f5281ba2a8feaf6f0aee93356f350855bb530fc upstream.

cpmac_start_xmit() used the max() macro on skb->len (an unsigned int)
and ETH_ZLEN (a signed int literal). This led to the following compiler
warning:

  In file included from include/linux/list.h:8:0,
                   from include/linux/module.h:9,
                   from drivers/net/ethernet/ti/cpmac.c:19:
  drivers/net/ethernet/ti/cpmac.c: In function 'cpmac_start_xmit':
  include/linux/kernel.h:748:17: warning: comparison of distinct pointer
  types lacks a cast
    (void) (&_max1 == &_max2);  \
                   ^
  drivers/net/ethernet/ti/cpmac.c:560:8: note: in expansion of macro 'max'
    len = max(skb->len, ETH_ZLEN);
          ^

On top of this, it assigned the result of the max() macro to a signed
integer whilst all further uses of it result in it being cast to varying
widths of unsigned integer.

Fix this up by using max_t to ensure the comparison is performed as
unsigned integers, and for consistency change the type of the len
variable to unsigned int.

Signed-off-by: Paul Burton 
Signed-off-by: David S. Miller 
Cc: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman