Wright Feng [Fri, 3 Jun 2016 21:31:11 +0000 (23:31 +0200)]
brcmfmac: change rx_seq check log from error print to debug print
The bus rx sequence is not in order because that control and event
frames always cause immediate send, but data frames may be held
for glomming in firmware side. It is not actually an error as the
packets are still processed even if the RX sequence is not in order.
Therefor the error message is rephrased and changed to a debug
message.
Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Wright Feng <wright.feng@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Wright Feng [Fri, 3 Jun 2016 21:31:09 +0000 (23:31 +0200)]
brcmfmac: use ndev->needed_headroom to reserve additional header space
When using nmap tool with FMAC, the nmap packets were be dropped by kernel
because the size was too short. The kernel message showed like
"nmap: packet size is too short (42 <= 50)". It is caused by the packet
length is shorter than ndev->hard_header_len. According to definition of
LL_RESERVED_SPACE() and hard_header_len, we should use hard_header_len
to reserve for L2 header, like ethernet header(ETH_HLEN) in our case and
use needed_headroom for the additional headroom needed by hardware.
Reviewed-by: Arend Van Spriel <arend@broadcom.com> Signed-off-by: Wright Feng <wright.feng@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Wright Feng [Fri, 3 Jun 2016 21:31:08 +0000 (23:31 +0200)]
brcmfmac: revise SDIO error message in brcmf_sdio_drivestrengthinit
The error message is given for something that is not an error here as
the drive strength configuration may not be applicable for specific
devices. Therefor the error message is rephrased and changed to a
debug message.
Signed-off-by: Wright Feng <wright.feng@broadcom.com>
[arend@broadcom.com: rephrase commit message] Signed-off-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Hante Meuleman [Fri, 3 Jun 2016 21:31:07 +0000 (23:31 +0200)]
brcmfmac: fix skb priority handling
SKBs can come with a prioriy. Currently a priority of 0..7 is
assumed. But this assumption is incorrect. To fix this any
priority of 0 or higher then 7 will be adjusted by calling
cfg80211_classify8021d
Reviewed-by: Arend Van Spriel <arend@broadcom.com> Reviewed-by: Franky Lin <franky.lin@broadcom.com> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Signed-off-by: Hante Meuleman <hante.meuleman@broadcom.com> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Lucas Stach [Fri, 3 Jun 2016 21:04:03 +0000 (23:04 +0200)]
b43: only hardcode LED behavior if SPROM doesn't encode any
Only hardcode the LED behavior if the SROM doesn't provide any for all
LEDs of the card. This avoids instantiating LED triggers for unconnected
LEDs, while (hopefully) keeping things working for old cards with a
blank SROM.
Signed-off-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Guenter Roeck [Fri, 3 Jun 2016 20:48:55 +0000 (13:48 -0700)]
libertas_tf: Drop unused variable and define
gcc-6 reports:
drivers/net/wireless/marvell/libertas_tf/main.c:30:19: error:
'lbtf_driver_version' defined but not used
with -Werror=unused-const-variable=.
Reported-by: Fengguang Wu <fengguang.wu@intel.com> [0-day test robot] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Arnd Bergmann [Mon, 30 May 2016 15:26:16 +0000 (17:26 +0200)]
rtlwifi: fix error handling in *_read_adapter_info()
There are nine copies of the _rtl88ee_read_adapter_info() function,
and most but not all of them cause a build warning in some configurations:
rtl8192de/hw.c: In function '_rtl92de_read_adapter_info':
rtl8192de/hw.c:1767:12: error: 'hwinfo' may be used uninitialized in this function [-Werror=maybe-uninitialized]
rtl8723ae/hw.c: In function '_rtl8723e_read_adapter_info.constprop':
rtlwifi/rtl8723ae/hw.c:1654:12: error: 'hwinfo' may be used uninitialized in this function [-Werror=maybe-uninitialized]
The problem is that when rtlefuse->epromtype is something other than
EEPROM_BOOT_EFUSE, the rest of the function uses undefined data, resulting
in random behavior later.
Apparently, in some drivers, the problem was already found and fixed
but the fix did not make it into the others.
This picks one approach to deal with the problem and applies identical
code to all 9 files, to simplify the later consolidation of those.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Mon, 30 May 2016 04:40:54 +0000 (06:40 +0200)]
brcmfmac: don't remove interface on link down firmware event
There are two firmware events we handle similarly in brcmfmac:
BRCMF_E_LINK and BRCMF_E_IF. The difference from firmware point of view
is that the first one means BSS remains present in the firmware. Trying
to (re)create it (e.g. when adding new virtual interface) will result in
an error.
Current code treats both events in a similar way. It removes Linux
interface for each of them. It works OK with e.g. BCM43602. Its firmware
generates both events for each interface. It means we get BRCMF_E_LINK
and remove interface. That is soon followed by BRCMF_E_IF which means
BSS was also removed in a firmware. The only downside of this is a
harmless error like:
[ 208.643180] brcmfmac: brcmf_fweh_call_event_handler: no interface object
Unfortunately BCM4366 firmware doesn't automatically remove BSS and so
it doesn't generate BRCMF_E_IF. In such case we incorrectly remove Linux
interface on BRCMF_E_LINK as BSS is still present in the firmware. It
results in an error when trying to re-create virtual interface, e.g.:
> iw phy phy1 interface add wlan1-1 type __ap
[ 3602.929199] brcmfmac: brcmf_ap_add_vif: timeout occurred
command failed: I/O error (-5)
With this patch we don't remove Linux interface while firmware keeps
BSS. Thanks to this we keep a consistent states of host driver and
device firmware.
Further improvement should be to mark BSS as disabled and remove
interface on BRCMF_E_LINK. Then we should add support for reusing
BSS-es.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Fri, 27 May 2016 19:07:19 +0000 (21:07 +0200)]
brcmfmac: fix setting AP channel with new firmwares
Firmware for new chipsets is based on a new major version of code
internally maintained at Broadcom. E.g. brcmfmac4366b-pcie.bin (used for
BCM4366B1) is based on 10.10.69.3309 while brcmfmac43602-pcie.ap.bin was
based on 7.35.177.56.
Currently setting AP 5 GHz channel doesn't work reliably with BCM4366B1.
When setting e.g. 36 control channel with VHT80 (center channel 42)
firmware may randomly pick one of:
1) 52 control channel with 58 as center one
2) 100 control channel with 106 as center one
3) 116 control channel with 122 as center one
4) 149 control channel with 155 as center one
It seems new firmwares require setting AP mode (BRCMF_C_SET_AP) before
specifying a channel. Changing an order of firmware calls fixes the
problem. This requirement resulted in two separated "chanspec" calls,
one in AP code path and one in P2P path.
This fix was verified with BCM4366B1 and tested for regressions on
BCM43602.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Arnd Bergmann [Fri, 27 May 2016 15:08:33 +0000 (17:08 +0200)]
wl3501_cs: avoid bogus gcc-6 warning
gcc-6 on x86 started warning about wl3501_get_encode when building
with -O2:
drivers/net/wireless/wl3501_cs.c: In function ‘wl3501_get_encode’:
drivers/net/wireless/wl3501_cs.c:1769:5: warning: ‘implemented’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1686:19: warning: ‘threshold’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1702:20: warning: ‘threshold’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1719:23: warning: ‘txpow’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1752:20: warning: ‘retry’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1806:25: warning: ‘pwr_state’ may be used uninitialized in this function
drivers/net/wireless/wl3501_cs.c:1383:24: warning: ‘value’ may be used uninitialized in this function
I could not figure out what exactly confuses gcc here, but splitting the
wl3501_get_mib_value function into two helps the compiler to figure out
that the variables are not actually used uninitialized, and makes it
slightly clearer to a human reader what the function actually does and
which parts of it are under the spinlock.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: use better message and error code when OF node doesn't match
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
binding document lists the possible compatible strings that a SDIO child
node can have, so the driver checks if the defined in the node matches.
But the error message when that's not the case is misleading, so change
for one that makes clear what the error really is. Also, returning a -1
as errno code is not correct since that's -EPERM. A -EINVAL seems to be
a more appropriate one.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: don't print an error if an optional DT property is missing
The Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt DT
binding document say that the "interrupts" property in the child node is
optional. So the property being missed shouldn't be treated as an error.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: check if mwifiex_sdio_probe_of() fails and return error
The function can fail so the returned value should be checked
and the error propagated to the caller in case of a failure.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: use dev_err() instead of pr_err() in mwifiex_sdio_probe()
It's better to have the device name prefixed in the error message.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Instead of duplicating part of the cleanups needed in case of an error
in .probe callback, have a single error path and use goto labels as is
common practice in the kernel.
This also has the nice side effect that the cleanup operations are made
in the inverse order of their counterparts, which was not the case for
the mwifiex_add_card() error path.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: propagate mwifiex_add_card() errno code in mwifiex_sdio_probe()
There's only a check if mwifiex_add_card() returned a nonzero value, but
the actual error code is neither stored nor propagated to the caller. So
instead of always returning -1 (which is -EPERM and not a suitable errno
code in this case), propagate the value returned by mwifiex_add_card().
Patch also removes the assignment of sdio_disable_func() returned value
since it was overwritten anyways and what matters is to know the error
value returned by the first function that failed.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: propagate sdio_enable_func() errno code in mwifiex_sdio_probe()
If the sdio_enable_func() function fails on .probe, the -EIO errno code
is always returned but that could make more difficult to debug and find
the cause of why the function actually failed.
Since the driver/device core prints the value returned by .probe in its
error message propagate what was returned by sdio_enable_func() at fail.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mwifiex: only call mwifiex_sdio_probe_of() if dev has an OF node
SDIO is an auto enumerable bus so the SDIO devices are matched using the
sdio_device_id table and not using compatible strings from a OF id table.
However, commit ce4f6f0c353b ("mwifiex: add platform specific wakeup
interrupt support") allowed to match nodes defined as child of the SDIO
host controller in the probe function using a compatible string to setup
platform specific parameters in the DT.
The problem is that the OF parse function is always called regardless if
the SDIO dev has an OF node associated or not, and prints an error if it
is not found. So, on a platform that doesn't have a node for a SDIO dev,
the following misleading error message will be printed:
[ 12.480042] mwifiex_sdio mmc2:0001:1: sdio platform data not available
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Fri, 27 May 2016 08:54:28 +0000 (10:54 +0200)]
brcmfmac: print errors if creating interface fails
This is helpful for debugging. Without this all I was getting from "iw"
command on failed creating of P2P interface was:
> command failed: Too many open files in system (-23)
Signed-off-by: Rafal Milecki <zajec5@gmail.com>
[arend@broadcom.com: reduce error prints upon iface creation] Signed-off-by: Arend van Spriel <arend@broadcom.com> Reviewed-by: Julian Calaby <julian.calaby@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Mathias Krause [Sat, 21 May 2016 13:43:31 +0000 (15:43 +0200)]
mwifiex: remove misleading GFP_DMA flag in buffer allocations
The GFP_DMA flag is obviously misunderstood in the mwifiex driver. It's
meant for legacy ISA DMA memory mappings only -- the lower 16MB on x86.
That doesn't apply to PCIe or SDIO devices, I guess.
Remove the GFP_DMA flag to reduce the need to place the socket buffer
allocation into the low mem DMA area, which might already be in use by
other drivers.
This misuse was flagged by the PaX USERCOPY feature by chance, as it
detected the user copy operation from a DMA buffer in the recvfrom()
syscall path.
Signed-off-by: Mathias Krause <minipli@googlemail.com> Tested-by: Dennis Wassenberg <dennis.wassenberg@secunet.com> Cc: Amitkumar Karwar <akarwar@marvell.com> Cc: Nishant Sarmukadam <nishants@marvell.com> Cc: Xinming Hu <huxm@marvell.com> Cc: Kalle Valo <kvalo@codeaurora.org> Cc: Brad Spengler <spender@grsecurity.net> Cc: PaX Team <pageexec@freemail.hu> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Fri, 20 May 2016 11:38:58 +0000 (13:38 +0200)]
brcmfmac: support get_channel cfg80211 callback
This is important for brcmfmac as some of released firmwares (e.g.
brcmfmac4366b-pcie.bin) may pick different channel than requested. This
has been tested with BCM4366B1 in D-Link DIR-885L.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Fri, 20 May 2016 11:38:57 +0000 (13:38 +0200)]
brcmutil: add field storing control channel to the struct brcmu_chan
Our d11 code supports encoding/decoding channel info into/from chanspec
format used by firmware. Current implementation is quite misleading
because of the way "chnum" field is used.
When encoding channel info, "chnum" has to be filled by a caller with
*center* channel number. However when decoding chanspec the same field
is filled with a *control* channel number.
1) This can be confusing. It's expected for information to be the same
after encoding and decoding.
2) It doesn't allow accessing all info when decoding. Some functions may
need to know both channel numbers, e.g. cfg80211 callback getting
current channel.
Solve this by adding a separated field for control channel.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Use kmemdup when some other buffer is immediately copied into allocated
region. It replaces call to allocation followed by memcpy, by a single
call to kmemdup.
Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Wei-Ning Huang [Thu, 19 May 2016 03:53:43 +0000 (11:53 +0800)]
mwifiex: fix racing condition when downloading firmware
The action 'check for winner' and 'download firmware' should be an
atomic action. This is true for btmrvl driver but not mwmfiex, which
cause firmware download to fail when the following senerio happens:
1) mwifiex check winner status: true
2) btmrvl check winner status: true, and start downloading firmware
3) mwfieix tries to download firmware, but failed because btmrvl is
already downloading.
This won't happen if 1) and 3) is an atomic action. This patch adds
sdio_claim/release_host call around those two actions to make sure it's
atomic.
Signed-off-by: Wei-Ning Huang <wnhuang@chromium.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Do not return undefined value for transmission power
if the rate is invalid.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Fixes: bf00dc22bc7a ("mwifiex: AMSDU Rx frame handling in AP mode") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Rafał Miłecki [Wed, 25 May 2016 23:44:27 +0000 (01:44 +0200)]
brcmfmac: rework function picking free BSS index
The old implementation was overcomplicated and slightly bugged in some
corner cases.
Consider following state of BSS-es (limited to 6 for simplification):
drvr->iflist[0]: { bsscfgidx:0, ndev->name:wlan1, }
drvr->iflist[1]: (null)
drvr->iflist[2]: { bsscfgidx:2, ndev->name:wlan1-1, }
drvr->iflist[3]: { bsscfgidx:3, ndev->name:wlan1-2, }
drvr->iflist[4]: (null)
drvr->iflist[5]: (null)
In such case the next AP interface should bsscfgidx 4 (we don't use 1 as
it's reserved for P2P).
With old code the loop iterations were following:
[ifidx = 0] [bsscfgidx = 2] [highest = 2]
[ifidx = 1] [bsscfgidx = 2] [highest = 2] available = true
[ifidx = 2] [bsscfgidx = 2] [highest = 2] bsscfgidx = highest + 1
[ifidx = 3] [bsscfgidx = 3] [highest = 2] bsscfgidx = highest + 1
[ifidx = 4] [bsscfgidx = 3] [highest = 2] available = true
[ifidx = 5] [bsscfgidx = 3] [highest = 2] available = true
There were 2 obvious problems:
1) Having empty BSS at index 1 was resulting in available being always
set to true, even if we would run out of BSS-es.
2) Calculated bsscfgidx was invalid (3 instead of 4) resulting in driver
not being able to create the 4th AP interface.
New code is simpler, placed in file where it's really used, handles
running out of free BSS-es and allows using 4 interfaces at the same
time. It also looks for the first free BSS instead of one after the last
in use. It works well with current driver (which doesn't allow deleting
interfaces) and should be future proof (if we ever allow deleting).
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christian Daudt [Wed, 11 May 2016 22:06:49 +0000 (15:06 -0700)]
brcmfmac: Fix 'did not remove int handler' warning
brcmf_sdiod_intr_unregister call that removes both func1 and
func2 interrupt handlers only called when brcmf_ops_sdio_remove
is called for func 1 (which is the 2nd call) but sdio is expecting
it to be removed at the end of each sdio_remove call.
This is causing 'rmmod bcmrfmac' on a 4356-sdio chip to complain
with:
WARNING: driver brcmfmac did not remove its interrupt handler!
The modification makes calling brcmf_sdiod_intr_unregister multiple
times harmless by clearing the variables that track if interrupt
handlers have been installed, and then calls it on every
brcmf_ops_sdio_remove call instead of just remove for func 1.
Signed-off-by: Christian Daudt <csd@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Christian Daudt [Wed, 11 May 2016 22:06:48 +0000 (15:06 -0700)]
brcmfmac: Fix kernel oops in failed chip_attach
When chip attach fails, brcmf_sdiod_intr_unregister is being called
but that is too early as sdiodev->settings has not been set yet
nor has brcmf_sdiod_intr_register been called.
Change to use oob_irq_requested + newly created sd_irq_requested
to decide on what to unregister at intr_unregister time.
Steps to reproduce problem:
- modprobe brcmfmac using buggy FW
- rmmod brcmfmac
- modprobe brcmfmac again.
If done with a buggy firmware, brcm_chip_attach will fail on the
2nd modprobe triggering the call to intr_unregister and the
kernel oops when attempting to de-reference sdiodev->settings->bus.sdio
which has not yet been set.
Signed-off-by: Christian Daudt <csd@broadcom.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Yuval Mintz [Sat, 4 Jun 2016 05:20:16 +0000 (08:20 +0300)]
qed: Fix next-ptr chains for BE / 32-bit
Commit a91eb52abb50 ("qed: Revisit chain implementation") contains an
incorrect implementation for BE platforms, as device's regpairs containing
addresses are LE and they're not converted correctly when read back.
In addition, it raises a compilation warning for 32-bit platforms where
dma_addr_t is a 32-bit variable.
Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Sat, 4 Jun 2016 00:08:45 +0000 (20:08 -0400)]
Merge branch 'qed-roce-iscsi'
Yuval Mintz says:
====================
qed: RocE & iSCSI infrastructure
We plan on sending 2 new protocol drivers in the imminent future -
both our RoCE [qedr] and iSCSI [qedi] drivers. As both submissions
would be rather massive and in order to avoid collisions between them,
the common infrastructure on the qed side was prepared as an independent
patch-series to be sent ahead of those 2 submissions.
This patch series introduces in QED 2 new 'ids' - one for iscsi and
one for roce. It then goes and adds logic required for configuring
said protocols in HW. Notice it *doesn't* actually add any client using
said ids, but rather only the infrastructure to allow their later usage.
What this patch doesn't contain is the slowpath protocol-configuration
toward the firmware. I.e., it contains register-setting logic, memory
allocations, etc., but not actual flow-related configuration specific
to the protocl. Those would be sent as part of the protocol driver
submissions.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz [Fri, 3 Jun 2016 11:35:35 +0000 (14:35 +0300)]
qed: Initialize hardware for new protocols
RoCE and iSCSI would require some added/changed hw configuration in order
to properly run; The biggest single change being the requirement of
allocating and mapping host memory for several HW blocks that aren't being
used by qede [SRC, QM, TM, etc.].
In addition, whereas qede is only using context memory for HW blocks, the
new protocol would also require task memories to be added.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz [Fri, 3 Jun 2016 11:35:33 +0000 (14:35 +0300)]
qed: Add common HSI for new protocols
This adds the qed portion of the RoCE & iSCSI firmware HSI,
as well as adding several new common HSI files which would be required
by both qed and qed* protocols.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Ivan Khoronzhuk [Thu, 2 Jun 2016 22:37:08 +0000 (01:37 +0300)]
net: ethernet: ti: cpsw: remove unused priv lock
There is no reason in this lock. At least for now.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Haiyang Zhang [Thu, 2 Jun 2016 19:02:04 +0000 (12:02 -0700)]
hv_netvsc: Fix VF register on vlan devices
Added a condition to avoid vlan devices with same MAC registering
as VF.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by: K. Y. Srinivasan <kys@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 3 Jun 2016 23:37:26 +0000 (19:37 -0400)]
Merge branch 'sctp-gso'
Marcelo Ricardo Leitner says:
====================
sctp: Add GSO support
This patchset adds sctp GSO support.
Performance tests indicates that increases throughput by 10% if using
bigger chunk sizes, specially if bigger than MTU. For small chunks, it
doesn't help much if not using heavy firewall rules.
For small chunks it will probably be of more use once we get something
like MSG_MORE as David Laight had suggested.
overall changes:
v1->v2:
Added support for receiving GSO frames on SCTP stack, as requested by
Dave Miller.
v2->v3:
Consider sctphdr size in skb_gso_transport_seglen()
rebased due to 5c7cdf339af5 ("gso: Remove arbitrary checks for
unsupported GSO")
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
sctp: improve debug message to also log curr pkt and new chunk size
This is useful for debugging packet sizes.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
SCTP has this pecualiarity that its packets cannot be just segmented to
(P)MTU. Its chunks must be contained in IP segments, padding respected.
So we can't just generate a big skb, set gso_size to the fragmentation
point and deliver it to IP layer.
This patch takes a different approach. SCTP will now build a skb as it
would be if it was received using GRO. That is, there will be a cover
skb with protocol headers and children ones containing the actual
segments, already segmented to a way that respects SCTP RFCs.
With that, we can tell skb_segment() to just split based on frag_list,
trusting its sizes are already in accordance.
This way SCTP can benefit from GSO and instead of passing several
packets through the stack, it can pass a single large packet.
v2:
- Added support for receiving GSO frames, as requested by Dave Miller.
- Clear skb->cb if packet is GSO (otherwise it's not used by SCTP)
- Added heuristics similar to what we have in TCP for not generating
single GSO packets that fills cwnd.
v3:
- consider sctphdr size in skb_gso_transport_seglen()
- rebased due to 5c7cdf339af5 ("gso: Remove arbitrary checks for
unsupported GSO")
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch is a preparation for the GSO one. In order to successfully
handle GSO packets on rx path we must not call skb_linearize, otherwise
it defeats any gain GSO may have had.
This patch thus delays as much as possible the call to skb_linearize,
leaving it to sctp_inq_pop() moment. For that the sanity checks
performed now know how to deal with fragments.
One positive side-effect of this is that if the socket is backlogged it
will have the chance of doing it on backlog processing instead of
during softirq.
With this move, it's evident that a check for non-linearity in
sctp_inq_pop was ineffective and is now removed. Note that a similar
check is performed a bit below this one.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
skb_gso_network_seglen is not enough for checking fragment sizes if
skb is using GSO_BY_FRAGS as we have to check frag per frag.
This patch introduces skb_gso_validate_mtu, based on the former, which
will wrap the use case inside it as all calls to skb_gso_network_seglen
were to validate if it fits on a given TMU, and improve the check.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch allows segmenting a skb based on its frags sizes instead of
based on a fixed value.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
sctp GSO requires it and sctp can be compiled as a module, so we need to
export this function.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
NETIF_F_GSO_SOFTWARE was defined to list all GSO software types, so lets
make use of it in loopback code. Note that veth/vxlan/others already
uses it.
Within this patch series, this patch causes lo to pick up SCTP GSO feature
automatically (as it's added to NETIF_F_GSO_SOFTWARE) and thus avoiding
segmentation if possible.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Tested-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The workqueue adapter->txrx_wq has workitem
&adapter->raise_intr_rxdata_task per adapter. Extended Socket Network
Device is shared memory based, so someone's transmission denotes other's
reception. raise_intr_rxdata_task raises interruption of receivers from
the sender in order to notify receivers.
The workqueue adapter->control_wq has workitem
&adapter->interrupt_watch_task per adapter. interrupt_watch_task is used
to prevent delay of interrupts.
Dedicated workqueues have been used in both cases since the workitems
on the workqueues are involved in normal device operation and require
forward progress under memory pressure.
max_active has been set to 0 since there is no need for throttling
the number of active work items.
Since network devices may be used for memory reclaim,
WQ_MEM_RECLAIM has been set to guarantee forward progress.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yuval Mintz [Thu, 2 Jun 2016 07:23:29 +0000 (10:23 +0300)]
qed: Utilize FW 8.10.3.0
The New QED firmware contains several fixes, including:
- Wrong classification of packets in 4-port devices.
- Anti-spoof interoperability with encapsulated packets.
- Tx-switching of encapsulated packets.
It also slightly improves Tx performance of the device.
In addition, this firmware contains the necessary logic for
supporting iscsi & rdma, for which we plan on pushing protocol
drivers in the imminent future.
Signed-off-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David Ahern [Thu, 2 Jun 2016 04:16:39 +0000 (21:16 -0700)]
net: vrf: set operstate and mtu at link create
The VRF device exists to define L3 domains and guide FIB lookups. As
such its operstate is not relevant. Seeing 'state UNKNOWN' in the
output of 'ip link show' can be confusing, so set operstate at link
create.
Similarly, the MTU for a VRF device is not used; any fragmentation
of the payload is done on the output path based on the real egress
device. An MTU of 1500 on the VRF device while enslaved devices
have a higher MTU can lead to confusion. Since the VRF MTU is not
relevant set to 64k similar to what is done for loopback.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Zhang Shengju [Tue, 31 May 2016 13:41:02 +0000 (13:41 +0000)]
ovs: set name assign type of internal port
Set name_assign_type of internal port to NET_NAME_USER.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com> Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net>
A dedicated workqueue has been used since the workitems are involved
in normal device operation. Workitems &priv->rx_work and &priv->tx_work,
map to w5100_rx_work and w5100_tx_work respectively and are involved in
receiving and transmitting packets. Forward progress under
memory pressure is a requirement here.
create_workqueue has been replaced with alloc_workqueue with max_active
as 0 since there is no need for throttling the number of active work
items.
Since the driver may be used in memory reclaim path,
WQ_MEM_RECLAIM has been set to guarantee forward progress.
flush_workqueue is unnecessary since destroy_workqueue() itself calls
drain_workqueue() which flushes repeatedly till the workqueue
becomes empty. Hence the call to flush_workqueue() has been dropped.
Signed-off-by: Bhaktipriya Shridhar <bhaktipriya96@gmail.com> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Masaru Nagai [Wed, 1 Jun 2016 16:41:05 +0000 (01:41 +0900)]
ravb: Remove manual pause frame transmit
Writing a non-zero value to the manual PAUSE frame register (MPR) starts
the transmission of a PAUSE frame.
A PAUSE frame is sent in ravb_emac_init(), but it is not expected behavior.
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch tries to improve macvlan multicast performance by
maintaining a filter hash at the macvlan_port level so that we
can quickly determine whether a given packet is needed or not.
It is preceded by a patch that fixes a potential use-after-free
bug that I discovered while looking over this.
v2 fixed a bug where promiscuous/allmulti settings weren't handled
correctly.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Wed, 1 Jun 2016 03:45:44 +0000 (11:45 +0800)]
macvlan: Avoid unnecessary multicast cloning
Currently we always queue a multicast packet for further processing,
even if none of the macvlan devices are subscribed to the address.
This patch optimises this by adding a global multicast filter for
a macvlan_port.
Note that this patch doesn't handle the broadcast addresses of the
individual macvlan devices correctly, if they are not all identical
to vlan->lowerdev. However, this is already broken because there
is no mechanism in place to update the individual multicast filters
when you change the broadcast address.
If someone cares enough they should fix this by collecting all
broadcast addresses for a macvlan as we do for multicast and unicast.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Wed, 1 Jun 2016 03:43:00 +0000 (11:43 +0800)]
macvlan: Fix potential use-after free for broadcasts
When we postpone a broadcast packet we save the source port in
the skb if it is local. However, the source port can disappear
before we get a chance to process the packet.
This patch fixes this by holding a ref count on the netdev.
It also delays the skb->cb modification until after we allocate
the new skb as you should not modify shared skbs.
Fixes: 412ca1550cbe ("macvlan: Move broadcasts into a work queue") Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Dumazet [Tue, 31 May 2016 22:22:41 +0000 (15:22 -0700)]
udp: avoid csum_partial() for validated skb
In commit e6afc8ace6dd5 ("udp: remove headers from UDP packets before
queueing"), udp_csum_pull_header() helper was added but missed fact
that CHECKSUM_UNNECESSARY packets were now converted to CHECKSUM_NONE
and skb->csum_valid was set to 1 for them.
Since csum_partial() is quite expensive, even for 8-byte area, it is
worth adding a test.
We also can use skb->data instead of udp_hdr() as we are pulling
UDP headers, as it is sightly faster.
Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Kazuya Mizuguchi [Sun, 29 May 2016 20:25:43 +0000 (05:25 +0900)]
ravb: Add SET_RUNTIME_PM_OPS macro
Use SET_RUNTIME_PM_OPS macro instead of assigning a member of
dev_pm_ops directly.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Masaru Nagai [Tue, 31 May 2016 18:01:28 +0000 (03:01 +0900)]
ravb: Add ESF in RCR for enabling separation filter
The H/W manual recommends B'10 or B'11 in a value of the separation
filtering select bits in the receive configuration register (RCR.ESF).
When B'10 is set, frames from non-matching streams are discarded.
When B'11 is set, frames from non-matching streams are processed in
reception queue 0 (best effort).
This patch sets B'11 in ESF.
[ykaneko0929@gmail.com: revised this commit message] Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net>
1) Fix negative error code usage in ATM layer, from Stefan Hajnoczi.
2) If CONFIG_SYSCTL is disabled, the default TTL is not initialized
properly. From Ezequiel Garcia.
3) Missing spinlock init in mvneta driver, from Gregory CLEMENT.
4) Missing unlocks in hwmb error paths, also from Gregory CLEMENT.
5) Fix deadlock on team->lock when propagating features, from Ivan
Vecera.
6) Work around buffer offset hw bug in alx chips, from Feng Tang.
7) Fix double listing of SCTP entries in sctp_diag dumps, from Xin
Long.
8) Various statistics bug fixes in mlx4 from Eric Dumazet.
9) Fix some randconfig build errors wrt fou ipv6 from Arnd Bergmann.
10) All of l2tp was namespace aware, but the ipv6 support code was not
doing so. From Shmulik Ladkani.
11) Handle on-stack hrtimers properly in pktgen, from Guenter Roeck.
12) Propagate MAC changes properly through VLAN devices, from Mike
Manning.
13) Fix memory leak in bnx2x_init_one(), from Vitaly Kuznetsov.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (62 commits)
sfc: Track RPS flow IDs per channel instead of per function
usbnet: smsc95xx: fix link detection for disabled autonegotiation
virtio_net: fix virtnet_open and virtnet_probe competing for try_fill_recv
bnx2x: avoid leaking memory on bnx2x_init_one() failures
fou: fix IPv6 Kconfig options
openvswitch: update checksum in {push,pop}_mpls
sctp: sctp_diag should dump sctp socket type
net: fec: update dirty_tx even if no skb
vlan: Propagate MAC address to VLANs
atm: iphase: off by one in rx_pkt()
atm: firestream: add more reserved strings
vxlan: Accept user specified MTU value when create new vxlan link
net: pktgen: Call destroy_hrtimer_on_stack()
timer: Export destroy_hrtimer_on_stack()
net: l2tp: Make l2tp_ip6 namespace aware
Documentation: ip-sysctl.txt: clarify secure_redirects
sfc: use flow dissector helpers for aRFS
ieee802154: fix logic error in ieee802154_llsec_parse_dev_addr
net: nps_enet: Disable interrupts before napi reschedule
net/lapb: tuse %*ph to dump buffers
...
Pull sparc fixes from David Miller:
"sparc64 mmu context allocation and trap return bug fixes"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix return from trap window fill crashes.
sparc: Harden signal return frame checks.
sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
Christoph Fritz [Thu, 26 May 2016 02:06:47 +0000 (04:06 +0200)]
usbnet: smsc95xx: fix link detection for disabled autonegotiation
To detect link status up/down for connections where autonegotiation is
explicitly disabled, we don't get an irq but need to poll the status
register for link up/down detection.
This patch adds a workqueue to poll for link status.
Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
wangyunjian [Tue, 31 May 2016 03:52:43 +0000 (11:52 +0800)]
virtio_net: fix virtnet_open and virtnet_probe competing for try_fill_recv
In function virtnet_open() and virtnet_probe(), func try_fill_recv() may
be executed at the same time. VQ in virtqueue_add() has not been protected
well and BUG_ON will be triggered when virito_net.ko being removed.
Signed-off-by: Yunjian Wang <wangyunjian@huawei.com> Acked-by: Jason Wang <jasowang@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Vitaly Kuznetsov [Mon, 30 May 2016 13:00:54 +0000 (15:00 +0200)]
bnx2x: avoid leaking memory on bnx2x_init_one() failures
bnx2x_init_bp() allocates memory with bnx2x_alloc_mem_bp() so if we
fail later in bnx2x_init_one() we need to free this memory
with bnx2x_free_mem_bp() to avoid leakages. E.g. I'm observing memory
leaks reported by kmemleak when a failure (unrelated) happens in
bnx2x_vfpf_acquire().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by: Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Arnd Bergmann [Tue, 31 May 2016 20:42:11 +0000 (22:42 +0200)]
fou: fix IPv6 Kconfig options
The Kconfig options I added to work around broken compilation ended
up screwing up things more, as I used the wrong symbol to control
compilation of the file, resulting in IPv6 fou support to never be built
into the kernel.
Changing CONFIG_NET_FOU_IPV6_TUNNELS to CONFIG_IPV6_FOU fixes that
problem, I had renamed the symbol in one location but not the other,
and as the file is never being used by other kernel code, this did not
lead to a build failure that I would have caught.
After that fix, another issue with the same patch becomes obvious, as we
'select INET6_TUNNEL', which is related to IPV6_TUNNEL, but not the same,
and this can still cause the original build failure when IPV6_TUNNEL is
not built-in but IPV6_FOU is. The fix is equally trivial, we just need
to select the right symbol.
I have successfully build 350 randconfig kernels with this patch
and verified that the driver is now being built.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Valentin Rothberg <valentinrothberg@gmail.com> Fixes: fabb13db448e ("fou: add Kconfig options for IPv6 support") Signed-off-by: David S. Miller <davem@davemloft.net>
Simon Horman [Mon, 30 May 2016 05:04:25 +0000 (14:04 +0900)]
openvswitch: update checksum in {push,pop}_mpls
In the case of CHECKSUM_COMPLETE the skb checksum should be updated in
{push,pop}_mpls() as they the type in the ethernet header.
As suggested by Pravin Shelar.
Cc: Pravin Shelar <pshelar@nicira.com> Fixes: 25cd9ba0abc0 ("openvswitch: Add basic MPLS support to kernel") Signed-off-by: Simon Horman <simon.horman@netronome.com> Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Xin Long [Sun, 29 May 2016 09:42:13 +0000 (17:42 +0800)]
sctp: sctp_diag should dump sctp socket type
Now we cannot distinguish that one sk is a udp or sctp style when
we use ss to dump sctp_info. it's necessary to dump it as well.
For sctp_diag, ss support is not officially available, thus there
are no official users of this yet, so we can add this field in the
middle of sctp_info without breaking user API.
v1->v2:
- move 'sctpi_s_type' field to the end of struct sctp_info, so
that it won't cause incompatibility with applications already
built.
- add __reserved3 in sctp_info to make sure sctp_info is 8-byte
alignment.
Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Troy Kisky [Fri, 27 May 2016 20:30:40 +0000 (13:30 -0700)]
net: fec: update dirty_tx even if no skb
If dirty_tx isn't updated, then dma_unmap_single
can be called twice.
This fixes a
[ 58.420980] ------------[ cut here ]------------
[ 58.425667] WARNING: CPU: 0 PID: 377 at /home/schurig/d/mkarm/linux-4.5/lib/dma-debug.c:1096 check_unmap+0x9d0/0xab8()
[ 58.436405] fec 2188000.ethernet: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=66 bytes]
encountered by Holger
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com> Tested-by: <holgerschurig@gmail.com> Acked-by: Fugang Duan <fugang.duan@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Mike Manning [Fri, 27 May 2016 16:45:07 +0000 (17:45 +0100)]
vlan: Propagate MAC address to VLANs
The MAC address of the physical interface is only copied to the VLAN
when it is first created, resulting in an inconsistency after MAC
address changes of only newly created VLANs having an up-to-date MAC.
The VLANs should continue inheriting the MAC address of the physical
interface until the VLAN MAC address is explicitly set to any value.
This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
to the MAC of the physical interface and thus for DAD to behave as
expected.
Signed-off-by: Mike Manning <mmanning@brocade.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Dan Carpenter [Fri, 27 May 2016 10:34:35 +0000 (13:34 +0300)]
atm: iphase: off by one in rx_pkt()
The iadev->rx_open[] array holds "iadev->num_vc" pointers (this code
assumes that pointers are 32 bits). So the > here should be >= or else
we could end up reading a garbage pointer from one element beyond the
end of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
There are supposed to be 64 entries in this array and the missing
strings are clearly in the 30 40 range. I added them as reserved 37 to
reserved 40. It's possible that strings are really supposed to be added
in the middle instead of at the end, but this approach is safe, in that
it fixes the bug and doesn't break anything that wasn't already broken.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Chen Haiquan [Fri, 27 May 2016 02:49:11 +0000 (10:49 +0800)]
vxlan: Accept user specified MTU value when create new vxlan link
When create a new vxlan link, example:
ip link add vtap mtu 1440 type vxlan vni 1 dev eth0
The argument "mtu" has no effect, because it is not set to conf->mtu. The
default value is used in vxlan_dev_configure function.
This problem was introduced by commit 0dfbdf4102b9 (vxlan: Factor out device
configuration).
Fixes: 0dfbdf4102b9 (vxlan: Factor out device configuration) Signed-off-by: Chen Haiquan <oc@yunify.com> Acked-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Linus Torvalds [Tue, 31 May 2016 16:43:24 +0000 (09:43 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Martin Schwidefsky:
"Three bugs fixes and an update for the default configuration"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390: fix info leak in do_sigsegv
s390/config: update default configuration
s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop
s390/bpf: reduce maximum program size to 64 KB
Linus Torvalds [Tue, 31 May 2016 16:27:00 +0000 (09:27 -0700)]
Merge tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"A bunch of GPIO fixes for the v4.7 series:
- Drop the lock before reading out the GPIO direction setting in
drivers supporting the .get_direction() callback: some of them may
be slowpath.
- Flush GPIO direction setting before locking a GPIO as an IRQ: some
electronics or other poking around in the registers behind our back
may have happened, so flush the direction status before trying to
lock the line for use by IRQs.
- Bail out silently when asked to perform operations on NULL GPIO
descriptors. That is what all the get_*_optional() is about: we
get optional GPIO handles, if they are not there, we get NULL.
- Handle compatible ioctl() correctly: we need to convert the ioctl()
pointer using compat_ptr() here like everyone else.
- Disable the broken .to_irq() on the LPC32xx platform. The whole
irqchip infrastructure was replaced in the last merge window, and a
new implementation will be needed"
* tag 'gpio-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: drop lock before reading GPIO direction
gpio: bail out silently on NULL descriptors
gpio: handle compatible ioctl() pointers
gpio: flush direction status in gpiochip_lock_as_irq()
gpio: lpc32xx: disable broken to_irq support
Andy Shevchenko [Mon, 30 May 2016 14:40:41 +0000 (17:40 +0300)]
lib/uuid: add a test module
It appears that somehow I missed a test of the latest UUID rework which
landed in the kernel. Present a small test module to avoid such cases
in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Walleij [Mon, 30 May 2016 15:11:59 +0000 (17:11 +0200)]
gpio: drop lock before reading GPIO direction
When adding the gpiochip, the GPIO HW drivers' callback get_direction()
could get called in atomic context. Some of the GPIO HW drivers may
sleep when accessing the register.
Move the lock before initializing the descriptors.
Linus Walleij [Mon, 30 May 2016 14:48:39 +0000 (16:48 +0200)]
gpio: bail out silently on NULL descriptors
In fdeb8e1547cb9dd39d5d7223b33f3565cf86c28e
("gpio: reflect base and ngpio into gpio_device")
assumed that GPIO descriptors are either valid or error
pointers, but gpiod_get_[index_]optional() actually return
NULL descriptors and then all subsequent calls should just
bail out.
Cc: stable@vger.kernel.org Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Fixes: fdeb8e1547cb ("gpio: reflect base and ngpio into gpio_device") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Linus Walleij [Wed, 25 May 2016 08:56:03 +0000 (10:56 +0200)]
gpio: flush direction status in gpiochip_lock_as_irq()
As irqchip and gpiochip functions are orthogonal, the IRQ
set-up or something else can have changed the direction of
the GPIO line from what the GPIO descriptor knows when we
get into gpiochip_lock_as_irq(). Make sure to re-read the
direction setting if we have the .get_direction() callback
enabled for the chip.
Else we get problems like this:
iio iio:device2: interrupts on the rising edge
gpio gpiochip2: (8012e080.gpio): gpiochip_lock_as_irq:
tried to flag a GPIO set as output for IRQ
gpio gpiochip2: (8012e080.gpio): unable to lock HW IRQ 0 for IRQ
genirq: Failed to request resources for l3g4200d-trigger
(irq 111) on irqchip nmk1-32-63
iio iio:device2: failed to request trigger IRQ.
st-gyro-i2c: probe of 2-0068 failed with error -22
Fixes: 72d320006177 ("gpio: set up initial state from .get_direction()") Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
projects / linux-beck.git / log