This patch ensures that 'locally_generated' parameter is correctly
passed to cfg80211_disconnected() API.
Signed-off-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NMathias Krause <minipli@googlemail.com>
Tested-by: NDennis 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: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NRafał Miłecki <zajec5@gmail.com>
Reviewed-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle 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: NMuhammad Falak R Wani <falakreyaz@gmail.com>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

gcc-6 warns about code in il3945_hw_txq_ctx_free() being
somewhat ambiguous:

drivers/net/wireless/intel/iwlegacy/3945.c:1022:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses]

This adds a set of curly braces to avoid the warning.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NWei-Ning Huang <wnhuang@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Simplify assignment in wlc_phy_rxcal_gainctrl_nphy_rev5.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Simplify _rtl92ee_phy_path_adda_on.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Do not dereference card before checking against NULL value.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Do not return undefined value for transmission power
if the rate is invalid.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NLarry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Variable adapter is incorrectly initialized.

Fixes: bf00dc22 ("mwifiex: AMSDU Rx frame handling in AP mode")
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Acked-by: NAmitkumar Karwar <akarwar@marvell.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

msg is dereferenced before checking against NULL, e.g.
when assigning pad_bytes.
Remove the superfluous check in function rsi_mgmt_pkt_to_core.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

firmare -> firmware
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Check the current PHY operating mode (gmode) to see if we should
fall back from 6MB OFDM to 11MB CCK.  For 5GHz operation this isn't
allowed.

Note, the fallback lookup is only done for RTS rates; normal fallback
rates are done via mac80211 and aren't affected by this change.
Signed-off-by: NAdrian Chadd <adrian@freebsd.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NChristian Daudt <csd@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

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: NChristian Daudt <csd@broadcom.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

The previous text was confusing, leading readers to think this
driver was a duplicate, and so didn't need to be enabled.

After the removal of the older staging driver, this is the only
driver in mainline for these devices.
Signed-off-by: NLauri Kasanen <cand@gmx.com>
Acked-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

size_t objects should be printed with %Z printf format.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit a91eb52a ("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: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDavid S. Miller <davem@davemloft.net>

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: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch adds in the ecore 2 new personalities in addition to
QED_PCI_ETH - QED_PCI_ISCSI and QED_PCI_ETH_ROCE.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

RoCE driver is going to need a 32-bit chain [current chain implementation
for qed* currently supports only 16-bit producer/consumer chains].

This patch adds said support, as well as doing other slight tweaks and
modifications to qed's chain API.
Signed-off-by: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is no reason in this lock. At least for now.
Signed-off-by: NIvan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use the more common kernel logging style and reduce object size.

The logging message prefix changes from a mixture of
"RxRPC:" and "RXRPC:" to "af_rxrpc: ".

$ size net/rxrpc/built-in.o*
   text	   data	    bss	    dec	    hex	filename
  64172	   1972	   8304	  74448	  122d0	net/rxrpc/built-in.o.new
  67512	   1972	   8304	  77788	  12fdc	net/rxrpc/built-in.o.old

Miscellanea:

o Consolidate the ASSERT macros to use a single pr_err call with
  decimal and hexadecimal output and a stringified #OP argument
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Added a condition to avoid vlan devices with same MAC registering
as VF.
Signed-off-by: NHaiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: NK. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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 5c7cdf33 ("gso: Remove arbitrary checks for
unsupported GSO")
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is useful for debugging packet sizes.
Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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 5c7cdf33 ("gso: Remove arbitrary checks for
  unsupported GSO")
Signed-off-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid 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: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Tested-by: NXin Long <lucien.xin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

alloc_workqueue replaces deprecated create_workqueue().

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: NBhaktipriya Shridhar <bhaktipriya96@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NYuval Mintz <Yuval.Mintz@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>