* Re: [PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode
From: Valo, Kalle @ 2016-09-12 15:31 UTC (permalink / raw)
To: Thiagarajan, Vasanthakumar
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <1469623085-13942-1-git-send-email-vthiagar@qti.qualcomm.com>
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> writes:
> Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
> rx_hdr_status is not padded to align in 4-byte boundary. Define a
> new hw_params field to handle different alignment behaviour between
> different hw. This patch fixes improper retrieval of rfc1042 header
> with QCA4019. This patch along with "ath10k: Properly remove padding
> from the start of rx payload" will fix traffic failure in ethernet
> decap mode for QCA4019.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
There were some conflicts, I fixed them in the pending branch. Please
check my changes:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=3Dpend=
ing&id=3Dd0d9e40216e1a8edd2f3b387b96aad62c3a49add
--=20
Kalle Valo=
^ permalink raw reply
* Re: [PATCH 2/2] ath10k: add platform regulatory domain support
From: Valo, Kalle @ 2016-09-12 15:35 UTC (permalink / raw)
To: bartosz.markowski@tieto.com
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <1470140454-3899-3-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> This overrides whatever regulatory the device
> EEPROM contains and uses what the platform says
> instead - in this implementation the ACPI driver.
>
> In case the hint is not programmed or corrupted (0xffff)
> the device falls back to the eeprom programmed settings.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
[...]
> +#ifdef CONFIG_ACPI
> +#define WRD_METHOD "WRDD"
> +#define WRDD_WIFI (0x07)
> +
> +static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_object =
*wrdd)
> +{
I don't think the ifdef is really necessary, acpi.h should handle that
(hopefully). Also I changed the error handling to use standard error
values and changed the info messages to dbg, they are too spammy in my
opinion. Please check carefully my changes in the pending branch:
https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=3Dpend=
ing&id=3Dfe91745381ec3999d8de6dedb07b396c82539717
--=20
Kalle Valo=
^ permalink raw reply
* Re: Support of rtl8723bs
From: Hanno Zulla @ 2016-09-12 15:48 UTC (permalink / raw)
To: Larry Finger, Jes Sorensen, Bastien Nocera; +Cc: anthony.wong, linux-wireless
In-Reply-To: <5b920339-abcd-0fc4-f054-039155c531a0@lwfinger.net>
Hi,
> Longer term I think it makes sense to add SDIO support to rtl8xxxu. The
> differences between the USB version and the SDIO version are rather
> small.
This is beyond my expertise, sadly.
Is there a good blueprint / example of a previous case where a USB
driver had SDIO support added that one might learn from?
Kind regards,
Hanno
^ permalink raw reply
* Re: Support of rtl8723bs
From: Bastien Nocera @ 2016-09-12 15:50 UTC (permalink / raw)
To: Hanno Zulla, Larry Finger, Jes Sorensen; +Cc: anthony.wong, linux-wireless
In-Reply-To: <cd991918-0bfa-a9a3-15e5-aa8561db2c65@hanno.de>
On Mon, 2016-09-12 at 17:48 +0200, Hanno Zulla wrote:
> Hi,
>
> > Longer term I think it makes sense to add SDIO support to rtl8xxxu.
> > The
> > differences between the USB version and the SDIO version are rather
> > small.
>
>
> This is beyond my expertise, sadly.
>
> Is there a good blueprint / example of a previous case where a USB
> driver had SDIO support added that one might learn from?
I don't know on top of my head, sorry. Best look in the kernel sources
directly.
^ permalink raw reply
* Re: Support of rtl8723bs
From: Jes Sorensen @ 2016-09-12 16:07 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Hanno Zulla, Larry Finger, anthony.wong, linux-wireless
In-Reply-To: <1473695458.6389.3.camel@hadess.net>
Bastien Nocera <hadess@hadess.net> writes:
> On Mon, 2016-09-12 at 17:48 +0200, Hanno Zulla wrote:
>> Hi,
>>
>> > Longer term I think it makes sense to add SDIO support to rtl8xxxu.
>> > The
>> > differences between the USB version and the SDIO version are rather
>> > small.
>>
>>
>> This is beyond my expertise, sadly.
>>
>> Is there a good blueprint / example of a previous case where a USB
>> driver had SDIO support added that one might learn from?
>
> I don't know on top of my head, sorry. Best look in the kernel sources
> directly.
The issues I am aware of is to start out changing the register access
macros into function pointers and stick them all into the fileops
structure. Provide a set of SDIO ones to match the USB ones. Then you
will need some code to detect the device, as that part will obviously be
different from the USB device detection.
I know there are a few issues to look out for in the hw register init
files to look out for too, that does some special casing for SDIO, but
that should be limited. I am happy to point someone in the right
direction on that when they get to that.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Ben Greear @ 2016-09-12 16:36 UTC (permalink / raw)
To: Johannes Berg, Pedersen, Thomas, linux-wireless
In-Reply-To: <1473662637.4201.2.camel@sipsolutions.net>
On 09/11/2016 11:43 PM, Johannes Berg wrote:
> On Wed, 2016-09-07 at 18:20 +0000, Pedersen, Thomas wrote:
>> On 09/06/2016 12:07 PM, Ben Greear wrote:
>>>
>>> On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
>>>>
>>>> Some drivers (ath10k) report MCS 9 @ 20MHz, which
>>>> technically isn't allowed. To get more meaningful value
>>>> than 0 out of this however, just cap the bitrate for 20MHz
>>>> to MCS 8.
>>>
>>> If it is actually reporting MCS9, why lie about it? Report it up
>>> the stack as a proper value instead of hiding the issue?
>>
>> Good point, will send a v2 extrapolating the value to 86.5Mb/s.
>
> That makes no sense either, IMHO.
>
> Are you saying that ath10k actually somehow manages to use an invalid
> bitrate over the air?!
>
> It seems more likely that it's actually just misreporting what it's
> doing, and thus the issue should be fixed in ath10k.
I saw ath10k report the same value in my testing.
Hard to know what the actual on-air encoding rate is.
I do know that some ath10k firmware would run 1Mbps encoding
management frames on 5Mhz, which is also not per spec, for what that is worth.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/3] ath10k: Grab rcu_read_lock before the txqs spinlock.
From: Ben Greear @ 2016-09-12 16:37 UTC (permalink / raw)
To: Johannes Berg, Valo, Kalle
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <1473662509.4201.0.camel@sipsolutions.net>
On 09/11/2016 11:41 PM, Johannes Berg wrote:
>
>>>> - rcu_read_unlock();
>>>> spin_unlock_bh(&ar->txqs_lock);
>>>> + rcu_read_unlock();
>>>
>>> I'm no RCU expert but this isn't making any sense. Maybe it changes
>>> timings on your kernel so that it hides the real problem?
>>
>> I'm not sure this fixed anything or not, it just seemed weird so I
>> changed it.
>>
>> I was hoping someone that understood rcu locking would comment...
>>
>
> RCU is no "locking". The sooner you get over that notion, the better.
>
> This therefore make no sense whatsoever.
>
> In fact, you want to keep the RCU protected section *small*, so having
> the spinlock inside hurts overall system performance.
Ok, thanks for the review. I'll drop this patch from my tree.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] mac80211: allow driver to handle packet-loss mechanism
From: Rajkumar Manoharan @ 2016-09-12 17:57 UTC (permalink / raw)
To: Johannes Berg; +Cc: Rajkumar Manoharan, linux-wireless
In-Reply-To: <1473684288.29016.38.camel@sipsolutions.net>
On 2016-09-12 18:14, Johannes Berg wrote:
> On Tue, 2016-09-06 at 12:26 +0530, Rajkumar Manoharan wrote:
>> mac80211 keeps track of missing acks and triggers CQM packet-loss
>> mechanism whenever consecutive msdu failure reaches threshold limit
>> (STA_LOST_PKT_THRESHOLD). Drivers like ath10k offlaoded rate countrol
>> and aggregation to firmware. Such drivers have its own connection
>> monitoring algorithm that is offloaded to firmware for triggering
>> station kickout due to excessive tries. In VHT mode, single PPDU can
>> have
>> more than 50 msdus at higher rates. Under noisy environment, single
>> ppdu
>> failure can cause station kickout by current mac80211 lost_packet
>> mechanism
>> while firmware is trying to adapt its rate table. This is causing
>> frequent
>> connect and disconnect iteration when station is roaming around.
>>
>> In such scenario, driver (or firmware) is not given enough chance to
>> tune its rate control. So for devices that report low ack events, add
>> a
>> hardware flag to rely on their mechnism.
>>
>
> The way you describe this it sounds like somehow you'll be reporting
> the indication to userspace from the driver; but you do not, and cannot
> do that. The description seems thus misleading?
>
Sorry for confusion.. The idea is that driver will report low ack status
by ieee80211_report_low_ack and if driver wants to completely rely on
firmware algorithm, then this flag will be used to bypass mac80211
packet loss mechanism. does it make sense?
-Rajkumar
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-12 18:50 UTC (permalink / raw)
To: Julia Lawall
Cc: Felipe Balbi, linux-renesas-soc, joe, kernel-janitors,
Sergei Shtylyov, linux-pm, platform-driver-x86, linux-media,
linux-can, Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail,
Chien Tin Tung, linux-rdma, netdev, devel, alsa-devel,
linux-kernel, linux-fbdev, linux-wireless, Jason Gunthorpe,
tpmdd-devel, linux-scsi, linux-spi, linux-usb, linux-acpi
In-Reply-To: <alpine.DEB.2.10.1609121548200.29099@hadrien>
On Mon, Sep 12, 2016 at 03:52:08PM +0200, Julia Lawall wrote:
>
>
> On Mon, 12 Sep 2016, Felipe Balbi wrote:
>
> >
> > Hi,
> >
> > Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> > >>
> > >>
> > >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> > >>
> > >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > >> > > Constify local structures.
> > >> > >
> > >> > > The semantic patch that makes this change is as follows:
> > >> > > (http://coccinelle.lip6.fr/)
> > >> >
> > >> > Just my two cents but:
> > >> >
> > >> > 1. You *can* use a static analysis too to find bugs or other issues.
> > >> > 2. However, you should manually do the commits and proper commit
> > >> > messages to subsystems based on your findings. And I generally think
> > >> > that if one contributes code one should also at least smoke test changes
> > >> > somehow.
> > >> >
> > >> > I don't know if I'm alone with my opinion. I just think that one should
> > >> > also do the analysis part and not blindly create and submit patches.
> > >>
> > >> All of the patches are compile tested. And the individual patches are
> > >
> > > Compile-testing is not testing. If you are not able to test a commit,
> > > you should explain why.
> >
> > Dude, Julia has been doing semantic patching for years already and
> > nobody has raised any concerns so far. There's already an expectation
> > that Coccinelle *works* and Julia's sematic patches are sound.
> >
> > Besides, adding 'const' is something that causes virtually no functional
> > changes to the point that build-testing is really all you need. Any
> > problems caused by adding 'const' to a definition will be seen by build
> > errors or warnings.
> >
> > Really, just stop with the pointless discussion and go read a bit about
> > Coccinelle and what semantic patches are giving you. The work done by
> > Julia and her peers are INRIA have measurable benefits.
> >
> > You're really making a thunderstorm in a glass of water.
>
> Thanks for the defense, but since a lot of these patches torned out to be
> wrong, due to an incorrect parse by Coccinelle, combined with an
> unpleasantly lax compiler, Jarkko does have a point that I should have
> looked at the patches more carefully. In any case, I have written to the
> maintainers relevant to the patches that turned out to be incorrect.
Exactly. I'm not excepting that every commit would require extensive
analysis but it would be good to quickly at least skim through commits
and see if they make sense (or ask if unsure) :)
And I'm fine with compile testing if it is mentioned in the commit msg.
> julia
/Jarkko
^ permalink raw reply
* Re: [PATCH 0/9] rsi: code clean-up
From: Joe Perches @ 2016-09-12 18:50 UTC (permalink / raw)
To: Kalle Valo, Prameela Rani Garnepudi
Cc: linux-wireless, johannes.berg, hofrat, prameela.garnepudi
In-Reply-To: <87sht5mg86.fsf@kamboji.qca.qualcomm.com>
On Mon, 2016-09-12 at 15:53 +0300, Kalle Valo wrote:
> Also try to get more familiar how development is done, here are few
> links:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
> https://www.kernel.org/doc/Documentation/SubmittingPatches
> https://kernelnewbies.org/FirstKernelPatch
>
> Also mailing list archives and git logs are a great way to learn from
> how others do it.
And only working on drivers/staging files is a good way to start.
^ permalink raw reply
* [PATCH] staging: squash lines for simple wrapper functions
From: Masahiro Yamada @ 2016-09-12 18:57 UTC (permalink / raw)
To: Greg KH, devel
Cc: Masahiro Yamada, linux-fbdev, Andreas Dilger, Sumit Semwal,
linux-kernel, linux-wireless, Larry Finger, Teddy Wang,
Sudip Mukherjee, Laura Abbott, Arve Hjønnevåg,
Jes Sorensen, Riley Andrews, Oleg Drokin, lustre-devel
Remove unneeded variables and assignments.
While we are here, clean up the following as well:
- refactor rtl8723a_get_bcn_valid() a bit
- remove unneeded casts in sii164Get{Vendor,Device}ID()
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/staging/android/ion/ion.c | 6 +-----
.../staging/lustre/lustre/obdclass/linux/linux-module.c | 5 +----
drivers/staging/lustre/lustre/ptlrpc/client.c | 5 +----
drivers/staging/lustre/lustre/ptlrpc/events.c | 5 +----
drivers/staging/rtl8723au/core/rtw_wlan_util.c | 7 +------
drivers/staging/rtl8723au/hal/hal_com.c | 6 +-----
drivers/staging/sm750fb/ddk750_sii164.c | 16 ++++------------
7 files changed, 10 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index a2cf93b..a07fc03 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -389,11 +389,7 @@ static void ion_handle_get(struct ion_handle *handle)
static int ion_handle_put_nolock(struct ion_handle *handle)
{
- int ret;
-
- ret = kref_put(&handle->ref, ion_handle_destroy);
-
- return ret;
+ return kref_put(&handle->ref, ion_handle_destroy);
}
static int ion_handle_put(struct ion_handle *handle)
diff --git a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
index 33342bf..3f2dd95 100644
--- a/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
+++ b/drivers/staging/lustre/lustre/obdclass/linux/linux-module.c
@@ -152,10 +152,7 @@ EXPORT_SYMBOL(obd_ioctl_getdata);
int obd_ioctl_popdata(void __user *arg, void *data, int len)
{
- int err;
-
- err = copy_to_user(arg, data, len) ? -EFAULT : 0;
- return err;
+ return copy_to_user(arg, data, len) ? -EFAULT : 0;
}
EXPORT_SYMBOL(obd_ioctl_popdata);
diff --git a/drivers/staging/lustre/lustre/ptlrpc/client.c b/drivers/staging/lustre/lustre/ptlrpc/client.c
index d4463d7..38cbf4a 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/client.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/client.c
@@ -417,10 +417,7 @@ void ptlrpc_request_cache_fini(void)
struct ptlrpc_request *ptlrpc_request_cache_alloc(gfp_t flags)
{
- struct ptlrpc_request *req;
-
- req = kmem_cache_zalloc(request_cache, flags);
- return req;
+ return kmem_cache_zalloc(request_cache, flags);
}
void ptlrpc_request_cache_free(struct ptlrpc_request *req)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/events.c b/drivers/staging/lustre/lustre/ptlrpc/events.c
index b1ce725..8821f4d 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/events.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/events.c
@@ -525,10 +525,7 @@ static void ptlrpc_ni_fini(void)
static lnet_pid_t ptl_get_pid(void)
{
- lnet_pid_t pid;
-
- pid = LNET_PID_LUSTRE;
- return pid;
+ return LNET_PID_LUSTRE;
}
static int ptlrpc_ni_init(void)
diff --git a/drivers/staging/rtl8723au/core/rtw_wlan_util.c b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
index 694cf17..7ab47f0 100644
--- a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
+++ b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
@@ -1202,12 +1202,7 @@ unsigned int update_supported_rate23a(unsigned char *ptn, unsigned int ptn_sz)
unsigned int update_MSC_rate23a(struct ieee80211_ht_cap *pHT_caps)
{
- unsigned int mask;
-
- mask = pHT_caps->mcs.rx_mask[0] << 12 |
- pHT_caps->mcs.rx_mask[1] << 20;
-
- return mask;
+ return pHT_caps->mcs.rx_mask[0] << 12 | pHT_caps->mcs.rx_mask[1] << 20;
}
int support_short_GI23a(struct rtw_adapter *padapter,
diff --git a/drivers/staging/rtl8723au/hal/hal_com.c b/drivers/staging/rtl8723au/hal/hal_com.c
index 9d7b11b..dfbeebe 100644
--- a/drivers/staging/rtl8723au/hal/hal_com.c
+++ b/drivers/staging/rtl8723au/hal/hal_com.c
@@ -708,11 +708,7 @@ void rtl8723a_bcn_valid(struct rtw_adapter *padapter)
bool rtl8723a_get_bcn_valid(struct rtw_adapter *padapter)
{
- bool retval;
-
- retval = (rtl8723au_read8(padapter, REG_TDECTRL + 2) & BIT(0)) ? true : false;
-
- return retval;
+ return !!(rtl8723au_read8(padapter, REG_TDECTRL + 2) & BIT(0));
}
void rtl8723a_set_beacon_interval(struct rtw_adapter *padapter, u16 interval)
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 67f36e7..28818e1 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -36,12 +36,8 @@ static char *gDviCtrlChipName = "Silicon Image SiI 164";
*/
unsigned short sii164GetVendorID(void)
{
- unsigned short vendorID;
-
- vendorID = ((unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_HIGH) << 8) |
- (unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_LOW);
-
- return vendorID;
+ return (i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_HIGH) << 8) |
+ i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_LOW);
}
/*
@@ -53,12 +49,8 @@ unsigned short sii164GetVendorID(void)
*/
unsigned short sii164GetDeviceID(void)
{
- unsigned short deviceID;
-
- deviceID = ((unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_HIGH) << 8) |
- (unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_LOW);
-
- return deviceID;
+ return (i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_HIGH) << 8) |
+ i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_LOW);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] staging: squash lines for simple wrapper functions
From: Jes Sorensen @ 2016-09-12 19:29 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Greg KH, devel, linux-fbdev, Andreas Dilger, Sumit Semwal,
linux-kernel, linux-wireless, Larry Finger, Teddy Wang,
Sudip Mukherjee, Laura Abbott, Arve Hjønnevåg,
Riley Andrews, Oleg Drokin, lustre-devel
In-Reply-To: <1473706668-24216-1-git-send-email-yamada.masahiro@socionext.com>
Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> Remove unneeded variables and assignments.
>
> While we are here, clean up the following as well:
> - refactor rtl8723a_get_bcn_valid() a bit
> - remove unneeded casts in sii164Get{Vendor,Device}ID()
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/staging/android/ion/ion.c | 6 +-----
> .../staging/lustre/lustre/obdclass/linux/linux-module.c | 5 +----
> drivers/staging/lustre/lustre/ptlrpc/client.c | 5 +----
> drivers/staging/lustre/lustre/ptlrpc/events.c | 5 +----
> drivers/staging/rtl8723au/core/rtw_wlan_util.c | 7 +------
> drivers/staging/rtl8723au/hal/hal_com.c | 6 +-----
> drivers/staging/sm750fb/ddk750_sii164.c | 16 ++++------------
> 7 files changed, 10 insertions(+), 40 deletions(-)
1) Do not submit one giant patch modifying multiple drivers in one go
2) drivers/staging/rtl8723au is gone - had you followed 1), you wouldn't
necessarily have had to respin this patch.
3) Consider if your changes, even if technically correct, actually
improve the code (see below)
Jes
> diff --git a/drivers/staging/rtl8723au/core/rtw_wlan_util.c b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
> index 694cf17..7ab47f0 100644
> --- a/drivers/staging/rtl8723au/core/rtw_wlan_util.c
> +++ b/drivers/staging/rtl8723au/core/rtw_wlan_util.c
> @@ -1202,12 +1202,7 @@ unsigned int update_supported_rate23a(unsigned char *ptn, unsigned int ptn_sz)
>
> unsigned int update_MSC_rate23a(struct ieee80211_ht_cap *pHT_caps)
> {
> - unsigned int mask;
> -
> - mask = pHT_caps->mcs.rx_mask[0] << 12 |
> - pHT_caps->mcs.rx_mask[1] << 20;
> -
> - return mask;
> + return pHT_caps->mcs.rx_mask[0] << 12 | pHT_caps->mcs.rx_mask[1] << 20;
> }
The use of the mask variable didn't cause any harm, and it was certainly
a lot nicer to read the way it was.
> int support_short_GI23a(struct rtw_adapter *padapter,
> diff --git a/drivers/staging/rtl8723au/hal/hal_com.c b/drivers/staging/rtl8723au/hal/hal_com.c
> index 9d7b11b..dfbeebe 100644
> --- a/drivers/staging/rtl8723au/hal/hal_com.c
> +++ b/drivers/staging/rtl8723au/hal/hal_com.c
> @@ -708,11 +708,7 @@ void rtl8723a_bcn_valid(struct rtw_adapter *padapter)
>
> bool rtl8723a_get_bcn_valid(struct rtw_adapter *padapter)
> {
> - bool retval;
> -
> - retval = (rtl8723au_read8(padapter, REG_TDECTRL + 2) & BIT(0)) ? true : false;
> -
> - return retval;
> + return !!(rtl8723au_read8(padapter, REG_TDECTRL + 2) & BIT(0));
> }
One word: Yuck!
Talk about obfuscating the code for the sake of obfuscation!
> void rtl8723a_set_beacon_interval(struct rtw_adapter *padapter, u16 interval)
> diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
> index 67f36e7..28818e1 100644
> --- a/drivers/staging/sm750fb/ddk750_sii164.c
> +++ b/drivers/staging/sm750fb/ddk750_sii164.c
> @@ -36,12 +36,8 @@ static char *gDviCtrlChipName = "Silicon Image SiI 164";
> */
> unsigned short sii164GetVendorID(void)
> {
> - unsigned short vendorID;
> -
> - vendorID = ((unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_HIGH) << 8) |
> - (unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_LOW);
> -
> - return vendorID;
> + return (i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_HIGH) << 8) |
> + i2cReadReg(SII164_I2C_ADDRESS, SII164_VENDOR_ID_LOW);
> }
>
> /*
> @@ -53,12 +49,8 @@ unsigned short sii164GetVendorID(void)
> */
> unsigned short sii164GetDeviceID(void)
> {
> - unsigned short deviceID;
> -
> - deviceID = ((unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_HIGH) << 8) |
> - (unsigned short) i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_LOW);
> -
> - return deviceID;
> + return (i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_HIGH) << 8) |
> + i2cReadReg(SII164_I2C_ADDRESS, SII164_DEVICE_ID_LOW);
> }
Getting rid of the casts would be nice, merging them into a giant
multi-line return line certainly isn't an improvement in my book. That
said, I will leave that to the maintainer of that driver to decide what
is preferred.
Jes
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Jarkko Sakkinen @ 2016-09-12 20:14 UTC (permalink / raw)
To: Felipe Balbi
Cc: Julia Lawall, linux-renesas-soc, joe, kernel-janitors,
Sergei Shtylyov, linux-pm, platform-driver-x86, linux-media,
linux-can, Tatyana Nikolova, Shiraz Saleem, Mustafa Ismail,
Chien Tin Tung, linux-rdma, netdev, devel, alsa-devel,
linux-kernel, linux-fbdev, linux-wireless, Jason Gunthorpe,
tpmdd-devel, linux-scsi, linux-spi, linux-usb, linux-acpi
In-Reply-To: <877fah5j35.fsf@linux.intel.com>
On Mon, Sep 12, 2016 at 04:43:58PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> >>
> >>
> >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> >>
> >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> >> > > Constify local structures.
> >> > >
> >> > > The semantic patch that makes this change is as follows:
> >> > > (http://coccinelle.lip6.fr/)
> >> >
> >> > Just my two cents but:
> >> >
> >> > 1. You *can* use a static analysis too to find bugs or other issues.
> >> > 2. However, you should manually do the commits and proper commit
> >> > messages to subsystems based on your findings. And I generally think
> >> > that if one contributes code one should also at least smoke test changes
> >> > somehow.
> >> >
> >> > I don't know if I'm alone with my opinion. I just think that one should
> >> > also do the analysis part and not blindly create and submit patches.
> >>
> >> All of the patches are compile tested. And the individual patches are
> >
> > Compile-testing is not testing. If you are not able to test a commit,
> > you should explain why.
>
> Dude, Julia has been doing semantic patching for years already and
> nobody has raised any concerns so far. There's already an expectation
> that Coccinelle *works* and Julia's sematic patches are sound.
>
> Besides, adding 'const' is something that causes virtually no functional
> changes to the point that build-testing is really all you need. Any
> problems caused by adding 'const' to a definition will be seen by build
> errors or warnings.
>
> Really, just stop with the pointless discussion and go read a bit about
> Coccinelle and what semantic patches are giving you. The work done by
> Julia and her peers are INRIA have measurable benefits.
>
> You're really making a thunderstorm in a glass of water.
Hmm... I've been using coccinelle in cyclic basis for some time now.
My comment was oversized but I didn't mean it to be impolite or attack
of any kind for that matter.
> --
> balbi
/Jarkko
^ permalink raw reply
* Re: [PATCH 00/26] constify local structures
From: Julia Lawall @ 2016-09-12 21:11 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: Felipe Balbi, Julia Lawall, linux-renesas-soc, joe,
kernel-janitors, Sergei Shtylyov, linux-pm, platform-driver-x86,
linux-media, linux-can, Tatyana Nikolova, Shiraz Saleem,
Mustafa Ismail, Chien Tin Tung, linux-rdma, netdev, devel,
alsa-devel, linux-kernel, linux-fbdev, linux-wireless,
Jason Gunthorpe, tpmdd-devel, linux-scsi, linux-spi, linux-usb,
linux-acpi
In-Reply-To: <20160912201450.GA8889@intel.com>
On Mon, 12 Sep 2016, Jarkko Sakkinen wrote:
> On Mon, Sep 12, 2016 at 04:43:58PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> writes:
> > > On Mon, Sep 12, 2016 at 10:54:07AM +0200, Julia Lawall wrote:
> > >>
> > >>
> > >> On Sun, 11 Sep 2016, Jarkko Sakkinen wrote:
> > >>
> > >> > On Sun, Sep 11, 2016 at 03:05:42PM +0200, Julia Lawall wrote:
> > >> > > Constify local structures.
> > >> > >
> > >> > > The semantic patch that makes this change is as follows:
> > >> > > (http://coccinelle.lip6.fr/)
> > >> >
> > >> > Just my two cents but:
> > >> >
> > >> > 1. You *can* use a static analysis too to find bugs or other issues.
> > >> > 2. However, you should manually do the commits and proper commit
> > >> > messages to subsystems based on your findings. And I generally think
> > >> > that if one contributes code one should also at least smoke test changes
> > >> > somehow.
> > >> >
> > >> > I don't know if I'm alone with my opinion. I just think that one should
> > >> > also do the analysis part and not blindly create and submit patches.
> > >>
> > >> All of the patches are compile tested. And the individual patches are
> > >
> > > Compile-testing is not testing. If you are not able to test a commit,
> > > you should explain why.
> >
> > Dude, Julia has been doing semantic patching for years already and
> > nobody has raised any concerns so far. There's already an expectation
> > that Coccinelle *works* and Julia's sematic patches are sound.
> >
> > Besides, adding 'const' is something that causes virtually no functional
> > changes to the point that build-testing is really all you need. Any
> > problems caused by adding 'const' to a definition will be seen by build
> > errors or warnings.
> >
> > Really, just stop with the pointless discussion and go read a bit about
> > Coccinelle and what semantic patches are giving you. The work done by
> > Julia and her peers are INRIA have measurable benefits.
> >
> > You're really making a thunderstorm in a glass of water.
>
> Hmm... I've been using coccinelle in cyclic basis for some time now.
> My comment was oversized but I didn't mean it to be impolite or attack
> of any kind for that matter.
No problem :) Thanks for the feedback.
julia
^ permalink raw reply
* Re: [PATCH 00/15] drivers: net: use IS_ENABLED() instead of checking for built-in or module
From: David Miller @ 2016-09-13 3:28 UTC (permalink / raw)
To: javier
Cc: linux-kernel, arnd, sony.chacko, peppe.cavallaro,
linux-net-drivers, fw, bkenward, geert, ecree, kvalo, mw, a,
intel-wired-lan, f.fainelli, felipe.balbi, gregory.clement,
Dept-HSGLinuxNICDev, jeffrey.t.kirsher, mugunthanvnm, andrew,
klassert, sgruszka, kda, qiang.zhao, netdev, gerlando.falauto,
linux-wireless, ionut, venza, alexandre.torgue
In-Reply-To: <1473689026-6983-1-git-send-email-javier@osg.samsung.com>
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Mon, 12 Sep 2016 10:03:31 -0400
> This trivial series is similar to [0] for net/ that you already merged, but
> for drivers/net. The patches replaces the open coding to check for a Kconfig
> symbol being built-in or module, with IS_ENABLED() macro that does the same.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] ath10k: Fix rfc1042 header retrieval in QCA4019 with eth decap mode
From: Thiagarajan, Vasanthakumar @ 2016-09-13 4:50 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <87fup5m8x5.fsf@kamboji.qca.qualcomm.com>
On Monday 12 September 2016 09:01 PM, Valo, Kalle wrote:
> Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> writes:
>
>> Chipset from QCA99X0 onwards (QCA99X0, QCA9984, QCA4019 & future)
>> rx_hdr_status is not padded to align in 4-byte boundary. Define a
>> new hw_params field to handle different alignment behaviour between
>> different hw. This patch fixes improper retrieval of rfc1042 header
>> with QCA4019. This patch along with "ath10k: Properly remove padding
>> from the start of rx payload" will fix traffic failure in ethernet
>> decap mode for QCA4019.
>>
>> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
>
> There were some conflicts, I fixed them in the pending branch. Please
> check my changes:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=3Dpe=
nding&id=3Dd0d9e40216e1a8edd2f3b387b96aad62c3a49add
>
Looks fine, thanks.
Vasanth=
^ permalink raw reply
* [PATCH] mac80211: simplify TDLS RA lookup
From: Johannes Berg @ 2016-09-13 6:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
smatch pointed out that the second check of "tdls_auth" was
pointless since if it was true, we returned from the function
already. We can further simplify the code by moving the first
check (if it's a TDLS peer at all) into the outer if, to only
handle that inside. This simplifies the control flow here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/tx.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ee9e7d60cb78..61d302d97145 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2263,15 +2263,9 @@ static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_STATION:
if (sdata->wdev.wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS) {
sta = sta_info_get(sdata, skb->data);
- if (sta) {
- bool tdls_peer, tdls_auth;
-
- tdls_peer = test_sta_flag(sta,
- WLAN_STA_TDLS_PEER);
- tdls_auth = test_sta_flag(sta,
- WLAN_STA_TDLS_PEER_AUTH);
-
- if (tdls_peer && tdls_auth) {
+ if (sta && test_sta_flag(sta, WLAN_STA_TDLS_PEER)) {
+ if (test_sta_flag(sta,
+ WLAN_STA_TDLS_PEER_AUTH)) {
*sta_out = sta;
return 0;
}
@@ -2283,8 +2277,7 @@ static int ieee80211_lookup_ra_sta(struct ieee80211_sub_if_data *sdata,
* after a TDLS sta is removed due to being
* unreachable.
*/
- if (tdls_peer && !tdls_auth &&
- !ieee80211_is_tdls_setup(skb))
+ if (!ieee80211_is_tdls_setup(skb))
return -EINVAL;
}
--
2.8.1
^ permalink raw reply related
* Re: [PATCH v3] mac80211: Re-structure aqm debugfs output and keep CoDel stats per txq
From: Johannes Berg @ 2016-09-13 7:17 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <20160912135543.26347-1-toke@toke.dk>
On Mon, 2016-09-12 at 15:55 +0200, Toke Høiland-Jørgensen wrote:
> Currently the 'aqm' stats in mac80211 only keeps overlimit drop
> stats,
> not CoDel stats. This moves the CoDel stats into the txqi structure
> to
> keep them per txq in order to show them in debugfs.
>
> In addition, the aqm debugfs output is restructured by splitting it
> up
> into three files: One global per phy, one per netdev and one per
> station, in the appropriate directories. The files are all called
> aqm,
> and are only created if the driver supports the wake_tx_queue op
> (rather
> than emitting an error on open as previously).
>
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding
From: Oleksij Rempel @ 2016-09-13 7:28 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: ath9k-devel, devicetree, linux-wireless, ath9k-devel, mcgrof,
mark.rutland, robh+dt, kvalo, chunkeey, arend.vanspriel,
julian.calaby, bjorn, nbd, arnd
In-Reply-To: <CAFBinCAOQmk3KY1b+D1iKAOEBfasYyei681cae4PbD+201mzbQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4629 bytes --]
Am 09.09.2016 um 22:57 schrieb Martin Blumenstingl:
> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>> +Optional properties:
>>> +- reg: Address and length of the register set for the device.
>>> +- qca,clk-25mhz: Defines that a 25MHz clock is used
>>
>> Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
>> case we need to use clock framework any way, so why not in this case too?
>> Provide dummy static clock in DT and connect it with this node?
>>
>> osc25m: oscillator {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> clock-frequency = <25000000>;
>> clock-accuracy = <30000>;
>> };
>>
>> acc: clock-controller@80040000 {
>> compatible = "some-clock-controller";
>> #clock-cells = <1>;
>> clocks = <&osc25m>;
>> reg = <0x80040000 0x204>;
>> };
>>
>>
>> &pci0 {
>> ath9k@168c,002d {
>> compatible = "pci168c,002d";
>> reg = <0x7000 0 0 0 0x1000>;
>> clocks = <&osc25m>;
>> qca,disable-5ghz;
>> };
>> };
>>
>>
>> driver will need to use clk_get and compare frequency instead of
>> of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
>> to define source clock only one time and reuse it by all affected DT
>> nodes. If we have 40MHz clock you will only need to change it in
>> fixed-clock.
> that does sound like a good idea, thanks for that input!
> However, I will remove the property for the first version because I am
> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
> needs more work (in other places, like ahb.c) anyways.
> But this suggestion should be remembered!
>
>>> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to the
>>> + ath9k wireless chip (in this case the calibration /
>>> + EEPROM data will be loaded from userspace using the
>>> + kernel firmware loader).
>>> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
>>> + 2.4GHz band. Setting this property is only needed
>>> + when the RF circuit does not support the 2.4GHz band
>>> + while it is enabled nevertheless in the EEPROM.
>>> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
>>> + 5GHz band. Setting this property is only needed when
>>> + the RF circuit does not support the 5GHz band while
>>> + it is enabled nevertheless in the EEPROM.
>>
>> This option can be reused for every WiFi controller. Not only for qca.
>> So may be instead of adding vendor specific name, make it reusable for
>> all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
>> disable-5ghz and disable-2ghz?
> I am personally fine with anything that fits best into the grand
> scheme of things.
> There are three scenarios I can think of which may be influenced by
> devicetree configuration:
> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
> band is/are enabled
> b) explicitly disable either bands (because the driver thinks due to
> whatever reason that a band is supported while in reality it isn't)
> c) explicitly enable a band (for example because the driver cannot
> automagically detect which band should be enabled)
>
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
>
> Felix' mt76 driver for example defaults to case a) but allows
> overriding (= forcefully enabling or disabling) a specific band.
>
> If we decide how this should look like in the devicetree then I can go
> ahead and implement it accordingly.
To avoid possible conflict with other device-tree bindings i would
suggest this kind of naming:
ieee80211-5ghz-enalbe
ieee80211-5ghz-disable
ieee80211-2.4ghz-enalbe
ieee80211-2.4ghz-disable
i assume at some point we would get even more eeprom overrides. For
example disable/enable some modulation and so on.
we would need 80211 specific functions to read this overrides from
device-tree and/or acpi.
any feedback from DT maintainers?
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* Re: Support of rtl8723bs
From: Hanno Zulla @ 2016-09-13 7:47 UTC (permalink / raw)
To: Jes Sorensen, Bastien Nocera; +Cc: Larry Finger, anthony.wong, linux-wireless
In-Reply-To: <wrfj4m5lhzja.fsf@redhat.com>
Hi,
> The issues I am aware of is to start out changing the register access
> macros into function pointers and stick them all into the fileops
> structure. Provide a set of SDIO ones to match the USB ones. Then you
> will need some code to detect the device, as that part will obviously be
> different from the USB device detection.
>
> I know there are a few issues to look out for in the hw register init
> files to look out for too, that does some special casing for SDIO, but
> that should be limited. I am happy to point someone in the right
> direction on that when they get to that.
I had a brief look into the sources of other drivers implementing SDIO,
but not being a kernel-dev, this is out of my league.
If you decide to reprioritize your TODO-List in favour of adding SDIO
sooner, I'll be gladly testing this for you on my hardware (and buy you
a beer).
Kind regards,
Hanno
^ permalink raw reply
* ath10k mesh + ap + encryption?
From: Simon Wunderlich @ 2016-09-13 8:00 UTC (permalink / raw)
To: ath10k@lists.infradead.org; +Cc: linux-wireless, openwrt-devel
[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]
Hi,
we have done some experiments last week on ath10k, trying to run mesh
(802.11s) and access point at the same time, both encrypted.
We have tested a recent LEDE (reboot-1519-g42f559e) but with
firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us a
working encrypted 802.11s network. However, starting an AP at the same time
didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was
running unencrypted.
We also tested version 10.2.4.97 (from codeaurora), which is now default in
LEDE. However, this version apparently doesn't support 11s mesh at all
(WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
advertises support).
So here are my questions:
* Did anyone succesfully run AP and mesh, both encrypted at the same time?
* Do you have any pointers how we could fix this? Could it be fixable in the
driver (i.e. not in firmware)?
* Does anyone have an idea if 11s will be supported in future versions? I
didn't find any changelogs, but having 11s mode no longer in the service map
does not make me optimistic.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* RE: [PATCH v3] cfg80211: Add support to configure a beacon data rate
From: Kushwaha, Purushottam @ 2016-09-13 9:04 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Undekari, Sunil Dutt, Hullur Subramanyam, Amarnath
In-Reply-To: <1473675973.29016.19.camel@sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gQWxsIG9mIHRoZXNlIGp1c3QgbW92ZSBhcm91bmQsIHJpZ2h0Pw0K
WWVzLCBqdXN0IG1vdmVkIGFyb3VuZC4gDQoNCj4gSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRv
IHNwbGl0IG91dCB0aGlzICJzaW5nbGUgcmF0ZSIgdGhpbmcgaW50byBhIGhlbHBlciBmdW5jdGlv
bi4NCnN1cmUsIHdpbGwgcmFpc2UgYSBuZXcgcGF0Y2hzZXQgd2l0aCB0aGlzIGNoYW5nZS4NCg0K
VGhhbmtzLA0KUHVydXNob3R0YW0NCg==
^ permalink raw reply
* [PATCH v4] cfg80211: Add support to configure a beacon data rate
From: Purushottam Kushwaha @ 2016-09-13 9:42 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, jouni, usdutt, amarnath, pkushwah
This allows an option to configure a single beacon tx rate (u8) for an AP.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
include/net/cfg80211.h | 25 +--
net/wireless/nl80211.c | 504 +++++++++++++++++++++++++++----------------------
2 files changed, 296 insertions(+), 233 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d5e7f69..c58afc8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -676,6 +676,18 @@ struct cfg80211_acl_data {
struct mac_address mac_addrs[];
};
+/*
+ * cfg80211_bitrate_mask - masks for bitrate control
+ */
+struct cfg80211_bitrate_mask {
+ struct {
+ u32 legacy;
+ u8 ht_mcs[IEEE80211_HT_MCS_MASK_LEN];
+ u16 vht_mcs[NL80211_VHT_NSS_MAX];
+ enum nl80211_txrate_gi gi;
+ } control[NUM_NL80211_BANDS];
+};
+
/**
* struct cfg80211_ap_settings - AP configuration
*
@@ -700,6 +712,7 @@ struct cfg80211_acl_data {
* MAC address based access control
* @pbss: If set, start as a PCP instead of AP. Relevant for DMG
* networks.
+ * @beacon_rate: masks for setting user configured beacon tx rate.
*/
struct cfg80211_ap_settings {
struct cfg80211_chan_def chandef;
@@ -719,6 +732,7 @@ struct cfg80211_ap_settings {
bool p2p_opp_ps;
const struct cfg80211_acl_data *acl;
bool pbss;
+ struct cfg80211_bitrate_mask beacon_rate;
};
/**
@@ -2001,17 +2015,6 @@ enum wiphy_params_flags {
WIPHY_PARAM_DYN_ACK = 1 << 5,
};
-/*
- * cfg80211_bitrate_mask - masks for bitrate control
- */
-struct cfg80211_bitrate_mask {
- struct {
- u32 legacy;
- u8 ht_mcs[IEEE80211_HT_MCS_MASK_LEN];
- u16 vht_mcs[NL80211_VHT_NSS_MAX];
- enum nl80211_txrate_gi gi;
- } control[NUM_NL80211_BANDS];
-};
/**
* struct cfg80211_pmksa - PMK Security Association
*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7ebad35..f49b7df 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3324,6 +3324,274 @@ static int nl80211_set_mac_acl(struct sk_buff *skb, struct genl_info *info)
return err;
}
+static u32 rateset_to_mask(struct ieee80211_supported_band *sband,
+ u8 *rates, u8 rates_len)
+{
+ u8 i;
+ u32 mask = 0;
+
+ for (i = 0; i < rates_len; i++) {
+ int rate = (rates[i] & 0x7f) * 5;
+ int ridx;
+
+ for (ridx = 0; ridx < sband->n_bitrates; ridx++) {
+ struct ieee80211_rate *srate =
+ &sband->bitrates[ridx];
+ if (rate == srate->bitrate) {
+ mask |= 1 << ridx;
+ break;
+ }
+ }
+ if (ridx == sband->n_bitrates)
+ return 0; /* rate not found */
+ }
+
+ return mask;
+}
+
+static bool ht_rateset_to_mask(struct ieee80211_supported_band *sband,
+ u8 *rates, u8 rates_len,
+ u8 mcs[IEEE80211_HT_MCS_MASK_LEN])
+{
+ u8 i;
+
+ memset(mcs, 0, IEEE80211_HT_MCS_MASK_LEN);
+
+ for (i = 0; i < rates_len; i++) {
+ int ridx, rbit;
+
+ ridx = rates[i] / 8;
+ rbit = BIT(rates[i] % 8);
+
+ /* check validity */
+ if ((ridx < 0) || (ridx >= IEEE80211_HT_MCS_MASK_LEN))
+ return false;
+
+ /* check availability */
+ if (sband->ht_cap.mcs.rx_mask[ridx] & rbit)
+ mcs[ridx] |= rbit;
+ else
+ return false;
+ }
+
+ return true;
+}
+
+static u16 vht_mcs_map_to_mcs_mask(u8 vht_mcs_map)
+{
+ u16 mcs_mask = 0;
+
+ switch (vht_mcs_map) {
+ case IEEE80211_VHT_MCS_NOT_SUPPORTED:
+ break;
+ case IEEE80211_VHT_MCS_SUPPORT_0_7:
+ mcs_mask = 0x00FF;
+ break;
+ case IEEE80211_VHT_MCS_SUPPORT_0_8:
+ mcs_mask = 0x01FF;
+ break;
+ case IEEE80211_VHT_MCS_SUPPORT_0_9:
+ mcs_mask = 0x03FF;
+ break;
+ default:
+ break;
+ }
+
+ return mcs_mask;
+}
+
+static void vht_build_mcs_mask(u16 vht_mcs_map,
+ u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+{
+ u8 nss;
+
+ for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++) {
+ vht_mcs_mask[nss] = vht_mcs_map_to_mcs_mask(vht_mcs_map & 0x03);
+ vht_mcs_map >>= 2;
+ }
+}
+
+static bool vht_set_mcs_mask(struct ieee80211_supported_band *sband,
+ struct nl80211_txrate_vht *txrate,
+ u16 mcs[NL80211_VHT_NSS_MAX])
+{
+ u16 tx_mcs_map = le16_to_cpu(sband->vht_cap.vht_mcs.tx_mcs_map);
+ u16 tx_mcs_mask[NL80211_VHT_NSS_MAX] = {};
+ u8 i;
+
+ if (!sband->vht_cap.vht_supported)
+ return false;
+
+ memset(mcs, 0, sizeof(u16) * NL80211_VHT_NSS_MAX);
+
+ /* Build vht_mcs_mask from VHT capabilities */
+ vht_build_mcs_mask(tx_mcs_map, tx_mcs_mask);
+
+ for (i = 0; i < NL80211_VHT_NSS_MAX; i++) {
+ if ((tx_mcs_mask[i] & txrate->mcs[i]) == txrate->mcs[i])
+ mcs[i] = txrate->mcs[i];
+ else
+ return false;
+ }
+
+ return true;
+}
+
+static const struct nla_policy nl80211_txattr_policy[NL80211_TXRATE_MAX + 1] = {
+ [NL80211_TXRATE_LEGACY] = { .type = NLA_BINARY,
+ .len = NL80211_MAX_SUPP_RATES },
+ [NL80211_TXRATE_HT] = { .type = NLA_BINARY,
+ .len = NL80211_MAX_SUPP_HT_RATES },
+ [NL80211_TXRATE_VHT] = { .len = sizeof(struct nl80211_txrate_vht)},
+ [NL80211_TXRATE_GI] = { .type = NLA_U8 },
+};
+
+static int nl80211_parse_tx_bitrate_mask(struct genl_info *info,
+ struct cfg80211_bitrate_mask *mask)
+{
+ struct nlattr *tb[NL80211_TXRATE_MAX + 1];
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ int rem, i;
+ struct nlattr *tx_rates;
+ struct ieee80211_supported_band *sband;
+ u16 vht_tx_mcs_map;
+
+ memset(mask, 0, sizeof(*mask));
+ /* Default to all rates enabled */
+ for (i = 0; i < NUM_NL80211_BANDS; i++) {
+ sband = rdev->wiphy.bands[i];
+
+ if (!sband)
+ continue;
+
+ mask->control[i].legacy = (1 << sband->n_bitrates) - 1;
+ memcpy(mask->control[i].ht_mcs,
+ sband->ht_cap.mcs.rx_mask,
+ sizeof(mask->control[i].ht_mcs));
+
+ if (!sband->vht_cap.vht_supported)
+ continue;
+
+ vht_tx_mcs_map = le16_to_cpu(sband->vht_cap.vht_mcs.tx_mcs_map);
+ vht_build_mcs_mask(vht_tx_mcs_map, mask->control[i].vht_mcs);
+ }
+
+ /* if no rates are given set it back to the defaults */
+ if (!info->attrs[NL80211_ATTR_TX_RATES])
+ goto out;
+
+ /* The nested attribute uses enum nl80211_band as the index. This maps
+ * directly to the enum nl80211_band values used in cfg80211.
+ */
+ BUILD_BUG_ON(NL80211_MAX_SUPP_HT_RATES > IEEE80211_HT_MCS_MASK_LEN * 8);
+ nla_for_each_nested(tx_rates, info->attrs[NL80211_ATTR_TX_RATES], rem) {
+ enum nl80211_band band = nla_type(tx_rates);
+ int err;
+
+ if (band < 0 || band >= NUM_NL80211_BANDS)
+ return -EINVAL;
+ sband = rdev->wiphy.bands[band];
+ if (sband == NULL)
+ return -EINVAL;
+ err = nla_parse(tb, NL80211_TXRATE_MAX, nla_data(tx_rates),
+ nla_len(tx_rates), nl80211_txattr_policy);
+ if (err)
+ return err;
+ if (tb[NL80211_TXRATE_LEGACY]) {
+ mask->control[band].legacy = rateset_to_mask(
+ sband,
+ nla_data(tb[NL80211_TXRATE_LEGACY]),
+ nla_len(tb[NL80211_TXRATE_LEGACY]));
+ if ((mask->control[band].legacy == 0) &&
+ nla_len(tb[NL80211_TXRATE_LEGACY]))
+ return -EINVAL;
+ }
+ if (tb[NL80211_TXRATE_HT]) {
+ if (!ht_rateset_to_mask(
+ sband,
+ nla_data(tb[NL80211_TXRATE_HT]),
+ nla_len(tb[NL80211_TXRATE_HT]),
+ mask->control[band].ht_mcs))
+ return -EINVAL;
+ }
+ if (tb[NL80211_TXRATE_VHT]) {
+ if (!vht_set_mcs_mask(
+ sband,
+ nla_data(tb[NL80211_TXRATE_VHT]),
+ mask->control[band].vht_mcs))
+ return -EINVAL;
+ }
+ if (tb[NL80211_TXRATE_GI]) {
+ mask->control[band].gi =
+ nla_get_u8(tb[NL80211_TXRATE_GI]);
+ if (mask->control[band].gi > NL80211_TXRATE_FORCE_LGI)
+ return -EINVAL;
+ }
+
+ if (mask->control[band].legacy == 0) {
+ /* don't allow empty legacy rates if HT or VHT
+ * are not even supported.
+ */
+ if (!(rdev->wiphy.bands[band]->ht_cap.ht_supported ||
+ rdev->wiphy.bands[band]->vht_cap.vht_supported))
+ return -EINVAL;
+
+ for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++)
+ if (mask->control[band].ht_mcs[i])
+ goto out;
+
+ for (i = 0; i < NL80211_VHT_NSS_MAX; i++)
+ if (mask->control[band].vht_mcs[i])
+ goto out;
+
+ /* legacy and mcs rates may not be both empty */
+ return -EINVAL;
+ }
+ }
+
+out:
+ return 0;
+}
+
+static int validate_beacon_tx_rate(struct cfg80211_ap_settings *params)
+{
+ u32 rate, count_ht, count_vht, i;
+ enum nl80211_band band;
+
+ band = params->chandef.chan->band;
+ rate = params->beacon_rate.control[band].legacy;
+
+ /* Allow only one rate */
+ if (rate && (rate & (rate - 1)))
+ return -EINVAL;
+
+ count_ht = 0;
+ for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++) {
+ if (params->beacon_rate.control[band].ht_mcs[i]) {
+ count_ht++;
+ if (count_ht > 1)
+ return -EINVAL;
+ }
+ }
+
+ count_vht = 0;
+ for (i = 0; i < NL80211_VHT_NSS_MAX; i++) {
+ if (params->beacon_rate.control[band].vht_mcs[i]) {
+ count_vht++;
+ if (count_vht > 1)
+ return -EINVAL;
+ }
+ }
+
+ if ((rate && count_ht) ||
+ (rate && count_vht) ||
+ (count_ht && count_vht) ||
+ (!rate && !count_ht && !count_vht))
+ return -EINVAL;
+
+ return 0;
+}
+
static int nl80211_parse_beacon(struct nlattr *attrs[],
struct cfg80211_beacon_data *bcn)
{
@@ -3553,6 +3821,15 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
wdev->iftype))
return -EINVAL;
+ if (info->attrs[NL80211_ATTR_TX_RATES]) {
+ err = nl80211_parse_tx_bitrate_mask(info, ¶ms.beacon_rate);
+ if (err)
+ return err;
+
+ if (validate_beacon_tx_rate(¶ms))
+ return -EINVAL;
+ }
+
if (info->attrs[NL80211_ATTR_SMPS_MODE]) {
params.smps_mode =
nla_get_u8(info->attrs[NL80211_ATTR_SMPS_MODE]);
@@ -8623,238 +8900,21 @@ static int nl80211_cancel_remain_on_channel(struct sk_buff *skb,
return rdev_cancel_remain_on_channel(rdev, wdev, cookie);
}
-static u32 rateset_to_mask(struct ieee80211_supported_band *sband,
- u8 *rates, u8 rates_len)
-{
- u8 i;
- u32 mask = 0;
-
- for (i = 0; i < rates_len; i++) {
- int rate = (rates[i] & 0x7f) * 5;
- int ridx;
-
- for (ridx = 0; ridx < sband->n_bitrates; ridx++) {
- struct ieee80211_rate *srate =
- &sband->bitrates[ridx];
- if (rate == srate->bitrate) {
- mask |= 1 << ridx;
- break;
- }
- }
- if (ridx == sband->n_bitrates)
- return 0; /* rate not found */
- }
-
- return mask;
-}
-
-static bool ht_rateset_to_mask(struct ieee80211_supported_band *sband,
- u8 *rates, u8 rates_len,
- u8 mcs[IEEE80211_HT_MCS_MASK_LEN])
-{
- u8 i;
-
- memset(mcs, 0, IEEE80211_HT_MCS_MASK_LEN);
-
- for (i = 0; i < rates_len; i++) {
- int ridx, rbit;
-
- ridx = rates[i] / 8;
- rbit = BIT(rates[i] % 8);
-
- /* check validity */
- if ((ridx < 0) || (ridx >= IEEE80211_HT_MCS_MASK_LEN))
- return false;
-
- /* check availability */
- if (sband->ht_cap.mcs.rx_mask[ridx] & rbit)
- mcs[ridx] |= rbit;
- else
- return false;
- }
-
- return true;
-}
-
-static u16 vht_mcs_map_to_mcs_mask(u8 vht_mcs_map)
-{
- u16 mcs_mask = 0;
-
- switch (vht_mcs_map) {
- case IEEE80211_VHT_MCS_NOT_SUPPORTED:
- break;
- case IEEE80211_VHT_MCS_SUPPORT_0_7:
- mcs_mask = 0x00FF;
- break;
- case IEEE80211_VHT_MCS_SUPPORT_0_8:
- mcs_mask = 0x01FF;
- break;
- case IEEE80211_VHT_MCS_SUPPORT_0_9:
- mcs_mask = 0x03FF;
- break;
- default:
- break;
- }
-
- return mcs_mask;
-}
-
-static void vht_build_mcs_mask(u16 vht_mcs_map,
- u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
-{
- u8 nss;
-
- for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++) {
- vht_mcs_mask[nss] = vht_mcs_map_to_mcs_mask(vht_mcs_map & 0x03);
- vht_mcs_map >>= 2;
- }
-}
-
-static bool vht_set_mcs_mask(struct ieee80211_supported_band *sband,
- struct nl80211_txrate_vht *txrate,
- u16 mcs[NL80211_VHT_NSS_MAX])
-{
- u16 tx_mcs_map = le16_to_cpu(sband->vht_cap.vht_mcs.tx_mcs_map);
- u16 tx_mcs_mask[NL80211_VHT_NSS_MAX] = {};
- u8 i;
-
- if (!sband->vht_cap.vht_supported)
- return false;
-
- memset(mcs, 0, sizeof(u16) * NL80211_VHT_NSS_MAX);
-
- /* Build vht_mcs_mask from VHT capabilities */
- vht_build_mcs_mask(tx_mcs_map, tx_mcs_mask);
-
- for (i = 0; i < NL80211_VHT_NSS_MAX; i++) {
- if ((tx_mcs_mask[i] & txrate->mcs[i]) == txrate->mcs[i])
- mcs[i] = txrate->mcs[i];
- else
- return false;
- }
-
- return true;
-}
-
-static const struct nla_policy nl80211_txattr_policy[NL80211_TXRATE_MAX + 1] = {
- [NL80211_TXRATE_LEGACY] = { .type = NLA_BINARY,
- .len = NL80211_MAX_SUPP_RATES },
- [NL80211_TXRATE_HT] = { .type = NLA_BINARY,
- .len = NL80211_MAX_SUPP_HT_RATES },
- [NL80211_TXRATE_VHT] = { .len = sizeof(struct nl80211_txrate_vht)},
- [NL80211_TXRATE_GI] = { .type = NLA_U8 },
-};
-
static int nl80211_set_tx_bitrate_mask(struct sk_buff *skb,
struct genl_info *info)
{
- struct nlattr *tb[NL80211_TXRATE_MAX + 1];
- struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct cfg80211_bitrate_mask mask;
- int rem, i;
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
struct net_device *dev = info->user_ptr[1];
- struct nlattr *tx_rates;
- struct ieee80211_supported_band *sband;
- u16 vht_tx_mcs_map;
+ int err;
if (!rdev->ops->set_bitrate_mask)
return -EOPNOTSUPP;
- memset(&mask, 0, sizeof(mask));
- /* Default to all rates enabled */
- for (i = 0; i < NUM_NL80211_BANDS; i++) {
- sband = rdev->wiphy.bands[i];
-
- if (!sband)
- continue;
-
- mask.control[i].legacy = (1 << sband->n_bitrates) - 1;
- memcpy(mask.control[i].ht_mcs,
- sband->ht_cap.mcs.rx_mask,
- sizeof(mask.control[i].ht_mcs));
-
- if (!sband->vht_cap.vht_supported)
- continue;
-
- vht_tx_mcs_map = le16_to_cpu(sband->vht_cap.vht_mcs.tx_mcs_map);
- vht_build_mcs_mask(vht_tx_mcs_map, mask.control[i].vht_mcs);
- }
-
- /* if no rates are given set it back to the defaults */
- if (!info->attrs[NL80211_ATTR_TX_RATES])
- goto out;
-
- /*
- * The nested attribute uses enum nl80211_band as the index. This maps
- * directly to the enum nl80211_band values used in cfg80211.
- */
- BUILD_BUG_ON(NL80211_MAX_SUPP_HT_RATES > IEEE80211_HT_MCS_MASK_LEN * 8);
- nla_for_each_nested(tx_rates, info->attrs[NL80211_ATTR_TX_RATES], rem) {
- enum nl80211_band band = nla_type(tx_rates);
- int err;
-
- if (band < 0 || band >= NUM_NL80211_BANDS)
- return -EINVAL;
- sband = rdev->wiphy.bands[band];
- if (sband == NULL)
- return -EINVAL;
- err = nla_parse(tb, NL80211_TXRATE_MAX, nla_data(tx_rates),
- nla_len(tx_rates), nl80211_txattr_policy);
- if (err)
- return err;
- if (tb[NL80211_TXRATE_LEGACY]) {
- mask.control[band].legacy = rateset_to_mask(
- sband,
- nla_data(tb[NL80211_TXRATE_LEGACY]),
- nla_len(tb[NL80211_TXRATE_LEGACY]));
- if ((mask.control[band].legacy == 0) &&
- nla_len(tb[NL80211_TXRATE_LEGACY]))
- return -EINVAL;
- }
- if (tb[NL80211_TXRATE_HT]) {
- if (!ht_rateset_to_mask(
- sband,
- nla_data(tb[NL80211_TXRATE_HT]),
- nla_len(tb[NL80211_TXRATE_HT]),
- mask.control[band].ht_mcs))
- return -EINVAL;
- }
- if (tb[NL80211_TXRATE_VHT]) {
- if (!vht_set_mcs_mask(
- sband,
- nla_data(tb[NL80211_TXRATE_VHT]),
- mask.control[band].vht_mcs))
- return -EINVAL;
- }
- if (tb[NL80211_TXRATE_GI]) {
- mask.control[band].gi =
- nla_get_u8(tb[NL80211_TXRATE_GI]);
- if (mask.control[band].gi > NL80211_TXRATE_FORCE_LGI)
- return -EINVAL;
- }
-
- if (mask.control[band].legacy == 0) {
- /* don't allow empty legacy rates if HT or VHT
- * are not even supported.
- */
- if (!(rdev->wiphy.bands[band]->ht_cap.ht_supported ||
- rdev->wiphy.bands[band]->vht_cap.vht_supported))
- return -EINVAL;
-
- for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++)
- if (mask.control[band].ht_mcs[i])
- goto out;
-
- for (i = 0; i < NL80211_VHT_NSS_MAX; i++)
- if (mask.control[band].vht_mcs[i])
- goto out;
-
- /* legacy and mcs rates may not be both empty */
- return -EINVAL;
- }
- }
+ err = nl80211_parse_tx_bitrate_mask(info, &mask);
+ if (err)
+ return err;
-out:
return rdev_set_bitrate_mask(rdev, dev, NULL, &mask);
}
--
1.9.1
^ permalink raw reply related
* Re: ath10k mesh + ap + encryption?
From: Valo, Kalle @ 2016-09-13 10:59 UTC (permalink / raw)
To: Simon Wunderlich
Cc: ath10k@lists.infradead.org, openwrt-devel@lists.openwrt.org,
linux-wireless@vger.kernel.org
In-Reply-To: <2661831.slnB0LOeVt@prime>
Simon Wunderlich <sw@simonwunderlich.de> writes:
> we have done some experiments last week on ath10k, trying to run mesh=20
> (802.11s) and access point at the same time, both encrypted.=20
>
> We have tested a recent LEDE (reboot-1519-g42f559e) but with=20
> firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave=
us a=20
> working encrypted 802.11s network. However, starting an AP at the same ti=
me=20
> didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was=20
> running unencrypted.
>
> We also tested version 10.2.4.97 (from codeaurora), which is now default =
in=20
> LEDE. However, this version apparently doesn't support 11s mesh at all=20
> (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211=20
> advertises support).
>
> So here are my questions:
>
> * Did anyone succesfully run AP and mesh, both encrypted at the same tim=
e?
> * Do you have any pointers how we could fix this? Could it be fixable in=
the=20
> driver (i.e. not in firmware)?
> * Does anyone have an idea if 11s will be supported in future versions? =
I=20
> didn't find any changelogs, but having 11s mode no longer in the service =
map=20
> does not make me optimistic.
Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
have no knowledge if anyone even tests that firmware branch with ath10k.
I recommend to only use firmware releases from ath10k-firmware.git as we
use those internally with ath10k. In any case, don't make any
assumptions about future from that firmware branch as it's so old.
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath10k mesh + ap + encryption?
From: Simon Wunderlich @ 2016-09-13 11:13 UTC (permalink / raw)
To: Valo, Kalle
Cc: ath10k@lists.infradead.org, openwrt-devel@lists.openwrt.org,
linux-wireless@vger.kernel.org, Martin Blumenstingl
In-Reply-To: <87h99kjca5.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]
On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
> > we have done some experiments last week on ath10k, trying to run mesh
> > (802.11s) and access point at the same time, both encrypted.
> >
> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
> > us a working encrypted 802.11s network. However, starting an AP at the
> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> > 802.11s was running unencrypted.
> >
> > We also tested version 10.2.4.97 (from codeaurora), which is now default
> > in
> > LEDE. However, this version apparently doesn't support 11s mesh at all
> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> > advertises support).
> >
> > So here are my questions:
> > * Did anyone succesfully run AP and mesh, both encrypted at the same
> > time?
> > * Do you have any pointers how we could fix this? Could it be fixable in
> > the>
> > driver (i.e. not in firmware)?
> >
> > * Does anyone have an idea if 11s will be supported in future versions? I
> >
> > didn't find any changelogs, but having 11s mode no longer in the service
> > map does not make me optimistic.
>
> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> have no knowledge if anyone even tests that firmware branch with ath10k.
> I recommend to only use firmware releases from ath10k-firmware.git as we
> use those internally with ath10k. In any case, don't make any
> assumptions about future from that firmware branch as it's so old.
This was introduced in December 25th, 2015 after some firmware-related
problems. I'm CC'ing Martin Blumenstingl who suggested this change.
Since then, ath10k is pulling firmware from here (unless ct firmware is used):
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
10.2.4/firmware-5.bin_10.2.4.97-1
However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
numbers. However, 10.2.4.70 has much more sub-revisions. Is there any document
describing the revisions? I don't understand it at least from this wiki page
[1].
Thanks!
Simon
[1] https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
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