* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 7:36 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190712105212.clf77zne6i4gh5ti@bars>
Hi Sergey,
Sorry for dropping the ball on this thread.
> > Right, it will be updated on RX. But then if we chanswitch, we would
> > probably (mac80211 using a pointer to the non-transmitting BSS) update
> > only one of the nontransmitting BSSes?
> >
> > Just saying that maybe we need to be careful there - or your wording
> > might be incorrect. We might end up updating a *nontransmitting* BSS,
> > and then its transmitting/other non-tx ones only later?
>
> Hmmm... I am not sure we are on the same page here. Could you please
> clarify your concerns here ?
I'm trying to say we might have this:
cfg80211
* transmitting BSS 0
- nontx BSS 1
- nontx BSS 2
- nontx BSS 3
mac80211
* ifmgd->associated (and cfg80211's wdev->current_bss?) = nontx BSS 2
Now, things like the channel information etc. will always be identical
between the 4 BSSes, by definition.
However, if you chanswitch and mac80211 just lets cfg80211 know about
the current_bss, then you may end up in a situation where the channel
information is no longer the same, which is very surprising.
> The normal (non multi-BSSID) BSS usecase seem to be clear: keep old and
> remove new (if any), since it is not easy to update ifmgd->associated.
Right.
> Now let me take another look at the usecase when STA is connected to
> a transmitting or non-transmitting BSS of a multi-BSS AP. At the moment
> suggested code does the following. If STA is connected to the non-transmitting
> BSS, then we switch to its transmitting BSS, instead of working with
> current_bss directly.
We switch? Where? Maybe I missed that.
> So we look for the new entry (with new channel) of the transmitting BSS.
> If it exists, then we remove it and _all_ of its non-transmitting BSSs.
> Finally, we update channel and location in rb-tree of the existing (old)
> transmitting BSS as well as _all_ of its non-transmitting entries.
That would indeed address the scenario I was thinking of ...
johannes
^ permalink raw reply
* RE: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: David Laight @ 2019-07-26 9:23 UTC (permalink / raw)
To: 'Jian-Hong Pan'
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <CAPpJ_ecAAw=1X=7+MOw-VVH0ZKBr6rcRub6JnEqgNbZ6Hxt=ag@mail.gmail.com>
From: Jian-Hong Pan
> Sent: 26 July 2019 07:18
...
> > While allocating all 512 buffers in one block (just over 4MB)
> > is probably not a good idea, you may need to allocated (and dma map)
> > then in groups.
>
> Thanks for reviewing. But got questions here to double confirm the idea.
> According to original code, it allocates 512 skbs for RX ring and dma
> mapping one by one. So, the new code allocates memory buffer 512
> times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> block? Do you mean aggregate the buffers as a scatterlist and use
> dma_map_sg?
If you malloc a buffer of size (8192+32) the allocator will either
round it up to a whole number of (often 4k) pages or to a power of
2 of pages - so either 12k of 16k.
I think the Linux allocator does the latter.
Some of the allocators also 'steal' a bit from the front of the buffer
for 'red tape'.
OTOH malloc the space 15 buffers and the allocator will round the
15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
buffers.
You then dma_map the large buffer and split into the actual rx buffers.
Repeat until you've filled the entire ring.
The only complication is remembering the base address (and size) for
the dma_unmap and free.
Although there is plenty of padding to extend the buffer structure
significantly without using more memory.
Allocate in 15's and you (probably) have 512 bytes per buffer.
Allocate in 31's and you have 256 bytes.
The problem is that larger allocates are more likely to fail
(especially if the system has been running for some time).
So you almost certainly want to be able to fall back to smaller
allocates even though they use more memory.
I also wonder if you actually need 512 8k rx buffers to cover
interrupt latency?
I've not done any measurements for 20 years!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH] rtw88: pci: Use general byte arrays as the elements of RX ring
From: Jian-Hong Pan @ 2019-07-26 9:40 UTC (permalink / raw)
To: David Laight
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux@endlessm.com,
stable@vger.kernel.org
In-Reply-To: <c2cdffd30923459e8773379fc2927e1d@AcuMS.aculab.com>
David Laight <David.Laight@aculab.com> 於 2019年7月26日 週五 下午5:23寫道：
>
> From: Jian-Hong Pan
> > Sent: 26 July 2019 07:18
> ...
> > > While allocating all 512 buffers in one block (just over 4MB)
> > > is probably not a good idea, you may need to allocated (and dma map)
> > > then in groups.
> >
> > Thanks for reviewing. But got questions here to double confirm the idea.
> > According to original code, it allocates 512 skbs for RX ring and dma
> > mapping one by one. So, the new code allocates memory buffer 512
> > times to get 512 buffer arrays. Will the 512 buffers arrays be in one
> > block? Do you mean aggregate the buffers as a scatterlist and use
> > dma_map_sg?
>
> If you malloc a buffer of size (8192+32) the allocator will either
> round it up to a whole number of (often 4k) pages or to a power of
> 2 of pages - so either 12k of 16k.
> I think the Linux allocator does the latter.
> Some of the allocators also 'steal' a bit from the front of the buffer
> for 'red tape'.
>
> OTOH malloc the space 15 buffers and the allocator will round the
> 15*(8192 + 32) up to 32*4k - and you waste under 8k across all the
> buffers.
>
> You then dma_map the large buffer and split into the actual rx buffers.
> Repeat until you've filled the entire ring.
> The only complication is remembering the base address (and size) for
> the dma_unmap and free.
> Although there is plenty of padding to extend the buffer structure
> significantly without using more memory.
> Allocate in 15's and you (probably) have 512 bytes per buffer.
> Allocate in 31's and you have 256 bytes.
>
> The problem is that larger allocates are more likely to fail
> (especially if the system has been running for some time).
> So you almost certainly want to be able to fall back to smaller
> allocates even though they use more memory.
>
> I also wonder if you actually need 512 8k rx buffers to cover
> interrupt latency?
> I've not done any measurements for 20 years!
Thanks for the explanation.
I am not sure the combination of 512 8k RX buffers. Maybe Realtek
folks can give us some idea.
Tony Chuang any comment?
Jian-Hong Pan
^ permalink raw reply
* [PATCH] ipw2x00: remove redundant assignment to err
From: Colin King @ 2019-07-26 10:06 UTC (permalink / raw)
To: Stanislav Yakovlev, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable err is initialized to a value that is never read and it
is re-assigned later. The initialization is redundant and can
be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2100.c b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
index 75c0c29d81f0..8dfbaff2d1fe 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2100.c
@@ -4413,7 +4413,7 @@ static void ipw2100_kill_works(struct ipw2100_priv *priv)
static int ipw2100_tx_allocate(struct ipw2100_priv *priv)
{
- int i, j, err = -EINVAL;
+ int i, j, err;
void *v;
dma_addr_t p;
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Sergey Matyukevich @ 2019-07-26 10:11 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <2efa83ab8120e29d1eb1be8295d59568b4eacc9a.camel@sipsolutions.net>
Hello Johannes,
> > > Right, it will be updated on RX. But then if we chanswitch, we would
> > > probably (mac80211 using a pointer to the non-transmitting BSS) update
> > > only one of the nontransmitting BSSes?
> > >
> > > Just saying that maybe we need to be careful there - or your wording
> > > might be incorrect. We might end up updating a *nontransmitting* BSS,
> > > and then its transmitting/other non-tx ones only later?
> >
> > Hmmm... I am not sure we are on the same page here. Could you please
> > clarify your concerns here ?
>
> I'm trying to say we might have this:
>
> cfg80211
> * transmitting BSS 0
> - nontx BSS 1
> - nontx BSS 2
> - nontx BSS 3
> mac80211
> * ifmgd->associated (and cfg80211's wdev->current_bss?) = nontx BSS 2
Yes, this is the use-case that I tried to address in the last revision
of the patch. Suggested approach is similar to what is done for normal
case:
- to keep this hierarchy updating channels and location in rb-tree
- remove newly added hierarchy of the same transmitting BSS on the new
channel
Note that here we update/remove not only transmitting BSSs, but their
nontx BSS hierarchies as well.
>
>
> Now, things like the channel information etc. will always be identical
> between the 4 BSSes, by definition.
>
> However, if you chanswitch and mac80211 just lets cfg80211 know about
> the current_bss, then you may end up in a situation where the channel
> information is no longer the same, which is very surprising.
>
>
> > The normal (non multi-BSSID) BSS usecase seem to be clear: keep old and
> > remove new (if any), since it is not easy to update ifmgd->associated.
>
> Right.
>
> > Now let me take another look at the usecase when STA is connected to
> > a transmitting or non-transmitting BSS of a multi-BSS AP. At the moment
> > suggested code does the following. If STA is connected to the non-transmitting
> > BSS, then we switch to its transmitting BSS, instead of working with
> > current_bss directly.
>
> We switch? Where? Maybe I missed that.
If you take a look at the top of new cfg80211_update_assoc_bss_entry
function:
+ /* use transmitting bss */
+ if (cbss->pub.transmitted_bss)
+ cbss = container_of(cbss->pub.transmitted_bss,
+ struct cfg80211_internal_bss,
+ pub);
> > So we look for the new entry (with new channel) of the transmitting BSS.
> > If it exists, then we remove it and _all_ of its non-transmitting BSSs.
> > Finally, we update channel and location in rb-tree of the existing (old)
> > transmitting BSS as well as _all_ of its non-transmitting entries.
>
> That would indeed address the scenario I was thinking of ...
Ok! Let me know if you have any other concerns or questions.
Actually one of the major concerns is the lack of testing for the 'multi-BSSID'
scenario. I verified the 'normal' scenario using both mac80211 (iwlwifi) and
FullMAC (qtnfmac) cards. But at the moment I don't have any mac80211 card
supporting multi-BSSID.
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH] mac80211: reject zero MAC address in add station
From: Johannes Berg @ 2019-07-26 11:06 UTC (permalink / raw)
To: Karthikeyan Periyasamy; +Cc: linux-wireless
In-Reply-To: <1563959770-21570-1-git-send-email-periyasa@codeaurora.org>
On Wed, 2019-07-24 at 14:46 +0530, Karthikeyan Periyasamy wrote:
> Don't allow using a zero MAC address as the station
> MAC address. so validated the MAC address using
> is_valid_ether_addr.
Theoretically, all zeroes might have been a valid address at some point.
I see no reason not to reject it, but I'd like to know why you ended up
with this now??
johannes
^ permalink raw reply
* Re: pull request: iwlwifi firmware updates 2019-07-20
From: Josh Boyer @ 2019-07-26 11:29 UTC (permalink / raw)
To: Luca Coelho
Cc: linux-firmware@kernel.org, linux-wireless@vger.kernel.org,
linuxwifi, kyle@infradead.org, ben@decadent.org.uk, dor.shaish
In-Reply-To: <b8246cb77dfc2d1344cd194682001a11a01dbf3a.camel@coelho.fi>
On Sat, Jul 20, 2019 at 4:03 AM Luca Coelho <luca@coelho.fi> wrote:
>
> Hi,
>
> This contains some updated firmwares for all our currently maintained
> FW binaries.
>
> Please pull or let me know if there are any issues.
>
> --
> Cheers,
> Luca.
>
>
> The following changes since commit bf13a71b18af229b4c900b321ef1f8443028ded8:
>
> Merge branch 'guc_v33' of git://anongit.freedesktop.org/drm/drm-firmware (2019-07-17 09:05:52 -0400)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git tags/iwlwifi-fw-2019-07-20
>
> for you to fetch changes up to cd6cb7bc50aa77d531c4417ffe1237510b71c73e:
>
> iwlwifi: update -48 FWs for Qu and cc (2019-07-20 10:58:24 +0300)
>
> ----------------------------------------------------------------
> iwlwifi: update a bunch of FW binaries
>
> ----------------------------------------------------------------
> Luca Coelho (2):
> iwlwifi: update FWs for 3168, 7265D, 9000, 9260, 8000, 8265 and cc
> iwlwifi: update -48 FWs for Qu and cc
>
> iwlwifi-3168-29.ucode | Bin 1036276 -> 1036300 bytes
> iwlwifi-7265D-29.ucode | Bin 1036432 -> 1036668 bytes
> iwlwifi-8000C-36.ucode | Bin 2400700 -> 2401356 bytes
> iwlwifi-8265-36.ucode | Bin 2414296 -> 2414592 bytes
> iwlwifi-9000-pu-b0-jf-b0-46.ucode | Bin 1460788 -> 1467952 bytes
> iwlwifi-9260-th-b0-jf-b0-46.ucode | Bin 1462324 -> 1469012 bytes
> iwlwifi-Qu-b0-hr-b0-48.ucode | Bin 1106208 -> 1106204 bytes
> iwlwifi-Qu-b0-jf-b0-48.ucode | Bin 1053156 -> 1052772 bytes
> iwlwifi-Qu-c0-hr-b0-48.ucode | Bin 1106228 -> 1106224 bytes
> iwlwifi-Qu-c0-jf-b0-48.ucode | Bin 1053176 -> 1052792 bytes
> iwlwifi-QuZ-a0-hr-b0-48.ucode | Bin 1105648 -> 1105644 bytes
> iwlwifi-QuZ-a0-jf-b0-48.ucode | Bin 1052968 -> 1052584 bytes
> iwlwifi-cc-a0-46.ucode | Bin 1044072 -> 1044452 bytes
> iwlwifi-cc-a0-48.ucode | Bin 1096684 -> 1096680 bytes
> 14 files changed, 0 insertions(+), 0 deletions(-)
Pulled and pushed out.
josh
^ permalink raw reply
* Re: [PATCH V3 2/2] mac80211: add support for the ADDBA extension element
From: Johannes Berg @ 2019-07-26 11:36 UTC (permalink / raw)
To: John Crispin; +Cc: linux-wireless, Shashidhar Lakkavalli
In-Reply-To: <20190713163642.18491-3-john@phrozen.org>
Hi,
Apologies for the late review.
I've applied patch 1, but not this one yet:
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_2 0x10
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_LEVEL_3 0x18
> #define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK 0x18
> +#define IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT 3
this will not be needed,
> -static void ieee80211_send_addba_resp(struct ieee80211_sub_if_data *sdata, u8 *da, u16 tid,
> +static void ieee80211_add_addbaext(struct ieee80211_sub_if_data *sdata,
> + struct sk_buff *skb,
> + const struct ieee80211_addba_ext_ie *req)
> +{
> + struct ieee80211_supported_band *sband;
> + struct ieee80211_addba_ext_ie *resp;
> + const struct ieee80211_sta_he_cap *he_cap;
> + u8 frag_level, cap_frag_level;
> + u8 *pos;
> +
> + sband = ieee80211_get_sband(sdata);
> + he_cap = ieee80211_get_he_iftype_cap(sband, sdata->vif.type);
> + if (!he_cap)
> + return;
> +
> + pos = skb_put_zero(skb, 2 + sizeof(struct ieee80211_addba_ext_ie));
> + *pos++ = WLAN_EID_ADDBA_EXT;
> + *pos++ = sizeof(struct ieee80211_addba_ext_ie);
> + resp = (struct ieee80211_addba_ext_ie *)pos;
> + resp->data = req->data & IEEE80211_ADDBA_EXT_NO_FRAG;
> +
> + frag_level = (req->data & IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK) >>
> + IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT;
> + cap_frag_level = (he_cap->he_cap_elem.mac_cap_info[0] &
> + IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_MASK) >>
> + IEEE80211_HE_MAC_CAP0_DYNAMIC_FRAG_SHIFT;
if you use u32_get_bits() from bitfield.h here for these two
assignments, which is nicer anyway.
> + if (frag_level > cap_frag_level)
> + frag_level = cap_frag_level;
> + resp->data |= (frag_level << IEEE80211_ADDBA_EXT_FRAG_LEVEL_SHIFT) &
> + IEEE80211_ADDBA_EXT_FRAG_LEVEL_MASK;
and probably that could also be u8_encode_bits()?
> - skb = dev_alloc_skb(sizeof(*mgmt) + local->hw.extra_tx_headroom);
> + skb = dev_alloc_skb(sizeof(*mgmt) +
> + (addbaext ? 2 + sizeof(struct ieee80211_addba_ext_ie) : 0) +
> + local->hw.extra_tx_headroom);
not much point in the if (ternary operator) for ... 3 bytes? :-)
johannes
^ permalink raw reply
* Re: [PATCH V3 2/2] mac80211: allow setting spatial reuse parameters from bss_conf
From: Johannes Berg @ 2019-07-26 11:48 UTC (permalink / raw)
To: John Crispin; +Cc: linux-wireless, Shashidhar Lakkavalli
In-Reply-To: <20190618061915.7102-3-john@phrozen.org>
On Tue, 2019-06-18 at 08:19 +0200, John Crispin wrote:
> Store the OBSS PD parameters inside bss_conf when bringing up an AP and/or
> when a station connects to an AP. This allows the driver to configure the
> HW accordingly.
>
> Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
> Signed-off-by: John Crispin <john@phrozen.org>
> ---
> include/net/cfg80211.h | 15 +++++++++++++
> include/net/mac80211.h | 4 ++++
> include/uapi/linux/nl80211.h | 27 ++++++++++++++++++++++
> net/mac80211/cfg.c | 5 ++++-
> net/mac80211/he.c | 24 ++++++++++++++++++++
> net/mac80211/ieee80211_i.h | 3 +++
> net/mac80211/mlme.c | 1 +
> net/wireless/nl80211.c | 43 ++++++++++++++++++++++++++++++++++++
> 8 files changed, 121 insertions(+), 1 deletion(-)
Not sure if I missed this before, but in any case please split between
cfg80211 and mac80211 for all but the most trivial patches.
> +/**
> + * enum nl80211_he_spr - spatial reuse attributes
bad copy/paste? :)
> + * @__NL80211_HE_OBSS_PD_ATTR_INVALID: Invalid
> + *
> + * @NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET: the OBSS PD minimum tx power offset.
> + * @NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET: the OBSS PD maximum tx power offset.
> + *
> + * @__NL80211_HE_OBSS_PD_ATTR_LAST: Internal
> + * @NL80211_HE_OBSS_PD_ATTR_MAX: highest spiatl reuse attribute.
typo & wrong anyway, OBSS PD not SPR
> + */
Those prefixes are a bit confusing - IMHO they should all be
NL80211_HE_OBSS_PD_ATTR_*, NL80211_ATTR_* is mostly (except for a few
historical bugs) the top-level attributes.
> +enum nl80211_he_spr_attributes {
here also
> + memcpy(&sdata->vif.bss_conf.he_obss_pd, ¶ms->he_obss_pd,
> + sizeof(struct ieee80211_he_obss_pd));
just use struct assignment
blabla.he_obss_pd = params->he_obss_pd;
> + [NL80211_ATTR_HE_OBSS_PD] = { .type = NLA_NESTED },
please use NLA_POLICY_NESTED() (requires putting the below policy above
this point)
> +static const struct nla_policy
> + he_spr_policy[NL80211_HE_OBSS_PD_ATTR_MAX + 1] = {
I guess I'd lose all the tabs here but don't really care that much.
> + [NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET] = { .type = NLA_U32 },
> + [NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET] = { .type = NLA_U32 },
That can't be right, they go into u8 eventually, no? Use NLA_U8 or maybe
even NLA_POLICY_RANGE().
Also in the struct ieee80211_he_obss_pd you have u32 for no real reason?
In the element in the frame you only used a single u8.
> + if (!tb[NL80211_ATTR_HE_OBSS_PD_MIN_OFFSET] ||
> + !tb[NL80211_ATTR_HE_OBSS_PD_MAX_OFFSET])
> + return -EINVAL;
> + if (he_obss_pd->min_offset >= he_obss_pd->max_offset)
> + return -EINVAL;
Maybe add some extack error messages for this.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 0/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 12:02 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190726101150.lykay6apgzvsb4ov@bars>
Hi Sergey,
> Yes, this is the use-case that I tried to address in the last revision
> of the patch.
OK! I didn't see it here and I guess I didn't look at the latest version
yet, or I missed it.
> If you take a look at the top of new cfg80211_update_assoc_bss_entry
> function:
>
> + /* use transmitting bss */
> + if (cbss->pub.transmitted_bss)
> + cbss = container_of(cbss->pub.transmitted_bss,
> + struct cfg80211_internal_bss,
> + pub);
Right, makes sense!
> Actually one of the major concerns is the lack of testing for the 'multi-BSSID'
> scenario. I verified the 'normal' scenario using both mac80211 (iwlwifi) and
> FullMAC (qtnfmac) cards. But at the moment I don't have any mac80211 card
> supporting multi-BSSID.
You might be able to do that with hwsim? There are multi-bssid test
cases in the hostap repository, and CSA test cases as well, so I guess
it'd be possible to come up with a combined one.
I'm not *too* worried about this though - we're still all testing and
developing this.
johannes
^ permalink raw reply
* Re: [RFC PATCH v3 2/2] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-26 12:04 UTC (permalink / raw)
To: Sergey Matyukevich, linux-wireless@vger.kernel.org
Cc: Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190710173651.15770-3-sergey.matyukevich.os@quantenna.com>
Umm, regarding multi-BSSID, I'm clearly just not paying any attention
... sorry about that.
This looks good to me, can you resend as just PATCH?
Thanks,
johannes
^ permalink raw reply
* [RFC] mt76: fix tx hung regression on MT7630E
From: Stanislaw Gruszka @ 2019-07-26 12:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Ryder Lee, Roy Luo
Since 41634aa8d6db ("mt76: only schedule txqs from the tx tasklet")
I can observe firmware hangs on MT7630E on station mode: tx stop
functioning after minor activity (rx keep working) and on module
unload device fail to stop with messages:
[ 5446.141413] mt76x0e 0000:06:00.0: TX DMA did not stop
[ 5449.176764] mt76x0e 0000:06:00.0: TX DMA did not stop
Loading module again results in failure to associate with AP.
Only machine power off / power on cycle can make device work again.
I have no idea why the commit caused F/W hangs. Most likely some proper
fix is needed of changing registers programming (or assuring proper order
of actions), but so far I can not came up with any better fix than
a partial revert of 41634aa8d6db.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 5397827668b9..fefe0ee52584 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -598,7 +598,7 @@ void mt76_wake_tx_queue(struct ieee80211_hw *hw, struct ieee80211_txq *txq)
if (!test_bit(MT76_STATE_RUNNING, &dev->state))
return;
- tasklet_schedule(&dev->tx_tasklet);
+ mt76_txq_schedule(dev, txq->ac);
}
EXPORT_SYMBOL_GPL(mt76_wake_tx_queue);
--
1.9.3
^ permalink raw reply related
* Re: [RFC PATCH v3 2/2] cfg80211: fix duplicated scan entries after channel switch
From: Sergey Matyukevich @ 2019-07-26 12:30 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <92167a1803b9f90d231b080c9edfbf335c4685ed.camel@sipsolutions.net>
> Umm, regarding multi-BSSID, I'm clearly just not paying any attention
> ... sorry about that.
>
>
> This looks good to me, can you resend as just PATCH?
Sure, I will rebase on top of latest mac80211-next and resend.
Regards,
Sergey
^ permalink raw reply
* [PATCH v2 00/26] ReST conversion of text files without .txt extension
From: Mauro Carvalho Chehab @ 2019-07-26 12:51 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel, linux-pm,
linux-arm-kernel, linux-samsung-soc, linux-pci, linuxppc-dev,
linux-scsi, devicetree, linux-i2c, linux-hwmon, linux-spi,
linux-iio, linux-rtc, netdev, linux-parisc, openrisc, devel,
linux-cifs, samba-technical, devel, dmaengine, alsa-devel,
linux-mips, linux-wireless, rcu
This series converts the text files under Documentation with doesn't end
neither .txt or .rst and are not part of ABI or features.
This series is at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=rst_for_5_4_v3
And it is based on yesterday's upstream tree.
After this series, we have ~320 files left to be converted to ReST.
v2:
- Added 3 files submitted for v5.3 that weren't merged yet;
- markdown patch broken into two, per Rob's request;
- rebased on the top of upstream master branch
Mauro Carvalho Chehab (26):
docs: power: add it to to the main documentation index
docs: thermal: add it to the driver API
docs: powerpc: convert docs to ReST and rename to *.rst
docs: ubifs-authentication.md: convert to ReST
docs: writing-schema.md: convert from markdown to ReST
docs: i2c: convert to ReST and add to driver-api bookset
docs: w1: convert to ReST and add to the kAPI group of docs
spi: docs: convert to ReST and add it to the kABI bookset
docs: ipmb: place it at driver-api and convert to ReST
docs: packing: move it to core-api book and adjust markups
docs: admin-guide: add auxdisplay files to it after conversion to ReST
docs: README.buddha: convert to ReST and add to m68k book
docs: parisc: convert to ReST and add to documentation body
docs: openrisc: convert to ReST and add to documentation body
docs: isdn: convert to ReST and add to kAPI bookset
docs: fs: cifs: convert to ReST and add to admin-guide book
docs: fs: convert docs without extension to ReST
docs: fs: convert porting to ReST
docs: index.rst: don't use genindex for pdf output
docs: wimax: convert to ReST and add to admin-guide
docs: mips: add to the documentation body as ReST
docs: hwmon: pxe1610: convert to ReST format and add to the index
docs: nios2: add it to the main Documentation body
docs: net: convert two README files to ReST format
docs: rcu: convert some articles from html to ReST
docs: ABI: remove extension from sysfs-class-mic.txt
Documentation/ABI/stable/sysfs-bus-w1 | 2 +-
.../ABI/stable/sysfs-driver-w1_ds28e04 | 4 +-
.../ABI/stable/sysfs-driver-w1_ds28ea00 | 2 +-
.../{sysfs-class-mic.txt => sysfs-class-mic} | 0
Documentation/PCI/pci-error-recovery.rst | 2 +-
.../Data-Structures/Data-Structures.html | 1391 -------
.../Data-Structures/Data-Structures.rst | 1163 ++++++
...riods.html => Expedited-Grace-Periods.rst} | 949 ++---
.../Memory-Ordering/Tree-RCU-Diagram.html | 9 -
...ring.html => Tree-RCU-Memory-Ordering.rst} | 1181 +++---
.../RCU/Design/Requirements/Requirements.html | 3330 -----------------
.../RCU/Design/Requirements/Requirements.rst | 2662 +++++++++++++
Documentation/RCU/index.rst | 5 +
Documentation/RCU/whatisRCU.txt | 4 +-
.../auxdisplay/cfag12864b.rst} | 115 +-
.../admin-guide/auxdisplay/index.rst | 16 +
.../auxdisplay/ks0108.rst} | 53 +-
.../AUTHORS => admin-guide/cifs/authors.rst} | 64 +-
.../CHANGES => admin-guide/cifs/changes.rst} | 4 +
Documentation/admin-guide/cifs/index.rst | 21 +
.../cifs/introduction.rst} | 8 +
.../cifs/TODO => admin-guide/cifs/todo.rst} | 87 +-
.../README => admin-guide/cifs/usage.rst} | 560 +--
.../cifs/winucase_convert.pl | 0
Documentation/admin-guide/index.rst | 3 +
.../wimax/i2400m.rst} | 145 +-
Documentation/admin-guide/wimax/index.rst | 19 +
.../wimax/wimax.rst} | 36 +-
Documentation/core-api/index.rst | 3 +-
.../{packing.txt => core-api/packing.rst} | 81 +-
.../devicetree/bindings/i2c/i2c-mux-gpmux.txt | 2 +-
.../{writing-schema.md => writing-schema.rst} | 137 +-
Documentation/driver-api/dmaengine/index.rst | 2 +-
Documentation/driver-api/index.rst | 2 +
Documentation/driver-api/ipmb.rst | 2 +-
Documentation/driver-api/soundwire/index.rst | 2 +-
.../thermal/cpu-cooling-api.rst | 0
.../thermal/exynos_thermal.rst | 0
.../thermal/exynos_thermal_emulation.rst | 0
.../{ => driver-api}/thermal/index.rst | 2 +-
.../thermal/intel_powerclamp.rst | 0
.../thermal/nouveau_thermal.rst | 0
.../thermal/power_allocator.rst | 0
.../{ => driver-api}/thermal/sysfs-api.rst | 12 +-
.../thermal/x86_pkg_temperature_thermal.rst | 2 +-
...irectory-locking => directory-locking.rst} | 40 +-
Documentation/filesystems/index.rst | 4 +
.../filesystems/{Locking => locking.rst} | 257 +-
.../nfs/{Exporting => exporting.rst} | 31 +-
.../filesystems/{porting => porting.rst} | 824 ++--
...entication.md => ubifs-authentication.rst} | 70 +-
Documentation/filesystems/vfs.rst | 2 +-
Documentation/hwmon/adm1021.rst | 2 +-
Documentation/hwmon/adm1275.rst | 2 +-
Documentation/hwmon/hih6130.rst | 2 +-
Documentation/hwmon/ibm-cffps.rst | 2 +-
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/lm25066.rst | 2 +-
Documentation/hwmon/max16064.rst | 2 +-
Documentation/hwmon/max16065.rst | 2 +-
Documentation/hwmon/max20751.rst | 2 +-
Documentation/hwmon/max34440.rst | 2 +-
Documentation/hwmon/max6650.rst | 2 +-
Documentation/hwmon/max8688.rst | 2 +-
Documentation/hwmon/menf21bmc.rst | 2 +-
Documentation/hwmon/pcf8591.rst | 2 +-
Documentation/hwmon/{pxe1610 => pxe1610.rst} | 33 +-
Documentation/hwmon/sht3x.rst | 2 +-
Documentation/hwmon/shtc1.rst | 2 +-
Documentation/hwmon/tmp103.rst | 2 +-
Documentation/hwmon/tps40422.rst | 2 +-
Documentation/hwmon/ucd9000.rst | 2 +-
Documentation/hwmon/ucd9200.rst | 2 +-
Documentation/hwmon/via686a.rst | 2 +-
Documentation/hwmon/zl6100.rst | 2 +-
.../busses/{i2c-ali1535 => i2c-ali1535.rst} | 13 +-
.../busses/{i2c-ali1563 => i2c-ali1563.rst} | 3 +
.../busses/{i2c-ali15x3 => i2c-ali15x3.rst} | 64 +-
.../busses/{i2c-amd-mp2 => i2c-amd-mp2.rst} | 14 +-
.../i2c/busses/{i2c-amd756 => i2c-amd756.rst} | 8 +-
.../busses/{i2c-amd8111 => i2c-amd8111.rst} | 14 +-
.../{i2c-diolan-u2c => i2c-diolan-u2c.rst} | 3 +
.../i2c/busses/{i2c-i801 => i2c-i801.rst} | 33 +-
.../i2c/busses/{i2c-ismt => i2c-ismt.rst} | 20 +-
.../busses/{i2c-mlxcpld => i2c-mlxcpld.rst} | 6 +
.../busses/{i2c-nforce2 => i2c-nforce2.rst} | 33 +-
.../{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} | 6 +-
.../i2c/busses/{i2c-ocores => i2c-ocores.rst} | 22 +-
...2c-parport-light => i2c-parport-light.rst} | 8 +-
.../busses/{i2c-parport => i2c-parport.rst} | 164 +-
.../busses/{i2c-pca-isa => i2c-pca-isa.rst} | 9 +-
.../i2c/busses/{i2c-piix4 => i2c-piix4.rst} | 18 +-
.../busses/{i2c-sis5595 => i2c-sis5595.rst} | 19 +-
.../i2c/busses/{i2c-sis630 => i2c-sis630.rst} | 39 +-
.../i2c/busses/{i2c-sis96x => i2c-sis96x.rst} | 31 +-
.../busses/{i2c-taos-evm => i2c-taos-evm.rst} | 8 +-
.../i2c/busses/{i2c-via => i2c-via.rst} | 28 +-
.../i2c/busses/{i2c-viapro => i2c-viapro.rst} | 12 +-
Documentation/i2c/busses/index.rst | 33 +
.../i2c/busses/{scx200_acb => scx200_acb.rst} | 9 +-
.../i2c/{dev-interface => dev-interface.rst} | 94 +-
...-considerations => dma-considerations.rst} | 0
.../i2c/{fault-codes => fault-codes.rst} | 5 +-
.../i2c/{functionality => functionality.rst} | 22 +-
...ult-injection => gpio-fault-injection.rst} | 12 +-
.../i2c/{i2c-protocol => i2c-protocol.rst} | 28 +-
Documentation/i2c/{i2c-stub => i2c-stub.rst} | 20 +-
.../i2c/{i2c-topology => i2c-topology.rst} | 68 +-
Documentation/i2c/index.rst | 37 +
...ting-devices => instantiating-devices.rst} | 45 +-
.../muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} | 26 +-
...e-parameters => old-module-parameters.rst} | 27 +-
...eprom-backend => slave-eeprom-backend.rst} | 4 +-
.../{slave-interface => slave-interface.rst} | 33 +-
.../{smbus-protocol => smbus-protocol.rst} | 86 +-
Documentation/i2c/{summary => summary.rst} | 6 +-
...en-bit-addresses => ten-bit-addresses.rst} | 5 +
...pgrading-clients => upgrading-clients.rst} | 204 +-
.../{writing-clients => writing-clients.rst} | 94 +-
Documentation/index.rst | 10 +
.../isdn/{README.avmb1 => avmb1.rst} | 231 +-
Documentation/isdn/{CREDITS => credits.rst} | 7 +-
.../isdn/{README.gigaset => gigaset.rst} | 290 +-
.../isdn/{README.hysdn => hysdn.rst} | 125 +-
Documentation/isdn/index.rst | 24 +
.../{INTERFACE.CAPI => interface_capi.rst} | 182 +-
.../isdn/{README.mISDN => m_isdn.rst} | 5 +-
.../m68k/{README.buddha => buddha-driver.rst} | 95 +-
Documentation/m68k/index.rst | 1 +
.../{AU1xxx_IDE.README => au1xxx_ide.rst} | 89 +-
Documentation/mips/index.rst | 17 +
.../networking/caif/{README => caif.rst} | 88 +-
.../networking/device_drivers/index.rst | 2 +-
Documentation/networking/index.rst | 2 +-
.../{README => mac80211_hwsim.rst} | 28 +-
Documentation/nios2/{README => nios2.rst} | 1 +
Documentation/openrisc/index.rst | 18 +
.../openrisc/{README => openrisc_port.rst} | 25 +-
Documentation/openrisc/{TODO => todo.rst} | 9 +-
.../parisc/{debugging => debugging.rst} | 7 +
Documentation/parisc/index.rst | 18 +
.../parisc/{registers => registers.rst} | 59 +-
Documentation/power/index.rst | 2 +-
.../{bootwrapper.txt => bootwrapper.rst} | 28 +-
.../{cpu_families.txt => cpu_families.rst} | 23 +-
.../{cpu_features.txt => cpu_features.rst} | 6 +-
Documentation/powerpc/{cxl.txt => cxl.rst} | 46 +-
.../powerpc/{cxlflash.txt => cxlflash.rst} | 10 +-
.../{DAWR-POWER9.txt => dawr-power9.rst} | 15 +-
Documentation/powerpc/{dscr.txt => dscr.rst} | 18 +-
...ecovery.txt => eeh-pci-error-recovery.rst} | 108 +-
...ed-dump.txt => firmware-assisted-dump.rst} | 117 +-
Documentation/powerpc/{hvcs.txt => hvcs.rst} | 108 +-
Documentation/powerpc/index.rst | 34 +
Documentation/powerpc/isa-versions.rst | 15 +-
.../powerpc/{mpc52xx.txt => mpc52xx.rst} | 12 +-
...nv.txt => pci_iov_resource_on_powernv.rst} | 15 +-
.../powerpc/{pmu-ebb.txt => pmu-ebb.rst} | 1 +
.../powerpc/{ptrace.txt => ptrace.rst} | 169 +-
.../{qe_firmware.txt => qe_firmware.rst} | 37 +-
.../{syscall64-abi.txt => syscall64-abi.rst} | 29 +-
...al_memory.txt => transactional_memory.rst} | 45 +-
Documentation/sound/index.rst | 2 +-
.../spi/{butterfly => butterfly.rst} | 44 +-
Documentation/spi/index.rst | 22 +
Documentation/spi/{pxa2xx => pxa2xx.rst} | 95 +-
.../spi/{spi-lm70llp => spi-lm70llp.rst} | 17 +-
.../spi/{spi-sc18is602 => spi-sc18is602.rst} | 5 +-
.../spi/{spi-summary => spi-summary.rst} | 105 +-
Documentation/spi/{spidev => spidev.rst} | 30 +-
Documentation/w1/index.rst | 21 +
.../w1/masters/{ds2482 => ds2482.rst} | 16 +-
.../w1/masters/{ds2490 => ds2490.rst} | 6 +-
Documentation/w1/masters/index.rst | 14 +
.../w1/masters/{mxc-w1 => mxc-w1.rst} | 13 +-
.../w1/masters/{omap-hdq => omap-hdq.rst} | 12 +-
.../w1/masters/{w1-gpio => w1-gpio.rst} | 21 +-
Documentation/w1/slaves/index.rst | 16 +
.../w1/slaves/{w1_ds2406 => w1_ds2406.rst} | 4 +-
.../w1/slaves/{w1_ds2413 => w1_ds2413.rst} | 9 +
.../w1/slaves/{w1_ds2423 => w1_ds2423.rst} | 27 +-
.../w1/slaves/{w1_ds2438 => w1_ds2438.rst} | 10 +-
.../w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} | 5 +
.../w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} | 16 +-
.../w1/slaves/{w1_therm => w1_therm.rst} | 11 +-
.../w1/{w1.generic => w1-generic.rst} | 88 +-
.../w1/{w1.netlink => w1-netlink.rst} | 89 +-
MAINTAINERS | 68 +-
arch/powerpc/kernel/exceptions-64s.S | 2 +-
drivers/auxdisplay/Kconfig | 2 +-
drivers/hwmon/atxp1.c | 2 +-
drivers/hwmon/smm665.c | 2 +-
drivers/i2c/Kconfig | 4 +-
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-i801.c | 2 +-
drivers/i2c/busses/i2c-taos-evm.c | 2 +-
drivers/i2c/i2c-core-base.c | 4 +-
drivers/iio/dummy/iio_simple_dummy.c | 4 +-
drivers/rtc/rtc-ds1374.c | 2 +-
drivers/soc/fsl/qe/qe.c | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/spi/spi-butterfly.c | 2 +-
drivers/spi/spi-lm70llp.c | 2 +-
drivers/staging/isdn/hysdn/Kconfig | 2 +-
drivers/tty/hvc/hvcs.c | 2 +-
fs/cifs/export.c | 2 +-
fs/exportfs/expfs.c | 2 +-
fs/isofs/export.c | 2 +-
fs/orangefs/file.c | 2 +-
fs/orangefs/orangefs-kernel.h | 2 +-
include/linux/dcache.h | 2 +-
include/linux/exportfs.h | 2 +-
include/linux/i2c.h | 2 +-
include/linux/platform_data/sc18is602.h | 2 +-
include/linux/thermal.h | 4 +-
include/soc/fsl/qe/qe.h | 2 +-
216 files changed, 9148 insertions(+), 8672 deletions(-)
rename Documentation/ABI/testing/{sysfs-class-mic.txt => sysfs-class-mic} (100%)
delete mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.html
create mode 100644 Documentation/RCU/Design/Data-Structures/Data-Structures.rst
rename Documentation/RCU/Design/Expedited-Grace-Periods/{Expedited-Grace-Periods.html => Expedited-Grace-Periods.rst} (15%)
delete mode 100644 Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Diagram.html
rename Documentation/RCU/Design/Memory-Ordering/{Tree-RCU-Memory-Ordering.html => Tree-RCU-Memory-Ordering.rst} (10%)
delete mode 100644 Documentation/RCU/Design/Requirements/Requirements.html
create mode 100644 Documentation/RCU/Design/Requirements/Requirements.rst
rename Documentation/{auxdisplay/cfag12864b => admin-guide/auxdisplay/cfag12864b.rst} (26%)
create mode 100644 Documentation/admin-guide/auxdisplay/index.rst
rename Documentation/{auxdisplay/ks0108 => admin-guide/auxdisplay/ks0108.rst} (32%)
rename Documentation/{filesystems/cifs/AUTHORS => admin-guide/cifs/authors.rst} (60%)
rename Documentation/{filesystems/cifs/CHANGES => admin-guide/cifs/changes.rst} (91%)
create mode 100644 Documentation/admin-guide/cifs/index.rst
rename Documentation/{filesystems/cifs/cifs.txt => admin-guide/cifs/introduction.rst} (98%)
rename Documentation/{filesystems/cifs/TODO => admin-guide/cifs/todo.rst} (58%)
rename Documentation/{filesystems/cifs/README => admin-guide/cifs/usage.rst} (72%)
rename Documentation/{filesystems => admin-guide}/cifs/winucase_convert.pl (100%)
rename Documentation/{wimax/README.i2400m => admin-guide/wimax/i2400m.rst} (69%)
create mode 100644 Documentation/admin-guide/wimax/index.rst
rename Documentation/{wimax/README.wimax => admin-guide/wimax/wimax.rst} (74%)
rename Documentation/{packing.txt => core-api/packing.rst} (61%)
rename Documentation/devicetree/{writing-schema.md => writing-schema.rst} (48%)
rename Documentation/{ => driver-api}/thermal/cpu-cooling-api.rst (100%)
rename Documentation/{ => driver-api}/thermal/exynos_thermal.rst (100%)
rename Documentation/{ => driver-api}/thermal/exynos_thermal_emulation.rst (100%)
rename Documentation/{ => driver-api}/thermal/index.rst (86%)
rename Documentation/{ => driver-api}/thermal/intel_powerclamp.rst (100%)
rename Documentation/{ => driver-api}/thermal/nouveau_thermal.rst (100%)
rename Documentation/{ => driver-api}/thermal/power_allocator.rst (100%)
rename Documentation/{ => driver-api}/thermal/sysfs-api.rst (98%)
rename Documentation/{ => driver-api}/thermal/x86_pkg_temperature_thermal.rst (94%)
rename Documentation/filesystems/{directory-locking => directory-locking.rst} (86%)
rename Documentation/filesystems/{Locking => locking.rst} (79%)
rename Documentation/filesystems/nfs/{Exporting => exporting.rst} (91%)
rename Documentation/filesystems/{porting => porting.rst} (49%)
rename Documentation/filesystems/{ubifs-authentication.md => ubifs-authentication.rst} (95%)
rename Documentation/hwmon/{pxe1610 => pxe1610.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1535 => i2c-ali1535.rst} (82%)
rename Documentation/i2c/busses/{i2c-ali1563 => i2c-ali1563.rst} (93%)
rename Documentation/i2c/busses/{i2c-ali15x3 => i2c-ali15x3.rst} (72%)
rename Documentation/i2c/busses/{i2c-amd-mp2 => i2c-amd-mp2.rst} (42%)
rename Documentation/i2c/busses/{i2c-amd756 => i2c-amd756.rst} (79%)
rename Documentation/i2c/busses/{i2c-amd8111 => i2c-amd8111.rst} (66%)
rename Documentation/i2c/busses/{i2c-diolan-u2c => i2c-diolan-u2c.rst} (91%)
rename Documentation/i2c/busses/{i2c-i801 => i2c-i801.rst} (89%)
rename Documentation/i2c/busses/{i2c-ismt => i2c-ismt.rst} (81%)
rename Documentation/i2c/busses/{i2c-mlxcpld => i2c-mlxcpld.rst} (88%)
rename Documentation/i2c/busses/{i2c-nforce2 => i2c-nforce2.rst} (58%)
rename Documentation/i2c/busses/{i2c-nvidia-gpu => i2c-nvidia-gpu.rst} (63%)
rename Documentation/i2c/busses/{i2c-ocores => i2c-ocores.rst} (82%)
rename Documentation/i2c/busses/{i2c-parport-light => i2c-parport-light.rst} (91%)
rename Documentation/i2c/busses/{i2c-parport => i2c-parport.rst} (49%)
rename Documentation/i2c/busses/{i2c-pca-isa => i2c-pca-isa.rst} (72%)
rename Documentation/i2c/busses/{i2c-piix4 => i2c-piix4.rst} (92%)
rename Documentation/i2c/busses/{i2c-sis5595 => i2c-sis5595.rst} (74%)
rename Documentation/i2c/busses/{i2c-sis630 => i2c-sis630.rst} (37%)
rename Documentation/i2c/busses/{i2c-sis96x => i2c-sis96x.rst} (74%)
rename Documentation/i2c/busses/{i2c-taos-evm => i2c-taos-evm.rst} (91%)
rename Documentation/i2c/busses/{i2c-via => i2c-via.rst} (54%)
rename Documentation/i2c/busses/{i2c-viapro => i2c-viapro.rst} (87%)
create mode 100644 Documentation/i2c/busses/index.rst
rename Documentation/i2c/busses/{scx200_acb => scx200_acb.rst} (86%)
rename Documentation/i2c/{dev-interface => dev-interface.rst} (71%)
rename Documentation/i2c/{DMA-considerations => dma-considerations.rst} (100%)
rename Documentation/i2c/{fault-codes => fault-codes.rst} (98%)
rename Documentation/i2c/{functionality => functionality.rst} (91%)
rename Documentation/i2c/{gpio-fault-injection => gpio-fault-injection.rst} (97%)
rename Documentation/i2c/{i2c-protocol => i2c-protocol.rst} (83%)
rename Documentation/i2c/{i2c-stub => i2c-stub.rst} (93%)
rename Documentation/i2c/{i2c-topology => i2c-topology.rst} (89%)
create mode 100644 Documentation/i2c/index.rst
rename Documentation/i2c/{instantiating-devices => instantiating-devices.rst} (93%)
rename Documentation/i2c/muxes/{i2c-mux-gpio => i2c-mux-gpio.rst} (85%)
rename Documentation/i2c/{old-module-parameters => old-module-parameters.rst} (75%)
rename Documentation/i2c/{slave-eeprom-backend => slave-eeprom-backend.rst} (90%)
rename Documentation/i2c/{slave-interface => slave-interface.rst} (94%)
rename Documentation/i2c/{smbus-protocol => smbus-protocol.rst} (82%)
rename Documentation/i2c/{summary => summary.rst} (96%)
rename Documentation/i2c/{ten-bit-addresses => ten-bit-addresses.rst} (95%)
rename Documentation/i2c/{upgrading-clients => upgrading-clients.rst} (54%)
rename Documentation/i2c/{writing-clients => writing-clients.rst} (91%)
rename Documentation/isdn/{README.avmb1 => avmb1.rst} (50%)
rename Documentation/isdn/{CREDITS => credits.rst} (96%)
rename Documentation/isdn/{README.gigaset => gigaset.rst} (74%)
rename Documentation/isdn/{README.hysdn => hysdn.rst} (80%)
create mode 100644 Documentation/isdn/index.rst
rename Documentation/isdn/{INTERFACE.CAPI => interface_capi.rst} (75%)
rename Documentation/isdn/{README.mISDN => m_isdn.rst} (89%)
rename Documentation/m68k/{README.buddha => buddha-driver.rst} (73%)
rename Documentation/mips/{AU1xxx_IDE.README => au1xxx_ide.rst} (67%)
create mode 100644 Documentation/mips/index.rst
rename Documentation/networking/caif/{README => caif.rst} (70%)
rename Documentation/networking/mac80211_hwsim/{README => mac80211_hwsim.rst} (81%)
rename Documentation/nios2/{README => nios2.rst} (96%)
create mode 100644 Documentation/openrisc/index.rst
rename Documentation/openrisc/{README => openrisc_port.rst} (80%)
rename Documentation/openrisc/{TODO => todo.rst} (78%)
rename Documentation/parisc/{debugging => debugging.rst} (94%)
create mode 100644 Documentation/parisc/index.rst
rename Documentation/parisc/{registers => registers.rst} (70%)
rename Documentation/powerpc/{bootwrapper.txt => bootwrapper.rst} (93%)
rename Documentation/powerpc/{cpu_families.txt => cpu_families.rst} (95%)
rename Documentation/powerpc/{cpu_features.txt => cpu_features.rst} (97%)
rename Documentation/powerpc/{cxl.txt => cxl.rst} (95%)
rename Documentation/powerpc/{cxlflash.txt => cxlflash.rst} (98%)
rename Documentation/powerpc/{DAWR-POWER9.txt => dawr-power9.rst} (95%)
rename Documentation/powerpc/{dscr.txt => dscr.rst} (91%)
rename Documentation/powerpc/{eeh-pci-error-recovery.txt => eeh-pci-error-recovery.rst} (82%)
rename Documentation/powerpc/{firmware-assisted-dump.txt => firmware-assisted-dump.rst} (80%)
rename Documentation/powerpc/{hvcs.txt => hvcs.rst} (91%)
create mode 100644 Documentation/powerpc/index.rst
rename Documentation/powerpc/{mpc52xx.txt => mpc52xx.rst} (91%)
rename Documentation/powerpc/{pci_iov_resource_on_powernv.txt => pci_iov_resource_on_powernv.rst} (97%)
rename Documentation/powerpc/{pmu-ebb.txt => pmu-ebb.rst} (99%)
rename Documentation/powerpc/{ptrace.txt => ptrace.rst} (48%)
rename Documentation/powerpc/{qe_firmware.txt => qe_firmware.rst} (95%)
rename Documentation/powerpc/{syscall64-abi.txt => syscall64-abi.rst} (82%)
rename Documentation/powerpc/{transactional_memory.txt => transactional_memory.rst} (93%)
rename Documentation/spi/{butterfly => butterfly.rst} (71%)
create mode 100644 Documentation/spi/index.rst
rename Documentation/spi/{pxa2xx => pxa2xx.rst} (83%)
rename Documentation/spi/{spi-lm70llp => spi-lm70llp.rst} (88%)
rename Documentation/spi/{spi-sc18is602 => spi-sc18is602.rst} (92%)
rename Documentation/spi/{spi-summary => spi-summary.rst} (93%)
rename Documentation/spi/{spidev => spidev.rst} (90%)
create mode 100644 Documentation/w1/index.rst
rename Documentation/w1/masters/{ds2482 => ds2482.rst} (71%)
rename Documentation/w1/masters/{ds2490 => ds2490.rst} (98%)
create mode 100644 Documentation/w1/masters/index.rst
rename Documentation/w1/masters/{mxc-w1 => mxc-w1.rst} (33%)
rename Documentation/w1/masters/{omap-hdq => omap-hdq.rst} (90%)
rename Documentation/w1/masters/{w1-gpio => w1-gpio.rst} (75%)
create mode 100644 Documentation/w1/slaves/index.rst
rename Documentation/w1/slaves/{w1_ds2406 => w1_ds2406.rst} (96%)
rename Documentation/w1/slaves/{w1_ds2413 => w1_ds2413.rst} (81%)
rename Documentation/w1/slaves/{w1_ds2423 => w1_ds2423.rst} (48%)
rename Documentation/w1/slaves/{w1_ds2438 => w1_ds2438.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e04 => w1_ds28e04.rst} (93%)
rename Documentation/w1/slaves/{w1_ds28e17 => w1_ds28e17.rst} (88%)
rename Documentation/w1/slaves/{w1_therm => w1_therm.rst} (95%)
rename Documentation/w1/{w1.generic => w1-generic.rst} (59%)
rename Documentation/w1/{w1.netlink => w1-netlink.rst} (77%)
--
2.21.0
^ permalink raw reply
* [PATCH v2 24/26] docs: net: convert two README files to ReST format
From: Mauro Carvalho Chehab @ 2019-07-26 12:51 UTC (permalink / raw)
Cc: Mauro Carvalho Chehab, David S. Miller, Jonathan Corbet,
Johannes Berg, netdev, linux-doc, linux-wireless
In-Reply-To: <cover.1564145354.git.mchehab+samsung@kernel.org>
There are two README files there with doesn't have a .txt
extension nor are at ReST format.
In order to help with the docs conversion to ReST, rename those
and manually convert them to ReST format.
As there are lot more to be done for networking to be part of
the documentation body, for now mark those two files with
:orphan:, in order to supress a build warning.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
.../networking/caif/{README => caif.rst} | 88 +++++++++++++------
.../{README => mac80211_hwsim.rst} | 28 ++++--
MAINTAINERS | 2 +-
3 files changed, 81 insertions(+), 37 deletions(-)
rename Documentation/networking/caif/{README => caif.rst} (70%)
rename Documentation/networking/mac80211_hwsim/{README => mac80211_hwsim.rst} (81%)
diff --git a/Documentation/networking/caif/README b/Documentation/networking/caif/caif.rst
similarity index 70%
rename from Documentation/networking/caif/README
rename to Documentation/networking/caif/caif.rst
index 757ccfaa1385..07afc8063d4d 100644
--- a/Documentation/networking/caif/README
+++ b/Documentation/networking/caif/caif.rst
@@ -1,18 +1,31 @@
-Copyright (C) ST-Ericsson AB 2010
-Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
-License terms: GNU General Public License (GPL) version 2
----------------------------------------------------------
+:orphan:
-=== Start ===
-If you have compiled CAIF for modules do:
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
-$modprobe crc_ccitt
-$modprobe caif
-$modprobe caif_socket
-$modprobe chnl_net
+================
+Using Linux CAIF
+================
-=== Preparing the setup with a STE modem ===
+
+:Copyright: |copy| ST-Ericsson AB 2010
+
+:Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
+
+Start
+=====
+
+If you have compiled CAIF for modules do::
+
+ $modprobe crc_ccitt
+ $modprobe caif
+ $modprobe caif_socket
+ $modprobe chnl_net
+
+
+Preparing the setup with a STE modem
+====================================
If you are working on integration of CAIF you should make sure
that the kernel is built with module support.
@@ -32,24 +45,30 @@ module parameter "ser_use_stx".
Normally Frame Checksum is always used on UART, but this is also provided as a
module parameter "ser_use_fcs".
-$ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes
-$ ifconfig caif_ttyS0 up
+::
-PLEASE NOTE: There is a limitation in Android shell.
+ $ modprobe caif_serial ser_ttyname=/dev/ttyS0 ser_use_stx=yes
+ $ ifconfig caif_ttyS0 up
+
+PLEASE NOTE:
+ There is a limitation in Android shell.
It only accepts one argument to insmod/modprobe!
-=== Trouble shooting ===
+Trouble shooting
+================
There are debugfs parameters provided for serial communication.
/sys/kernel/debug/caif_serial/<tty-name>/
* ser_state: Prints the bit-mask status where
+
- 0x02 means SENDING, this is a transient state.
- 0x10 means FLOW_OFF_SENT, i.e. the previous frame has not been sent
- and is blocking further send operation. Flow OFF has been propagated
- to all CAIF Channels using this TTY.
+ and is blocking further send operation. Flow OFF has been propagated
+ to all CAIF Channels using this TTY.
* tty_status: Prints the bit-mask tty status information
+
- 0x01 - tty->warned is on.
- 0x02 - tty->low_latency is on.
- 0x04 - tty->packed is on.
@@ -58,13 +77,17 @@ There are debugfs parameters provided for serial communication.
- 0x20 - tty->stopped is on.
* last_tx_msg: Binary blob Prints the last transmitted frame.
- This can be printed with
+
+ This can be printed with::
+
$od --format=x1 /sys/kernel/debug/caif_serial/<tty>/last_rx_msg.
- The first two tx messages sent look like this. Note: The initial
- byte 02 is start of frame extension (STX) used for re-syncing
- upon errors.
- - Enumeration:
+ The first two tx messages sent look like this. Note: The initial
+ byte 02 is start of frame extension (STX) used for re-syncing
+ upon errors.
+
+ - Enumeration::
+
0000000 02 05 00 00 03 01 d2 02
| | | | | |
STX(1) | | | |
@@ -73,7 +96,9 @@ There are debugfs parameters provided for serial communication.
Command:Enumeration(1)
Link-ID(1)
Checksum(2)
- - Channel Setup:
+
+ - Channel Setup::
+
0000000 02 07 00 00 00 21 a1 00 48 df
| | | | | | | |
STX(1) | | | | | |
@@ -86,13 +111,18 @@ There are debugfs parameters provided for serial communication.
Checksum(2)
* last_rx_msg: Prints the last transmitted frame.
- The RX messages for LinkSetup look almost identical but they have the
- bit 0x20 set in the command bit, and Channel Setup has added one byte
- before Checksum containing Channel ID.
- NOTE: Several CAIF Messages might be concatenated. The maximum debug
+
+ The RX messages for LinkSetup look almost identical but they have the
+ bit 0x20 set in the command bit, and Channel Setup has added one byte
+ before Checksum containing Channel ID.
+
+ NOTE:
+ Several CAIF Messages might be concatenated. The maximum debug
buffer size is 128 bytes.
-== Error Scenarios:
+Error Scenarios
+===============
+
- last_tx_msg contains channel setup message and last_rx_msg is empty ->
The host seems to be able to send over the UART, at least the CAIF ldisc get
notified that sending is completed.
@@ -103,7 +133,9 @@ There are debugfs parameters provided for serial communication.
- if /sys/kernel/debug/caif_serial/<tty>/tty_status is non-zero there
might be problems transmitting over UART.
+
E.g. host and modem wiring is not correct you will typically see
tty_status = 0x10 (hw_stopped) and ser_state = 0x10 (FLOW_OFF_SENT).
+
You will probably see the enumeration message in last_tx_message
and empty last_rx_message.
diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
similarity index 81%
rename from Documentation/networking/mac80211_hwsim/README
rename to Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
index 3566a725d19c..d2266ce5534e 100644
--- a/Documentation/networking/mac80211_hwsim/README
+++ b/Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
@@ -1,5 +1,13 @@
+:orphan:
+
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+===================================================================
mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
-Copyright (c) 2008, Jouni Malinen <j@w1.fi>
+===================================================================
+
+:Copyright: |copy| 2008, Jouni Malinen <j@w1.fi>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 2 as
@@ -7,6 +15,7 @@ published by the Free Software Foundation.
Introduction
+============
mac80211_hwsim is a Linux kernel module that can be used to simulate
arbitrary number of IEEE 802.11 radios for mac80211. It can be used to
@@ -43,6 +52,7 @@ regardless of channel.
Simple example
+==============
This example shows how to use mac80211_hwsim to simulate two radios:
one to act as an access point and the other as a station that
@@ -50,17 +60,19 @@ associates with the AP. hostapd and wpa_supplicant are used to take
care of WPA2-PSK authentication. In addition, hostapd is also
processing access point side of association.
+::
-# Build mac80211_hwsim as part of kernel configuration
-# Load the module
-modprobe mac80211_hwsim
+ # Build mac80211_hwsim as part of kernel configuration
-# Run hostapd (AP) for wlan0
-hostapd hostapd.conf
+ # Load the module
+ modprobe mac80211_hwsim
-# Run wpa_supplicant (station) for wlan1
-wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
+ # Run hostapd (AP) for wlan0
+ hostapd hostapd.conf
+
+ # Run wpa_supplicant (station) for wlan1
+ wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf
More test cases are available in hostap.git:
diff --git a/MAINTAINERS b/MAINTAINERS
index c7656edee696..4de2f288d1ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9568,7 +9568,7 @@ F: Documentation/networking/mac80211-injection.txt
F: include/net/mac80211.h
F: net/mac80211/
F: drivers/net/wireless/mac80211_hwsim.[ch]
-F: Documentation/networking/mac80211_hwsim/README
+F: Documentation/networking/mac80211_hwsim/mac80211_hwsim.rst
MAILBOX API
M: Jassi Brar <jassisinghbrar@gmail.com>
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 00/26] ReST conversion of text files without .txt extension
From: Mauro Carvalho Chehab @ 2019-07-26 13:05 UTC (permalink / raw)
To: Jonathan Corbet
Cc: linux-doc, linux-kernel, linux-pm, linux-arm-kernel,
linux-samsung-soc, linux-pci, linuxppc-dev, linux-scsi,
devicetree, linux-i2c, linux-hwmon, linux-spi, linux-iio,
linux-rtc, netdev, linux-parisc, openrisc, devel, linux-cifs,
samba-technical, devel, dmaengine, alsa-devel, linux-mips,
linux-wireless, rcu
In-Reply-To: <cover.1564145354.git.mchehab+samsung@kernel.org>
Em Fri, 26 Jul 2019 09:51:10 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> This series converts the text files under Documentation with doesn't end
> neither .txt or .rst and are not part of ABI or features.
>
> This series is at:
> https://git.linuxtv.org/mchehab/experimental.git/log/?h=rst_for_5_4_v3
>
> And it is based on yesterday's upstream tree.
>
> After this series, we have ~320 files left to be converted to ReST.
>
> v2:
> - Added 3 files submitted for v5.3 that weren't merged yet;
> - markdown patch broken into two, per Rob's request;
> - rebased on the top of upstream master branch
>
> Mauro Carvalho Chehab (26):
> docs: ABI: remove extension from sysfs-class-mic.txt
^ In time: this one was already merged.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Register support for HE meshpoint
From: Johannes Berg @ 2019-07-26 13:26 UTC (permalink / raw)
To: Sven Eckelmann, linux-wireless; +Cc: ath11k, Sven Eckelmann
In-Reply-To: <20190724163359.3507-3-sven@narfation.org>
On Wed, 2019-07-24 at 18:33 +0200, Sven Eckelmann wrote:
> From: Sven Eckelmann <seckelmann@datto.com>
>
> Some features of 802.11ax without central organizing (AP) STA can also be
> used in mesh mode. hwsim can be used to assist initial development of these
> features without having access to HW.
>
> Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
Even with the tshark workaround in place, this breaks 68 mesh-related
tests in hwsim tests. Jouni says only 3 use tshark ...
johannes
^ permalink raw reply
* Re: [PATCH v5 1/2] nl80211: Add support for EDMG channels
From: Johannes Berg @ 2019-07-26 13:29 UTC (permalink / raw)
To: Alexei Avshalom Lazar; +Cc: linux-wireless, wil6210
In-Reply-To: <1563194767-4817-2-git-send-email-ailizaro@codeaurora.org>
Hi Alexei,
I'm not exactly sure why, but this breaks practically all connectivity
on 2.4 and 5 GHz channels (at least in hwsim tests).
Please check and resubmit.
It'd also be good to reformat the commit log a bit, maybe adding
paragraphs, it's a bit of a "wall of text".
Thanks,
johannes
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Register support for HE meshpoint
From: Sven Eckelmann @ 2019-07-26 13:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, ath11k, Sven Eckelmann
In-Reply-To: <f2e16d10ce3eb3ff08c97c27424b824b8e012553.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]
On Friday, 26 July 2019 15:26:32 CEST Johannes Berg wrote:
> On Wed, 2019-07-24 at 18:33 +0200, Sven Eckelmann wrote:
> > From: Sven Eckelmann <seckelmann@datto.com>
> >
> > Some features of 802.11ax without central organizing (AP) STA can also be
> > used in mesh mode. hwsim can be used to assist initial development of these
> > features without having access to HW.
> >
> > Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
>
> Even with the tshark workaround in place, this breaks 68 mesh-related
> tests in hwsim tests. Jouni says only 3 use tshark ...
As I already wrote:
> The first three things looks like wpa_supplicant problems. Seems to be
> caused by the way HE forces VHT to be enabled and now the tests fail
> which try to disable VHT. There was already a patch [0] for that but it
> wasn't considered a good solution.
> But beside these three things there are various other problems in
> > wpa_supplicant regarding HE with pending patches. So I've used
> wpa_supplicant 91b6eba7732354ed3dfe0aa9715dc4c0746e3336 with two
> additional patches [1,2] and increased the VM memory to 1024 MB. Also
> wireshark (tshark to be more precise) had to be updated to
> v3.1.0rc0-1192-gf64990438c
[...]
> [0] https://patchwork.ozlabs.org/patch/1125305/
> [1] https://patchwork.ozlabs.org/patch/1125314/
> [2] https://patchwork.ozlabs.org/patch/1125322/
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] mac80211_hwsim: Register support for HE meshpoint
From: Johannes Berg @ 2019-07-26 13:32 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: linux-wireless, ath11k, Sven Eckelmann
In-Reply-To: <3082836.hUm4yBdaKs@sven-edge>
On Fri, 2019-07-26 at 15:31 +0200, Sven Eckelmann wrote:
> As I already wrote:
>
> > The first three things looks like wpa_supplicant problems. Seems to be
> > caused by the way HE forces VHT to be enabled and now the tests fail
> > which try to disable VHT. There was already a patch [0] for that but it
> > wasn't considered a good solution.
> > But beside these three things there are various other problems in
> > > wpa_supplicant regarding HE with pending patches. So I've used
> > wpa_supplicant 91b6eba7732354ed3dfe0aa9715dc4c0746e3336 with two
> > additional patches [1,2] and increased the VM memory to 1024 MB. Also
> > wireshark (tshark to be more precise) had to be updated to
> > v3.1.0rc0-1192-gf64990438c
Ok, dunno. But I don't really want to break everything in the hwsim
tests, even if the kernel patch may be correct ... so I guess I'll wait
until you resubmit after some fixes go into wpa_s?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: reject zero MAC address in add station
From: Karthikeyan Periyasamy @ 2019-07-26 14:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <0cc7d0c578b60730e77ecd03e2df240dd1b393a0.camel@sipsolutions.net>
>> Don't allow using a zero MAC address as the station
>> MAC address. so validated the MAC address using
>> is_valid_ether_addr.
>
> Theoretically, all zeroes might have been a valid address at some
> point.
> I see no reason not to reject it, but I'd like to know why you ended up
> with this now??
>
Its a Wireless fuzz testing tool (codenomicon) which sends out different
types of frames to the AP. It actually tampers legitimate wireless
frames (Probe, Auth, Assoc, Data etc..) and will send to the AP. I
thought allowing a zero MAC address station is not a valid. so validated
the given MAC address. Just for curious, which case all zero address is
a valid MAC.
Thanks,
Karthikeyan
^ permalink raw reply
* Re: [PATCH] mac80211: reject zero MAC address in add station
From: Johannes Berg @ 2019-07-26 14:07 UTC (permalink / raw)
To: Karthikeyan Periyasamy; +Cc: linux-wireless
In-Reply-To: <fd6e7a7e0746b861bbbd660bf54cc675@codeaurora.org>
On Fri, 2019-07-26 at 19:36 +0530, Karthikeyan Periyasamy wrote:
> > > Don't allow using a zero MAC address as the station
> > > MAC address. so validated the MAC address using
> > > is_valid_ether_addr.
> >
> > Theoretically, all zeroes might have been a valid address at some
> > point.
> > I see no reason not to reject it, but I'd like to know why you ended up
> > with this now??
> >
>
> Its a Wireless fuzz testing tool (codenomicon) which sends out different
> types of frames to the AP. It actually tampers legitimate wireless
> frames (Probe, Auth, Assoc, Data etc..) and will send to the AP. I
> thought allowing a zero MAC address station is not a valid. so validated
> the given MAC address. Just for curious, which case all zero address is
> a valid MAC.
Well, it isn't really, but the OUI 00:00:00 *is* in fact assigned (or
was), and theoretically the vendor could assign it to a device.
We do assume basically everywhere that it's invalid though.
Was just wondering how you came across this really, I guess I'll add a
bit of text to the commit log and merge it.
johannes
^ permalink raw reply
* [PATCH] brcmsmac: remove three set but not used variables
From: YueHaibing @ 2019-07-26 14:15 UTC (permalink / raw)
To: kvalo, arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng
Cc: linux-kernel, netdev, linux-wireless, brcm80211-dev-list.pdl,
brcm80211-dev-list, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode':
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable]
They are never used so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
index 7d4e8f5..080e829 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c
@@ -5248,15 +5248,7 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
/* Default to 54g Auto */
/* Advertise and use shortslot (-1/0/1 Auto/Off/On) */
s8 shortslot = BRCMS_SHORTSLOT_AUTO;
- bool shortslot_restrict = false; /* Restrict association to stations
- * that support shortslot
- */
bool ofdm_basic = false; /* Make 6, 12, and 24 basic rates */
- /* Advertise and use short preambles (-1/0/1 Auto/Off/On) */
- int preamble = BRCMS_PLCP_LONG;
- bool preamble_restrict = false; /* Restrict association to stations
- * that support short preambles
- */
struct brcms_band *band;
/* if N-support is enabled, allow Gmode set as long as requested
@@ -5297,16 +5289,11 @@ int brcms_c_set_gmode(struct brcms_c_info *wlc, u8 gmode, bool config)
case GMODE_ONLY:
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
case GMODE_PERFORMANCE:
shortslot = BRCMS_SHORTSLOT_ON;
- shortslot_restrict = true;
ofdm_basic = true;
- preamble = BRCMS_PLCP_SHORT;
- preamble_restrict = true;
break;
default:
--
2.7.4
^ permalink raw reply related
* [PATCH] iwlwifi: mvm: fix old-style declaration
From: YueHaibing @ 2019-07-26 14:18 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo, sara.sharon
Cc: linux-kernel, netdev, linux-wireless, YueHaibing
There expect the 'static' keyword to come first in a
declaration, and we get a warning for this with "make W=1":
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:427:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c:434:1: warning:
'static' is not at beginning of declaration [-Wold-style-declaration]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
index 55cd49c..6ed0c49 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c
@@ -424,14 +424,14 @@ int iwl_mvm_init_fw_regd(struct iwl_mvm *mvm)
return ret;
}
-const static u8 he_if_types_ext_capa_sta[] = {
+static const u8 he_if_types_ext_capa_sta[] = {
[0] = WLAN_EXT_CAPA1_EXT_CHANNEL_SWITCHING,
[2] = WLAN_EXT_CAPA3_MULTI_BSSID_SUPPORT,
[7] = WLAN_EXT_CAPA8_OPMODE_NOTIF,
[9] = WLAN_EXT_CAPA10_TWT_REQUESTER_SUPPORT,
};
-const static struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
+static const struct wiphy_iftype_ext_capab he_iftypes_ext_capa[] = {
{
.iftype = NL80211_IFTYPE_STATION,
.extended_capabilities = he_if_types_ext_capa_sta,
--
2.7.4
^ permalink raw reply related
* [PATCH] rtw88: pci: remove set but not used variable 'ip_sel'
From: YueHaibing @ 2019-07-26 14:20 UTC (permalink / raw)
To: yhchuang, kvalo; +Cc: linux-kernel, netdev, linux-wireless, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
variable 'ip_sel' set but not used [-Wunused-but-set-variable]
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index 23dd06a..c562515 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -990,7 +990,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
u16 cut;
u16 value;
u16 offset;
- u16 ip_sel;
int i;
cut = BIT(0) << rtwdev->hal.cut_version;
@@ -1003,7 +1002,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, true);
else
@@ -1018,7 +1016,6 @@ static void rtw_pci_phy_cfg(struct rtw_dev *rtwdev)
break;
offset = para->offset;
value = para->value;
- ip_sel = para->ip_sel;
if (para->ip_sel == RTW_IP_SEL_PHY)
rtw_mdio_write(rtwdev, offset, value, false);
else
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox