Variable-length arrays considered bad
Hi, in an lkml discussion[1] it was mentioned that variable-length arrays should not be used. Few warnings were found[2] from wireless: drivers/net/wireless/ath/ath9k/dfs.c:104:2: warning: ISO C90 forbids variable length array 'max_bin' [-Wvla] drivers/net/wireless/rsi/rsi_91x_sdio.c:570:2: warning: ISO C90 forbids variable length array 'temp_buf' [-Wvla] Patches welcome. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com [2] http://paste.ubuntu.com/p/srQxwPQS9s/ -- Kalle Valo
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
> Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
> >On 2 March 2018 at 10:22, Sebastian Gottschall
> >wrote:
> leds-gpio is crap and limited. you can just register one platform data at
> kernel runtime since its identified by its object name "led-gpio" but the
> kernel forbidds to register 2 platform datas with the same name
> consider the ar71xx devices with qca988x wifi chipsets. they all have
> already a led platform data registered
> at boottime. a second can't be registered anymore so gpio_led is useless
> at
> all for most developers on such platforms. its mainly used for early
> kernel
> platform data initialisation for system leds.
> >>>If leds-gpio has limitations, please fix those, rather then
> >>>introducing duplicated code.
> >>there is no duplicated code introduced and there is no solution for it.
> >>consider that all wifi drivers with softled support
> >>are going that way with registering a own led driver. see ath9k for
> >>instance. gpio-led cannot be used for it and there is no way to
> >>support multiple platform datas with the same name. its a kernel limitation
> >I just reviewed some mips arch patch adding support for more LEDs for
> >selected devices:
> >[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
> >https://patchwork.linux-mips.org/patch/18681/
> >
> >It seems to be simply adding another call to the
> >gpio_led_register_device(). It seems to me you can call that function
> >multiple times and register multiple structs with LEDs.
> >
> >Isn't all you need something like this?
> >
> >static const struct gpio_led ath10k_leds[] = {
> > {
> > .name = "ath10k:color:function",
> > .active_low = 1,
> > .default_state = LEDS_GPIO_DEFSTATE_KEEP,
> > }
> >};
> >
> >static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
> > leds = ath10k_leds;
> > num_leds = ARRAY_SIZE(ath10k_leds);
> >};
> >
> >ath10k_leds.gpio = ar->hw_params.led_pin;
> >gpio_led_register_device(0, &ath10k_leds);
> the problem are other architectures which have already registered gpio_led
> at system start like ar71xx
> you cannot register a second one. so a independend led driver is a
> requirement for direct control
If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
Hi
On Wed, Mar 07, 2018 at 05:47:34PM +0200, Jamie Stuart wrote:
> config wifi-device 'radio0'
> option type 'mac80211'
> option channel 'auto'
To make reproducible testing results I would suggest to setup a channel,
(choose one that is the less used by other wireless networks),
problem may happen on some channels and not happen on other.
> The 30 clients are all Apple iPads (a mixture of iPad mini and mini 2,
> running iOS 9-11). During this testing period, all clients were
> simultaneously downloading files from the devices’ sdcard (served via nginx
> running on the device). Although this is not a typical use-case, it was
> useful in stress-testing the wireless setup.
For such scenario I would suggest hardcode ba_size = 0 and see if that
would help.
I also attach another patch, can be applied on top of two previous.
This one should give RX hardware more time to provide proper BlockACK
frame, so hopefully could help with seq mismashes.
Stanislaw
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index e68f7f9d48f8..95f20072a219 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -9286,7 +9286,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
spec->ht.cap |= rx_chains << IEEE80211_HT_CAP_RX_STBC_SHIFT;
spec->ht.ampdu_factor = 0;
- spec->ht.ampdu_density = 4;
+ spec->ht.ampdu_density = 7;
spec->ht.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
if (tx_chains != rx_chains) {
spec->ht.mcs.tx_params |= IEEE80211_HT_MCS_TX_RX_DIFF;
Re: brcmfmac signal/interference issues
On 2/23/2018 2:49 PM, Daniel Drake wrote: On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel wrote: Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | tail -1' you can see the firmware build target and it likely has 'ndis' in it. Hi Daniel, Bit late response. Sorry. 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf Yes, ndis. So no easy way to run the same firmware on the 2 OSes. Indeed. I could try building nearly same firmware target. Can you provide the firmware version as well. Now reading over your orignal email again: > If I place both antenna terminals inside the Linux MiniPC case, the > Linux pings are bad but the Windows pings are fine. > > If I place both antenna terminals inside the Windows MiniPC case, it > is the same: Linux pings are bad, but the Windows pings are fine. > > And when the Linux antenna is placed outside of both cases, the Linux > pings are fine. I've repeated these tests a handful of times in quick > succession to make sure that I'm not going crazy and that this is not > a case of the problem intermittency causing misleading results. These > findings appear very solid. So it picks up something in the PC. Some sources of interference that I have seen before are USB3 and HDMI. Maybe try to shield those if present and see if that helps. The nvram contains sensitivity parameters, but as you stated you are using the same nvram for windows and linux for now we can rule it out for debugging the issue. Regards, Arend
[RFC] ath10k: report tx rate using ieee80211_tx_status()
Mesh path metric needs txrate information from ieee80211_tx_status()
call but in ath10k there is no mechanism to report tx rate information
via ieee80211_tx_status(), the rate is only accessible via
sta_statiscs() op.
Per peer stats has tx rate info available, this patch stores per peer
last tx rate and updates the tx rate info structures in tx completition.
The rate updated in ieee80211_tx_status() is not exactly for the last
transmitted frame since the actual rate is available in
HTT_T2H_MSG_TYPE_PEER_STATS.
Per peer txrate information is updated through per peer statistics
and is available for QCA9888/QCA9984/QCA4019/QCA998X only
Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00053
Tested on QCA998X with firmware-5.bin_10.2.4-1.0-00036
Signed-off-by: Anilkumar Kolli
---
drivers/net/wireless/ath/ath10k/core.h |1 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 97 +-
drivers/net/wireless/ath/ath10k/mac.c| 13
drivers/net/wireless/ath/ath10k/txrx.c | 25
drivers/net/wireless/ath/ath10k/wmi.h|1 +
5 files changed, 94 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index fe6b30356d3b..d69f0340b487 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -346,6 +346,7 @@ struct ath10k_peer {
/* protected by ar->data_lock */
struct ieee80211_key_conf *keys[WMI_MAX_KEY_INDEX + 1];
+ struct ieee80211_tx_info tx_info;
};
struct ath10k_txq {
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 6d96f9560950..abfea326e1ad 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2427,7 +2427,7 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar,
struct sk_buff *skb)
dev_kfree_skb_any(skb);
}
-static inline bool is_valid_legacy_rate(u8 rate)
+static inline int get_ath10k_rate_idx(u8 rate)
{
static const u8 legacy_rates[] = {1, 2, 5, 11, 6, 9, 12,
18, 24, 36, 48, 54};
@@ -2435,20 +2435,23 @@ static inline bool is_valid_legacy_rate(u8 rate)
for (i = 0; i < ARRAY_SIZE(legacy_rates); i++) {
if (rate == legacy_rates[i])
- return true;
+ return i;
}
- return false;
+ return -EINVAL;
}
static void
ath10k_update_per_peer_tx_stats(struct ath10k *ar,
struct ieee80211_sta *sta,
- struct ath10k_per_peer_tx_stats *peer_stats)
+ struct ath10k_per_peer_tx_stats *peer_stats,
+ struct ath10k_peer *peer)
{
struct ath10k_sta *arsta = (struct ath10k_sta *)sta->drv_priv;
+ struct ieee80211_chanctx_conf *conf = NULL;
u8 rate = 0, sgi;
struct rate_info txrate;
+ bool skip_auto_rate;
lockdep_assert_held(&ar->data_lock);
@@ -2457,6 +2460,13 @@ static inline bool is_valid_legacy_rate(u8 rate)
txrate.nss = ATH10K_HW_NSS(peer_stats->ratecode);
txrate.mcs = ATH10K_HW_MCS_RATE(peer_stats->ratecode);
sgi = ATH10K_HW_GI(peer_stats->flags);
+ skip_auto_rate = ATH10K_FW_SKIPPED_RATE_CTRL(peer_stats->flags);
+
+ /* Firmware's rate control skips broadcast/managment frames, if host has
+* configure fixed rates and in some other special cases.
+*/
+ if (skip_auto_rate)
+ return;
if (txrate.flags == WMI_RATE_PREAMBLE_VHT && txrate.mcs > 9) {
ath10k_warn(ar, "Invalid VHT mcs %hhd peer stats", txrate.mcs);
@@ -2470,36 +2480,63 @@ static inline bool is_valid_legacy_rate(u8 rate)
return;
}
- memset(&arsta->txrate, 0, sizeof(arsta->txrate));
+ memset(&peer->tx_info.status, 0, sizeof(peer->tx_info.status));
if (txrate.flags == WMI_RATE_PREAMBLE_CCK ||
txrate.flags == WMI_RATE_PREAMBLE_OFDM) {
rate = ATH10K_HW_LEGACY_RATE(peer_stats->ratecode);
-
- if (!is_valid_legacy_rate(rate)) {
- ath10k_warn(ar, "Invalid legacy rate %hhd peer stats",
- rate);
- return;
- }
-
- /* This is hacky, FW sends CCK rate 5.5Mbps as 6 */
- rate *= 10;
- if (rate == 60 && txrate.flags == WMI_RATE_PREAMBLE_CCK)
- rate = rate - 5;
- arsta->txrate.legacy = rate;
- } else if (txrate.flags == WMI_RATE_PREAMBLE_HT) {
- arsta->txrate.flags = RATE_INFO_FLAGS_MCS;
- arsta->txrate.mcs = txrate.mcs + 8 * (txrate.nss - 1);
- } else {
- arsta->txrate.flags = RATE_INFO_FLAGS_VHT_MCS;
- arsta->txrate.mcs = txrate.mcs;
+
Re: [PATCH v2] bcma: Prevent build of PCI host features in module
Hi, On 02/03/18 17:56, Larry Finger wrote: On 03/01/2018 04:45 AM, Kalle Valo wrote: Matt Redfearn writes: Attempting to build bcma.ko with BCMA_DRIVER_PCI_HOSTMODE=y results in a build error due to use of symbols not exported from vmlinux: ERROR: "pcibios_enable_device" [drivers/bcma/bcma.ko] undefined! ERROR: "register_pci_controller" [drivers/bcma/bcma.ko] undefined! make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1 To prevent this, don't allow the host mode feature to be built if CONFIG_BCMA=m Signed-off-by: Matt Redfearn --- Changes in v2: Rebase on v4.16-rc1 drivers/bcma/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig index ba8acca036df..cb0f1aad20b7 100644 --- a/drivers/bcma/Kconfig +++ b/drivers/bcma/Kconfig @@ -55,7 +55,7 @@ config BCMA_DRIVER_PCI config BCMA_DRIVER_PCI_HOSTMODE bool "Driver for PCI core working in hostmode" - depends on MIPS && BCMA_DRIVER_PCI && PCI_DRIVERS_LEGACY + depends on MIPS && BCMA_DRIVER_PCI && PCI_DRIVERS_LEGACY && BCMA = y Due to the recent regression in bcma I would prefer extra careful review before I apply this. So does this look ok to everyone? I have a preference for wireless device drivers to be modules. For that reason, I would have submitted a patch exporting those two missing globals rather than forcing bcma to be built in. That said, it seems that the patch will do no further harm. This patch was purely intended to fix the build breakage caused by attempting to build host-mode PCI into a module, which fails due to necessary symbols not being exported by the kernel for use by modules. Making it possible to build the driver including host mode may not be as trivial as "lets just export the symbols", and testing that it works correctly once it can be built as a module will require hardware with this device present (which I don't have). So I would propose that this patch be merged as is, since as you say, it does no further harm - it should just fix build breakage - and if the driver, including this host mode feature, is really required as a module, perhaps someone with access to the hardware could spin a patch to implement that. Thanks, Matt Larry
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Am 08.03.2018 um 10:02 schrieb Pavel Machek:
On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
On 2 March 2018 at 10:22, Sebastian Gottschall wrote:
leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless
at
all for most developers on such platforms. its mainly used for early
kernel
platform data initialisation for system leds.
If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.
there is no duplicated code introduced and there is no solution for it.
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for
instance. gpio-led cannot be used for it and there is no way to
support multiple platform datas with the same name. its a kernel limitation
I just reviewed some mips arch patch adding support for more LEDs for
selected devices:
[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
https://patchwork.linux-mips.org/patch/18681/
It seems to be simply adding another call to the
gpio_led_register_device(). It seems to me you can call that function
multiple times and register multiple structs with LEDs.
Isn't all you need something like this?
static const struct gpio_led ath10k_leds[] = {
{
.name = "ath10k:color:function",
.active_low = 1,
.default_state = LEDS_GPIO_DEFSTATE_KEEP,
}
};
static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
leds = ath10k_leds;
num_leds = ARRAY_SIZE(ath10k_leds);
};
ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, &ath10k_leds);
the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control
If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.
see ath9k. its exact the same implementation.
in addition my variant does also work without gpiolib support. so it can
be used even if the kernel is configured
without gpio support.
and not to forget, using a own led driver is more ligthweight from the
call path for each led on / off event which is important for
low performance embedded devices
Sebastian
Pavel
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH] Revert "mac80211: use QoS NDP for AP probing"
On 27/02/18 23:04, Johannes Berg wrote:
It seems to be a particular driver problem, so blindly reverting seems
a bit heavy-handed.
Johannes, perhaps you could temporarily revert commit 7b6ddeaf27ec
("mac80211: use QoS NDP for AP probing") until you have an
implementation that does not break ath9k_htc.
Kind regards,
--
Ben Caradoc-Davies
Director
Transient Software Limited
Re: [PATCH] ath10k: Enable IOMMU support for WCN3990 target
Arnd Bergmann writes: > On Thu, Mar 1, 2018 at 2:18 PM, Govind Singh wrote: The asm/dma-iommu.h header file exsists only on arm32, no other architecture. I'm not sure about the purpose of the patch to start with: it's normally up to the platform code to allocate IOMMU domains, device drivers should only need to manually interact with the IOMMU layer if they need more than one domain, but this ath10k patch appears to be using the default domain and should have no effect as long as the platform code works correctly. >> Thanks Arnd, I have fixed this and migrated to 64bit >> API's(iommu_attach_device/iommu_detach_device/ >> iommu_get_domain_for_dev), will share the next revision. >> I tried using the default domain by adding the stream ID and mask in >> dt and no manual interaction, but it is resulting in TZ error and >> unhandled context fault. >> Seems I need to provide explicit mapping range(aperture_start/ >> aperture_end) as this is only working combination for me.. > > I don't see why you need to do that at all, can you clarify? > > The IOMMU should be set up implicitly for you here based on the iommus > property in DT, with no driver changes at all. This should work on all > architectures/ Maybe Govind is using some out-of-tree tree which is buggy in this regard? -- Kalle Valo
Re: [PATCH] ath10k: Enable IOMMU support for WCN3990 target
On 2018-03-08 19:20, Kalle Valo wrote: Arnd Bergmann writes: On Thu, Mar 1, 2018 at 2:18 PM, Govind Singh wrote: The asm/dma-iommu.h header file exsists only on arm32, no other architecture. I'm not sure about the purpose of the patch to start with: it's normally up to the platform code to allocate IOMMU domains, device drivers should only need to manually interact with the IOMMU layer if they need more than one domain, but this ath10k patch appears to be using the default domain and should have no effect as long as the platform code works correctly. Thanks Arnd, I have fixed this and migrated to 64bit API's(iommu_attach_device/iommu_detach_device/ iommu_get_domain_for_dev), will share the next revision. I tried using the default domain by adding the stream ID and mask in dt and no manual interaction, but it is resulting in TZ error and unhandled context fault. Seems I need to provide explicit mapping range(aperture_start/ aperture_end) as this is only working combination for me.. I don't see why you need to do that at all, can you clarify? The IOMMU should be set up implicitly for you here based on the iommus property in DT, with no driver changes at all. This should work on all architectures/ Maybe Govind is using some out-of-tree tree which is buggy in this regard? Actually there is limitations in using the iova address range for wlan IP. It can allow certain iova range and i was attaching the iommu to specify the iova range. I am exploring if i can use "dma-ranges" in dt to avoid the manual interaction apart from stream ID and mask. BR, Govind
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:
> Am 08.03.2018 um 10:02 schrieb Pavel Machek:
> >On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
> >>Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
> >>>On 2 March 2018 at 10:22, Sebastian Gottschall
> >>>wrote:
> >>leds-gpio is crap and limited. you can just register one platform data
> >>at
> >>kernel runtime since its identified by its object name "led-gpio" but
> >>the
> >>kernel forbidds to register 2 platform datas with the same name
> >>consider the ar71xx devices with qca988x wifi chipsets. they all have
> >>already a led platform data registered
> >>at boottime. a second can't be registered anymore so gpio_led is useless
> >>at
> >>all for most developers on such platforms. its mainly used for early
> >>kernel
> >>platform data initialisation for system leds.
> >If leds-gpio has limitations, please fix those, rather then
> >introducing duplicated code.
> there is no duplicated code introduced and there is no solution for it.
> consider that all wifi drivers with softled support
> are going that way with registering a own led driver. see ath9k for
> instance. gpio-led cannot be used for it and there is no way to
> support multiple platform datas with the same name. its a kernel
> limitation
> >>>I just reviewed some mips arch patch adding support for more LEDs for
> >>>selected devices:
> >>>[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
> >>>https://patchwork.linux-mips.org/patch/18681/
> >>>
> >>>It seems to be simply adding another call to the
> >>>gpio_led_register_device(). It seems to me you can call that function
> >>>multiple times and register multiple structs with LEDs.
> >>>
> >>>Isn't all you need something like this?
> >>>
> >>>static const struct gpio_led ath10k_leds[] = {
> >>> {
> >>> .name = "ath10k:color:function",
> >>> .active_low = 1,
> >>> .default_state = LEDS_GPIO_DEFSTATE_KEEP,
> >>> }
> >>>};
> >>>
> >>>static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
> >>> leds = ath10k_leds;
> >>> num_leds = ARRAY_SIZE(ath10k_leds);
> >>>};
> >>>
> >>>ath10k_leds.gpio = ar->hw_params.led_pin;
> >>>gpio_led_register_device(0, &ath10k_leds);
> >>the problem are other architectures which have already registered gpio_led
> >>at system start like ar71xx
> >>you cannot register a second one. so a independend led driver is a
> >>requirement for direct control
> >If the limitation indeed exists, please fix the limitation rather than
> >working around it in each and every driver.
> see ath9k. its exact the same implementation.
Ok, so one more driver to fix.
> in addition my variant does also work without gpiolib support. so it can be
> used even if the kernel is configured
> without gpio support.
> and not to forget, using a own led driver is more ligthweight from the call
> path for each led on / off event which is important for
> low performance embedded devices
We are not going to copy&paste code because such code works without
libraries, and we are not going to copy&paste code because that uses
less cache during calls. Sorry.
NAK. Please fix your patch.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?
BTW, the problem triggered today on my MR200 (first one), on channel 11, only one iPhone. OpenWrt configuration was typical, the only change I made was encryption (psk2), and adding an encryption key. all the rest comes directly from OpenWrt wifi detect feature. [ 2761.755086] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.764577] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.774035] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.783492] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.792916] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.802359] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.811802] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.821250] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.830693] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.840136] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.849580] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.859028] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.868470] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.877911] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.887352] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.896793] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.906235] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.915676] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.925118] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.934567] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.944009] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.953450] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.962867] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.972309] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.981750] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2761.991191] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.000632] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.010076] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.019518] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.028955] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.038398] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.047840] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.057282] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.066724] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.076164] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.085605] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.095046] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 [ 2762.104488] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue 2 I know this report is quite useless, but still. On Thu, 8 Mar 2018, Stanislaw Gruszka wrote: Date: Thu, 8 Mar 2018 10:39:39 From: Stanislaw Gruszka To: Jamie Stuart Cc: Daniel Golle , Enrico Mioso , Tom Psyborg , linux-wireless , Johannes Berg , Arnd Bergmann , John Crispin , Felix Fietkau , Mathias Kresin Subject: Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...? Hi On Wed, Mar 07, 2018 at 05:47:34PM +0200, Jamie Stuart wrote: config wifi-device 'radio0' option type 'mac80211' option channel 'auto' To make reproducible testing results I would suggest to setup a channel, (choose one that is the less
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Pavel Machek writes: >> >>>ath10k_leds.gpio = ar->hw_params.led_pin; >> >>>gpio_led_register_device(0, &ath10k_leds); >> >> >> >>the problem are other architectures which have already registered gpio_led >> >>at system start like ar71xx >> >>you cannot register a second one. so a independend led driver is a >> >>requirement for direct control >> > >> >If the limitation indeed exists, please fix the limitation rather than >> >working around it in each and every driver. >> see ath9k. its exact the same implementation. > > Ok, so one more driver to fix. > >> in addition my variant does also work without gpiolib support. so it >> can be used even if the kernel is configured without gpio support. >> and not to forget, using a own led driver is more ligthweight from >> the call path for each led on / off event which is important for low >> performance embedded devices > > We are not going to copy&paste code because such code works without > libraries, and we are not going to copy&paste code because that uses > less cache during calls. Sorry. > > NAK. Please fix your patch. To me it's not that black and white, sometimes copying code is simpler than trying to bring up complicated or restricting frameworks (talking in general here). I haven't been able to review this patch in detail yet but from a quick look most of the code is about standard ath10k infrastructure code. How many lines of code would using leds-gpio save? -- Kalle Valo
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Am 08.03.2018 um 15:05 schrieb Pavel Machek:
On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:
Am 08.03.2018 um 10:02 schrieb Pavel Machek:
On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
On 2 March 2018 at 10:22, Sebastian Gottschall wrote:
leds-gpio is crap and limited. you can just register one platform data at
kernel runtime since its identified by its object name "led-gpio" but the
kernel forbidds to register 2 platform datas with the same name
consider the ar71xx devices with qca988x wifi chipsets. they all have
already a led platform data registered
at boottime. a second can't be registered anymore so gpio_led is useless
at
all for most developers on such platforms. its mainly used for early
kernel
platform data initialisation for system leds.
If leds-gpio has limitations, please fix those, rather then
introducing duplicated code.
there is no duplicated code introduced and there is no solution for it.
consider that all wifi drivers with softled support
are going that way with registering a own led driver. see ath9k for
instance. gpio-led cannot be used for it and there is no way to
support multiple platform datas with the same name. its a kernel limitation
I just reviewed some mips arch patch adding support for more LEDs for
selected devices:
[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
https://patchwork.linux-mips.org/patch/18681/
It seems to be simply adding another call to the
gpio_led_register_device(). It seems to me you can call that function
multiple times and register multiple structs with LEDs.
Isn't all you need something like this?
static const struct gpio_led ath10k_leds[] = {
{
.name = "ath10k:color:function",
.active_low = 1,
.default_state = LEDS_GPIO_DEFSTATE_KEEP,
}
};
static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
leds = ath10k_leds;
num_leds = ARRAY_SIZE(ath10k_leds);
};
ath10k_leds.gpio = ar->hw_params.led_pin;
gpio_led_register_device(0, &ath10k_leds);
the problem are other architectures which have already registered gpio_led
at system start like ar71xx
you cannot register a second one. so a independend led driver is a
requirement for direct control
If the limitation indeed exists, please fix the limitation rather than
working around it in each and every driver.
see ath9k. its exact the same implementation.
Ok, so one more driver to fix.
in addition my variant does also work without gpiolib support. so it can be
used even if the kernel is configured
without gpio support.
and not to forget, using a own led driver is more ligthweight from the call
path for each led on / off event which is important for
low performance embedded devices
We are not going to copy&paste code because such code works without
libraries, and we are not going to copy&paste code because that uses
less cache during calls. Sorry.
NAK. Please fix your patch.
show me a proof that its copy & paste. because its not
Pavel
--
Mit freundlichen Grüssen / Regards
Sebastian Gottschall / CTO
NewMedia-NET GmbH - DD-WRT
Firmensitz: Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Am 08.03.2018 um 15:29 schrieb Kalle Valo: Pavel Machek writes: ath10k_leds.gpio = ar->hw_params.led_pin; gpio_led_register_device(0, &ath10k_leds); the problem are other architectures which have already registered gpio_led at system start like ar71xx you cannot register a second one. so a independend led driver is a requirement for direct control If the limitation indeed exists, please fix the limitation rather than working around it in each and every driver. see ath9k. its exact the same implementation. Ok, so one more driver to fix. in addition my variant does also work without gpiolib support. so it can be used even if the kernel is configured without gpio support. and not to forget, using a own led driver is more ligthweight from the call path for each led on / off event which is important for low performance embedded devices We are not going to copy&paste code because such code works without libraries, and we are not going to copy&paste code because that uses less cache during calls. Sorry. NAK. Please fix your patch. To me it's not that black and white, sometimes copying code is simpler than trying to bring up complicated or restricting frameworks (talking in general here). I haven't been able to review this patch in detail yet but from a quick look most of the code is about standard ath10k infrastructure code. How many lines of code would using leds-gpio save? nothing. the led driver code is already very small. (see gpio.c in the patch) i had a leds-gpio implementation but it will not work since a platform data with the name "leds-gpio" does already exist on various platforms (ath79 for instance) so a second leds-gpio can't be registered. so this solution does simply not work and asking me for fixing the kernel generic platform data handling like pavel did, is really out of mind and a own led driver has also better performance than using the leds-gpio->gpiolib->ath10k gpio driver callpath. if someone is still complaining that i added a gpio feature driver as well to my patch, i can simply remove that usefull feature and all would be happy. but i think having access to all gpios of the card instead of just the led gpio makes sense to. thats why i implemented a gpiolib driver as well Sebastian -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Hi! > show me a proof that its copy & paste. because its not I don't have to prove you anything. Sorry. But you said: > >>see ath9k. its exact the same implementation. We don't want to have exact same code multiple times in the tree. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH 03/10] staging: wilc1000: rename CfgScanResult to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 2fda90d..051ba12 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -363,10 +363,9 @@ static void add_network_to_shadow(struct network_info
*nw_info,
last_scanned_shadow[ap_index].join_params = pJoinParams;
}
-static void CfgScanResult(enum scan_event scan_event,
- struct network_info *network_info,
- void *user_void,
- void *join_params)
+static void cfg_scan_result(enum scan_event scan_event,
+ struct network_info *network_info,
+ void *user_void, void *join_params)
{
struct wilc_priv *priv;
struct wiphy *wiphy;
@@ -622,14 +621,14 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
au8ScanChanList,
request->n_channels,
(const u8 *)request->ie,
- request->ie_len, CfgScanResult,
+ request->ie_len, cfg_scan_result,
(void *)priv, &hidden_ntwk);
} else {
ret = wilc_scan(vif, USER_SCAN, ACTIVE_SCAN,
au8ScanChanList,
request->n_channels,
(const u8 *)request->ie,
- request->ie_len, CfgScanResult,
+ request->ie_len, cfg_scan_result,
(void *)priv, NULL);
}
} else {
--
2.7.4
[PATCH 02/10] staging: wilc1000: rename pstrNetworkInfo to avoid camelCase
Fix 'Avoid camleCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index dd7ab51..2fda90d 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -294,8 +294,7 @@ static void clear_duringIP(struct timer_list *unused)
wilc_optaining_ip = false;
}
-static int is_network_in_shadow(struct network_info *pstrNetworkInfo,
- void *user_void)
+static int is_network_in_shadow(struct network_info *nw_info, void *user_void)
{
int state = -1;
int i;
@@ -306,7 +305,7 @@ static int is_network_in_shadow(struct network_info
*pstrNetworkInfo,
} else {
for (i = 0; i < last_scanned_cnt; i++) {
if (memcmp(last_scanned_shadow[i].bssid,
- pstrNetworkInfo->bssid, 6) == 0) {
+ nw_info->bssid, 6) == 0) {
state = i;
break;
}
@@ -315,10 +314,10 @@ static int is_network_in_shadow(struct network_info
*pstrNetworkInfo,
return state;
}
-static void add_network_to_shadow(struct network_info *pstrNetworkInfo,
+static void add_network_to_shadow(struct network_info *nw_info,
void *user_void, void *pJoinParams)
{
- int ap_found = is_network_in_shadow(pstrNetworkInfo, user_void);
+ int ap_found = is_network_in_shadow(nw_info, user_void);
u32 ap_index = 0;
u8 rssi_index = 0;
@@ -332,30 +331,30 @@ static void add_network_to_shadow(struct network_info
*pstrNetworkInfo,
ap_index = ap_found;
}
rssi_index = last_scanned_shadow[ap_index].rssi_history.index;
- last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] =
pstrNetworkInfo->rssi;
+ last_scanned_shadow[ap_index].rssi_history.samples[rssi_index++] =
nw_info->rssi;
if (rssi_index == NUM_RSSI) {
rssi_index = 0;
last_scanned_shadow[ap_index].rssi_history.full = true;
}
last_scanned_shadow[ap_index].rssi_history.index = rssi_index;
- last_scanned_shadow[ap_index].rssi = pstrNetworkInfo->rssi;
- last_scanned_shadow[ap_index].cap_info = pstrNetworkInfo->cap_info;
- last_scanned_shadow[ap_index].ssid_len = pstrNetworkInfo->ssid_len;
+ last_scanned_shadow[ap_index].rssi = nw_info->rssi;
+ last_scanned_shadow[ap_index].cap_info = nw_info->cap_info;
+ last_scanned_shadow[ap_index].ssid_len = nw_info->ssid_len;
memcpy(last_scanned_shadow[ap_index].ssid,
- pstrNetworkInfo->ssid, pstrNetworkInfo->ssid_len);
+ nw_info->ssid, nw_info->ssid_len);
memcpy(last_scanned_shadow[ap_index].bssid,
- pstrNetworkInfo->bssid, ETH_ALEN);
- last_scanned_shadow[ap_index].beacon_period =
pstrNetworkInfo->beacon_period;
- last_scanned_shadow[ap_index].dtim_period =
pstrNetworkInfo->dtim_period;
- last_scanned_shadow[ap_index].ch = pstrNetworkInfo->ch;
- last_scanned_shadow[ap_index].ies_len = pstrNetworkInfo->ies_len;
- last_scanned_shadow[ap_index].tsf_hi = pstrNetworkInfo->tsf_hi;
+ nw_info->bssid, ETH_ALEN);
+ last_scanned_shadow[ap_index].beacon_period = nw_info->beacon_period;
+ last_scanned_shadow[ap_index].dtim_period = nw_info->dtim_period;
+ last_scanned_shadow[ap_index].ch = nw_info->ch;
+ last_scanned_shadow[ap_index].ies_len = nw_info->ies_len;
+ last_scanned_shadow[ap_index].tsf_hi = nw_info->tsf_hi;
if (ap_found != -1)
kfree(last_scanned_shadow[ap_index].ies);
- last_scanned_shadow[ap_index].ies = kmalloc(pstrNetworkInfo->ies_len,
+ last_scanned_shadow[ap_index].ies = kmalloc(nw_info->ies_len,
GFP_KERNEL);
memcpy(last_scanned_shadow[ap_index].ies,
- pstrNetworkInfo->ies, pstrNetworkInfo->ies_len);
+ nw_info->ies, nw_info->ies_len);
last_scanned_shadow[ap_index].time_scan = jiffies;
last_scanned_shadow[ap_index].time_scan_cached = jiffies;
last_scanned_shadow[ap_index].found = 1;
@@ -654,7 +653,7 @@ static int connect(struct wiphy *wiphy, struct net_device
*dev,
struct wilc_priv *priv;
struct host_if_drv *wfi_drv;
- struct network_info *pstrNetworkInfo = NULL;
+ struct network_info *nw_info = NULL;
struct wilc_vif *vif;
wilc_connecting = 1;
@@ -689,7 +688,7 @@ static int connect(struct wiphy *wiphy, struct net_device
*dev,
}
if (sel_bssi_idx < last_scanned_cnt) {
-
[PATCH 05/10] staging: wilc1000: fix line over 80 char in change_virtual_intf()
Fix 'line over 80 char' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 1f6c02a..3354bf2 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1804,7 +1804,8 @@ static int set_power_mgmt(struct wiphy *wiphy, struct
net_device *dev,
}
static int change_virtual_intf(struct wiphy *wiphy, struct net_device *dev,
- enum nl80211_iftype type, struct vif_params
*params)
+ enum nl80211_iftype type,
+ struct vif_params *params)
{
struct wilc_priv *priv;
struct wilc_vif *vif;
@@ -1828,7 +1829,8 @@ static int change_virtual_intf(struct wiphy *wiphy,
struct net_device *dev,
vif->iftype = STATION_MODE;
wilc_set_operation_mode(vif, STATION_MODE);
- memset(priv->assoc_stainfo.sta_associated_bss, 0, MAX_NUM_STA *
ETH_ALEN);
+ memset(priv->assoc_stainfo.sta_associated_bss, 0,
+ MAX_NUM_STA * ETH_ALEN);
wilc_enable_ps = true;
wilc_set_power_mgmt(vif, 1, 0);
--
2.7.4
[PATCH 06/10] staging: wilc1000: fix line over 80 char in get_key() & set_default_key()
Fix 'line over 80 characters' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 3354bf2..92c3213 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1118,8 +1118,8 @@ static int del_key(struct wiphy *wiphy, struct net_device
*netdev,
}
static int get_key(struct wiphy *wiphy, struct net_device *netdev, u8
key_index,
- bool pairwise,
- const u8 *mac_addr, void *cookie, void (*callback)(void
*cookie, struct key_params *))
+ bool pairwise, const u8 *mac_addr, void *cookie,
+ void (*callback)(void *cookie, struct key_params *))
{
struct wilc_priv *priv;
struct key_params key_params;
@@ -1145,8 +1145,8 @@ static int get_key(struct wiphy *wiphy, struct net_device
*netdev, u8 key_index,
return 0;
}
-static int set_default_key(struct wiphy *wiphy, struct net_device *netdev, u8
key_index,
- bool unicast, bool multicast)
+static int set_default_key(struct wiphy *wiphy, struct net_device *netdev,
+ u8 key_index, bool unicast, bool multicast)
{
struct wilc_priv *priv;
struct wilc_vif *vif;
--
2.7.4
[PATCH 07/10] staging: wilc1000: fix line over 80 char for cfg parse RX and TX function
Fix 'line over 80 characters' issue found by checkpatch.pl script. Moved
the common code from wilc_wfi_cfg_parse_tx_action() &
wilc_wfi_cfg_parse_rx_action() to new function to avoid checkpatch issue.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 67 +++
1 file changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 92c3213..911af68 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1337,10 +1337,33 @@ static int flush_pmksa(struct wiphy *wiphy, struct
net_device *netdev)
return 0;
}
+static inline void wilc_wfi_cfg_parse_ch_attr(u8 *buf, u8 ch_list_attr_idx,
+ u8 op_ch_attr_idx)
+{
+ int i = 0;
+ int j = 0;
+
+ if (ch_list_attr_idx) {
+ u8 limit = ch_list_attr_idx + 3 + buf[ch_list_attr_idx + 1];
+
+ for (i = ch_list_attr_idx + 3; i < limit; i++) {
+ if (buf[i] == 0x51) {
+ for (j = i + 2; j < ((i + 2) + buf[i + 1]); j++)
+ buf[j] = wlan_channel;
+ break;
+ }
+ }
+ }
+
+ if (op_ch_attr_idx) {
+ buf[op_ch_attr_idx + 6] = 0x51;
+ buf[op_ch_attr_idx + 7] = wlan_channel;
+ }
+}
+
static void wilc_wfi_cfg_parse_rx_action(u8 *buf, u32 len)
{
u32 index = 0;
- u32 i = 0, j = 0;
u8 op_channel_attr_index = 0;
u8 channel_list_attr_index = 0;
@@ -1355,28 +1378,15 @@ static void wilc_wfi_cfg_parse_rx_action(u8 *buf, u32
len)
op_channel_attr_index = index;
index += buf[index + 1] + 3;
}
- if (wlan_channel != INVALID_CHANNEL) {
- if (channel_list_attr_index) {
- for (i = channel_list_attr_index + 3; i <
((channel_list_attr_index + 3) + buf[channel_list_attr_index + 1]); i++) {
- if (buf[i] == 0x51) {
- for (j = i + 2; j < ((i + 2) + buf[i +
1]); j++)
- buf[j] = wlan_channel;
- break;
- }
- }
- }
-
- if (op_channel_attr_index) {
- buf[op_channel_attr_index + 6] = 0x51;
- buf[op_channel_attr_index + 7] = wlan_channel;
- }
- }
+ if (wlan_channel != INVALID_CHANNEL)
+ wilc_wfi_cfg_parse_ch_attr(buf, channel_list_attr_index,
+ op_channel_attr_index);
}
-static void wilc_wfi_cfg_parse_tx_action(u8 *buf, u32 len, bool oper_ch, u8
iftype)
+static void wilc_wfi_cfg_parse_tx_action(u8 *buf, u32 len, bool oper_ch,
+u8 iftype)
{
u32 index = 0;
- u32 i = 0, j = 0;
u8 op_channel_attr_index = 0;
u8 channel_list_attr_index = 0;
@@ -1394,22 +1404,9 @@ static void wilc_wfi_cfg_parse_tx_action(u8 *buf, u32
len, bool oper_ch, u8 ifty
op_channel_attr_index = index;
index += buf[index + 1] + 3;
}
- if (wlan_channel != INVALID_CHANNEL && oper_ch) {
- if (channel_list_attr_index) {
- for (i = channel_list_attr_index + 3; i <
((channel_list_attr_index + 3) + buf[channel_list_attr_index + 1]); i++) {
- if (buf[i] == 0x51) {
- for (j = i + 2; j < ((i + 2) + buf[i +
1]); j++)
- buf[j] = wlan_channel;
- break;
- }
- }
- }
-
- if (op_channel_attr_index) {
- buf[op_channel_attr_index + 6] = 0x51;
- buf[op_channel_attr_index + 7] = wlan_channel;
- }
- }
+ if (wlan_channel != INVALID_CHANNEL && oper_ch)
+ wilc_wfi_cfg_parse_ch_attr(buf, channel_list_attr_index,
+ op_channel_attr_index);
}
void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, u32 size)
--
2.7.4
[PATCH 01/10] staging: wilc1000: rename strHiddenNetwork to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 205304c..dd7ab51 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -584,7 +584,7 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
u32 i;
s32 ret = 0;
u8 au8ScanChanList[MAX_NUM_SCANNED_NETWORKS];
- struct hidden_network strHiddenNetwork;
+ struct hidden_network hidden_ntwk;
struct wilc_vif *vif;
priv = wiphy_priv(wiphy);
@@ -602,21 +602,21 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
au8ScanChanList[i] =
(u8)ieee80211_frequency_to_channel(request->channels[i]->center_freq);
if (request->n_ssids >= 1) {
- strHiddenNetwork.net_info =
+ hidden_ntwk.net_info =
kmalloc_array(request->n_ssids,
sizeof(struct hidden_network),
GFP_KERNEL);
- if (!strHiddenNetwork.net_info)
+ if (!hidden_ntwk.net_info)
return -ENOMEM;
- strHiddenNetwork.n_ssids = request->n_ssids;
+ hidden_ntwk.n_ssids = request->n_ssids;
for (i = 0; i < request->n_ssids; i++) {
if (request->ssids[i].ssid_len != 0) {
- strHiddenNetwork.net_info[i].ssid =
kmalloc(request->ssids[i].ssid_len, GFP_KERNEL);
-
memcpy(strHiddenNetwork.net_info[i].ssid, request->ssids[i].ssid,
request->ssids[i].ssid_len);
- strHiddenNetwork.net_info[i].ssid_len =
request->ssids[i].ssid_len;
+ hidden_ntwk.net_info[i].ssid =
kmalloc(request->ssids[i].ssid_len, GFP_KERNEL);
+ memcpy(hidden_ntwk.net_info[i].ssid,
request->ssids[i].ssid, request->ssids[i].ssid_len);
+ hidden_ntwk.net_info[i].ssid_len =
request->ssids[i].ssid_len;
} else {
- strHiddenNetwork.n_ssids -= 1;
+ hidden_ntwk.n_ssids -= 1;
}
}
ret = wilc_scan(vif, USER_SCAN, ACTIVE_SCAN,
@@ -624,7 +624,7 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
request->n_channels,
(const u8 *)request->ie,
request->ie_len, CfgScanResult,
- (void *)priv, &strHiddenNetwork);
+ (void *)priv, &hidden_ntwk);
} else {
ret = wilc_scan(vif, USER_SCAN, ACTIVE_SCAN,
au8ScanChanList,
--
2.7.4
[PATCH 00/10] staging: wilc1000: fixes related to camelCase & line over 80 chars
Patch series contains fixes to remove checkpatch reported warnings. Ajay Singh (10): staging: wilc1000: rename strHiddenNetwork to avoid camelCase staging: wilc1000: rename pstrNetworkInfo to avoid camelCase staging: wilc1000: rename CfgScanResult to avoid camelCase staging: wilc1000: rename au8ScanChanList to avoid camelCase staging: wilc1000: fix line over 80 char in change_virtual_intf() staging: wilc1000: fix line over 80 char in get_key() & set_default_key() staging: wilc1000: fix line over 80 char for cfg parse RX and TX function staging: wilc1000: fix line over 80 char in mgmt_tx_cancel_wait() staging: wilc1000: rename pJoinParams to avoid camelCase staging: wilc1000: fix line over 80 char in cfg_scan_result() drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 329 +++--- 1 file changed, 168 insertions(+), 161 deletions(-) -- 2.7.4
[PATCH 09/10] staging: wilc1000: rename pJoinParams to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a93c550..9da686b 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -315,7 +315,7 @@ static int is_network_in_shadow(struct network_info
*nw_info, void *user_void)
}
static void add_network_to_shadow(struct network_info *nw_info,
- void *user_void, void *pJoinParams)
+ void *user_void, void *join_params)
{
int ap_found = is_network_in_shadow(nw_info, user_void);
u32 ap_index = 0;
@@ -360,7 +360,7 @@ static void add_network_to_shadow(struct network_info
*nw_info,
last_scanned_shadow[ap_index].found = 1;
if (ap_found != -1)
kfree(last_scanned_shadow[ap_index].join_params);
- last_scanned_shadow[ap_index].join_params = pJoinParams;
+ last_scanned_shadow[ap_index].join_params = join_params;
}
static void cfg_scan_result(enum scan_event scan_event,
--
2.7.4
[PATCH 10/10] staging: wilc1000: fix line over 80 char in cfg_scan_result()
Refactor cfg_scan_result() API to avoid 'line over 80 chars' issue
reported by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 148 +++---
1 file changed, 77 insertions(+), 71 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 9da686b..5395648 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -374,91 +374,97 @@ static void cfg_scan_result(enum scan_event scan_event,
struct cfg80211_bss *bss = NULL;
priv = user_void;
- if (priv->cfg_scanning) {
- if (scan_event == SCAN_EVENT_NETWORK_FOUND) {
- wiphy = priv->dev->ieee80211_ptr->wiphy;
+ if (!priv->cfg_scanning)
+ return;
+
+ if (scan_event == SCAN_EVENT_NETWORK_FOUND) {
+ wiphy = priv->dev->ieee80211_ptr->wiphy;
+
+ if (!wiphy || !network_info)
+ return;
- if (!wiphy)
+ if (wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
+ (((s32)network_info->rssi * 100) < 0 ||
+ ((s32)network_info->rssi * 100) > 100))
+ return;
+
+ s32Freq = ieee80211_channel_to_frequency((s32)network_info->ch,
+NL80211_BAND_2GHZ);
+ channel = ieee80211_get_channel(wiphy, s32Freq);
+
+ if (!channel)
+ return;
+
+ if (network_info->new_network) {
+ if (priv->rcvd_ch_cnt >= MAX_NUM_SCANNED_NETWORKS)
return;
- if (wiphy->signal_type == CFG80211_SIGNAL_TYPE_UNSPEC &&
- (((s32)network_info->rssi * 100) < 0 ||
- ((s32)network_info->rssi * 100) > 100))
+ priv->rcvd_ch_cnt++;
+
+ add_network_to_shadow(network_info, priv, join_params);
+
+ if (memcmp("DIRECT-", network_info->ssid, 7))
return;
- if (network_info) {
- s32Freq =
ieee80211_channel_to_frequency((s32)network_info->ch, NL80211_BAND_2GHZ);
- channel = ieee80211_get_channel(wiphy, s32Freq);
-
- if (!channel)
- return;
-
- if (network_info->new_network) {
- if (priv->rcvd_ch_cnt <
MAX_NUM_SCANNED_NETWORKS) {
- priv->rcvd_ch_cnt++;
-
-
add_network_to_shadow(network_info, priv, join_params);
-
- if (!(memcmp("DIRECT-",
network_info->ssid, 7))) {
- bss =
cfg80211_inform_bss(wiphy,
-
channel,
-
CFG80211_BSS_FTYPE_UNKNOWN,
-
network_info->bssid,
-
network_info->tsf_hi,
-
network_info->cap_info,
-
network_info->beacon_period,
-
(const u8 *)network_info->ies,
-
(size_t)network_info->ies_len,
-
(s32)network_info->rssi * 100,
-
GFP_KERNEL);
- cfg80211_put_bss(wiphy,
bss);
- }
- }
- } else {
- u32 i;
+ bss = cfg80211_inform_bss(wiphy,
+ channel,
+ CFG80211_BSS_FTYPE_UNKNOWN,
+ network_info->bssid,
+ network_info->tsf_hi,
+ network_info->cap_info,
+ network_info->beacon_period,
+
pull-request: wireless-drivers 2018-03-08
Hi Dave, here's a pull requsest to net tree for 4.16. Since the merge window I have had some clannges to keep up with some patches but catching up now. There should be nothing special here but please let me know if you have any problems. Kalle The following changes since commit 7ac8ff95f48cbfa609a060fd6a1e361dd62feeb3: mvpp2: fix multicast address filter (2018-02-11 22:37:04 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2018-03-08 for you to fetch changes up to 455f3e76cfc0d893585a5f358b9ddbe9c1e1e53b: brcmfmac: fix P2P_DEVICE ethernet address generation (2018-03-07 16:36:41 +0200) wireless-drivers fixes for 4.16 Quote a few fixes as I have not been able to send a pull request earlier. Most of the fixes for iwlwifi but also few others, nothing really standing out though. iwlwifi * fix a bogus warning when freeing a TFD * fix severe throughput problem with 9000 series * fix for a bug that caused queue hangs in certain situations * fix for an issue with IBSS * fix an issue with rate-scaling in AP-mode * fix Channel Switch Announcement (CSA) issues with count 0 and 1 * some firmware debugging fixes * remov a wrong error message when removing keys * fix a firmware sysassert most usually triggered in IBSS * a couple of fixes on multicast queues * a fix with CCMP 256 rtlwifi * fix loss of signal for rtl8723be brcmfmac * add possibility to obtain firmware error * fix P2P_DEVICE ethernet address generation Andrei Otcheretianski (1): iwlwifi: mvm: Fix channel switch for count 0 and 1 Arend Van Spriel (2): brcmfmac: add possibility to obtain firmware error brcmfmac: fix P2P_DEVICE ethernet address generation Emmanuel Grumbach (1): iwlwifi: pcie: don't warn if we use all the transmit pointers Haim Dreyfuss (1): iwlwifi: Cancel and set MARKER_CMD timer during suspend-resume Ilan Peer (2): iwlwifi: mvm: Direct multicast frames to the correct station iwlwifi: mvm: Correctly set the tid for mcast queue Kalle Valo (2): Merge tag 'iwlwifi-for-kalle-2018-02-16-2' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Merge tag 'iwlwifi-for-kalle-2018-03-02' of git://git.kernel.org/.../iwlwifi/iwlwifi-fixes Larry Finger (1): rtlwifi: rtl8723be: Fix loss of signal Naftali Goldstein (1): iwlwifi: mvm: always init rs with 20mhz bandwidth rates Sara Sharon (5): iwlwifi: mvm: fix security bug in PN checking iwlwifi: mvm: fix IBSS for devices that support station type API iwlwifi: mvm: fix TX of CCMP 256 iwlwifi: mvm: fix assert 0x2B00 on older FWs iwlwifi: mvm: fix "failed to remove key" message Shaul Triebitz (2): iwlwifi: align timestamp cancel with timestamp start iwlwifi: avoid collecting firmware dump if not loaded Ulf Magnusson (1): iwlwifi: fix malformed CONFIG_IWLWIFI_PCIE_RTPM default .../wireless/broadcom/brcm80211/brcmfmac/core.h| 2 + .../wireless/broadcom/brcm80211/brcmfmac/feature.c | 10 + .../wireless/broadcom/brcm80211/brcmfmac/fwil.c| 3 ++ .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 24 +-- drivers/net/wireless/intel/iwlwifi/Kconfig | 1 - .../net/wireless/intel/iwlwifi/fw/api/time-event.h | 4 +- drivers/net/wireless/intel/iwlwifi/fw/dbg.c| 13 +- drivers/net/wireless/intel/iwlwifi/fw/dbg.h| 3 ++ drivers/net/wireless/intel/iwlwifi/fw/debugfs.h| 18 drivers/net/wireless/intel/iwlwifi/fw/init.c | 12 -- drivers/net/wireless/intel/iwlwifi/fw/runtime.h| 7 drivers/net/wireless/intel/iwlwifi/mvm/d3.c| 8 drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 5 +-- drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 3 +- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 49 +- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 + drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 10 - drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 28 + drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 39 - drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 33 --- .../net/wireless/intel/iwlwifi/mvm/time-event.c| 6 ++- drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 13 -- drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 2 +- .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c| 3 +- 25 files changed, 212 insertions(+), 88 deletions(-)
[PATCH 04/10] staging: wilc1000: rename au8ScanChanList to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 051ba12..1f6c02a 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -581,7 +581,7 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
struct wilc_priv *priv;
u32 i;
s32 ret = 0;
- u8 au8ScanChanList[MAX_NUM_SCANNED_NETWORKS];
+ u8 scan_ch_list[MAX_NUM_SCANNED_NETWORKS];
struct hidden_network hidden_ntwk;
struct wilc_vif *vif;
@@ -597,7 +597,7 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
priv->cfg_scanning = true;
if (request->n_channels <= MAX_NUM_SCANNED_NETWORKS) {
for (i = 0; i < request->n_channels; i++)
- au8ScanChanList[i] =
(u8)ieee80211_frequency_to_channel(request->channels[i]->center_freq);
+ scan_ch_list[i] =
(u8)ieee80211_frequency_to_channel(request->channels[i]->center_freq);
if (request->n_ssids >= 1) {
hidden_ntwk.net_info =
@@ -618,14 +618,14 @@ static int scan(struct wiphy *wiphy, struct
cfg80211_scan_request *request)
}
}
ret = wilc_scan(vif, USER_SCAN, ACTIVE_SCAN,
- au8ScanChanList,
+ scan_ch_list,
request->n_channels,
(const u8 *)request->ie,
request->ie_len, cfg_scan_result,
(void *)priv, &hidden_ntwk);
} else {
ret = wilc_scan(vif, USER_SCAN, ACTIVE_SCAN,
- au8ScanChanList,
+ scan_ch_list,
request->n_channels,
(const u8 *)request->ie,
request->ie_len, cfg_scan_result,
--
2.7.4
[PATCH 08/10] staging: wilc1000: fix line over 80 char in mgmt_tx_cancel_wait()
Fix 'line over 80 char' issue found in checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 911af68..a93c550 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1705,9 +1705,13 @@ static int mgmt_tx_cancel_wait(struct wiphy *wiphy,
wfi_drv->p2p_timeout = jiffies;
if (!priv->p2p_listen_state) {
+ struct wilc_wfi_p2p_listen_params *params;
+
+ params = &priv->remain_on_ch_params;
+
cfg80211_remain_on_channel_expired(priv->wdev,
-
priv->remain_on_ch_params.listen_cookie,
-
priv->remain_on_ch_params.listen_ch,
+ params->listen_cookie,
+ params->listen_ch,
GFP_KERNEL);
}
--
2.7.4
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
Am 08.03.2018 um 16:04 schrieb Pavel Machek: Hi! show me a proof that its copy & paste. because its not I don't have to prove you anything. Sorry. then i will deny your argument because its false. But you said: see ath9k. its exact the same implementation. We don't want to have exact same code multiple times in the tree. it isnt the exact same code, its just the way its done. i mean registering a led driver function happens multiple times in the kernel you cannot say that calling led_classdev_register with the required parameters and function implementation is a case of code duplication. then i would just say using of "printk" is a case of code duplication. registering a led driver is nothing unusual, the implementation of the led driver is different each time. the implementation for led_brightness is very different there are many led drivers in the kernel. all are going the same way. i checked the kernel drivers just right now. almost all major wireless drivers are comming with a led driver without using gpiolib your way is a case of codebloating since a registering gpio-leds requires a gpio driver for each wireless driver, even if its sometimes just a single register write for a led and no real gpio. a gpio driver is more complex and bigger than just a led driver. i just wrote a optional gpio driver to get access to all gpios available on the card. some vendors are using these in a unusual way i have seen that vendors used them for reset button input etc. this is why i made it. so dont take this as a argument for going a impossible way (again. the kernel does not support multiple platform datas with the same name THE KERNEL not leds-gpio. so once a leds-gpio platform data is registered, no other driver can register a new one. in addition the kernel must have gpiolib support which increases the kernel size. the best way is always the most simple way and the smallest performant way. and again. i did not duplicate the code of ath9k, i just used it as documentation to write a own led driver in a simple way now a list of wireless drivers with a led driver intersil carl9170 ath5k rt2x00 b43legacy b43 iwlegacy rtl8187 brcmsmac iwlwifi Sebastian Pavel -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [PATCH v12] ath10k: add LED and GPIO controlling support for various chipsets
On 2018-03-08 15:05, Pavel Machek wrote:
> On Thu 2018-03-08 13:33:29, Sebastian Gottschall wrote:
>> Am 08.03.2018 um 10:02 schrieb Pavel Machek:
>> >On Wed 2018-03-07 18:54:41, Sebastian Gottschall wrote:
>> >>Am 07.03.2018 um 17:22 schrieb Rafał Miłecki:
>> >>>On 2 March 2018 at 10:22, Sebastian Gottschall
>> >>>wrote:
>> >>leds-gpio is crap and limited. you can just register one platform data
>> >>at
>> >>kernel runtime since its identified by its object name "led-gpio" but
>> >>the
>> >>kernel forbidds to register 2 platform datas with the same name
>> >>consider the ar71xx devices with qca988x wifi chipsets. they all have
>> >>already a led platform data registered
>> >>at boottime. a second can't be registered anymore so gpio_led is
>> >>useless
>> >>at
>> >>all for most developers on such platforms. its mainly used for early
>> >>kernel
>> >>platform data initialisation for system leds.
>> >If leds-gpio has limitations, please fix those, rather then
>> >introducing duplicated code.
>> there is no duplicated code introduced and there is no solution for it.
>> consider that all wifi drivers with softled support
>> are going that way with registering a own led driver. see ath9k for
>> instance. gpio-led cannot be used for it and there is no way to
>> support multiple platform datas with the same name. its a kernel
>> limitation
>> >>>I just reviewed some mips arch patch adding support for more LEDs for
>> >>>selected devices:
>> >>>[PATCH] MIPS: BCM47XX: Add Luxul XAP1500/XWR1750 WiFi LEDs
>> >>>https://patchwork.linux-mips.org/patch/18681/
>> >>>
>> >>>It seems to be simply adding another call to the
>> >>>gpio_led_register_device(). It seems to me you can call that function
>> >>>multiple times and register multiple structs with LEDs.
>> >>>
>> >>>Isn't all you need something like this?
>> >>>
>> >>>static const struct gpio_led ath10k_leds[] = {
>> >>> {
>> >>> .name = "ath10k:color:function",
>> >>> .active_low = 1,
>> >>> .default_state = LEDS_GPIO_DEFSTATE_KEEP,
>> >>> }
>> >>>};
>> >>>
>> >>>static struct gpio_led_platform_data bcm47xx_leds_pdata_extra = {
>> >>> leds = ath10k_leds;
>> >>> num_leds = ARRAY_SIZE(ath10k_leds);
>> >>>};
>> >>>
>> >>>ath10k_leds.gpio = ar->hw_params.led_pin;
>> >>>gpio_led_register_device(0, &ath10k_leds);
>> >>the problem are other architectures which have already registered gpio_led
>> >>at system start like ar71xx
>> >>you cannot register a second one. so a independend led driver is a
>> >>requirement for direct control
>> >If the limitation indeed exists, please fix the limitation rather than
>> >working around it in each and every driver.
>> see ath9k. its exact the same implementation.
>
> Ok, so one more driver to fix.
>
>> in addition my variant does also work without gpiolib support. so it can be
>> used even if the kernel is configured
>> without gpio support.
>> and not to forget, using a own led driver is more ligthweight from the call
>> path for each led on / off event which is important for
>> low performance embedded devices
>
> We are not going to copy&paste code because such code works without
> libraries, and we are not going to copy&paste code because that uses
> less cache during calls. Sorry.
>
> NAK. Please fix your patch. Since this discussion seems to have taken a
> rather weird turn, I've
taken a look at the specific code, and from my point of view the code
that sets up the LED (including callback) is so trivial that it's simply
not worth dealing with adding the leds-gpio driver to the mix.
It adds extra complexity and an extra dependency for no reason at all.
There's no extra functionality to be gained by using it.
- Felix
[PATCH 02/10] staging: wilc1000: rename strConnectInfo to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 56 +++
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 41fed8c..e3ef7b8 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1134,32 +1134,32 @@ static s32 handle_connect(struct wilc_vif *vif,
ERRORHANDLER:
if (result) {
- struct connect_info strConnectInfo;
+ struct connect_info conn_info;
del_timer(&hif_drv->connect_timer);
- memset(&strConnectInfo, 0, sizeof(struct connect_info));
+ memset(&conn_info, 0, sizeof(struct connect_info));
if (conn_attr->result) {
if (conn_attr->bssid)
- memcpy(strConnectInfo.bssid, conn_attr->bssid,
6);
+ memcpy(conn_info.bssid, conn_attr->bssid, 6);
if (conn_attr->ies) {
- strConnectInfo.req_ies_len = conn_attr->ies_len;
- strConnectInfo.req_ies =
kmalloc(conn_attr->ies_len, GFP_KERNEL);
- memcpy(strConnectInfo.req_ies,
+ conn_info.req_ies_len = conn_attr->ies_len;
+ conn_info.req_ies = kmalloc(conn_attr->ies_len,
GFP_KERNEL);
+ memcpy(conn_info.req_ies,
conn_attr->ies,
conn_attr->ies_len);
}
conn_attr->result(CONN_DISCONN_EVENT_CONN_RESP,
- &strConnectInfo,
+ &conn_info,
MAC_DISCONNECTED,
NULL,
conn_attr->arg);
hif_drv->hif_state = HOST_IF_IDLE;
- kfree(strConnectInfo.req_ies);
- strConnectInfo.req_ies = NULL;
+ kfree(conn_info.req_ies);
+ conn_info.req_ies = NULL;
} else {
netdev_err(vif->ndev, "Connect callback is NULL\n");
@@ -1343,7 +1343,7 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif
*vif,
u8 u8MacStatus;
u8 u8MacStatusReasonCode;
u8 u8MacStatusAdditionalInfo;
- struct connect_info strConnectInfo;
+ struct connect_info conn_info;
struct disconnect_info disconn_info;
s32 s32Err = 0;
struct host_if_drv *hif_drv = vif->hif_drv;
@@ -1380,7 +1380,7 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif
*vif,
u32 u32RcvdAssocRespInfoLen = 0;
struct connect_resp_info *pstrConnectRespInfo = NULL;
- memset(&strConnectInfo, 0, sizeof(struct connect_info));
+ memset(&conn_info, 0, sizeof(struct connect_info));
if (u8MacStatus == MAC_CONNECTED) {
memset(rcv_assoc_resp, 0,
MAX_ASSOC_RESP_FRAME_SIZE);
@@ -1396,12 +1396,12 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif
*vif,
if (s32Err) {
netdev_err(vif->ndev,
"wilc_parse_assoc_resp_info() returned error %d\n", s32Err);
} else {
- strConnectInfo.status =
pstrConnectRespInfo->status;
+ conn_info.status =
pstrConnectRespInfo->status;
- if (strConnectInfo.status ==
SUCCESSFUL_STATUSCODE && pstrConnectRespInfo->ies) {
-
strConnectInfo.resp_ies_len = pstrConnectRespInfo->ies_len;
- strConnectInfo.resp_ies
= kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
-
memcpy(strConnectInfo.resp_ies, pstrConnectRespInfo->ies,
+ if (conn_info.status ==
SUCCESSFUL_STATUSCODE && pstrConnectRespInfo->ies) {
+ conn_info.resp_ies_len
= pstrConnectRespInfo->ies_len;
+ conn_info.resp_ies =
kmalloc(pstrConnectRespInfo->ies_len, GFP_KERNEL);
+
memcpy(conn_info.resp_ies, pstrConnectRespInfo
[PATCH 00/10] staging: wilc1000: fixes for checkpatch issues & coding style related
This patch series contains modification to remove the checkpatch warnings and changes to follow linux coding style. Ajay Singh (10): staging: wilc1000: rename pstrHostIFconnectAttr to avoid camelCase issue staging: wilc1000: rename strConnectInfo to avoid camelCase staging: wilc1000: rename label 'ERRORHANDLER' to avoid uppercase name staging: wilc1000: fix line over 80 char in handle_scan() staging: wilc1000: fix line over 80 char in handle_connect() staging: wilc1000: fix line over 80 character in handle_disconnect() staging: wilc1000: rename variables prefix using datatype 'u8' staging: wilc1000: rename WILC_HostIf_PackStaParam to avoid camelCase staging: wilc1000: rename variables using camelCase in handle_rcvd_gnrl_async_info() staging: wilc1000: fix line over 80 char issue in handle_scan_done() drivers/staging/wilc1000/coreconfigurator.c | 28 +- drivers/staging/wilc1000/host_interface.c | 580 ++-- 2 files changed, 308 insertions(+), 300 deletions(-) -- 2.7.4
[PATCH 01/10] staging: wilc1000: rename pstrHostIFconnectAttr to avoid camelCase issue
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 104 +++---
1 file changed, 52 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index a4ee175..41fed8c 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -917,7 +917,7 @@ static s32 handle_scan_done(struct wilc_vif *vif, enum
scan_event evt)
u8 wilc_connected_ssid[6] = {0};
static s32 handle_connect(struct wilc_vif *vif,
- struct connect_attr *pstrHostIFconnectAttr)
+ struct connect_attr *conn_attr)
{
s32 result = 0;
struct wid wid_list[8];
@@ -926,45 +926,45 @@ static s32 handle_connect(struct wilc_vif *vif,
struct join_bss_param *bss_param;
struct host_if_drv *hif_drv = vif->hif_drv;
- if (memcmp(pstrHostIFconnectAttr->bssid, wilc_connected_ssid, ETH_ALEN)
== 0) {
+ if (memcmp(conn_attr->bssid, wilc_connected_ssid, ETH_ALEN) == 0) {
result = 0;
netdev_err(vif->ndev, "Discard connect request\n");
return result;
}
- bss_param = pstrHostIFconnectAttr->params;
+ bss_param = conn_attr->params;
if (!bss_param) {
netdev_err(vif->ndev, "Required BSSID not found\n");
result = -ENOENT;
goto ERRORHANDLER;
}
- if (pstrHostIFconnectAttr->bssid) {
+ if (conn_attr->bssid) {
hif_drv->usr_conn_req.bssid = kmalloc(6, GFP_KERNEL);
- memcpy(hif_drv->usr_conn_req.bssid,
pstrHostIFconnectAttr->bssid, 6);
+ memcpy(hif_drv->usr_conn_req.bssid, conn_attr->bssid, 6);
}
- hif_drv->usr_conn_req.ssid_len = pstrHostIFconnectAttr->ssid_len;
- if (pstrHostIFconnectAttr->ssid) {
- hif_drv->usr_conn_req.ssid =
kmalloc(pstrHostIFconnectAttr->ssid_len + 1, GFP_KERNEL);
+ hif_drv->usr_conn_req.ssid_len = conn_attr->ssid_len;
+ if (conn_attr->ssid) {
+ hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
GFP_KERNEL);
memcpy(hif_drv->usr_conn_req.ssid,
- pstrHostIFconnectAttr->ssid,
- pstrHostIFconnectAttr->ssid_len);
- hif_drv->usr_conn_req.ssid[pstrHostIFconnectAttr->ssid_len] =
'\0';
+ conn_attr->ssid,
+ conn_attr->ssid_len);
+ hif_drv->usr_conn_req.ssid[conn_attr->ssid_len] = '\0';
}
- hif_drv->usr_conn_req.ies_len = pstrHostIFconnectAttr->ies_len;
- if (pstrHostIFconnectAttr->ies) {
- hif_drv->usr_conn_req.ies =
kmalloc(pstrHostIFconnectAttr->ies_len, GFP_KERNEL);
+ hif_drv->usr_conn_req.ies_len = conn_attr->ies_len;
+ if (conn_attr->ies) {
+ hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
GFP_KERNEL);
memcpy(hif_drv->usr_conn_req.ies,
- pstrHostIFconnectAttr->ies,
- pstrHostIFconnectAttr->ies_len);
+ conn_attr->ies,
+ conn_attr->ies_len);
}
- hif_drv->usr_conn_req.security = pstrHostIFconnectAttr->security;
- hif_drv->usr_conn_req.auth_type = pstrHostIFconnectAttr->auth_type;
- hif_drv->usr_conn_req.conn_result = pstrHostIFconnectAttr->result;
- hif_drv->usr_conn_req.arg = pstrHostIFconnectAttr->arg;
+ hif_drv->usr_conn_req.security = conn_attr->security;
+ hif_drv->usr_conn_req.auth_type = conn_attr->auth_type;
+ hif_drv->usr_conn_req.conn_result = conn_attr->result;
+ hif_drv->usr_conn_req.arg = conn_attr->arg;
wid_list[wid_cnt].id = WID_SUCCESS_FRAME_COUNT;
wid_list[wid_cnt].type = WID_INT;
@@ -991,7 +991,7 @@ static s32 handle_connect(struct wilc_vif *vif,
wid_list[wid_cnt].size = hif_drv->usr_conn_req.ies_len;
wid_cnt++;
- if (memcmp("DIRECT-", pstrHostIFconnectAttr->ssid, 7)) {
+ if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
info_element_size = hif_drv->usr_conn_req.ies_len;
info_element = kmalloc(info_element_size, GFP_KERNEL);
memcpy(info_element, hif_drv->usr_conn_req.ies,
@@ -1004,7 +1004,7 @@ static s32 handle_connect(struct wilc_vif *vif,
wid_list[wid_cnt].val = (s8 *)&hif_drv->usr_conn_req.security;
wid_cnt++;
- if (memcmp("DIRECT-", pstrHostIFconnectAttr->ssid, 7))
+ if (memcmp("DIRECT-", conn_attr->ssid, 7))
mode_11i = hif_drv->usr_conn_req.security;
wid_list[wid_cnt].id = (u16)WID_AUTH_TYPE;
@@ -1013,7 +1013,7 @@ static s32 handle_connect(struct wilc_vif *vif,
wid_list[wid_cnt].val = (s8 *)&hif_drv->usr_co
[PATCH 03/10] staging: wilc1000: rename label 'ERRORHANDLER' to avoid uppercase name
Cleanup patch to avoid use of uppercase for label names, to follow linux
coding style.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 54 +++
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index e3ef7b8..d0c17cd 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -779,13 +779,13 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
hif_drv->hif_state < HOST_IF_CONNECTED) {
netdev_err(vif->ndev, "Already scan\n");
result = -EBUSY;
- goto ERRORHANDLER;
+ goto error;
}
if (wilc_optaining_ip || wilc_connecting) {
netdev_err(vif->ndev, "Don't do obss scan\n");
result = -EBUSY;
- goto ERRORHANDLER;
+ goto error;
}
hif_drv->usr_scan_req.rcvd_ch_cnt = 0;
@@ -859,7 +859,7 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
if (result)
netdev_err(vif->ndev, "Failed to send scan parameters\n");
-ERRORHANDLER:
+error:
if (result) {
del_timer(&hif_drv->scan_timer);
handle_scan_done(vif, SCAN_EVENT_ABORTED);
@@ -936,7 +936,7 @@ static s32 handle_connect(struct wilc_vif *vif,
if (!bss_param) {
netdev_err(vif->ndev, "Required BSSID not found\n");
result = -ENOENT;
- goto ERRORHANDLER;
+ goto error;
}
if (conn_attr->bssid) {
@@ -1027,7 +1027,7 @@ static s32 handle_connect(struct wilc_vif *vif,
}
if (!wid_list[wid_cnt].val) {
result = -EFAULT;
- goto ERRORHANDLER;
+ goto error;
}
cur_byte = wid_list[wid_cnt].val;
@@ -1127,12 +1127,12 @@ static s32 handle_connect(struct wilc_vif *vif,
if (result) {
netdev_err(vif->ndev, "failed to send config packet\n");
result = -EFAULT;
- goto ERRORHANDLER;
+ goto error;
} else {
hif_drv->hif_state = HOST_IF_WAITING_CONN_RESP;
}
-ERRORHANDLER:
+error:
if (result) {
struct connect_info conn_info;
@@ -2010,7 +2010,7 @@ static void handle_add_beacon(struct wilc_vif *vif,
struct beacon_attr *param)
wid.size = param->head_len + param->tail_len + 16;
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
- goto ERRORHANDLER;
+ goto error;
cur_byte = wid.val;
*cur_byte++ = (param->interval & 0xFF);
@@ -2045,7 +2045,7 @@ static void handle_add_beacon(struct wilc_vif *vif,
struct beacon_attr *param)
if (result)
netdev_err(vif->ndev, "Failed to send add beacon\n");
-ERRORHANDLER:
+error:
kfree(wid.val);
kfree(param->head);
kfree(param->tail);
@@ -2117,7 +2117,7 @@ static void handle_add_station(struct wilc_vif *vif,
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
- goto ERRORHANDLER;
+ goto error;
cur_byte = wid.val;
cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
@@ -2127,7 +2127,7 @@ static void handle_add_station(struct wilc_vif *vif,
if (result != 0)
netdev_err(vif->ndev, "Failed to send add station\n");
-ERRORHANDLER:
+error:
kfree(param->rates);
kfree(wid.val);
}
@@ -2147,7 +2147,7 @@ static void handle_del_all_sta(struct wilc_vif *vif,
wid.val = kmalloc((param->assoc_sta * ETH_ALEN) + 1, GFP_KERNEL);
if (!wid.val)
- goto ERRORHANDLER;
+ goto error;
curr_byte = wid.val;
@@ -2167,7 +2167,7 @@ static void handle_del_all_sta(struct wilc_vif *vif,
if (result)
netdev_err(vif->ndev, "Failed to send add station\n");
-ERRORHANDLER:
+error:
kfree(wid.val);
complete(&hif_wait_response);
@@ -2185,7 +2185,7 @@ static void handle_del_station(struct wilc_vif *vif,
struct del_sta *param)
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
- goto ERRORHANDLER;
+ goto error;
cur_byte = wid.val;
@@ -2196,7 +2196,7 @@ static void handle_del_station(struct wilc_vif *vif,
struct del_sta *param)
if (result)
netdev_err(vif->ndev, "Failed to send add station\n");
-ERRORHANDLER:
+error:
kfree(wid.val);
}
@@ -2213,7 +2213,7 @@ static void handle_edit_station(struct wilc_vif *vif,
wid.val = kmalloc(wid.size, GFP_KERNEL);
if (!wid.val)
- goto ERRORHANDLER;
+ goto error;
cur_byte = wid.val;
cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
@
[PATCH 05/10] staging: wilc1000: fix line over 80 char in handle_connect()
Fix 'line over 80 characters' issue reported by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 48 +--
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index a218497..22d7bcc 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -948,7 +948,8 @@ static s32 handle_connect(struct wilc_vif *vif,
hif_drv->usr_conn_req.ssid_len = conn_attr->ssid_len;
if (conn_attr->ssid) {
- hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
GFP_KERNEL);
+ hif_drv->usr_conn_req.ssid = kmalloc(conn_attr->ssid_len + 1,
+GFP_KERNEL);
memcpy(hif_drv->usr_conn_req.ssid,
conn_attr->ssid,
conn_attr->ssid_len);
@@ -957,7 +958,8 @@ static s32 handle_connect(struct wilc_vif *vif,
hif_drv->usr_conn_req.ies_len = conn_attr->ies_len;
if (conn_attr->ies) {
- hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
GFP_KERNEL);
+ hif_drv->usr_conn_req.ies = kmalloc(conn_attr->ies_len,
+ GFP_KERNEL);
memcpy(hif_drv->usr_conn_req.ies,
conn_attr->ies,
conn_attr->ies_len);
@@ -986,19 +988,17 @@ static s32 handle_connect(struct wilc_vif *vif,
wid_list[wid_cnt].val = (s8 *)(&(dummyval));
wid_cnt++;
- {
- wid_list[wid_cnt].id = WID_INFO_ELEMENT_ASSOCIATE;
- wid_list[wid_cnt].type = WID_BIN_DATA;
- wid_list[wid_cnt].val = hif_drv->usr_conn_req.ies;
- wid_list[wid_cnt].size = hif_drv->usr_conn_req.ies_len;
- wid_cnt++;
-
- if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
- info_element_size = hif_drv->usr_conn_req.ies_len;
- info_element = kmalloc(info_element_size, GFP_KERNEL);
- memcpy(info_element, hif_drv->usr_conn_req.ies,
- info_element_size);
- }
+ wid_list[wid_cnt].id = WID_INFO_ELEMENT_ASSOCIATE;
+ wid_list[wid_cnt].type = WID_BIN_DATA;
+ wid_list[wid_cnt].val = hif_drv->usr_conn_req.ies;
+ wid_list[wid_cnt].size = hif_drv->usr_conn_req.ies_len;
+ wid_cnt++;
+
+ if (memcmp("DIRECT-", conn_attr->ssid, 7)) {
+ info_element_size = hif_drv->usr_conn_req.ies_len;
+ info_element = kmalloc(info_element_size, GFP_KERNEL);
+ memcpy(info_element, hif_drv->usr_conn_req.ies,
+ info_element_size);
}
wid_list[wid_cnt].id = (u16)WID_11I_MODE;
wid_list[wid_cnt].type = WID_CHAR;
@@ -1075,10 +1075,12 @@ static s32 handle_connect(struct wilc_vif *vif,
*(cur_byte++) = bss_param->rsn_grp_policy;
*(cur_byte++) = bss_param->mode_802_11i;
- memcpy(cur_byte, bss_param->rsn_pcip_policy,
sizeof(bss_param->rsn_pcip_policy));
+ memcpy(cur_byte, bss_param->rsn_pcip_policy,
+ sizeof(bss_param->rsn_pcip_policy));
cur_byte += sizeof(bss_param->rsn_pcip_policy);
- memcpy(cur_byte, bss_param->rsn_auth_policy,
sizeof(bss_param->rsn_auth_policy));
+ memcpy(cur_byte, bss_param->rsn_auth_policy,
+ sizeof(bss_param->rsn_auth_policy));
cur_byte += sizeof(bss_param->rsn_auth_policy);
memcpy(cur_byte, bss_param->rsn_cap, sizeof(bss_param->rsn_cap));
@@ -1101,13 +1103,16 @@ static s32 handle_connect(struct wilc_vif *vif,
*(cur_byte++) = bss_param->cnt;
- memcpy(cur_byte, bss_param->duration,
sizeof(bss_param->duration));
+ memcpy(cur_byte, bss_param->duration,
+ sizeof(bss_param->duration));
cur_byte += sizeof(bss_param->duration);
- memcpy(cur_byte, bss_param->interval,
sizeof(bss_param->interval));
+ memcpy(cur_byte, bss_param->interval,
+ sizeof(bss_param->interval));
cur_byte += sizeof(bss_param->interval);
- memcpy(cur_byte, bss_param->start_time,
sizeof(bss_param->start_time));
+ memcpy(cur_byte, bss_param->start_time,
+ sizeof(bss_param->start_time));
cur_byte += sizeof(bss_param->start_time);
}
@@ -1148,7 +1153,8 @@ static s32 handle_connect(struct wilc_vif *vif,
if (conn_attr->ies) {
conn_info.req_ies_len = conn_attr->ies_len;
- conn_info.req_ies = kmalloc(conn_attr->ies_len,
GFP_KERNEL);
+ conn_info.req_ies = kmalloc(conn_attr->ies_len,
+
[PATCH 10/10] staging: wilc1000: fix line over 80 char issue in handle_scan_done()
Fix 'line over 80 characters' issue found by checkpatch.pl script in
handle_scan_done().
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index d822b15..5082ede 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -886,6 +886,7 @@ static s32 handle_scan_done(struct wilc_vif *vif, enum
scan_event evt)
u8 abort_running_scan;
struct wid wid;
struct host_if_drv *hif_drv = vif->hif_drv;
+ struct user_scan_req *scan_req;
if (evt == SCAN_EVENT_ABORTED) {
abort_running_scan = 1;
@@ -908,10 +909,10 @@ static s32 handle_scan_done(struct wilc_vif *vif, enum
scan_event evt)
return result;
}
- if (hif_drv->usr_scan_req.scan_result) {
- hif_drv->usr_scan_req.scan_result(evt, NULL,
- hif_drv->usr_scan_req.arg,
NULL);
- hif_drv->usr_scan_req.scan_result = NULL;
+ scan_req = &hif_drv->usr_scan_req;
+ if (scan_req->scan_result) {
+ scan_req->scan_result(evt, NULL, scan_req->arg, NULL);
+ scan_req->scan_result = NULL;
}
return result;
--
2.7.4
[PATCH 09/10] staging: wilc1000: rename variables using camelCase in handle_rcvd_gnrl_async_info()
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 86 +++
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index b26ea85..d822b15 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1343,17 +1343,17 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif
*vif,
struct rcvd_async_info *rcvd_info)
{
s32 result = 0;
- u8 u8MsgType = 0;
- u8 u8MsgID = 0;
- u16 u16MsgLen = 0;
- u16 u16WidID = (u16)WID_NIL;
- u8 u8WidLen = 0;
- u8 u8MacStatus;
- u8 u8MacStatusReasonCode;
- u8 u8MacStatusAdditionalInfo;
+ u8 msg_type = 0;
+ u8 msg_id = 0;
+ u16 msg_len = 0;
+ u16 wid_id = (u16)WID_NIL;
+ u8 wid_len = 0;
+ u8 mac_status;
+ u8 mac_status_reason_code;
+ u8 mac_status_additional_info;
struct connect_info conn_info;
struct disconnect_info disconn_info;
- s32 s32Err = 0;
+ s32 err = 0;
struct host_if_drv *hif_drv = vif->hif_drv;
if (!hif_drv) {
@@ -1370,62 +1370,62 @@ static s32 handle_rcvd_gnrl_async_info(struct wilc_vif
*vif,
return -EINVAL;
}
- u8MsgType = rcvd_info->buffer[0];
+ msg_type = rcvd_info->buffer[0];
- if ('I' != u8MsgType) {
+ if ('I' != msg_type) {
netdev_err(vif->ndev, "Received Message incorrect.\n");
return -EFAULT;
}
- u8MsgID = rcvd_info->buffer[1];
- u16MsgLen = MAKE_WORD16(rcvd_info->buffer[2],
rcvd_info->buffer[3]);
- u16WidID = MAKE_WORD16(rcvd_info->buffer[4],
rcvd_info->buffer[5]);
- u8WidLen = rcvd_info->buffer[6];
- u8MacStatus = rcvd_info->buffer[7];
- u8MacStatusReasonCode = rcvd_info->buffer[8];
- u8MacStatusAdditionalInfo = rcvd_info->buffer[9];
+ msg_id = rcvd_info->buffer[1];
+ msg_len = MAKE_WORD16(rcvd_info->buffer[2],
rcvd_info->buffer[3]);
+ wid_id = MAKE_WORD16(rcvd_info->buffer[4],
rcvd_info->buffer[5]);
+ wid_len = rcvd_info->buffer[6];
+ mac_status = rcvd_info->buffer[7];
+ mac_status_reason_code = rcvd_info->buffer[8];
+ mac_status_additional_info = rcvd_info->buffer[9];
if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP) {
- u32 u32RcvdAssocRespInfoLen = 0;
- struct connect_resp_info *pstrConnectRespInfo = NULL;
+ u32 rcvd_assoc_resp_info_len = 0;
+ struct connect_resp_info *connect_resp_info = NULL;
memset(&conn_info, 0, sizeof(struct connect_info));
- if (u8MacStatus == MAC_CONNECTED) {
+ if (mac_status == MAC_CONNECTED) {
memset(rcv_assoc_resp, 0,
MAX_ASSOC_RESP_FRAME_SIZE);
host_int_get_assoc_res_info(vif,
rcv_assoc_resp,
MAX_ASSOC_RESP_FRAME_SIZE,
-
&u32RcvdAssocRespInfoLen);
+
&rcvd_assoc_resp_info_len);
- if (u32RcvdAssocRespInfoLen != 0) {
- s32Err =
wilc_parse_assoc_resp_info(rcv_assoc_resp, u32RcvdAssocRespInfoLen,
-
&pstrConnectRespInfo);
- if (s32Err) {
- netdev_err(vif->ndev,
"wilc_parse_assoc_resp_info() returned error %d\n", s32Err);
+ if (rcvd_assoc_resp_info_len != 0) {
+ err =
wilc_parse_assoc_resp_info(rcv_assoc_resp, rcvd_assoc_resp_info_len,
+
&connect_resp_info);
+ if (err) {
+ netdev_err(vif->ndev,
"wilc_parse_assoc_resp_info() returned error %d\n", err);
} else {
- conn_info.status =
pstrConnectRespInfo->status;
+ conn_info.status =
connect_resp_info->status;
- if (conn_info.status ==
SUCCESSFUL_STATUSCODE && pstrConnectRespInfo->i
[PATCH 08/10] staging: wilc1000: rename WILC_HostIf_PackStaParam to avoid camelCase
Fix 'Avoid camelCase' issue found by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 5bf3bcc..b26ea85 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2081,7 +2081,7 @@ static void handle_del_beacon(struct wilc_vif *vif)
netdev_err(vif->ndev, "Failed to send delete beacon\n");
}
-static u32 WILC_HostIf_PackStaParam(u8 *buff, struct add_sta_param *param)
+static u32 wilc_hif_pack_sta_param(u8 *buff, struct add_sta_param *param)
{
u8 *cur_byte;
@@ -2127,7 +2127,7 @@ static void handle_add_station(struct wilc_vif *vif,
goto error;
cur_byte = wid.val;
- cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
+ cur_byte += wilc_hif_pack_sta_param(cur_byte, param);
result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
wilc_get_vif_idx(vif));
@@ -2223,7 +2223,7 @@ static void handle_edit_station(struct wilc_vif *vif,
goto error;
cur_byte = wid.val;
- cur_byte += WILC_HostIf_PackStaParam(cur_byte, param);
+ cur_byte += wilc_hif_pack_sta_param(cur_byte, param);
result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
wilc_get_vif_idx(vif));
--
2.7.4
[PATCH 06/10] staging: wilc1000: fix line over 80 character in handle_disconnect()
Refactor handle_disconnect() to avoid line over 80 characters issue
reported by checkpatch.pl script.
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 90 +++
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 22d7bcc..4050128 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -1801,7 +1801,9 @@ static void handle_disconnect(struct wilc_vif *vif)
{
struct wid wid;
struct host_if_drv *hif_drv = vif->hif_drv;
-
+ struct disconnect_info disconn_info;
+ struct user_scan_req *scan_req;
+ struct user_conn_req *conn_req;
s32 result = 0;
u16 dummy_reason_code = 0;
@@ -1820,63 +1822,61 @@ static void handle_disconnect(struct wilc_vif *vif)
if (result) {
netdev_err(vif->ndev, "Failed to send dissconect\n");
- } else {
- struct disconnect_info disconn_info;
+ goto out;
+ }
- memset(&disconn_info, 0, sizeof(struct disconnect_info));
+ memset(&disconn_info, 0, sizeof(struct disconnect_info));
- disconn_info.reason = 0;
- disconn_info.ie = NULL;
- disconn_info.ie_len = 0;
+ disconn_info.reason = 0;
+ disconn_info.ie = NULL;
+ disconn_info.ie_len = 0;
+ scan_req = &hif_drv->usr_scan_req;
+ conn_req = &hif_drv->usr_conn_req;
- if (hif_drv->usr_scan_req.scan_result) {
- del_timer(&hif_drv->scan_timer);
- hif_drv->usr_scan_req.scan_result(SCAN_EVENT_ABORTED,
- NULL,
-
hif_drv->usr_scan_req.arg,
- NULL);
- hif_drv->usr_scan_req.scan_result = NULL;
- }
+ if (scan_req->scan_result) {
+ del_timer(&hif_drv->scan_timer);
+ scan_req->scan_result(SCAN_EVENT_ABORTED, NULL, scan_req->arg,
+ NULL);
+ scan_req->scan_result = NULL;
+ }
- if (hif_drv->usr_conn_req.conn_result) {
- if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP)
- del_timer(&hif_drv->connect_timer);
+ if (conn_req->conn_result) {
+ if (hif_drv->hif_state == HOST_IF_WAITING_CONN_RESP)
+ del_timer(&hif_drv->connect_timer);
-
hif_drv->usr_conn_req.conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF,
- NULL,
- 0,
- &disconn_info,
-
hif_drv->usr_conn_req.arg);
- } else {
- netdev_err(vif->ndev, "conn_result = NULL\n");
- }
+ conn_req->conn_result(CONN_DISCONN_EVENT_DISCONN_NOTIF, NULL,
+ 0, &disconn_info, conn_req->arg);
+ } else {
+ netdev_err(vif->ndev, "conn_result = NULL\n");
+ }
- scan_while_connected = false;
+ scan_while_connected = false;
- hif_drv->hif_state = HOST_IF_IDLE;
+ hif_drv->hif_state = HOST_IF_IDLE;
- eth_zero_addr(hif_drv->assoc_bssid);
+ eth_zero_addr(hif_drv->assoc_bssid);
- hif_drv->usr_conn_req.ssid_len = 0;
- kfree(hif_drv->usr_conn_req.ssid);
- hif_drv->usr_conn_req.ssid = NULL;
- kfree(hif_drv->usr_conn_req.bssid);
- hif_drv->usr_conn_req.bssid = NULL;
- hif_drv->usr_conn_req.ies_len = 0;
- kfree(hif_drv->usr_conn_req.ies);
- hif_drv->usr_conn_req.ies = NULL;
+ conn_req->ssid_len = 0;
+ kfree(conn_req->ssid);
+ conn_req->ssid = NULL;
+ kfree(conn_req->bssid);
+ conn_req->bssid = NULL;
+ conn_req->ies_len = 0;
+ kfree(conn_req->ies);
+ conn_req->ies = NULL;
- if (join_req && join_req_vif == vif) {
- kfree(join_req);
- join_req = NULL;
- }
+ if (join_req && join_req_vif == vif) {
+ kfree(join_req);
+ join_req = NULL;
+ }
- if (info_element && join_req_vif == vif) {
- kfree(info_element);
- info_element = NULL;
- }
+ if (info_element && join_req_vif == vif) {
+ kfree(info_element);
+ info_element = NULL;
}
+out:
+
complete(&hif_drv->comp_test_disc
[PATCH 07/10] staging: wilc1000: rename variables prefix using datatype 'u8'
Rename variables with datatype 'u8' in their name to follow the linux
coding style.
Renamed following variables:
u8abort_running_scan
pu8Buffer
pu8keybuf
pu8msa
u8remain_on_chan_flag
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/coreconfigurator.c | 28 +++---
drivers/staging/wilc1000/host_interface.c | 135 ++--
2 files changed, 81 insertions(+), 82 deletions(-)
diff --git a/drivers/staging/wilc1000/coreconfigurator.c
b/drivers/staging/wilc1000/coreconfigurator.c
index 2e2187b..db66b1c 100644
--- a/drivers/staging/wilc1000/coreconfigurator.c
+++ b/drivers/staging/wilc1000/coreconfigurator.c
@@ -148,19 +148,19 @@ static inline u8 get_from_ds(u8 *header)
return ((header[1] & 0x02) >> 1);
}
-static inline void get_address1(u8 *pu8msa, u8 *addr)
+static inline void get_address1(u8 *msa, u8 *addr)
{
- memcpy(addr, pu8msa + 4, 6);
+ memcpy(addr, msa + 4, 6);
}
-static inline void get_address2(u8 *pu8msa, u8 *addr)
+static inline void get_address2(u8 *msa, u8 *addr)
{
- memcpy(addr, pu8msa + 10, 6);
+ memcpy(addr, msa + 10, 6);
}
-static inline void get_address3(u8 *pu8msa, u8 *addr)
+static inline void get_address3(u8 *msa, u8 *addr)
{
- memcpy(addr, pu8msa + 16, 6);
+ memcpy(addr, msa + 16, 6);
}
static inline void get_BSSID(u8 *data, u8 *bssid)
@@ -238,30 +238,30 @@ static inline u16 get_asoc_id(u8 *data)
return asoc_id;
}
-static u8 *get_tim_elm(u8 *pu8msa, u16 rx_len, u16 tag_param_offset)
+static u8 *get_tim_elm(u8 *msa, u16 rx_len, u16 tag_param_offset)
{
u16 index;
index = tag_param_offset;
while (index < (rx_len - FCS_LEN)) {
- if (pu8msa[index] == ITIM)
- return &pu8msa[index];
- index += (IE_HDR_LEN + pu8msa[index + 1]);
+ if (msa[index] == ITIM)
+ return &msa[index];
+ index += (IE_HDR_LEN + msa[index + 1]);
}
return NULL;
}
-static u8 get_current_channel_802_11n(u8 *pu8msa, u16 rx_len)
+static u8 get_current_channel_802_11n(u8 *msa, u16 rx_len)
{
u16 index;
index = TAG_PARAM_OFFSET;
while (index < (rx_len - FCS_LEN)) {
- if (pu8msa[index] == IDSPARMS)
- return pu8msa[index + 2];
- index += pu8msa[index + 1] + IE_HDR_LEN;
+ if (msa[index] == IDSPARMS)
+ return msa[index + 2];
+ index += msa[index + 1] + IE_HDR_LEN;
}
return 0;
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index 4050128..5bf3bcc 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -883,15 +883,15 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
static s32 handle_scan_done(struct wilc_vif *vif, enum scan_event evt)
{
s32 result = 0;
- u8 u8abort_running_scan;
+ u8 abort_running_scan;
struct wid wid;
struct host_if_drv *hif_drv = vif->hif_drv;
if (evt == SCAN_EVENT_ABORTED) {
- u8abort_running_scan = 1;
+ abort_running_scan = 1;
wid.id = (u16)WID_ABORT_RUNNING_SCAN;
wid.type = WID_CHAR;
- wid.val = (s8 *)&u8abort_running_scan;
+ wid.val = (s8 *)&abort_running_scan;
wid.size = sizeof(char);
result = wilc_send_config_pkt(vif, SET_CFG, &wid, 1,
@@ -1552,7 +1552,7 @@ static int handle_key(struct wilc_vif *vif, struct
key_attr *hif_key)
struct wid wid;
struct wid wid_list[5];
u8 i;
- u8 *pu8keybuf;
+ u8 *key_buf;
s8 s8idxarray[1];
s8 ret = 0;
struct host_if_drv *hif_drv = vif->hif_drv;
@@ -1571,15 +1571,15 @@ static int handle_key(struct wilc_vif *vif, struct
key_attr *hif_key)
wid_list[1].size = sizeof(char);
wid_list[1].val = (s8 *)&hif_key->attr.wep.auth_type;
- pu8keybuf = kmalloc(hif_key->attr.wep.key_len + 2,
- GFP_KERNEL);
- if (!pu8keybuf)
+ key_buf = kmalloc(hif_key->attr.wep.key_len + 2,
+ GFP_KERNEL);
+ if (!key_buf)
return -ENOMEM;
- pu8keybuf[0] = hif_key->attr.wep.index;
- pu8keybuf[1] = hif_key->attr.wep.key_len;
+ key_buf[0] = hif_key->attr.wep.index;
+ key_buf[1] = hif_key->attr.wep.key_len;
- memcpy(&pu8keybuf[2], hif_key->attr.wep.key,
+ memcpy(&key_buf[2], hif_key->attr.wep.key,
hif_key->attr.wep.key_len);
kfree(hif_key->att
[PATCH 04/10] staging: wilc1000: fix line over 80 char in handle_scan()
Fix 'line over 80 character' issue reported by checkpatch.pl script in
handle_scan().
Signed-off-by: Ajay Singh
---
drivers/staging/wilc1000/host_interface.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/wilc1000/host_interface.c
b/drivers/staging/wilc1000/host_interface.c
index d0c17cd..a218497 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -771,6 +771,7 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
u8 valuesize = 0;
u8 *hdn_ntwk_wid_val = NULL;
struct host_if_drv *hif_drv = vif->hif_drv;
+ struct hidden_network *hidden_net = &scan_info->hidden_network;
hif_drv->usr_scan_req.scan_result = scan_info->result;
hif_drv->usr_scan_req.arg = scan_info->arg;
@@ -793,19 +794,20 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
wid_list[index].id = (u16)WID_SSID_PROBE_REQ;
wid_list[index].type = WID_STR;
- for (i = 0; i < scan_info->hidden_network.n_ssids; i++)
- valuesize += ((scan_info->hidden_network.net_info[i].ssid_len)
+ 1);
+ for (i = 0; i < hidden_net->n_ssids; i++)
+ valuesize += ((hidden_net->net_info[i].ssid_len) + 1);
hdn_ntwk_wid_val = kmalloc(valuesize + 1, GFP_KERNEL);
wid_list[index].val = hdn_ntwk_wid_val;
if (wid_list[index].val) {
buffer = wid_list[index].val;
- *buffer++ = scan_info->hidden_network.n_ssids;
+ *buffer++ = hidden_net->n_ssids;
- for (i = 0; i < scan_info->hidden_network.n_ssids; i++) {
- *buffer++ =
scan_info->hidden_network.net_info[i].ssid_len;
- memcpy(buffer,
scan_info->hidden_network.net_info[i].ssid,
scan_info->hidden_network.net_info[i].ssid_len);
- buffer +=
scan_info->hidden_network.net_info[i].ssid_len;
+ for (i = 0; i < hidden_net->n_ssids; i++) {
+ *buffer++ = hidden_net->net_info[i].ssid_len;
+ memcpy(buffer, hidden_net->net_info[i].ssid,
+ hidden_net->net_info[i].ssid_len);
+ buffer += hidden_net->net_info[i].ssid_len;
}
wid_list[index].size = (s32)(valuesize + 1);
@@ -833,7 +835,7 @@ static s32 handle_scan(struct wilc_vif *vif, struct
scan_attr *scan_info)
for (i = 0; i < scan_info->ch_list_len; i++){
if (scan_info->ch_freq_list[i] > 0)
- scan_info->ch_freq_list[i] =
scan_info->ch_freq_list[i] - 1;
+ scan_info->ch_freq_list[i] -= 1;
}
}
--
2.7.4
Re: brcmfmac signal/interference issues
On Thu, Mar 8, 2018 at 2:47 AM, Arend van Spriel wrote: > On 2/23/2018 2:49 PM, Daniel Drake wrote: >> >> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel >> wrote: >>> >>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | >>> tail -1' you can see the firmware build target and it likely has 'ndis' >>> in >>> it. > > > Hi Daniel, > > Bit late response. Sorry. > >> >> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf >> >> Yes, ndis. So no easy way to run the same firmware on the 2 OSes. > > > Indeed. I could try building nearly same firmware target. Can you provide > the firmware version as well. > > Now reading over your orignal email again: > >> If I place both antenna terminals inside the Linux MiniPC case, the >> Linux pings are bad but the Windows pings are fine. >> >> If I place both antenna terminals inside the Windows MiniPC case, it >> is the same: Linux pings are bad, but the Windows pings are fine. >> >> And when the Linux antenna is placed outside of both cases, the Linux >> pings are fine. I've repeated these tests a handful of times in quick >> succession to make sure that I'm not going crazy and that this is not >> a case of the problem intermittency causing misleading results. These >> findings appear very solid. > > So it picks up something in the PC. Some sources of interference that I have > seen before are USB3 and HDMI. Maybe try to shield those if present and see > if that helps. The nvram contains sensitivity parameters, but as you stated > you are using the same nvram for windows and linux for now we can rule it > out for debugging the issue. > Hi Daniel, I'll jump in here too... Did you check the Bluetooth? I don't know if this chip has it or if it's an independent chip on this board, but if Linux is leaving it powered up but not properly configured you could have issues. And in some designs, the BT and WiFi will share a single antenna. Note that I'm not saying you've configured BT to run, I'm actually suggesting that the pin that enables it is on, but you might not be loading the BT drivers and firmware and so the thing is just in a wonky uninitialized state. Or you do have it enabled and should try turning it off. Either way. And WiFi/BT coex has always been a bit of a problem (speaking generally, I don't know the status with this particular chip) in Linux. I see WiFi and BT interfering with each other frequently in my testing setups with my dev boards. Often I can magically make problems go away by simply pulling the enable line high (which is "off"). - Steve -- Steve deRosier Cal-Sierra Consulting LLC https://www.cal-sierra.com/
Re: pull-request: wireless-drivers 2018-03-08
From: Kalle Valo Date: Thu, 08 Mar 2018 17:18:29 +0200 > here's a pull requsest to net tree for 4.16. Since the merge window I > have had some clannges to keep up with some patches but catching up now. > > There should be nothing special here but please let me know if you have > any problems. Pulled, thank you.
[RFC] mac80211: advertise supported interface types for sw encryption
From: Manikanta Pubbisetty
Extending SW_CRYPTO_CONTROL interface so that drivers can advertise
the interface types on which they can support software encryption.
Driver's job is not done by advertising the supported vif types alone,
they should also return -EOPNOTSUPP from set_key.
Mac80211 will make the fallback decision to sw ecryption based
on the return type of set_key callback and the driver's support for
software encryption.
This change is done with the sole reason of adding the support of
VLANs for drivers which enable SW_CRYPTO_CONTROL(ex:ath10k).
With the current logic, configuring GTKs for specific VLAN groups will
always fail with the drivers enabling SW_CRYPTO_CONTROL. I understand
that the driver can return 1 from set_key to enable software encryption
in mac80211, but GTKs for VLANs are never passed down to the driver.
Since the return value is initialized to -EOPNOTSUPP, with this approach,
we get away with the failure.
Signed-off-by: Manikanta Pubbisetty
---
include/net/mac80211.h | 5 +
net/mac80211/key.c | 12 +---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 2fd59ed..3df6bee5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2237,6 +2237,10 @@ enum ieee80211_hw_flags {
* supported by HW.
* @max_nan_de_entries: maximum number of NAN DE functions supported by the
* device.
+ * @supp_sw_crypto_iftypes: supported interface types for software crypto,
+ * this field is applicable for devices advertising SW_CRYPTO_CONTROL
+ * hwflag. Drivers may also set the interface types on which mac80211
+ * can fallback to software encryption if set_key returns -EOPNOTSUPP.
*/
struct ieee80211_hw {
struct ieee80211_conf conf;
@@ -2272,6 +2276,7 @@ struct ieee80211_hw {
u8 n_cipher_schemes;
const struct ieee80211_cipher_scheme *cipher_schemes;
u8 max_nan_de_entries;
+ u16 supp_sw_crypto_iftypes;
};
static inline bool _ieee80211_hw_check(struct ieee80211_hw *hw,
diff --git a/net/mac80211/key.c b/net/mac80211/key.c
index aee05ec..a1011c4 100644
--- a/net/mac80211/key.c
+++ b/net/mac80211/key.c
@@ -126,7 +126,7 @@ static void decrease_tailroom_need_count(struct
ieee80211_sub_if_data *sdata,
static int ieee80211_key_enable_hw_accel(struct ieee80211_key *key)
{
- struct ieee80211_sub_if_data *sdata;
+ struct ieee80211_sub_if_data *sdata = key->sdata;
struct sta_info *sta;
int ret = -EOPNOTSUPP;
@@ -162,7 +162,6 @@ static int ieee80211_key_enable_hw_accel(struct
ieee80211_key *key)
if (sta && !sta->uploaded)
goto out_unsupported;
- sdata = key->sdata;
if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN) {
/*
* The driver doesn't know anything about VLAN interfaces.
@@ -214,8 +213,15 @@ static int ieee80211_key_enable_hw_accel(struct
ieee80211_key *key)
/* all of these we can do in software - if driver can */
if (ret == 1)
return 0;
- if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL))
+
+ if (ieee80211_hw_check(&key->local->hw, SW_CRYPTO_CONTROL)) {
+ if ((ret == -EOPNOTSUPP) &&
+ (sdata->local->hw.supp_sw_crypto_iftypes &
+ (1 << sdata->vif.type)))
+ return 0;
return -EINVAL;
+ }
+
return 0;
default:
return -EINVAL;
--
2.7.4
Re: Variable-length arrays considered bad
On Thu, Mar 8, 2018 at 2:10 PM, Kalle Valo wrote: > Hi, > > in an lkml discussion[1] it was mentioned that variable-length arrays > should not be used. Few warnings were found[2] from wireless: > > drivers/net/wireless/ath/ath9k/dfs.c:104:2: warning: ISO C90 forbids variable > length array 'max_bin' [-Wvla] > drivers/net/wireless/rsi/rsi_91x_sdio.c:570:2: warning: ISO C90 forbids > variable length array 'temp_buf' [-Wvla] > > Patches welcome. > > [1] > https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com > > [2] http://paste.ubuntu.com/p/srQxwPQS9s/ > I will submit a cleanup patch for RSI warning Regards, Amitkumar Karwar
