Re: [PATCH 30/30] brcmfmac: Reduce the noise from repeatedly dereferencing common pointers

On 22-08-17 13:25, Ian Molton wrote: This introduces no functional changes, but makes the code drastically more readable, reducing the amount of dereferencing performed inside functions throughout the SDIO core. For example, reduce: sdio_release_host(bus->sdiodev->func1); to:

Re: [PATCH 27/30] brcmfmac: Replace function index with function pointer

On 22-08-17 13:25, Ian Molton wrote: In preparation for removing the function array, remove all code that refers to function by index and replace with pointers to the function itself. Acked-by: Arend van Spriel Signed-off-by: Ian Molton

Re: [PATCH 26/30] brcmfmac: More efficient and slightly easier to read fixup for 4339 chips

On 22-08-17 13:25, Ian Molton wrote: Its more efficient to test the register we're interested in first, potentially avoiding two more comparisons, and therefore always avoiding one comparison per call on all other chips. Efficiency is really not a big issue. The buscore callbacks are really

Re: [PATCH 25/30] brcmfmac: Remove func0 from function array

On 22-08-17 13:25, Ian Molton wrote: Linux doesnt pass you func0 as a function when probing - instead providing specific access functions to read/write it. This prepares for a patch to remove the actual array entry itself. Acked-by: Arend van Spriel

Re: [PATCH 24/30] brcmfmac: Correctly handle accesses to SDIO func0

On 22-08-17 13:25, Ian Molton wrote: Rather than workaround the restrictions on func0 addressing in the driver, set MMC_QUIRK_LENIENT_FN0 Acked-by: Arend van Spriel Signed-off-by: Ian Molton ---

Re: [PATCH 22/30] brcmfmac: Rename buscore->core for consistency

On 22-08-17 13:25, Ian Molton wrote: Avoid confusion with unrelated _buscore labels. Acked-by: Arend van Spriel Signed-off-by: Ian Molton --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 11 +-- 1 file changed, 5

Re: [PATCH 23/30] brcmfmac: stabilise the value of ->sbwad in use for some xfer routines.

On 22-08-17 13:25, Ian Molton wrote: The IO functions operate within the Chipcommon IO window. Explicitly set this, rather than relying on the last initialisation IO access to leave it set to the right value by chance. Acked-by: Arend van Spriel Signed-off-by:

Re: [PATCH 21/30] brcmfmac: Remove {r,w}_sdreg32

On 22-08-17 13:25, Ian Molton wrote: Remove yet another IO function from the code and replace with one that already exists. Reviewed-by: Arend van Spriel Signed-off-by: Ian Molton --- .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|

Re: [PATCH 28/30] brcmfmac: Clean up interrupt macros

On 22-08-17 13:25, Ian Molton wrote: Make it more obvious that this code acually enables interrupts, and provide nice definitions for the bits in the register. Acked-by: Arend van Spriel Signed-off-by: Ian Molton ---

Re: [PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero

On Tue, 5 Sep 2017 19:15:50 +0100 Colin King wrote: > From: Colin Ian King > > The u8 char array ret is not being initialized and elements outside > the range start to end contain just garbage values from the stack. > This results in a later

Re: [PATCH v5] brcmfmac: add CLM download support

On 29-08-17 08:23, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept separately in a binary form that needs to be downloaded to the device. This

Re: 915f3e3f76 ("mac80211_hwsim: Replace bogus hrtimer clockid"): BUG: kernel reboot-without-warning in test stage

On Tue, 5 Sep 2017, Sebastian Andrzej Siewior wrote: > On 2017-09-05 09:12:40 [+0200], Thomas Gleixner wrote: > > Sorry, no. That bisect is completely bogus. The commit in question merily > > replaces the unsupported clockid with a valid one. > > The bisect is correct. It just has problems to

Re: [PATCH v5] brcmfmac: add CLM download support

On 04-09-17 13:33, Chung-Hsien Hsu wrote: On Tue, Aug 29, 2017 at 02:23:41PM +0800, Wright Feng wrote: From: Chung-Hsien Hsu The firmware for brcmfmac devices includes information regarding regulatory constraints. For certain devices this information is kept

[PATCH 2/2] b43legacy: fix unitialized reads of ret by initializing the array to zero

From: Colin Ian King The u8 char array ret is not being initialized and elements outside the range start to end contain just garbage values from the stack. This results in a later scan of the array to read potentially uninitialized values. Fix this by initializing the

[PATCH 1/2] b43: fix unitialized reads of ret by initializing the array to zero

From: Colin Ian King The u8 char array ret is not being initialized and elements outside the range start to end contain just garbage values from the stack. This results in a later scan of the array to read potentially uninitialized values. Fix this by initializing the

Re: Bug Report for iwlwifi kernel module

On Tue, 2017-09-05 at 09:51 -0700, Carl Myers wrote: > Hi Luca, > > On Mon, Sep 04, 2017 at 10:34:37AM +0300, Luca Coelho wrote: > > Date: Mon, 04 Sep 2017 10:34:37 +0300 > > From: Luca Coelho > > To: Carl Myers , linux-wireless@vger.kernel.org > > Cc:

Re: Bug Report for iwlwifi kernel module

Hi Luca, On Mon, Sep 04, 2017 at 10:34:37AM +0300, Luca Coelho wrote: > Date: Mon, 04 Sep 2017 10:34:37 +0300 > From: Luca Coelho > To: Carl Myers , linux-wireless@vger.kernel.org > Cc: linuxw...@intel.com > Subject: Re: Bug Report for iwlwifi kernel module >

Re: [PATCH 00/10] mac80211 patches from our internal tree 2017-08-05

On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote: > > Liad Kaufman (2): >   mac80211: add MESH IE in the correct order applied. > Naftali Goldstein (1): >   mac80211: add api to start ba session timer expired flow you already had this merged > Sharon Dvir (1): >   mac80211: shorten debug

VLAN/bridge "compression" in wifi (was: Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support)

+netdev On Tue, 2017-09-05 at 15:45 +0200, Johannes Berg wrote: > > In a way this feature seems mis-designed - you never have 802.1Q tags > over the air, but you're inserting them on RX and stripping them on > TX, probably in order to make bridging to ethernet easier and not > have to have

Re: [PATCH 3/8] qtnfmac: implement AP_VLAN iftype support

Hi Sergey, all, On Tue, 2017-06-20 at 22:55 +0300, Sergey Matyukevich wrote: > This patch implements AP_VLAN interface type support enabling > the use of dynamic VLAN mode in hostapd. My first thought here is that this is completely wrong. AP_VLAN interfaces have no relation to 802.1Q, but it

Re: Cisco's Wi-Fi Direct Client Policy and iwlwifi (8260)

On Fri, 2017-08-18 at 20:16 +0300, Luca Coelho wrote: > > I have heard about this before.  The issue is that the Cisco AP > doesn't allow the 8260 to connect because it has the P2P IE in > it.  But AFAICT it is not against any specs to include this IE.  The > Cisco AP is using the IE as an

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

Johannes Berg writes: > On Tue, 2017-09-05 at 11:49 +0200, Toke Høiland-Jørgensen wrote: >> >> Ah, so the station is attached to the VLAN interface, not the parent >> interface? > > Doesn't actually matter, but if the VLAN goes where the station belongs > then either

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

On Tue, 2017-09-05 at 11:49 +0200, Toke Høiland-Jørgensen wrote: > > Ah, so the station is attached to the VLAN interface, not the parent > interface? Doesn't actually matter, but if the VLAN goes where the station belongs then either the station must've moved somewhere else or have been

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

Johannes Berg writes: > On Tue, 2017-09-05 at 11:02 +0200, Toke Høiland-Jørgensen wrote: >> >> > I'm not sure. However, I think it's less bad than one might guess >> > since it really should only affect multicast frames, right? All >> > unicast frames should go

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

On Tue, 2017-09-05 at 11:02 +0200, Toke Høiland-Jørgensen wrote: > > > I'm not sure. However, I think it's less bad than one might guess > > since it really should only affect multicast frames, right? All > > unicast frames should go directly to the per-STA TXQ. > > Ah, right, that is the

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

Johannes Berg writes: > On Mon, 2017-09-04 at 16:23 +0200, Toke Høiland-Jørgensen wrote: >> >> Hmm, not apart from agreeing with you that it would be better to not >> drop everything when removing a VLAN. Not sure how often this >> happens, though (and hence how big

Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

On Tue, 5 Sep 2017, Johannes Berg wrote: > On Thu, 2017-08-31 at 12:23 +, Anna-Maria Gleixner wrote: > > From: Thomas Gleixner > > > > Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer > > callback in softirq context and remove the hrtimer_tasklet. > > >

Re: [PATCH 20/25] mac80211_hwsim: Replace hrtimer tasklet with softirq hrtimer

On Thu, 2017-08-31 at 12:23 +, Anna-Maria Gleixner wrote: > From: Thomas Gleixner > > Switch the timer to CLOCK_MONOTONIC_SOFT, which executed the timer > callback in softirq context and remove the hrtimer_tasklet. > > Signed-off-by: Thomas Gleixner

Re: [PATCH 3/3] mac80211: fix VLAN handling with TXQs

On Mon, 2017-09-04 at 16:23 +0200, Toke Høiland-Jørgensen wrote: > > Hmm, not apart from agreeing with you that it would be better to not > drop everything when removing a VLAN. Not sure how often this > happens, though (and hence how big of a problem it is). What happens > in scenarios where