Pali Rohár writes:
> In case there is no valid MAC address kernel generates random one. This
> patch propagate this generated MAC address back to NVS data which will be
> uploaded to wl1251 chip. So HW would have same MAC address as linux kernel
> uses.
>
> Signed-off-by:
Pali Rohár writes:
> This patch implements parsing MAC address from NVS data which are sent to
> wl1251 chip. Calibration NVS data could contain valid MAC address and it
> will be used instead randomly generated.
>
> This patch also move code for requesting NVS data from
Hi folks,
recently, a laptop featuring a rtl8187b usb wifi adapter, precisely,
this one:
Bus 001 Device 002: ID 0bda:8197 Realtek Semiconductor Corp. RTL8187B Wireless
Adapter
fell into my hands. I noticed that in my IPv6 enabled home network,
the card would not receive any RAs and thus not
Hi Kalle,
Here's my first pull-request intended for v4.11. It has a bunch of
fixes, cleanups and improvements here and there, as well as a few new
features. More details in the tag description.
I have sent this out before and kbuildbot didn't find any issues.
Please let me know if there are
From: Michael Schenk
In the function rtl_usb_start we pre-allocate a certain number of urbs
for RX path but they will not be freed when calling rtl_usb_stop. This
results in leaking urbs when doing ifconfig up and down. Eventually,
the system has no available
On Thu, 2017-01-26 at 17:20 +0100, Johannes Berg wrote:
> From: Johannes Berg
>
> The spec writes cipher/AKM suites as something like 00-0F-AC:9,
> but the part after the colon isn't hex, it's decimal, so that
> we've already had a few mistakes (in other code, or
From: Johannes Berg
The spec writes cipher/AKM suites as something like 00-0F-AC:9,
but the part after the colon isn't hex, it's decimal, so that
we've already had a few mistakes (in other code, or unmerged
patches) to e.g. write 0x000FAC10 instead of 0x000FAC0A.
Use a
On Thu, 2017-01-26 at 07:27 -0800, Eric Dumazet wrote:
>
> if (!uh->check && !udp_sk(sk)->no_check6_rx) {
> udp6_csum_zero_error(skb);
> goto csum_error;
> }
Yeah, I'd found no_check6_rx already, was still trying
On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
>
> > Unfortunately, I haven't been able to actually test this yet. I
> > also
> > didn't find the code that would drop frames with CSUM 0 either, so
> > I'm
> > thinking - for now -
On Thu, 2017-01-26 at 07:24 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
>
> > Unfortunately, I haven't been able to actually test this yet. I also
> > didn't find the code that would drop frames with CSUM 0 either, so I'm
> > thinking - for now - that if
On Thu, 2017-01-26 at 15:49 +0100, Johannes Berg wrote:
> Unfortunately, I haven't been able to actually test this yet. I also
> didn't find the code that would drop frames with CSUM 0 either, so I'm
> thinking - for now - that if all the csum handling is skipped, dropping
> 0 csum frames would
fix an issue where we printed the sdio buffer before
actually read it.
Signed-off-by: Guy Mishol
---
drivers/net/wireless/ti/wlcore/sdio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
On Thu, 2017-01-26 at 06:45 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote:
>
> > Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY",
> > nothing more advanced right now, but right now we'd indicate that
> > if
> > the packet had 0x in the
On Thu, 2017-01-26 at 14:49 +0100, Johannes Berg wrote:
> Oops, sorry - receive. We can only indicate "CHECKSUM_UNNECESSARY",
> nothing more advanced right now, but right now we'd indicate that if
> the packet had 0x in the checksum field, but should've had 0x.
>
> On TX I believe we
On Thu, 2017-01-26 at 05:44 -0800, Eric Dumazet wrote:
> On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote:
> > Hi,
> >
> > It looks like right now we may have a hardware bug and accept
> > 0x as
> > valid, when the outcome of the calculation is 0x.
> >
> > What do you think we
On Thu, 2017-01-26 at 14:27 +0100, Johannes Berg wrote:
> Hi,
>
> It looks like right now we may have a hardware bug and accept 0x as
> valid, when the outcome of the calculation is 0x.
>
> What do you think we should do about this?
>
> We could ignore the issue entirely, since 0 wasn't
Hi,
It looks like right now we may have a hardware bug and accept 0x as
valid, when the outcome of the calculation is 0x.
What do you think we should do about this?
We could ignore the issue entirely, since 0 wasn't ever supposed to be
sent anyway - but then we don't drop frames that we
Hi Felix,
On Thursday, January 26, 2017 11:26:03 AM CET Felix Fietkau wrote:
> On 2017-01-26 11:15, Simon Wunderlich wrote:
> > Hey,
> >
> > On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote:
> >> On 2017-01-26 10:50, Simon Wunderlich wrote:
> >> > Hey Felix,
> >> >
> >> > On
On 2017-01-26 11:15, Simon Wunderlich wrote:
> Hey,
>
> On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote:
>> On 2017-01-26 10:50, Simon Wunderlich wrote:
>> > Hey Felix,
>> >
>> > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
>> >> Various chips occasionally
Hey,
On Thursday, January 26, 2017 11:02:53 AM CET Felix Fietkau wrote:
> On 2017-01-26 10:50, Simon Wunderlich wrote:
> > Hey Felix,
> >
> > On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
> >> Various chips occasionally run into a state where the tx path still
> >> appears
On 2017-01-26 10:50, Simon Wunderlich wrote:
> Hey Felix,
>
>
> On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
>> Various chips occasionally run into a state where the tx path still
>> appears to be working normally, but the rx path is deaf.
>>
>> There is no known register
Hey Felix,
On Wednesday, January 25, 2017 5:36:53 PM CET Felix Fietkau wrote:
> Various chips occasionally run into a state where the tx path still
> appears to be working normally, but the rx path is deaf.
>
> There is no known register signature to check for this state explicitly,
> so use
On Wed, 2017-01-25 at 17:01 +0530, Vasanthakumar Thiagarajan wrote:
> Sharing DFS channel state across multiple wiphys (radios) could
> be useful with multiple radios on the system. When one radio
> completes CAC and marks the channel available another radio
> can use this information and start
> +static bool cfg80211_off_channel_oper_allowed(struct wireless_dev
> *wdev)
> +{
> + if (!cfg80211_beaconing_iface_active(wdev))
> + return true;
> +
> + if (!(wdev->chandef.chan->flags & IEEE80211_CHAN_RADAR))
> + return true;
That could use some locking
> + /* Should we apply the grace period during beaconing
> interface
> + * shutdown also?
> + */
> + cfg80211_sched_dfs_chan_update(rdev);
It might make some sense, say if hostapd crashes and you restart it
automatically or something?
>
On Tue, 2017-01-24 at 16:42 +0100, Amadeusz Sławiński wrote:
> cleanup patch to make use of ieee80211_ac_from_tid() to retrieve ac
> from
> ieee802_1d_to_ac[]
Applied.
johannes
26 matches
Mail list logo