[PATCH mac80211-next] ath10k: fix unhandled switch value warning
Cited commit introduced the following warnings:
drivers/net/wireless/ath/ath10k/mac.c: In function 'chan_to_phymode':
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_1' not handled in switch [-Wswitch]
558 | switch (chandef->width) {
| ^~
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_2' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_4' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_8' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:558:3: warning: enumeration value
'NL80211_CHAN_WIDTH_16' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value
'NL80211_CHAN_WIDTH_1' not handled in switch [-Wswitch]
581 | switch (chandef->width) {
| ^~
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value
'NL80211_CHAN_WIDTH_2' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value
'NL80211_CHAN_WIDTH_4' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value
'NL80211_CHAN_WIDTH_8' not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:581:3: warning: enumeration value
'NL80211_CHAN_WIDTH_16' not handled in switch [-Wswitch]
Fix them by making the existing invalid channel width
cases the default, as the introduced channel widths
currently don't make sense in 2 or 5GHz either.
Fixes: e5cb3d34a66d ("nl80211: S1G band and channel definitions")
Signed-off-by: Thomas Pedersen
---
drivers/net/wireless/ath/ath10k/mac.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 919d15584d4a..3c0c33a9f30c 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -568,11 +568,7 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
case NL80211_CHAN_WIDTH_40:
phymode = MODE_11NG_HT40;
break;
- case NL80211_CHAN_WIDTH_5:
- case NL80211_CHAN_WIDTH_10:
- case NL80211_CHAN_WIDTH_80:
- case NL80211_CHAN_WIDTH_80P80:
- case NL80211_CHAN_WIDTH_160:
+ default:
phymode = MODE_UNKNOWN;
break;
}
@@ -597,8 +593,7 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
case NL80211_CHAN_WIDTH_80P80:
phymode = MODE_11AC_VHT80_80;
break;
- case NL80211_CHAN_WIDTH_5:
- case NL80211_CHAN_WIDTH_10:
+ default:
phymode = MODE_UNKNOWN;
break;
}
--
2.27.0
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
BUSINESS PROPOSAL
Hello, Apply for a loan, at a 3% interest rate. Do you need a personal loan? Do you need a business loan? Do you need a consolidation loan? Do you need a secure loan? Do you need an unsecured loan? Do you need a mortgage loan? Do you need a pay off debt loan? Do you need a project loan? Do you need a student loan? Whatever loan that you are looking for, kindly send us a mail: (trustfinance1...@outlook.com) Mr. James kenneth Managing Director -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC 1/2] devlink: add simple fw crash helpers
Hi, Sorry ... long delay. > > The reason I'm asking is that it's starting to sound like we really > > ought to be implementing devlink, but we've got a bunch of > > infrastructure that uses the devcoredump, and it'll take time > > (significantly so) to change all that... > > In devlink world pure FW core dumps are exposed by devlink regions. > An API allowing reading device memory, registers, etc., but also > creating dumps of memory regions when things go wrong. It should be > a fairly straightforward migration. Right. We also have regions (various memory pieces, registers, ...). One issue might be that for devlink we wouldn't want to expose these as a single blob, I guess, but for devcoredump we already have a custom format to glue all the things together. Since it seems unlikely that anyone else would want to use the *iwlwifi* format to glue things together, we'd have to do something there. But perhaps that could be a matter of providing a "glue things into a devcoredump" function that would have a reasonable default but could be overridden by the driver for those migration cases. > Devlink health is more targeted, the dump is supposed to contain only > relevant information, selected and formatted by the driver. When device > misbehaves driver reads the relevant registers and FW state and creates > a formatted state dump. I believe each element of the dump must fit > into a netlink message (but there may be multiple elements, see > devlink_fmsg_prepare_skb()). That wouldn't help for our big memory dumps, but OK. > We should be able to convert dl-regions dumps and dl-health dumps into > devcoredumps, but since health reporters are supposed to be more > targeted there's usually multiple of them per device. Right. > Conversely devcoredumps can be trivially exposed as dl-region dumps, > but I believe dl-health would require driver changes to format the > information appropriately. Agree. Anyway, thanks. I'll put it on my list of things to look at ... not too hopeful that will be soon, given how long it even took me to get back to this email :) johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
On Fri, 2020-07-24 at 12:26 +0300, Kalle Valo wrote:
> > > So to me it feels like the best solution forward is to go with the
> > > vendor API, do you agree? We can, of course, later switch to the common
> > > API if we manage to create one which is usable for everyone.
But why wouldn't we try that now, while we have it all in our heads (in
a way ... even if this discussion drags out forever)?
I mean, the range-based approach ought to work, and if we define it as a
nested attribute list or so, we can even later add more attributes to it
(chain limits, whatnot) without any backward compatibility concerns.
So what is it that we _cannot_ do in a more common way today?
> > I think we've had some healthy (though very protracted) discussion,
> > and I don't think I've seen anyone bring up anything I wasn't already
> > aware of that would prevent eventual consolidation. As long as we
> > acknowledge those things (item 2 at
> > https://wireless.wiki.kernel.org/en/developers/documentation/nl80211#vendor-specific_api),
> > I'm happy.
>
> Good, I was just checking that we all are on the same page.
But are we? ;-)
I don't really see anything in the new proposal [1] that really explains
why the common API that we've sort of vaguely outlined in this thread
couldn't work? It just speaks of technical difficulties ("need a
reporting API too"), but should we let that stop us?
[1] https://patchwork.kernel.org/patch/11686317/
johannes
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [PATCH 1/2] nl80211: vendor-cmd: qca: add dynamic SAR power limits
On Mon, 2020-06-01 at 18:32 -0700, Brian Norris wrote: > I haven't quite reached the 3 month lag on the prior replies here :) But I did, almost ;-) > I do want to see this question resolved somehow, or else we'll be > dragging along out-of-tree patches for...(counts on fingers)...4 > different nl80211 APIs for the same feature, and a driver-detecting > user space for it. Right. > I think I was half-hoping that we'd get to chat at > netdev about this, but that's not happening any time soon. (Topic for > another day: does a "wireless workshop" still happen at a virtual-only > conference?) Yes, but only a short 1.5hr video call I guess. I'm not even sure what to do there yet. [snip] Thanks for the overview! > Also, Kalle had some concerns about stable ABI questions: shouldn't we > bake in some kind of "check for support" feature to these kinds of > APIs [3]? That would help ease transition, if we do start with a > vendor API and move to a common one in the future. Given the nature of > this feature, I wouldn't expect there will be a large variety of users > making use of the APIs -- and I, for one, would be happy to migrate my > user space over some period of time, as needed. We do that? We list out the available vendor APIs, and in most cases (perhaps not the one you've noticed there) we also list out the availability of real nl80211 APIs in some way. johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
[PATCH] Revert "ath: add support for special 0x0 regulatory domain"
This reverts commit 2dc016599cfa9672a147528ca26d70c3654a5423.
Per Atheros documentation to manufacturers, the EEPROM regulatory domain
code 0x0 must always map to "US". In particular, it should not map to a
custom world regulatory domain. For references, see [1] and [2] below.
Furthermore, __ath_regd_init() has a specific condition to set the
country code to "US" in this case, which emits the following log
message:
[7.814307] ath: EEPROM indicates default country code should be used
The patch being reverted mistakenly maps 0x0 to the custom world
regulatory domain 0x64 - the most restrictive of the world regulatory
domains. The premise of the patch is that in the case of EEPROM
regulatory domain code 0x0, ath_is_world_regd() should return true. But,
as stated above, 0x0 should not map to a world regulatory domain, and so
the function should return false. The original behaviour, whereby
NL80211_REGDOM_SET_BY_COUNTRY_IE is ignored, was correct according to
the manufacturer's intent and should not have been changed.
[1]
https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
[2] http://article.gmane.org/gmane.linux.kernel.wireless.general/38410
Fixes: 2dc016599cfa ("ath: add support for special 0x0 regulatory domain")
Cc: Wen Gong
Cc: Luis R. Rodriguez
Cc: linux-wirel...@vger.kernel.org
Tested-on: QCA9880 hw2.0 PCI 10.2.4-1.0-00047
Signed-off-by: Alvin Šipraga
---
drivers/net/wireless/ath/regd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index bee9110b91f3..20f4f8ea9f89 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -666,14 +666,14 @@ ath_regd_init_wiphy(struct ath_regulatory *reg,
/*
* Some users have reported their EEPROM programmed with
- * 0x8000 or 0x0 set, this is not a supported regulatory
- * domain but since we have more than one user with it we
- * need a solution for them. We default to 0x64, which is
- * the default Atheros world regulatory domain.
+ * 0x8000 set, this is not a supported regulatory domain
+ * but since we have more than one user with it we need
+ * a solution for them. We default to 0x64, which is the
+ * default Atheros world regulatory domain.
*/
static void ath_regd_sanitize(struct ath_regulatory *reg)
{
- if (reg->current_rd != COUNTRY_ERD_FLAG && reg->current_rd != 0)
+ if (reg->current_rd != COUNTRY_ERD_FLAG)
return;
printk(KERN_DEBUG "ath: EEPROM regdomain sanitized\n");
reg->current_rd = 0x64;
--
2.27.0
___
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
Re: [RFC 1/7] mac80211: Add check for napi handle before WARN_ON
On Sun, 2020-07-26 at 21:49 +0530, Rakesh Pillai wrote: > We do have the usage of napi_gro_receive and netif_receive_skb in mac80211. > /* deliver to local stack */ > if (rx->napi) > napi_gro_receive(rx->napi, skb); > else > netif_receive_skb(skb); > > > Also all the rx_handlers are called under the " rx->local->rx_path_lock" lock. > Is the BH disable still required ? I tend to think so, but you're welcome to show that it's not. The lock serves a different purpose. TBH, I don't have all of this in my head at all times either, so please do your own work and analyse why it may or may not be necessary. But without any such analysis I'm not going to take patches that change it. johannes ___ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
