* [PATCH] ath10k: change firmware file name for UTF mode of SDIO/USB
From: Wen Gong @ 2019-05-15 3:30 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Firmware name for UTF mode of SDIO has changed from utf-2.bin to
utf-sdio-2.bin, so it need to change in ath10k, otherwise it will
fail for UTF mode.
After change the name in ath10k, it will success for UTF mode of
SDIO/USB.
Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 ++
drivers/net/wireless/ath/ath10k/testmode.c | 17 ++++++++++++++++-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7131499..d4fc13d 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -151,6 +151,8 @@ enum qca9377_chip_id_rev {
#define ATH10K_FW_UTF_FILE "utf.bin"
#define ATH10K_FW_UTF_API2_FILE "utf-2.bin"
+#define ATH10K_FW_UTF_FILE_BASE "utf"
+
/* includes also the null byte */
#define ATH10K_FIRMWARE_MAGIC "QCA-ATH10K"
#define ATH10K_BOARD_MAGIC "QCA-ATH10K-BOARD"
diff --git a/drivers/net/wireless/ath/ath10k/testmode.c b/drivers/net/wireless/ath/ath10k/testmode.c
index 6433ff1..da9c596 100644
--- a/drivers/net/wireless/ath/ath10k/testmode.c
+++ b/drivers/net/wireless/ath/ath10k/testmode.c
@@ -174,8 +174,23 @@ static int ath10k_tm_fetch_firmware(struct ath10k *ar)
{
struct ath10k_fw_components *utf_mode_fw;
int ret;
+ char fw_name[100];
+ int fw_api2 = 2;
+
+ switch (ar->hif.bus) {
+ case ATH10K_BUS_SDIO:
+ case ATH10K_BUS_USB:
+ scnprintf(fw_name, sizeof(fw_name), "%s-%s-%d.bin",
+ ATH10K_FW_UTF_FILE_BASE, ath10k_bus_str(ar->hif.bus),
+ fw_api2);
+ break;
+ default:
+ scnprintf(fw_name, sizeof(fw_name), "%s-%d.bin",
+ ATH10K_FW_UTF_FILE_BASE, fw_api2);
+ break;
+ }
- ret = ath10k_core_fetch_firmware_api_n(ar, ATH10K_FW_UTF_API2_FILE,
+ ret = ath10k_core_fetch_firmware_api_n(ar, fw_name,
&ar->testmode.utf_mode_fw.fw_file);
if (ret == 0) {
ath10k_dbg(ar, ATH10K_DBG_TESTMODE, "testmode using fw utf api 2");
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-15 8:32 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Oleg Zhurakivskyy, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <20190514170136.GI9224@smile.fi.intel.com>
On Tue, May 14, 2019 at 7:01 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, May 14, 2019 at 04:53:10PM +0200, Sedat Dilek wrote:
> > On Tue, May 14, 2019 at 3:57 PM Oleg Zhurakivskyy
> > <oleg.zhurakivskyy@intel.com> wrote:
>
> > What about this one?
> >
> > diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
> > index a28c4265354d..b9e6486aa8fe 100644
> > --- a/drivers/nfc/nxp-nci/Kconfig
> > +++ b/drivers/nfc/nxp-nci/Kconfig
> > @@ -2,8 +2,8 @@ config NFC_NXP_NCI
> > tristate "NXP-NCI NFC driver"
> > depends on NFC_NCI
> > ---help---
> > - Generic core driver for NXP NCI chips such as the NPC100
> > - or PN7150 families.
> > + Generic core driver for NXP NCI chips such as the NPC100 (PN547),
> > + NPC300 (PN548) or PN7150 families.
> > This is a driver based on the NCI NFC kernel layers and
> > will thus not work with NXP libnfc library.
> >
> > @@ -19,6 +19,11 @@ config NFC_NXP_NCI_I2C
> > chips.
> > Select this if your platform is using the I2C bus.
> >
> > + Furthermore, the pin control and GPIO driver of the actual SoC or
> > + PCH is needed.
> > + For example set CONFIG_PINCTRL_SUNRISEPOINT=y to activate the
> > + Intel Sunrisepoint (PCH of Intel Skylake) pinctrl and GPIO driver.
> > +
>
> Besides some indentation problems (the help lines should be prefixed with
> 'TAB + 2 spaces'), this is not needed — it's obvious and usually distros
> provide all of pin control drivers anyway.
>
> For debugging one may check deferred devices via DebugFS, or use
> 'initcall_debug', or other facilities.
>
> > To compile this driver as a module, choose m here. The module will
> > be called nxp_nci_i2c.
> > - Say Y if unsure.
> > + Say N if unsure.
>
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
Excellent eyes (TAB + 2 spaces)!
So, this is enough?
$ git diff
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index a28c4265354d..d85a4761e271 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -2,8 +2,8 @@ config NFC_NXP_NCI
tristate "NXP-NCI NFC driver"
depends on NFC_NCI
---help---
- Generic core driver for NXP NCI chips such as the NPC100
- or PN7150 families.
+ Generic core driver for NXP NCI chips such as the PN547 (NPC100),
+ PN548 (NPC300) or PN7150 families.
This is a driver based on the NCI NFC kernel layers and
will thus not work with NXP libnfc library.
@@ -21,4 +21,4 @@ config NFC_NXP_NCI_I2C
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
- Say Y if unsure.
+ Say N if unsure.
Shall I sent a patch for this, or do you want to that yourself?
Thanks.
- Sedat -
^ permalink raw reply related
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 9:33 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190513094837.GB15694@redhat.com>
On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > >
> > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > edcca processing
> > > >
> > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > >
> > > It's good to explain what edcca does and how the file is used supposed
> > > to be used. In other words, have a small introduction for the user.
> >
> > Hi Kalle,
> >
> > edcca is used for adjusting energy detect based on CCA thresholds.
> > The code was already there so I just reported the acronym.
>
> What for it is needed ?
Care to comment why EDCCA is needed at all ?
Taking that debugfs file that enable it is read-only, it looks like
feature that nobody needs nor tests.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 9:43 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515093333.GA2333@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
> On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > >
> > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > edcca processing
> > > > >
> > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > >
> > > > It's good to explain what edcca does and how the file is used supposed
> > > > to be used. In other words, have a small introduction for the user.
> > >
> > > Hi Kalle,
> > >
> > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > The code was already there so I just reported the acronym.
> >
> > What for it is needed ?
>
> Care to comment why EDCCA is needed at all ?
>
> Taking that debugfs file that enable it is read-only, it looks like
> feature that nobody needs nor tests.
already fixed in v2
https://patchwork.kernel.org/patch/10940645/
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 9:54 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515094354.GA30757@localhost.localdomain>
On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > >
> > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > edcca processing
> > > > > >
> > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > >
> > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > to be used. In other words, have a small introduction for the user.
> > > >
> > > > Hi Kalle,
> > > >
> > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > The code was already there so I just reported the acronym.
> > >
> > > What for it is needed ?
> >
> > Care to comment why EDCCA is needed at all ?
> >
> > Taking that debugfs file that enable it is read-only, it looks like
> > feature that nobody needs nor tests.
>
> already fixed in v2
> https://patchwork.kernel.org/patch/10940645/
I'm aware of this patch and other one for mt76x02. But so far in the
sources EDCCA is disabled for mt76x02 without possibility to enable it
(and this permission file issue was pointed by Kalle during review, not
by someone who want to test EDCCA). So again, what for EDCCA is needed ?
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 10:03 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515095440.GB3407@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1832 bytes --]
> On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > >
> > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > edcca processing
> > > > > > >
> > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > >
> > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > to be used. In other words, have a small introduction for the user.
> > > > >
> > > > > Hi Kalle,
> > > > >
> > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > The code was already there so I just reported the acronym.
> > > >
> > > > What for it is needed ?
> > >
> > > Care to comment why EDCCA is needed at all ?
> > >
> > > Taking that debugfs file that enable it is read-only, it looks like
> > > feature that nobody needs nor tests.
> >
> > already fixed in v2
> > https://patchwork.kernel.org/patch/10940645/
>
> I'm aware of this patch and other one for mt76x02. But so far in the
> sources EDCCA is disabled for mt76x02 without possibility to enable it
> (and this permission file issue was pointed by Kalle during review, not
> by someone who want to test EDCCA). So again, what for EDCCA is needed ?
As I have already written in a previous email, ED/CCA is used to control tx power
according to the CCA MIB counters (e.g do not transmit if the channel busy time
is higher than 90% for given amount of time in a row). I guess it is required
by ETSI regulatory.
Regarding file permission for mt76x02 debugfs edcca node is a typo.
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Andy Shevchenko @ 2019-05-15 10:09 UTC (permalink / raw)
To: Sedat Dilek
Cc: Oleg Zhurakivskyy, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <CA+icZUW0KM07sUH=muhRwFBZQKQpeqN6wCDHSDrQM-L35bA+SQ@mail.gmail.com>
On Wed, May 15, 2019 at 10:32:36AM +0200, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 7:01 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> So, this is enough?
Yes, please send it as a formal patch, I will chain it to my series and resend
in a bunch of v3.
> $ git diff
> diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
> index a28c4265354d..d85a4761e271 100644
> --- a/drivers/nfc/nxp-nci/Kconfig
> +++ b/drivers/nfc/nxp-nci/Kconfig
> @@ -2,8 +2,8 @@ config NFC_NXP_NCI
> tristate "NXP-NCI NFC driver"
> depends on NFC_NCI
> ---help---
> - Generic core driver for NXP NCI chips such as the NPC100
> - or PN7150 families.
> + Generic core driver for NXP NCI chips such as the PN547 (NPC100),
> + PN548 (NPC300) or PN7150 families.
> This is a driver based on the NCI NFC kernel layers and
> will thus not work with NXP libnfc library.
>
> @@ -21,4 +21,4 @@ config NFC_NXP_NCI_I2C
>
> To compile this driver as a module, choose m here. The module will
> be called nxp_nci_i2c.
> - Say Y if unsure.
> + Say N if unsure.
>
> Shall I sent a patch for this, or do you want to that yourself?
>
> Thanks.
>
> - Sedat -
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Sedat Dilek @ 2019-05-15 10:22 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Oleg Zhurakivskyy, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <20190515100919.GJ9224@smile.fi.intel.com>
On Wed, May 15, 2019 at 12:09 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Wed, May 15, 2019 at 10:32:36AM +0200, Sedat Dilek wrote:
> > On Tue, May 14, 2019 at 7:01 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
>
> > So, this is enough?
>
> Yes, please send it as a formal patch, I will chain it to my series and resend
> in a bunch of v3.
>
Will do after rebooting into Linux v5.1.2 stable :-).
- Sedat -
> > $ git diff
> > diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
> > index a28c4265354d..d85a4761e271 100644
> > --- a/drivers/nfc/nxp-nci/Kconfig
> > +++ b/drivers/nfc/nxp-nci/Kconfig
> > @@ -2,8 +2,8 @@ config NFC_NXP_NCI
> > tristate "NXP-NCI NFC driver"
> > depends on NFC_NCI
> > ---help---
> > - Generic core driver for NXP NCI chips such as the NPC100
> > - or PN7150 families.
> > + Generic core driver for NXP NCI chips such as the PN547 (NPC100),
> > + PN548 (NPC300) or PN7150 families.
> > This is a driver based on the NCI NFC kernel layers and
> > will thus not work with NXP libnfc library.
> >
> > @@ -21,4 +21,4 @@ config NFC_NXP_NCI_I2C
> >
> > To compile this driver as a module, choose m here. The module will
> > be called nxp_nci_i2c.
> > - Say Y if unsure.
> > + Say N if unsure.
> >
> > Shall I sent a patch for this, or do you want to that yourself?
> >
> > Thanks.
> >
> > - Sedat -
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 10:33 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515100343.GB30757@localhost.localdomain>
On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > >
> > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > edcca processing
> > > > > > > >
> > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > >
> > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > >
> > > > > > Hi Kalle,
> > > > > >
> > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > The code was already there so I just reported the acronym.
> > > > >
> > > > > What for it is needed ?
> > > >
> > > > Care to comment why EDCCA is needed at all ?
> > > >
> > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > feature that nobody needs nor tests.
> > >
> > > already fixed in v2
> > > https://patchwork.kernel.org/patch/10940645/
> >
> > I'm aware of this patch and other one for mt76x02. But so far in the
> > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > (and this permission file issue was pointed by Kalle during review, not
> > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
>
> As I have already written in a previous email, ED/CCA is used to control tx power
> according to the CCA MIB counters (e.g do not transmit if the channel busy time
> is higher than 90% for given amount of time in a row). I guess it is required
> by ETSI regulatory.
But what is user case for that, i.e. who need this (it wasn't implemented in
mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> Regarding file permission for mt76x02 debugfs edcca node is a typo.
Typo or not, effectively disable the feature and show nobody is
testing it.
The reason I'm asking is that seems EDCCA is the main reason to
implement watchod for mt76x2, it wasn't necessary to have a watchdog
as seems devices did not hung before EDCCA was added.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 11:46 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515111348.GC30757@localhost.localdomain>
On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > > >
> > > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > > edcca processing
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > > >
> > > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > > >
> > > > > > > > Hi Kalle,
> > > > > > > >
> > > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > > The code was already there so I just reported the acronym.
> > > > > > >
> > > > > > > What for it is needed ?
> > > > > >
> > > > > > Care to comment why EDCCA is needed at all ?
> > > > > >
> > > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > > feature that nobody needs nor tests.
> > > > >
> > > > > already fixed in v2
> > > > > https://patchwork.kernel.org/patch/10940645/
> > > >
> > > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > > (and this permission file issue was pointed by Kalle during review, not
> > > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> > >
> > > As I have already written in a previous email, ED/CCA is used to control tx power
> > > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > > is higher than 90% for given amount of time in a row). I guess it is required
> > > by ETSI regulatory.
> > But what is user case for that, i.e. who need this (it wasn't implemented in
> > mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> >
> > > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> > Typo or not, effectively disable the feature and show nobody is
> > testing it.
> >
> > The reason I'm asking is that seems EDCCA is the main reason to
> > implement watchod for mt76x2, it wasn't necessary to have a watchdog
> > as seems devices did not hung before EDCCA was added.
>
> IIRC I added the first watchdog implementation to fix tx hangs that occur
> under heavy load even using FCC regulatory (so when EDCCA processing is
> disabled)
There was changes in various registers programming introduced by EDCCA
support, even with EDCCA disabled. It's rally not convenient that
watchdog and EDCCA are not related, since you added tx hung watchdog
2 weeks after adding EDCCA.
You can look at this report:
https://github.com/openwrt/mt76/issues/246
Before mt76x2e worked without hungs & watchodg. Now, even with EDCCA
disabled watchdog and HW restarts are required to fix hungs on runtime.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 11:13 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515103309.GA15134@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]
> On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > >
> > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > edcca processing
> > > > > > > > >
> > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > >
> > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > >
> > > > > > > Hi Kalle,
> > > > > > >
> > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > The code was already there so I just reported the acronym.
> > > > > >
> > > > > > What for it is needed ?
> > > > >
> > > > > Care to comment why EDCCA is needed at all ?
> > > > >
> > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > feature that nobody needs nor tests.
> > > >
> > > > already fixed in v2
> > > > https://patchwork.kernel.org/patch/10940645/
> > >
> > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > (and this permission file issue was pointed by Kalle during review, not
> > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> >
> > As I have already written in a previous email, ED/CCA is used to control tx power
> > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > is higher than 90% for given amount of time in a row). I guess it is required
> > by ETSI regulatory.
> But what is user case for that, i.e. who need this (it wasn't implemented in
> mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
>
> > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> Typo or not, effectively disable the feature and show nobody is
> testing it.
>
> The reason I'm asking is that seems EDCCA is the main reason to
> implement watchod for mt76x2, it wasn't necessary to have a watchdog
> as seems devices did not hung before EDCCA was added.
IIRC I added the first watchdog implementation to fix tx hangs that occur
under heavy load even using FCC regulatory (so when EDCCA processing is
disabled)
Regards,
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Lorenzo Bianconi @ 2019-05-15 12:07 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515114615.GB15134@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
> On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > > > >
> > > > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > > > edcca processing
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > > > >
> > > > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > > > >
> > > > > > > > > Hi Kalle,
> > > > > > > > >
> > > > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > > > The code was already there so I just reported the acronym.
> > > > > > > >
> > > > > > > > What for it is needed ?
> > > > > > >
> > > > > > > Care to comment why EDCCA is needed at all ?
> > > > > > >
> > > > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > > > feature that nobody needs nor tests.
> > > > > >
> > > > > > already fixed in v2
> > > > > > https://patchwork.kernel.org/patch/10940645/
> > > > >
> > > > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > > > (and this permission file issue was pointed by Kalle during review, not
> > > > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> > > >
> > > > As I have already written in a previous email, ED/CCA is used to control tx power
> > > > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > > > is higher than 90% for given amount of time in a row). I guess it is required
> > > > by ETSI regulatory.
> > > But what is user case for that, i.e. who need this (it wasn't implemented in
> > > mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> > >
> > > > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> > > Typo or not, effectively disable the feature and show nobody is
> > > testing it.
> > >
> > > The reason I'm asking is that seems EDCCA is the main reason to
> > > implement watchod for mt76x2, it wasn't necessary to have a watchdog
> > > as seems devices did not hung before EDCCA was added.
> >
> > IIRC I added the first watchdog implementation to fix tx hangs that occur
> > under heavy load even using FCC regulatory (so when EDCCA processing is
> > disabled)
>
> There was changes in various registers programming introduced by EDCCA
> support, even with EDCCA disabled. It's rally not convenient that
> watchdog and EDCCA are not related, since you added tx hung watchdog
> 2 weeks after adding EDCCA.
>
> You can look at this report:
> https://github.com/openwrt/mt76/issues/246
> Before mt76x2e worked without hungs & watchodg. Now, even with EDCCA
> disabled watchdog and HW restarts are required to fix hungs on runtime.
Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
traffic) and moreover they do not always occur so I am not convinced they
are always EDCCA related and so I am not confident to remove the watchdog
Lorenzo
>
> Stanislaw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] NFC: nxp-nci: Clarify on supported chips
From: Oleg Zhurakivskyy @ 2019-05-15 12:10 UTC (permalink / raw)
To: Sedat Dilek, Samuel Ortiz, Charles Gorand,
Clément Perrochaud, linux-nfc, linux-wireless, linux-kernel
Cc: Andy Shevchenko
In-Reply-To: <20190515120233.19159-1-sedat.dilek@credativ.de>
On 5/15/19 3:02 PM, Sedat Dilek wrote:
> This patch clarifies on the supported NXP NCI chips and families
> and lists PN547 and PN548 separately which are known as NPC100
> respectively NPC300.
LGTM and thanks!
Regards,
Oleg
^ permalink raw reply
* [PATCH 1/2] NFC: nxp-nci: Clarify on supported chips
From: Sedat Dilek @ 2019-05-15 12:02 UTC (permalink / raw)
To: Samuel Ortiz, Charles Gorand, Clément Perrochaud, linux-nfc,
linux-wireless, linux-kernel
Cc: Sedat Dilek, Andy Shevchenko, Oleg Zhurakivskyy
This patch clarifies on the supported NXP NCI chips and families
and lists PN547 and PN548 separately which are known as NPC100
respectively NPC300.
This helps to find informations and identify drivers on vendor's
support websites.
This patch is on top of Andy Shevchenko's patchset:
"[PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID"
For details see the discussion in [1] and [2].
I add the references to the linux-wireless mailing-list and patchwork
URLs as Linux NFC is marked orphan now (see commit "NFC: Orphan the
subsystem").
NOTE: Tested above patchset against Linux v5.1.1 and v5.1.2.
[1] https://marc.info/?t=155774435600001&r=1&w=2
[2] https://patchwork.kernel.org/project/linux-wireless/list/?submitter=33142
[3] https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=d0a7e8cb3c9d7d4fa2bcdd557be19f0841e2a3be
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
---
drivers/nfc/nxp-nci/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index a28c4265354d..16473cfcb1d8 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -2,8 +2,8 @@ config NFC_NXP_NCI
tristate "NXP-NCI NFC driver"
depends on NFC_NCI
---help---
- Generic core driver for NXP NCI chips such as the NPC100
- or PN7150 families.
+ Generic core driver for NXP NCI chips such as the NPC100 (PN547),
+ NPC300 (PN548) or PN7150 families.
This is a driver based on the NCI NFC kernel layers and
will thus not work with NXP libnfc library.
--
2.20.1
^ permalink raw reply related
* [PATCH 2/2] NFC: nxp-nci: Fix recommendation for NFC_NXP_NCI_I2C Kconfig
From: Sedat Dilek @ 2019-05-15 12:04 UTC (permalink / raw)
To: Clément Perrochaud, Charles Gorand, Samuel Ortiz, linux-nfc,
linux-wireless, linux-kernel
Cc: Sedat Dilek, Andy Shevchenko, Oleg Zhurakivskyy
This is a simple cleanup to the Kconfig help text as discussed in [1].
[1] https://marc.info/?t=155774435600001&r=1&w=2
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Suggested-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Signed-off-by: Sedat Dilek <sedat.dilek@credativ.de>
---
drivers/nfc/nxp-nci/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/Kconfig b/drivers/nfc/nxp-nci/Kconfig
index 16473cfcb1d8..a38c426452ca 100644
--- a/drivers/nfc/nxp-nci/Kconfig
+++ b/drivers/nfc/nxp-nci/Kconfig
@@ -21,4 +21,4 @@ config NFC_NXP_NCI_I2C
To compile this driver as a module, choose m here. The module will
be called nxp_nci_i2c.
- Say Y if unsure.
+ Say N if unsure.
--
2.20.1
^ permalink raw reply related
* [PATCH] wireless-regdb: Update regulatory rules for Japan (JP) on 5GHz
From: Vladimir Koutny @ 2019-05-15 11:50 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless
According to multiple sources channels 8-16 (5030-5090MHz) were only
allowed in Japan until Nov-30, 2017 (later extended to Nov-30, 2018).
https://www.tele.soumu.go.jp/j/adm/system/trunk/wimax/5ghz/index.htm
http://www.dspr.co.jp/wp/wp-content/uploads/2017/10/The-expiration-date-of-some-frequency-of-the-5GHz-band-radio-access-system_eng.pdf
Signed-off-by: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
---
db.txt | 1 -
1 file changed, 1 deletion(-)
diff --git a/db.txt b/db.txt
index 4fb1948..7e10d0d 100644
--- a/db.txt
+++ b/db.txt
@@ -658,7 +658,6 @@ country JP: DFS-JP
(2402 - 2482 @ 40), (20)
(2474 - 2494 @ 20), (20), NO-OFDM
(4910 - 4990 @ 40), (23)
- (5030 - 5090 @ 40), (23)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (23), DFS
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] libertas/libertas_tf: fix spelling mistake "Donwloading" -> "Downloading"
From: Mukesh Ojha @ 2019-05-15 12:26 UTC (permalink / raw)
To: Colin King, Kalle Valo, David S . Miller, libertas-dev,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190514211406.6353-1-colin.king@canonical.com>
On 5/15/2019 2:44 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is are two spelling mistakes in lbtf_deb_usb2 messages, fix these.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Cheers,
-Mukesh
> ---
> drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
> drivers/net/wireless/marvell/libertas_tf/if_usb.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/if_usb.c b/drivers/net/wireless/marvell/libertas/if_usb.c
> index 220dcdee8d2b..1d06fa564e28 100644
> --- a/drivers/net/wireless/marvell/libertas/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas/if_usb.c
> @@ -367,7 +367,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
> cardp->fwseqnum, cardp->totalbytes);
> } else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
> lbs_deb_usb2(&cardp->udev->dev, "Host has finished FW downloading\n");
> - lbs_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
> + lbs_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
>
> cardp->fwfinalblk = 1;
> }
> diff --git a/drivers/net/wireless/marvell/libertas_tf/if_usb.c b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> index a4b9ede70705..38f77b1a02ca 100644
> --- a/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> +++ b/drivers/net/wireless/marvell/libertas_tf/if_usb.c
> @@ -319,7 +319,7 @@ static int if_usb_send_fw_pkt(struct if_usb_card *cardp)
> } else if (fwdata->hdr.dnldcmd == cpu_to_le32(FW_HAS_LAST_BLOCK)) {
> lbtf_deb_usb2(&cardp->udev->dev,
> "Host has finished FW downloading\n");
> - lbtf_deb_usb2(&cardp->udev->dev, "Donwloading FW JUMP BLOCK\n");
> + lbtf_deb_usb2(&cardp->udev->dev, "Downloading FW JUMP BLOCK\n");
>
> /* Host has finished FW downloading
> * Donwloading FW JUMP BLOCK
^ permalink raw reply
* Re: [wireless-regdb] [PATCH v2] wireless-regdb: Update regulatory rules for South Korea
From: Seth Forshee @ 2019-05-15 13:03 UTC (permalink / raw)
To: Peter Oh; +Cc: wireless-regdb@lists.infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <1556314283-17842-1-git-send-email-peter.oh@bowerswilkins.com>
On Fri, Apr 26, 2019 at 09:31:31PM +0000, Peter Oh wrote:
> From: Peter Oh <peter.oh@bowerswilkins.com>
>
> Update power limit as documented in:
> http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/
> %EC%8B%A0%EA%B3%A0%ED%95%98%EC%A7%80%EC%95%84%EB%8B%88%ED
> %95%98%EA%B3%A0%EA%B0%9C%EC%84%A4%ED%95%A0%EC%88%98%EC%9E
> %88%EB%8A%94%EB%AC%B4%EC%84%A0%EA%B5%AD%EC%9A%A9%EB%AC%B4
> %EC%84%A0%EA%B8%B0%EA%B8%B0/(2018-89,20181227)
> which revised on December 27, 2018.
>
> Signed-off-by: Peter Oh <peter.oh@bowerswilkins.com>
> ---
> db.txt | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/db.txt b/db.txt
> index 4fb1948..8d24305 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -695,11 +695,12 @@ country KP: DFS-JP
> (5735 - 5815 @ 20), (30)
>
> country KR: DFS-JP
> - (2402 - 2482 @ 40), (13)
> - (5170 - 5250 @ 80), (20), AUTO-BW
> - (5250 - 5330 @ 80), (20), DFS, AUTO-BW
> - (5490 - 5710 @ 160), (30), DFS
> - (5735 - 5835 @ 80), (30)
> + # ref: https://www.rra.go.kr
> + (2402 - 2482 @ 40), (23)
> + (5170 - 5250 @ 80), (23), AUTO-BW
> + (5250 - 5330 @ 80), (23), DFS, AUTO-BW
> + (5490 - 5710 @ 160), (23), DFS
> + (5735 - 5835 @ 80), (23)
Is there any mention of transmit power control in the document? The fact
that some of the old limits are exactly half of they values you've given
makes me wonder if they weren't set lower for TPC, especially for
5250-5350 MHz where TPC is common.
Since you're changing these rules, I'd also like to see the frequency
ranges changed to match the documented ranges, i.e.:
2400 - 2483.5
5150 - 5250
5250 - 5350
5470 - 5710
5735 - 5850
I left the gap in the 5470-5850 MHz range since I can't tell exactly
where the DFS requirement ends. Usually it seems to be 5725 MHz, but
that is not universal. If you can determine where the break is those
ranges could also be expanded.
Thanks,
Seth
^ permalink raw reply
* Re: [wireless-regdb] wireless-regdb: Please update regulatory rules for Japan (JP) on 60GHz
From: seth.forshee @ 2019-05-15 13:15 UTC (permalink / raw)
To: b.K.il.h.u+tigbuh
Cc: junping.xu@jaguarwave.com, linux-wireless, wireless-regdb
In-Reply-To: <CAPuHQ=EvWzXtxk0fLOT6PyeYkcNOOXmw0ck-yT-JsqhhDmu2gA@mail.gmail.com>
On Fri, Apr 26, 2019 at 12:00:22AM +0200, b.K.il.h.u+tigbuh@gmail.com wrote:
> This seems to be the page for the previous standard:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t74.html
>
> And the following should be the new standard, but I don't know where
> to obtain it:
> https://www.arib.or.jp/english/std_tr/telecommunications/std-t117.html
>
> The description fields here do note the range of 57-66GHz, though:
> https://www.arib.or.jp/kikaku/kikaku_tushin/desc/std-t117.html
> https://webstore.arib.or.jp/en/products/detail.php?product_id=288
>
> Similar mentions in the news (search for T117):
> https://www.arib.or.jp/image/osirase/news/1044.pdf
> https://www.arib.or.jp/image/iinkai/kikaku-kaigi/rireki/101.pdf
>
> Testing procedure is described here, not sure if it's considered useful:
> file:///home/bkil/chrome.root/Downloads/60ghz2_1_19_4_2_1.pdf
Thanks. Judging by these and numerous other third-party resources I've
found, I think it's safe to say that the range was expanded back to 57
GHz quite some time ago. I'll send a patch to update this range.
Seth
^ permalink raw reply
* [PATCH] wireless-regdb: Expand 60 GHz band for Japan to 57-66 GHz
From: Seth Forshee @ 2019-05-15 13:26 UTC (permalink / raw)
To: wireless-regdb; +Cc: linux-wireless
The official documents are not feely available, but based on
summaries such as [1] and numerous third-party resources the 60
GHz band in Japan has been 57-66 GHz for some time now. Update
our rules accordingly.
[1] https://webstore.arib.or.jp/en/products/detail.php?product_id=288
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 4fb194835116..e11e0f747386 100644
--- a/db.txt
+++ b/db.txt
@@ -664,7 +664,7 @@ country JP: DFS-JP
(5490 - 5710 @ 160), (23), DFS
# 60 GHz band channels 2-4 at 10mW,
# ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
- (59000 - 66000 @ 2160), (10 mW)
+ (57000 - 66000 @ 2160), (10 mW)
country KE: DFS-JP
(2402 - 2482 @ 40), (20)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] wireless-regdb: update source of information for ES
From: Seth Forshee @ 2019-05-15 13:29 UTC (permalink / raw)
To: Xose Vazquez Perez; +Cc: WIRELESS ML, REGDB ML
In-Reply-To: <20190504191817.3668-1-xose.vazquez@gmail.com>
On Sat, May 04, 2019 at 09:18:17PM +0200, Xose Vazquez Perez wrote:
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: WIRELESS ML <linux-wireless@vger.kernel.org>
> Cc: REGDB ML <wireless-regdb@lists.infradead.org>
> Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Applied, thanks!
> ---
> db.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/db.txt b/db.txt
> index 4fb1948..fe909a8 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -432,7 +432,7 @@ country EG: DFS-ETSI
>
> # Source:
> # Cuadro nacional de atribución de frecuencias (CNAF)
> -# http://www.mincotur.gob.es/telecomunicaciones/espectro/paginas/cnaf.aspx
> +# https://avancedigital.gob.es/espectro/Paginas/cnaf.aspx
> country ES: DFS-ETSI
> (2400 - 2483.5 @ 40), (100 mW)
> (5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] wireless-regdb: Update regulatory rules for Japan (JP) on 5GHz
From: Seth Forshee @ 2019-05-15 13:32 UTC (permalink / raw)
To: Vladimir Koutny; +Cc: wireless-regdb, linux-wireless
In-Reply-To: <82a15f3c-fe0c-a5dc-9846-13b3efb01f0d@streamunlimited.com>
On Wed, May 15, 2019 at 01:50:59PM +0200, Vladimir Koutny wrote:
> According to multiple sources channels 8-16 (5030-5090MHz) were only
> allowed in Japan until Nov-30, 2017 (later extended to Nov-30, 2018).
>
> https://www.tele.soumu.go.jp/j/adm/system/trunk/wimax/5ghz/index.htm
> http://www.dspr.co.jp/wp/wp-content/uploads/2017/10/The-expiration-date-of-some-frequency-of-the-5GHz-band-radio-access-system_eng.pdf
>
> Signed-off-by: Vladimir Koutny <vladimir.koutny@streamunlimited.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 13:48 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515120741.GD30757@localhost.localdomain>
On Wed, May 15, 2019 at 02:07:42PM +0200, Lorenzo Bianconi wrote:
> > On Wed, May 15, 2019 at 01:13:49PM +0200, Lorenzo Bianconi wrote:
> > > > On Wed, May 15, 2019 at 12:03:44PM +0200, Lorenzo Bianconi wrote:
> > > > > > On Wed, May 15, 2019 at 11:43:55AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > On Mon, May 13, 2019 at 11:48:37AM +0200, Stanislaw Gruszka wrote:
> > > > > > > > > On Mon, May 13, 2019 at 10:41:28AM +0200, Lorenzo Bianconi wrote:
> > > > > > > > > > > Lorenzo Bianconi <lorenzo@kernel.org> writes:
> > > > > > > > > > >
> > > > > > > > > > > > Introduce a knob in mt7603 debugfs in order to enable/disable
> > > > > > > > > > > > edcca processing
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > > > > > > > > >
> > > > > > > > > > > It's good to explain what edcca does and how the file is used supposed
> > > > > > > > > > > to be used. In other words, have a small introduction for the user.
> > > > > > > > > >
> > > > > > > > > > Hi Kalle,
> > > > > > > > > >
> > > > > > > > > > edcca is used for adjusting energy detect based on CCA thresholds.
> > > > > > > > > > The code was already there so I just reported the acronym.
> > > > > > > > >
> > > > > > > > > What for it is needed ?
> > > > > > > >
> > > > > > > > Care to comment why EDCCA is needed at all ?
> > > > > > > >
> > > > > > > > Taking that debugfs file that enable it is read-only, it looks like
> > > > > > > > feature that nobody needs nor tests.
> > > > > > >
> > > > > > > already fixed in v2
> > > > > > > https://patchwork.kernel.org/patch/10940645/
> > > > > >
> > > > > > I'm aware of this patch and other one for mt76x02. But so far in the
> > > > > > sources EDCCA is disabled for mt76x02 without possibility to enable it
> > > > > > (and this permission file issue was pointed by Kalle during review, not
> > > > > > by someone who want to test EDCCA). So again, what for EDCCA is needed ?
> > > > >
> > > > > As I have already written in a previous email, ED/CCA is used to control tx power
> > > > > according to the CCA MIB counters (e.g do not transmit if the channel busy time
> > > > > is higher than 90% for given amount of time in a row). I guess it is required
> > > > > by ETSI regulatory.
> > > > But what is user case for that, i.e. who need this (it wasn't implemented in
> > > > mt76x2 since you added it on Dec 2018). What will happen if it will be removed?
> > > >
> > > > > Regarding file permission for mt76x02 debugfs edcca node is a typo.
> > > > Typo or not, effectively disable the feature and show nobody is
> > > > testing it.
> > > >
> > > > The reason I'm asking is that seems EDCCA is the main reason to
> > > > implement watchod for mt76x2, it wasn't necessary to have a watchdog
> > > > as seems devices did not hung before EDCCA was added.
> > >
> > > IIRC I added the first watchdog implementation to fix tx hangs that occur
> > > under heavy load even using FCC regulatory (so when EDCCA processing is
> > > disabled)
> >
> > There was changes in various registers programming introduced by EDCCA
> > support, even with EDCCA disabled. It's rally not convenient that
> > watchdog and EDCCA are not related, since you added tx hung watchdog
> > 2 weeks after adding EDCCA.
> >
> > You can look at this report:
> > https://github.com/openwrt/mt76/issues/246
> > Before mt76x2e worked without hungs & watchodg. Now, even with EDCCA
> > disabled watchdog and HW restarts are required to fix hungs on runtime.
>
> Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
> traffic) and moreover they do not always occur so I am not convinced they
> are always EDCCA related and so I am not confident to remove the watchdog
I'm not opting for watchdog removal, but for full EDCCA removal.
Apparently nobody cares, if it can be enabled or not.
Stanislaw
^ permalink raw reply
* Re: [PATCH] mt76: mt7603: add debugfs knob to enable/disable edcca
From: Stanislaw Gruszka @ 2019-05-15 13:59 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: Kalle Valo, nbd, lorenzo.bianconi, linux-wireless
In-Reply-To: <20190515134828.GA2992@redhat.com>
On Wed, May 15, 2019 at 03:48:29PM +0200, Stanislaw Gruszka wrote:
> > Tx hangs occur in very particular conditions (e.g 200Mbps bidirectional
> > traffic) and moreover they do not always occur so I am not convinced they
> > are always EDCCA related and so I am not confident to remove the watchdog
>
> I'm not opting for watchdog removal, but for full EDCCA removal.
On mt76x02, on other chips/firmwares it can work just fine.
Stanislaw
^ permalink raw reply
* Re: [wireless-regdb] [PATCH v2] wireless-regdb: Update regulatory rules for South Korea
From: Seth Forshee @ 2019-05-15 16:21 UTC (permalink / raw)
To: suchan; +Cc: wireless-regdb, Peter Oh, linux-wireless
In-Reply-To: <a2fa616d-7829-137c-7f48-6c59974cfa46@mail.com>
You dropped Peter and the linux-wireless list from your reply, adding
them back.
On Thu, May 16, 2019 at 12:10:16AM +0900, suchan wrote:
>
> 2019-05-15 10:03PM at Seth Forshee wrote:
> >
> > Is there any mention of transmit power control in the document? The fact
> > that some of the old limits are exactly half of they values you've given
> > makes me wonder if they weren't set lower for TPC, especially for
> > 5250-5350 MHz where TPC is common.
> >
> > Since you're changing these rules, I'd also like to see the frequency
> > ranges changed to match the documented ranges, i.e.:
> >
> > 2400 - 2483.5
> > 5150 - 5250
> > 5250 - 5350
> > 5470 - 5710
> > 5735 - 5850
> >
> > I left the gap in the 5470-5850 MHz range since I can't tell exactly
> > where the DFS requirement ends. Usually it seems to be 5725 MHz, but
> > that is not universal. If you can determine where the break is those
> > ranges could also be expanded.
> >
> > Thanks,
> > Seth
> >
> > _______________________________________________
> > wireless-regdb mailing list
> > wireless-regdb@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/wireless-regdb
>
> from same document, just under the table for wifi range itself 5250∼5350
> MHz and 5470∼5725 MHz need TPC and DFS
>
> TPC rule is if power exceeds 25mW/MHz (this includes antenna gain), it
> has do be able to reduce it under 12.5mW/Mhz.
>
> DFS rule itself (DFS-JP) looks right.
Thanks! Based on that I think this is probably what we need:
(2400 - 2483.5 @ 40), (23)
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (20), DFS, AUTO-BW
(5470 - 5725 @ 160), (20), DFS
(5725 - 5835 @ 80), (23)
Peter, if that looks good to you please send a v3 patch.
Thanks,
Seth
^ 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