Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 11月, 2018 1 次提交
    • D
      brcmfmac: Use standard SKB list accessors in brcmf_sdiod_sglist_rw. · 4a5a553d
      由 David S. Miller 提交于 
      Instead of direct SKB list pointer accesses.

The loops in this function had to be rewritten to accommodate this
more easily.

The first loop iterates now over the target list in the outer loop,
and triggers an mmc data operation when the per-operation limits are
hit.

Then after the loops, if we have any residue, we trigger the last
and final operation.

For the page aligned workaround, where we have to copy the read data
back into the original list of SKBs, we use a two-tiered loop.  The
outer loop stays the same and iterates over pktlist, and then we have
an inner loop which uses skb_peek_next().  The break logic has been
simplified because we know that the aggregate length of the SKBs in
the source and destination lists are the same.

This change also ends up fixing a bug, having to do with the
maintainance of the seg_sz variable and how it drove the outermost
loop.  It begins as:

	seg_sz = target_list->qlen;

ie. the number of packets in the target_list queue.  The loop
structure was then:

	while (seq_sz) {
		...
		while (not at end of target_list) {
			...
			sg_cnt++
			...
		}
		...
		seg_sz -= sg_cnt;

The assumption built into that last statement is that sg_cnt counts
how many packets from target_list have been fully processed by the
inner loop.  But this not true.

If we hit one of the limits, such as the max segment size or the max
request size, we will break and copy a partial packet then contine
back up to the top of the outermost loop.

With the new loops we don't have this problem as we don't guard the
loop exit with a packet count, but instead use the progression of the
pkt_next SKB through the list to the end.  The general structure is:

	sg_cnt = 0;
	skb_queue_walk(target_list, pkt_next) {
		pkt_offset = 0;
		...
		sg_cnt++;
		...
		while (pkt_offset < pkt_next->len) {
			pkt_offset += sg_data_size;
			if (queued up max per request)
				mmc_submit_one();
		}
	}
	if (sg_cnt)
		mmc_submit_one();

The variables that maintain where we are in the MMC command state such
as req_sz, sg_cnt, and sgl are reset when we emit one of these full
sized requests.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a5a553d
  3. 11 9月, 2018 1 次提交
  5. 23 5月, 2018 1 次提交
  7. 09 5月, 2018 1 次提交
    • S
      brcmfmac: Add support for bcm43364 wireless chipset · 9c4a121e
      由 Sean Lanigan 提交于 
      Add support for the BCM43364 chipset via an SDIO interface, as used in
e.g. the Murata 1FX module.

The BCM43364 uses the same firmware as the BCM43430 (which is already
included), the only difference is the omission of Bluetooth.

However, the SDIO_ID for the BCM43364 is 02D0:A9A4, giving it a MODALIAS
of sdio:c00v02D0dA9A4, which doesn't get recognised and hence doesn't
load the brcmfmac module. Adding the 'A9A4' ID in the appropriate place
triggers the brcmfmac driver to load, and then correctly use the
firmware file 'brcmfmac43430-sdio.bin'.
Signed-off-by: NSean Lanigan <sean@lano.id.au>
Acked-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      9c4a121e
  9. 12 1月, 2018 2 次提交
  11. 09 1月, 2018 5 次提交
  13. 14 12月, 2017 7 次提交
  15. 07 12月, 2017 10 次提交
  17. 08 8月, 2017 1 次提交
  19. 21 6月, 2017 1 次提交
  21. 13 6月, 2017 1 次提交
  23. 31 3月, 2017 1 次提交
  25. 20 1月, 2017 1 次提交
  27. 27 9月, 2016 1 次提交
  29. 09 9月, 2016 1 次提交
  31. 20 7月, 2016 1 次提交
  33. 04 6月, 2016 2 次提交
    • C
      brcmfmac: Fix 'did not remove int handler' warning · b7467401
      由 Christian Daudt 提交于 
      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>
      b7467401
    • C
      brcmfmac: Fix kernel oops in failed chip_attach · b88a2e80
      由 Christian Daudt 提交于 
      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>
      b88a2e80
  35. 12 5月, 2016 1 次提交
  37. 07 4月, 2016 1 次提交