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
> Signed-off-by: Anna-Maria Gleixner
> C
On Tue, 5 Sep 2017, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit 915f3e3f76c05b2da93c4cc278eebc2d9219d9f4
> Author: Thomas Gleixner
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.
> >
> > Signed-off-by: Tho
On Tue, 2017-09-05 at 10:49 +0200, Thomas Gleixner wrote:
>
> > Are you planning to integrate all patches in the series through
> > some other tree, perhaps to be able to get rid of the
> > tasklet_hrtimer API, or should I apply this?
>
> The patch depends on the hrtimer core changes, so we eithe
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 of a problem it is). What hap
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 interfa
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 directly to the per-STA TXQ.
>>
>
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
destroye
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 the station must've moved so
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 indicat
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 se
+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 802.1Q
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 p
On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote:
> + regd = get_wiphy_regdom(wiphy);
> + if (regd) {
> + const struct ieee80211_reg_rule *reg_rule =
> + freq_reg_info_regd(MHZ_TO_KHZ(channel-
> >center_freq),
> + r
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 express itself properly. So
the table says:
| WARNING:at_kernel/ti
On Tue, 2017-09-05 at 16:30 +0200, Johannes Berg wrote:
> On Sat, 2017-08-05 at 11:44 +0300, Luca Coelho wrote:
>
> > + regd = get_wiphy_regdom(wiphy);
> > + if (regd) {
> > + const struct ieee80211_reg_rule *reg_rule =
> > + freq_reg_info_regd(MHZ_TO_KHZ(channel-
>
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
>
> Hi Carl,
>
> On Sun, 2017-09-03 a
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: linuxw...@intel.com
> > Subject: Re: Bug Rep
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 array to zero.
This seems t
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 array to zero.
This seems t
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
separately in a binary form that ne
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 exp
On Mon, Sep 4, 2017 at 12:34 AM, Wright Feng wrote:
> Firmware returns proprietary error code when getting error in
> fil_cmd_data_set or fil_cmd_data_get. The vendor tools or
> utilities which uses libnl may stuck in some commands when wl is down.
> For example, issue "scan" command after issuing
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 patch adds support to dow
On Tue, 5 Sep 2017 19:16:58 +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 scan of the array to read potentially
> uninitialize
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 scan of the array to read potentially
> uninitialize
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
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 3 ++-
drive
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| 91 +++---
1 file changed, 45 insert
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 insertions(+), 6 deletions(-)
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: Ian Molton
---
drivers/net/wi
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
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4
drivers/net/wireless/broad
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
on
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
Signed-off-by: Ian Molton
# Conflicts:
#
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
Reviewed-by: Arend van Spriel
# Conflicts:
# dr
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:
sdi
35 matches
Mail list logo