brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT - net-next.git - net-next plumbings

summary refs log tree commit diff

path: root/include/acpi/acpiosxf.h

diff options

author	Rafał Miłecki <rafal@milecki.pl>	2017-01-17 23:35:50 +0100
committer	Kalle Valo <kvalo@codeaurora.org>	2017-02-07 09:57:07 +0200
commit	0f83ff69735651cc7a3d150466a5257ff829b62b (patch)
tree	ecb1f4f0956a1f61ce923a970e99bef734656d56 /include/acpi/acpiosxf.h
parent	50d55b6d3f1c40485e2e06b2805ef81f881ee9db (diff)

brcmfmac: use wiphy_read_of_freq_limits to respect limits from DT

This new helper reads extra frequency limits specified in DT and disables unavailable chanels. This is useful for devices (like home routers) with chipsets limited e.g. by board design. In order to respect info read from DT we simply need to check for IEEE80211_CHAN_DISABLED bit when constructing channel info. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Diffstat (limited to 'include/acpi/acpiosxf.h')

0 files changed, 0 insertions, 0 deletions

I have fixed it as suggested by Marek Szyprowski. First, I have replaced `pch->lock' with `pl330->lock' in functions `pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids the double-lock by acquiring a different lock than `dma_pl330_rqcb'. NOTE that, as a result, `pl330_free_chan_resources' executes `list_splice_tail_init' on `pch->work_list' under lock `pl330->lock', whereas in the rest of the code `pch->work_list' is protected by `pch->lock'. I don't know if this may cause race conditions. Similarly `pch->cyclic' is written by `pl330_alloc_chan_resources' under `pl330->lock' but read by `pl330_tx_submit' under `pch->lock'. Second, I have removed locking from `pl330_request_channel' and `pl330_release_channel' functions. Function `pl330_request_channel' is only called from `pl330_alloc_chan_resources', so the lock is already held. Function `pl330_release_channel' is called from `pl330_free_chan_resources', which already holds the lock, and from `pl330_del'. Function `pl330_del' is called in an error path of `pl330_probe' and at the end of `pl330_remove', but I assume that there cannot be concurrent accesses to the protected data at those points. Signed-off-by: Iago Abal <mail@iagoabal.eu> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>

Diffstat (limited to 'tools/testing/selftests/ftrace/samples/xfail.tc')