* 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: 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: 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 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 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] 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] 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 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: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 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
* [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] ath10k: add support for simulate crash on SDIO chip
From: Claire Chang @ 2019-05-15 2:52 UTC (permalink / raw)
To: Wen Gong; +Cc: ath10k, open list:NETWORKING DRIVERS (WIRELESS)
In-Reply-To: <1556524457-17469-1-git-send-email-wgong@codeaurora.org>
Tested-by: Claire Chang <tientzu@chromium.org>
If this patch adds support for detecting the real firmware assert,
maybe the title should be "add support for _crash recovery_ on SDIO
chip"
^ permalink raw reply
* Thank You For Contacting Us
From: Clarendon Fleet Livery Ltd via Clarendon Fleet Livery Ltd @ 2019-05-15 1:38 UTC (permalink / raw)
To: linux-wireless
Dear FrankGlaKy,
Thank you for contacting us. We have received your message and will respond
as soon as we can.
^ permalink raw reply
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From: Jia-Ju Bai @ 2019-05-15 1:20 UTC (permalink / raw)
To: Larry Finger, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org, netdev
In-Reply-To: <12810ae7-ff10-42be-7887-19b68331980c@lwfinger.net>
On 2019/5/15 9:08, Larry Finger wrote:
> On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
>> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy()
>> in rtl_pci_intr_mode_decide() fails, a crash occurs.
>> The crash information is as follows:
>>
>> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
>> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user
>> memory access
>> ......
>> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
>> ......
>> [ 108.271235] Call Trace:
>> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
>> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
>> [ 108.271261] ? ethtool_get_settings+0x340/0x340
>> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271279] ? kasan_check_write+0x14/0x20
>> [ 108.271284] dev_ethtool+0x272d/0x4c20
>> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271299] ? __save_stack_trace+0x92/0x100
>> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
>> [ 108.271316] ? save_stack+0xa3/0xd0
>> [ 108.271323] ? save_stack+0x43/0xd0
>> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
>> [ 108.271354] ? update_stack_state+0x3b2/0x670
>> [ 108.271361] ? update_stack_state+0x3b2/0x670
>> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
>> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
>> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
>> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
>> [ 108.271408] ? kernel_text_address+0x11d/0x130
>> [ 108.271416] ? __kernel_text_address+0x12/0x40
>> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
>> [ 108.271431] ? __save_stack_trace+0x92/0x100
>> [ 108.271440] ? save_stack+0xa3/0xd0
>> [ 108.271448] ? udp_ioctl+0x35/0xe0
>> [ 108.271457] ? inet_ioctl+0x100/0x320
>> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
>> [ 108.271475] ? alloc_file+0x60/0x480
>> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
>> [ 108.271495] ? sock_alloc_file+0x51/0x170
>> [ 108.271502] ? __sys_socket+0x12c/0x1f0
>> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
>> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
>> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 108.271538] ? kasan_check_read+0x11/0x20
>> [ 108.271548] ? mutex_lock+0x8f/0xe0
>> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
>> [ 108.271568] dev_ioctl+0x1fb/0xae0
>> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
>> [ 108.271586] ? _copy_from_user+0x71/0xd0
>> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
>> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
>> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
>> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
>> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
>> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
>> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
>> [ 108.271670] sock_ioctl+0x361/0x590
>> [ 108.271678] ? sock_ioctl+0x361/0x590
>> [ 108.271686] ? routing_ioctl+0x470/0x470
>> [ 108.271695] ? kasan_check_write+0x14/0x20
>> [ 108.271703] ? __mutex_init+0xba/0x130
>> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
>> [ 108.271722] ? alloc_empty_file+0xae/0x150
>> [ 108.271729] ? routing_ioctl+0x470/0x470
>> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
>> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
>> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
>> [ 108.271770] ? alloc_file+0x480/0x480
>> [ 108.271778] ? kasan_check_read+0x11/0x20
>> [ 108.271786] ? __fget+0x24d/0x320
>> [ 108.271794] ? iterate_fd+0x180/0x180
>> [ 108.271802] ? fd_install+0x52/0x60
>> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
>> [ 108.271820] ksys_ioctl+0x99/0xb0
>> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
>> [ 108.271839] do_syscall_64+0xb1/0x2e0
>> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
>> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> ......
>>
>> I checked the driver source code, but cannot find the reason, so I
>> only report the crash...
>> Can somebody give an explanation about this crash?
>>
>> This crash is triggered by a runtime fuzzing tool named FIZZER
>> written by us.
>
> Your backtrace does not include any references to rtlwifi routines,
> and I have no idea what FIZZER does, thus it is not possible for me to
> debug this. If the error situation that you state happens, the code
> should end up at label "fail3" in routine rtl_pci_probe(). Insert
> printk statements after every line of the following, and report the
> last good point before the error. It is certainly possible that
> something is being torn down that was never erected. The likelihood of
> failure of both MSI and legacy interrupts is not very likely, and we
> probably have never hit those conditions.
>
> fail3:
> pci_set_drvdata(pdev, NULL);
> rtl_deinit_core(hw);
>
> fail2:
> if (rtlpriv->io.pci_mem_start != 0)
> pci_iounmap(pdev, (void __iomem
> *)rtlpriv->io.pci_mem_start);
>
> pci_release_regions(pdev);
> complete(&rtlpriv->firmware_loading_complete);
>
> fail1:
> if (hw)
> ieee80211_free_hw(hw);
> pci_disable_device(pdev);
>
> return err;
Thanks for the advice :)
I will insert some printk statements to debug this problem.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [BUG] rtlwifi: a crash in error handling code of rtl_pci_probe()
From: Larry Finger @ 2019-05-15 1:08 UTC (permalink / raw)
To: Jia-Ju Bai, pkshih, Kalle Valo, David Miller
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org, netdev
In-Reply-To: <4627da7a-c56c-5d88-62ae-ea2be9430f6f@gmail.com>
On 5/14/19 8:07 AM, Jia-Ju Bai wrote:
> In rtl_pci_probe(), when request_irq() in rtl_pci_intr_mode_legacy() in
> rtl_pci_intr_mode_decide() fails, a crash occurs.
> The crash information is as follows:
>
> [ 108.271155] kasan: CONFIG_KASAN_INLINE enabled
> [ 108.271163] kasan: GPF could be caused by NULL-ptr deref or user memory access
> ......
> [ 108.271193] RIP: 0010:cfg80211_get_drvinfo+0xce/0x3b0 [cfg80211]
> ......
> [ 108.271235] Call Trace:
> [ 108.271245] ethtool_get_drvinfo+0x110/0x640
> [ 108.271255] ? cfg80211_get_chan_state+0x7e0/0x7e0 [cfg80211]
> [ 108.271261] ? ethtool_get_settings+0x340/0x340
> [ 108.271268] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271279] ? kasan_check_write+0x14/0x20
> [ 108.271284] dev_ethtool+0x272d/0x4c20
> [ 108.271290] ? unwind_get_return_address+0x66/0xb0
> [ 108.271299] ? __save_stack_trace+0x92/0x100
> [ 108.271307] ? ethtool_get_rxnfc+0x3f0/0x3f0
> [ 108.271316] ? save_stack+0xa3/0xd0
> [ 108.271323] ? save_stack+0x43/0xd0
> [ 108.271331] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271338] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271346] ? ftrace_graph_ret_addr+0x2d/0x170
> [ 108.271354] ? update_stack_state+0x3b2/0x670
> [ 108.271361] ? update_stack_state+0x3b2/0x670
> [ 108.271370] ? __read_once_size_nocheck.constprop.7+0x20/0x20
> [ 108.271379] ? unwind_next_frame.part.5+0x19f/0xa60
> [ 108.271388] ? bpf_prog_kallsyms_find+0x3e/0x270
> [ 108.271396] ? is_bpf_text_address+0x1a/0x30
> [ 108.271408] ? kernel_text_address+0x11d/0x130
> [ 108.271416] ? __kernel_text_address+0x12/0x40
> [ 108.271423] ? unwind_get_return_address+0x66/0xb0
> [ 108.271431] ? __save_stack_trace+0x92/0x100
> [ 108.271440] ? save_stack+0xa3/0xd0
> [ 108.271448] ? udp_ioctl+0x35/0xe0
> [ 108.271457] ? inet_ioctl+0x100/0x320
> [ 108.271466] ? inet_stream_connect+0xb0/0xb0
> [ 108.271475] ? alloc_file+0x60/0x480
> [ 108.271483] ? alloc_file_pseudo+0x19d/0x270
> [ 108.271495] ? sock_alloc_file+0x51/0x170
> [ 108.271502] ? __sys_socket+0x12c/0x1f0
> [ 108.271510] ? __x64_sys_socket+0x78/0xb0
> [ 108.271520] ? do_syscall_64+0xb1/0x2e0
> [ 108.271529] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 108.271538] ? kasan_check_read+0x11/0x20
> [ 108.271548] ? mutex_lock+0x8f/0xe0
> [ 108.271557] ? __mutex_lock_slowpath+0x20/0x20
> [ 108.271568] dev_ioctl+0x1fb/0xae0
> [ 108.271576] ? dev_ioctl+0x1fb/0xae0
> [ 108.271586] ? _copy_from_user+0x71/0xd0
> [ 108.271594] sock_do_ioctl+0x1e2/0x2f0
> [ 108.271602] ? kmem_cache_alloc+0xf9/0x250
> [ 108.271611] ? ___sys_recvmsg+0x5a0/0x5a0
> [ 108.271621] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271630] ? kasan_unpoison_shadow+0x35/0x50
> [ 108.271638] ? kasan_kmalloc+0xad/0xe0
> [ 108.271652] ? apparmor_file_alloc_security+0x128/0x7e0
> [ 108.271662] ? apparmor_file_alloc_security+0x269/0x7e0
> [ 108.271670] sock_ioctl+0x361/0x590
> [ 108.271678] ? sock_ioctl+0x361/0x590
> [ 108.271686] ? routing_ioctl+0x470/0x470
> [ 108.271695] ? kasan_check_write+0x14/0x20
> [ 108.271703] ? __mutex_init+0xba/0x130
> [ 108.271713] ? percpu_counter_add_batch+0xc7/0x120
> [ 108.271722] ? alloc_empty_file+0xae/0x150
> [ 108.271729] ? routing_ioctl+0x470/0x470
> [ 108.271738] do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271745] ? do_vfs_ioctl+0x1ae/0xfe0
> [ 108.271754] ? alloc_file_pseudo+0x1ad/0x270
> [ 108.271762] ? ioctl_preallocate+0x1e0/0x1e0
> [ 108.271770] ? alloc_file+0x480/0x480
> [ 108.271778] ? kasan_check_read+0x11/0x20
> [ 108.271786] ? __fget+0x24d/0x320
> [ 108.271794] ? iterate_fd+0x180/0x180
> [ 108.271802] ? fd_install+0x52/0x60
> [ 108.271812] ? security_file_ioctl+0x8c/0xb0
> [ 108.271820] ksys_ioctl+0x99/0xb0
> [ 108.271829] __x64_sys_ioctl+0x78/0xb0
> [ 108.271839] do_syscall_64+0xb1/0x2e0
> [ 108.271857] ? prepare_exit_to_usermode+0xc8/0x160
> [ 108.271871] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> ......
>
> I checked the driver source code, but cannot find the reason, so I only report
> the crash...
> Can somebody give an explanation about this crash?
>
> This crash is triggered by a runtime fuzzing tool named FIZZER written by us.
Your backtrace does not include any references to rtlwifi routines, and I have
no idea what FIZZER does, thus it is not possible for me to debug this. If the
error situation that you state happens, the code should end up at label "fail3"
in routine rtl_pci_probe(). Insert printk statements after every line of the
following, and report the last good point before the error. It is certainly
possible that something is being torn down that was never erected. The
likelihood of failure of both MSI and legacy interrupts is not very likely, and
we probably have never hit those conditions.
fail3:
pci_set_drvdata(pdev, NULL);
rtl_deinit_core(hw);
fail2:
if (rtlpriv->io.pci_mem_start != 0)
pci_iounmap(pdev, (void __iomem *)rtlpriv->io.pci_mem_start);
pci_release_regions(pdev);
complete(&rtlpriv->firmware_loading_complete);
fail1:
if (hw)
ieee80211_free_hw(hw);
pci_disable_device(pdev);
return err;
Larry
^ permalink raw reply
* Re: [PATCH] NFC: Orphan the subsystem
From: David Miller @ 2019-05-14 22:32 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, netdev, sameo
In-Reply-To: <20190514090231.32414-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Tue, 14 May 2019 11:02:31 +0200
> Samuel clearly hasn't been working on this in many years and
> patches getting to the wireless list are just being ignored
> entirely now. Mark the subsystem as orphan to reflect the
> current state and revert back to the netdev list so at least
> some fixes can be picked up by Dave.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Applied.
^ permalink raw reply
* [PATCH] libertas/libertas_tf: fix spelling mistake "Donwloading" -> "Downloading"
From: Colin King @ 2019-05-14 21:14 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, libertas-dev, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
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>
---
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
--
2.20.1
^ permalink raw reply related
* Re: [PATCH][next] iwlwifi: d3: Use struct_size() helper
From: Gustavo A. R. Silva @ 2019-05-14 18:58 UTC (permalink / raw)
To: Luciano Coelho, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, David S. Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <c4a1fd36abf6acafa35bb70f87791d4ef802d87c.camel@intel.com>
On 5/14/19 12:16 AM, Luciano Coelho wrote:
>
> Thanks! Applied to our internal tree and it will reach the mainline
> following our normal upstreaming process.
>
Awesome. :)
Thanks, Luciano.
--
Gustavo
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 18:57 UTC (permalink / raw)
To: Ben Greear, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <730d3664-488d-7d57-04d5-1a57e91fa070@candelatech.com>
On Tue, 2019-05-14 at 11:54 -0700, Ben Greear wrote:
>
> Here is the info I have in my commit that changed this to WARN_ON_ONCE.
> I never posted it because I had to hack ath10k to get to this state, so maybe
> this is not a valid case to debug.
>
>
> Maybe Yibo Zhao has a better example.
>
> mac80211: don't spam kernel logs when chantx is null.
>
> I set up ath10k to be chandef based again in order to test
> WDS. My WDS stations are not very functional yet, and
> when ethtool stats are queried, there is a WARN_ON splat
> generated. Change this to WARN_ON_ONCE so that there is
> less kernel spam.
I'm totally fine with WARN_ON_ONCE, FWIW.
Sounds like different bugs though. You're talking about WDS here, and
Yibo was talking about something with AP interfaces prematurely
accepting frames or so.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Ben Greear @ 2019-05-14 18:54 UTC (permalink / raw)
To: Johannes Berg, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <8eacb8e107c854b64a0c6116fca9731ddd99dcac.camel@sipsolutions.net>
On 5/14/19 11:40 AM, Johannes Berg wrote:
>
>> We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
>> at least) to reproduce this. So, the WARN logic has done its job.
>>
>> Having more of these spam the kernel doesn't add much benefit I think.
>
> Well, this doesn't necessarily just catch a *single* issue, so it should
> remain for the future, I'd think.
>
>> Anyone have any suggestions on how to fix the underlying issue?
>
> I don't even have the backtrace and scenario that causes it.
>
> johannes
>
Here is the info I have in my commit that changed this to WARN_ON_ONCE.
I never posted it because I had to hack ath10k to get to this state, so maybe
this is not a valid case to debug.
Maybe Yibo Zhao has a better example.
mac80211: don't spam kernel logs when chantx is null.
I set up ath10k to be chandef based again in order to test
WDS. My WDS stations are not very functional yet, and
when ethtool stats are queried, there is a WARN_ON splat
generated. Change this to WARN_ON_ONCE so that there is
less kernel spam.
[ 2401.445631] WARNING: CPU: 1 PID: 14070 at /home/greearb/git/linux-4.13.dev.y/net/mac80211/ieee80211_i.h:1452 sta_set_rate_info_tx+0x18c/0x1a0 [mac80211]
[ 2401.445727] Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink wanlink(O) ath10k_pci ath10k_core mac80211_hwsim ath5k ath9k ath9k_common
ath9k_hw ath mac80211 cfg80211 nf_defrag_ipv4 libcrc32c 8021q garp mrp stp llc fuse macvlan pktgen nfsv3 nfs fscache amd64_edac_mod edac_mce_amd kvm_amd kvm
irqbypass sp5100_tco fam15h_power k10temp i2c_piix4 ccp shpchp acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc sdhci_pci sdhci mmc_core
igb hwmon ptp pps_core i2c_algo_bit i2c_core dca ipv6 crc_ccitt [last unloaded: nfnetlink]
[ 2401.445911] CPU: 1 PID: 14070 Comm: btserver Tainted: G W O 4.13.11+ #18
[ 2401.445914] Hardware name: PC Engines apu2/apu2, BIOS 88a4f96 03/07/2016
[ 2401.445918] task: ffff880118c73b80 task.stack: ffffc90001400000
[ 2401.445973] RIP: 0010:sta_set_rate_info_tx+0x18c/0x1a0 [mac80211]
[ 2401.446003] RSP: 0018:ffffc90001403820 EFLAGS: 00010246
[ 2401.446007] RAX: 0000000000000000 RBX: ffff8800ca38e4a0 RCX: 000000000000000c
[ 2401.446010] RDX: 0000000000000000 RSI: ffff8800ca38e4a0 RDI: ffff8800ca38e000
[ 2401.446013] RBP: ffffc90001403850 R08: ffffffffa04437a0 R09: 0000000000002000
[ 2401.446016] R10: 000000001183be82 R11: 0000000000000000 R12: ffffc90001403970
[ 2401.446018] R13: 0000000000000000 R14: ffff8800c01d8900 R15: ffff8800ca180780
[ 2401.446023] FS: 00007f8123ed7740(0000) GS:ffff88011ec80000(0000) knlGS:0000000000000000
[ 2401.446026] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2401.446029] CR2: 00000000036e8018 CR3: 00000000c0b29000 CR4: 00000000000406e0
[ 2401.446034] Call Trace:
[ 2401.446140] sta_set_sinfo+0x629/0x8b0 [mac80211]
[ 2401.446192] ieee80211_get_stats+0x3f2/0x8c0 [mac80211]
[ 2401.446207] ? __nla_put+0x20/0x30
[ 2401.446221] ? __kmalloc_reserve.isra.35+0x2c/0x80
[ 2401.446229] ? netlink_deliver_tap+0x2d/0x1e0
[ 2401.446235] ? sock_def_readable+0x6d/0x70
[ 2401.446239] ? __netlink_sendskb+0x36/0x40
[ 2401.446245] ? netlink_unicast+0x1b0/0x1f0
[ 2401.446252] ? rtnl_getlink+0x135/0x1c0
[ 2401.446261] ? get_page_from_freelist+0x913/0xac0
[ 2401.446270] ? vmap_page_range_noflush+0x27d/0x370
[ 2401.446277] ? map_vm_area+0x31/0x40
[ 2401.446284] ? __vmalloc_node_range+0x21f/0x270
[ 2401.446319] dev_ethtool+0x11d1/0x1ce0
[ 2401.446325] ? __rtnl_unlock+0x25/0x50
[ 2401.446330] ? netdev_run_todo+0x4d/0x2e0
[ 2401.446338] ? dev_get_by_name_rcu+0x6f/0xa0
[ 2401.446344] dev_ioctl+0x330/0x550
[ 2401.446349] ? reuse_swap_page+0x30/0x100
[ 2401.446355] sock_do_ioctl+0x3d/0x50
[ 2401.446359] ? sock_do_ioctl+0x3d/0x50
[ 2401.446363] sock_ioctl+0x1e5/0x2a0
[ 2401.446370] do_vfs_ioctl+0x8b/0x5b0
[ 2401.446376] ? getnstimeofday64+0x9/0x20
[ 2401.446383] ? __audit_syscall_entry+0xba/0x110
[ 2401.446391] ? syscall_trace_enter+0x1b0/0x2b0
[ 2401.446395] SyS_ioctl+0x74/0x80
[ 2401.446400] ? __audit_syscall_exit+0x215/0x2b0
[ 2401.446405] do_syscall_64+0x5c/0x190
[ 2401.446412] entry_SYSCALL64_slow_path+0x25/0x25
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Johannes Berg @ 2019-05-14 18:40 UTC (permalink / raw)
To: Ben Greear, Joe Perches, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <4d013893-3302-14f0-c957-b3771f4b6b82@candelatech.com>
> We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
> at least) to reproduce this. So, the WARN logic has done its job.
>
> Having more of these spam the kernel doesn't add much benefit I think.
Well, this doesn't necessarily just catch a *single* issue, so it should
remain for the future, I'd think.
> Anyone have any suggestions on how to fix the underlying issue?
I don't even have the backtrace and scenario that causes it.
johannes
^ permalink raw reply
* Re: [PATCH v2] mac80211: remove warning message
From: Ben Greear @ 2019-05-14 17:55 UTC (permalink / raw)
To: Joe Perches, Johannes Berg, Yibo Zhao; +Cc: linux-wireless, ath10k, Zhi Chen
In-Reply-To: <34f72d5db336b9898618bf1c5c15ec41094d7d06.camel@perches.com>
On 5/14/19 8:44 AM, Joe Perches wrote:
> On Tue, 2019-05-14 at 11:12 +0200, Johannes Berg wrote:
>> On Tue, 2019-05-14 at 17:10 +0800, Yibo Zhao wrote:
>>> On 2019-05-14 17:05, Johannes Berg wrote:
>>>> On Tue, 2019-05-14 at 17:01 +0800, Yibo Zhao wrote:
>>>>> In multiple SSID cases, it takes time to prepare every AP interface
>>>>> to be ready in initializing phase. If a sta already knows everything
>>>>> it
>>>>> needs to join one of the APs and sends authentication to the AP which
>>>>> is not fully prepared at this point of time, AP's channel context
>>>>> could be NULL. As a result, warning message occurs.
> []
>>> I was planning to use WARN_ON_ONCE() in the first place to replace
>>> WARN_ON() then after some discussion, we think removing it could be
>>> better. So the first patch was based on my first version which is sent
>>> incorrectly. Please check again.
> []
>> I guess changing it to WARN_ON_ONCE() makes sense,
>
> WARN_ON_RATELIMIT exists.
We know the WARN hits, we have the backtrace, and it is easy enough (in my setup
at least) to reproduce this. So, the WARN logic has done its job.
Having more of these spam the kernel doesn't add much benefit I think.
Anyone have any suggestions on how to fix the underlying issue?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] mt76: mt7615: add preliminary support for mtd eeprom parsing
From: Lorenzo Bianconi @ 2019-05-14 17:11 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <cover.1557853278.git.lorenzo@kernel.org>
Calibration data are often available on a specific mtd partition on
embedded devices. Take into account eeprom calibration data if
available. Calibration free data parsing is currently missing
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../wireless/mediatek/mt76/mt7615/eeprom.c | 32 +++++++++++++++----
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
index dd5ab46a4f66..0313c604ea61 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/eeprom.c
@@ -42,13 +42,13 @@ static int mt7615_efuse_read(struct mt7615_dev *dev, u32 base,
static int mt7615_efuse_init(struct mt7615_dev *dev)
{
- u32 base = mt7615_reg_map(dev, MT_EFUSE_BASE);
- int len = MT7615_EEPROM_SIZE;
- int ret, i;
+ u32 val, base = mt7615_reg_map(dev, MT_EFUSE_BASE);
+ int i, len = MT7615_EEPROM_SIZE;
void *buf;
- if (mt76_rr(dev, base + MT_EFUSE_BASE_CTRL) & MT_EFUSE_BASE_CTRL_EMPTY)
- return -EINVAL;
+ val = mt76_rr(dev, base + MT_EFUSE_BASE_CTRL);
+ if (val & MT_EFUSE_BASE_CTRL_EMPTY)
+ return 0;
dev->mt76.otp.data = devm_kzalloc(dev->mt76.dev, len, GFP_KERNEL);
dev->mt76.otp.size = len;
@@ -57,6 +57,8 @@ static int mt7615_efuse_init(struct mt7615_dev *dev)
buf = dev->mt76.otp.data;
for (i = 0; i + 16 <= len; i += 16) {
+ int ret;
+
ret = mt7615_efuse_read(dev, base, i, buf + i);
if (ret)
return ret;
@@ -76,6 +78,18 @@ static int mt7615_eeprom_load(struct mt7615_dev *dev)
return mt7615_efuse_init(dev);
}
+static int mt7615_check_eeprom(struct mt76_dev *dev)
+{
+ u16 val = get_unaligned_le16(dev->eeprom.data);
+
+ switch (val) {
+ case 0x7615:
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
int mt7615_eeprom_init(struct mt7615_dev *dev)
{
int ret;
@@ -84,7 +98,13 @@ int mt7615_eeprom_init(struct mt7615_dev *dev)
if (ret < 0)
return ret;
- memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data, MT7615_EEPROM_SIZE);
+ if (dev->mt76.otp.data) {
+ ret = mt7615_check_eeprom(&dev->mt76);
+ if (ret < 0)
+ memcpy(dev->mt76.eeprom.data, dev->mt76.otp.data,
+ MT7615_EEPROM_SIZE);
+ /* TODO: take into account cal free data */
+ }
dev->mt76.cap.has_2ghz = true;
dev->mt76.cap.has_5ghz = true;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 00/12] NFC: nxp-nci: clean up and support new ID
From: Andy Shevchenko @ 2019-05-14 17:01 UTC (permalink / raw)
To: Sedat Dilek
Cc: Oleg Zhurakivskyy, Clément Perrochaud, Charles Gorand,
linux-nfc, Samuel Ortiz, linux-wireless
In-Reply-To: <CA+icZUV=TBfabHsbzj_JPnxXBjo114LWVJ==xSS7zVPkajmNgw@mail.gmail.com>
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
^ permalink raw reply
* Re: NXP NFC version and ACPI
From: Daniel Lezcano @ 2019-05-14 16:36 UTC (permalink / raw)
To: sedat.dilek
Cc: Samuel Ortiz, linux-wireless, linux-nfc, oleg.zhurakivskyy,
clement.perrochaud, charles.gorand, Andy Shevchenko
In-Reply-To: <CA+icZUVaBdswfmRfbRtdVJY8ymeDOwDSFEf7G6jneqEmpW84bg@mail.gmail.com>
On 14/05/2019 16:59, Sedat Dilek wrote:
> On Tue, May 14, 2019 at 10:17 AM Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
> [...]
>
> Just for the records:
>
> root@iniza:~# rfkill --output ID,TYPE
> ID TYPE
> 0 bluetooth
> 1 nfc
> 2 wlan
> 3 bluetooth
>
> root@iniza:~# rfkill list nfc
> 1: nfc0: NFC
> Soft blocked: no
> Hard blocked: no
>
Thanks, I have checked and it is the same values.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ 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