* [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
The TRF7970A has configuration options to support hardware designs
which use a 27.12MHz clock. This commit adds a device tree option
'clock-frequency' to support configuring the this chip for default
13.56MHz clock or the optional 27.12MHz clock.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 2 +
drivers/nfc/trf7970a.c | 50 +++++++++++++++++-----
2 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 32b35a0..8b01fc81 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -43,6 +44,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
irq-status-read-quirk;
en2-rf-quirk;
t5t-rmb-extra-byte-quirk;
+ clock-frequency = <27120000>;
status = "okay";
};
};
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index 26c9dbb..b1cd4ef 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -124,6 +124,9 @@
NFC_PROTO_ISO15693_MASK | NFC_PROTO_NFC_DEP_MASK)
#define TRF7970A_AUTOSUSPEND_DELAY 30000 /* 30 seconds */
+#define TRF7970A_13MHZ_CLOCK_FREQUENCY 13560000
+#define TRF7970A_27MHZ_CLOCK_FREQUENCY 27120000
+
#define TRF7970A_RX_SKB_ALLOC_SIZE 256
@@ -1056,12 +1059,11 @@ static int trf7970a_init(struct trf7970a *trf)
trf->chip_status_ctrl &= ~TRF7970A_CHIP_STATUS_RF_ON;
- ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL, 0);
+ ret = trf7970a_write(trf, TRF7970A_MODULATOR_SYS_CLK_CTRL,
+ trf->modulator_sys_clk_ctrl);
if (ret)
goto err_out;
- trf->modulator_sys_clk_ctrl = 0;
-
ret = trf7970a_write(trf, TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS,
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLH_96 |
TRF7970A_ADJUTABLE_FIFO_IRQ_LEVELS_WLL_32);
@@ -1181,27 +1183,37 @@ static int trf7970a_in_config_rf_tech(struct trf7970a *trf, int tech)
switch (tech) {
case NFC_DIGITAL_RF_TECH_106A:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443A_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_NFCA;
break;
case NFC_DIGITAL_RF_TECH_106B:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_14443B_106;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCB;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_FELICA_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
trf->guard_time = TRF7970A_GUARD_TIME_NFCF;
break;
case NFC_DIGITAL_RF_TECH_ISO15693:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_15693_SGL_1OF4_2648;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
trf->guard_time = TRF7970A_GUARD_TIME_15693;
break;
default:
@@ -1571,17 +1583,23 @@ static int trf7970a_tg_config_rf_tech(struct trf7970a *trf, int tech)
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_CE |
TRF7970A_ISO_CTRL_NFC_CE_14443A;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_OOK;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_OOK;
break;
case NFC_DIGITAL_RF_TECH_212F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_212;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
case NFC_DIGITAL_RF_TECH_424F:
trf->iso_ctrl_tech = TRF7970A_ISO_CTRL_NFC_NFC_CE_MODE |
TRF7970A_ISO_CTRL_NFC_NFCF_424;
- trf->modulator_sys_clk_ctrl = TRF7970A_MODULATOR_DEPTH_ASK10;
+ trf->modulator_sys_clk_ctrl =
+ (trf->modulator_sys_clk_ctrl & 0xf8) |
+ TRF7970A_MODULATOR_DEPTH_ASK10;
break;
default:
dev_dbg(trf->dev, "Unsupported rf technology: %d\n", tech);
@@ -1987,6 +2005,7 @@ static int trf7970a_probe(struct spi_device *spi)
struct device_node *np = spi->dev.of_node;
struct trf7970a *trf;
int uvolts, autosuspend_delay, ret;
+ u32 clk_freq = TRF7970A_13MHZ_CLOCK_FREQUENCY;
if (!np) {
dev_err(&spi->dev, "No Device Tree entry\n");
@@ -2043,6 +2062,15 @@ static int trf7970a_probe(struct spi_device *spi)
return ret;
}
+ of_property_read_u32(np, "clock-frequency", &clk_freq);
+ if ((clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
+ (clk_freq != TRF7970A_13MHZ_CLOCK_FREQUENCY)) {
+ dev_err(trf->dev,
+ "clock-frequency (%u Hz) unsupported\n",
+ clk_freq);
+ return -EINVAL;
+ }
+
if (of_property_read_bool(np, "en2-rf-quirk"))
trf->quirks |= TRF7970A_QUIRK_EN2_MUST_STAY_LOW;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Geoff Lansberry
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
The TRF7970A has configuration options for supporting hardware designs
with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
using a fixed regulator binding, for setting the io voltage to match
the hardware configuration. If no option is supplied it defaults to
3.3 volt configuration.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 26 +++++++++++++++++++++-
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 8b01fc81..b5777d8 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -21,6 +21,7 @@ Optional SoC Specific Properties:
- t5t-rmb-extra-byte-quirk: Specify that the trf7970a has the erratum
where an extra byte is returned by Read Multiple Block commands issued
to Type 5 tags.
+- vdd-io-supply: Regulator specifying voltage for vdd-io
- clock-frequency: Set to specify that the input frequency to the trf7970a is 13560000Hz or 27120000Hz
Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -40,6 +41,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
<&gpio2 5 GPIO_ACTIVE_LOW>;
vin-supply = <&ldo3_reg>;
vin-voltage-override = <5000000>;
+ vdd-io-supply = <&ldo2_reg>;
autosuspend-delay = <30000>;
irq-status-read-quirk;
en2-rf-quirk;
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index b1cd4ef..e3c72c6 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -444,6 +444,7 @@ struct trf7970a {
u8 iso_ctrl_tech;
u8 modulator_sys_clk_ctrl;
u8 special_fcn_reg1;
+ u8 io_ctrl;
unsigned int guard_time;
int technology;
int framing;
@@ -1051,6 +1052,11 @@ static int trf7970a_init(struct trf7970a *trf)
if (ret)
goto err_out;
+ ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
+ trf->io_ctrl | TRF7970A_REG_IO_CTRL_VRS(0x1));
+ if (ret)
+ goto err_out;
+
ret = trf7970a_write(trf, TRF7970A_NFC_TARGET_LEVEL, 0);
if (ret)
goto err_out;
@@ -1767,7 +1773,7 @@ static int _trf7970a_tg_listen(struct nfc_digital_dev *ddev, u16 timeout,
goto out_err;
ret = trf7970a_write(trf, TRF7970A_REG_IO_CTRL,
- TRF7970A_REG_IO_CTRL_VRS(0x1));
+ trf->io_ctrl | TRF7970A_REG_IO_CTRL_VRS(0x1));
if (ret)
goto out_err;
@@ -2105,6 +2111,24 @@ static int trf7970a_probe(struct spi_device *spi)
if (uvolts > 4000000)
trf->chip_status_ctrl = TRF7970A_CHIP_STATUS_VRS5_3;
+ trf->regulator = devm_regulator_get(&spi->dev, "vdd-io");
+ if (IS_ERR(trf->regulator)) {
+ ret = PTR_ERR(trf->regulator);
+ dev_err(trf->dev, "Can't get VDD_IO regulator: %d\n", ret);
+ goto err_destroy_lock;
+ }
+
+ ret = regulator_enable(trf->regulator);
+ if (ret) {
+ dev_err(trf->dev, "Can't enable VDD_IO: %d\n", ret);
+ goto err_destroy_lock;
+ }
+
+ if (regulator_get_voltage(trf->regulator) == 1800000) {
+ trf->io_ctrl = TRF7970A_REG_IO_CTRL_IO_LOW;
+ dev_dbg(trf->dev, "trf7970a config vdd_io to 1.8V\n");
+ }
+
trf->ddev = nfc_digital_allocate_device(&trf7970a_nfc_ops,
TRF7970A_SUPPORTED_PROTOCOLS,
NFC_DIGITAL_DRV_CAPS_IN_CRC |
--
2.7.4
^ permalink raw reply related
* [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Geoff Lansberry @ 2016-12-22 4:18 UTC (permalink / raw)
To: linux-wireless
Cc: lauro.venancio, aloisio.almeida, sameo, robh+dt, mark.rutland,
netdev, devicetree, linux-kernel, mgreer, justin, Jaret Cantu,
Geoff Lansberry
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
From: Jaret Cantu <jaret.cantu@timesys.com>
Repeated polling attempts cause a NULL dereference error to occur.
This is because the state of the trf7970a is currently reading but
another request has been made to send a command before it has finished.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
---
drivers/nfc/trf7970a.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
index e3c72c6..ba5f9b8 100644
--- a/drivers/nfc/trf7970a.c
+++ b/drivers/nfc/trf7970a.c
@@ -1496,6 +1496,10 @@ static int trf7970a_send_cmd(struct nfc_digital_dev *ddev,
(trf->state != TRF7970A_ST_IDLE_RX_BLOCKED)) {
dev_err(trf->dev, "%s - Bogus state: %d\n", __func__,
trf->state);
+ if (trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA ||
+ trf->state == TRF7970A_ST_WAIT_FOR_RX_DATA_CONT)
+ trf->ignore_timeout =
+ !cancel_delayed_work(&trf->timeout_work);
ret = -EIO;
goto out_err;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: kbuild test robot @ 2016-12-22 5:18 UTC (permalink / raw)
To: Ozgur Karatas
Cc: kbuild-all, johannes, David Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
Hi Ozgur,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.9 next-20161221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed-to-checkpatch-errors/20161222-125128
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: i386-randconfig-x006-201651 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/reg.c: In function 'regulatory_hint_core':
>> net/wireless/reg.c:2294:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c:2294:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function 'regulatory_hint_user':
net/wireless/reg.c:2316:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint':
net/wireless/reg.c:2388:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
vim +/regulatory_request +2294 net/wireless/reg.c
2288 * and when we restore regulatory settings.
2289 */
2290 static int regulatory_hint_core(const char *alpha2)
2291 {
2292 struct regulatory_request *request;
2293
> 2294 request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
2295 if (!request)
2296 return -ENOMEM;
2297
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 23376 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: kbuild test robot @ 2016-12-22 7:05 UTC (permalink / raw)
To: Ozgur Karatas
Cc: kbuild-all, johannes, David Miller, linux-wireless, netdev,
linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]
Hi Ozgur,
[auto build test ERROR on mac80211-next/master]
[also build test ERROR on v4.9 next-20161221]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed-to-checkpatch-errors/20161222-125128
base: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
net/wireless/reg.c: In function 'reg_query_builtin':
>> net/wireless/reg.c:493:28: error: 'reg_regdb_apply_request' undeclared (first use in this function)
request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~~~~~~
net/wireless/reg.c:493:28: note: each undeclared identifier is reported only once for each function it appears in
net/wireless/reg.c: In function 'regulatory_hint_core':
net/wireless/reg.c:2294:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint_user':
net/wireless/reg.c:2316:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
net/wireless/reg.c: In function 'regulatory_hint':
net/wireless/reg.c:2388:28: error: 'regulatory_request' undeclared (first use in this function)
request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
^~~~~~~~~~~~~~~~~~
vim +/reg_regdb_apply_request +493 net/wireless/reg.c
487 }
488 }
489
490 if (!regdom)
491 return -ENODATA;
492
> 493 request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
494 if (!request)
495 return -ENOMEM;
496
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57000 bytes --]
^ permalink raw reply
* RE: ATH9 driver issues on ARM64
From: Bharat Kumar Gogada @ 2016-12-22 7:19 UTC (permalink / raw)
To: Bharat Kumar Gogada, Bjorn Helgaas
Cc: Tobias Klausmann, Kalle Valo, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, Marc Zyngier,
Janusz.Dziedzic@tieto.com, rmanohar@qti.qualcomm.com,
ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org
In-Reply-To: <8520D5D51A55D047800579B094147198263AADCA@XAP-PVEXMBX02.xlnx.xilinx.com>
Hi All,
After further debugging we know the place it hangs.
In function:
static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel *=
hchan)
{
disable_irq(sc->irq);
tasklet_disable(&sc->intr_tq);
tasklet_disable(&sc->bcon_tasklet);
spin_lock_bh(&sc->sc_pcu_lock);
....
....
....
if (!ath_complete_reset(sc, true)) -> This function enables hardwar=
e interrupts
r =3D -EIO;
out:
enable_irq(sc->irq); -> Here IRQ line state is changed to enable =
state
spin_unlock_bh(&sc->sc_pcu_lock);
tasklet_enable(&sc->bcon_tasklet);
tasklet_enable(&sc->intr_tq);
=09
}
static bool ath_complete_reset(struct ath_softc *sc, bool start)
{
struct ath_hw *ah =3D sc->sc_ah;
struct ath_common *common =3D ath9k_hw_common(ah);
unsigned long flags;
ath9k_calculate_summary_state(sc, sc->cur_chan);
ath_startrecv(sc);
....
....
=20
sc->gtt_cnt =3D 0;
ath9k_hw_set_interrupts(ah); -> Here hardware interrupts are being=
enabled
ath9k_hw_enable_interrupts(ah); -> We see hang after this line
ieee80211_wake_queues(sc->hw);
ath9k_p2p_ps_timer(sc);
return true;
}
Before changing IRQ line to to enabled state, hardware interrupts are being=
enabled.=20
Wont this cause a race condition where within this period of hardware raise=
s an interrupt, but IRQ line state is disabled state, this will=20
reach the following condition making EP handler not being invoked.
void handle_simple_irq(struct irq_desc *desc)
{
raw_spin_lock(&desc->lock);
...=20
if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data))) =
{ // This condition is reaching and becoming true.
desc->istate |=3D IRQS_PENDING;
goto out_unlock;
} =20
kstat_incr_irqs_this_cpu(desc);
handle_irq_event(desc);
out_unlock:
raw_spin_unlock(&desc->lock);
}
We see hang at that statement, without reaching back enable_irq, looks like=
by this time CPU is in stall.
Can any tell why hardware interrupts are being enabled before kernel changi=
ng IRQ line state?
Regards,
Bharat
>=20
> > On Sat, Dec 10, 2016 at 02:40:48PM +0000, Bharat Kumar Gogada wrote:
> > > Hi,
> > >
> > > After taking some more lecroy traces, we see that after 2nd ASSERT
> > > from EP
> > on ARM64 we see continuous data movement of 32 dwords or 12 dwords and
> > never sign of DEASSERT.
> > > Comparatively on working traces (x86) after 2nd assert there are
> > > only BAR
> > register reads and writes and then DEASSERT, for almost most of the
> > interrupts and we haven't seen 12 or 32 dwords data movement on this tr=
ace.
> > >
> > > I did not work on EP wifi/network drivers, any help why EP needs
> > > those many
> > number of data at scan time ?
> >
> > The device doesn't know whether it's in an x86 or an arm64 system. If
> > it works differently, it must be because the PCI core or the driver is
> > programming the device differently.
> >
> > You should be able to match up Memory transactions from the host in
> > the trace with things the driver does. For example, if you see an
> > Assert_INTx message from the device, you should eventually see a
> > Memory Read from the host to get the ISR, i.e., some read done in the b=
owels
> of ath9k_hw_getisr().
> >
> > I don't know how the ath9k device works, but there must be some Memory
> > Read or Write done by the driver that tells the device "we've handled t=
his
> interrupt".
> > The device should then send a Deassert_INTx; of course, if the device
> > still requires service, e.g., because it has received more packets, it
> > might leave the INTx asserted.
> >
> > I doubt you'd see exactly the same traces on x86 and arm64 because
> > they aren't seeing the same network packets and the driver is executing=
at
> different rates.
> > But you should at least be able to identify interrupt assertion and
> > the actions of the driver's interrupt service routine.
>=20
>=20
> Thanks Bjorn.
>=20
> As you mentioned we did try to debug in that path. After we start scan af=
ter 2nd
> ASSERT we see lots of 32 and 12 dword data, and in function void
> ath9k_hw_enable_interrupts(struct ath_hw *ah) {
> ...
> ..
> REG_WRITE(ah, AR_IER, AR_IER_ENABLE);
> // EP driver hangs at this
> position after 2nd ASSERT
> // The following writes are not
> happening
> if (!AR_SREV_9100(ah)) {
> REG_WRITE(ah, AR_INTR_ASYNC_ENABLE, async_mask);
> REG_WRITE(ah, AR_INTR_ASYNC_MASK, async_mask);
>=20
> REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
> REG_WRITE(ah, AR_INTR_SYNC_MASK, sync_default);
> }
> ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
> REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER)); } The above =
funtion
> is invoked from tasklet.
> I tried several boots every it stops here. The condition (!AR_SREV_9100(a=
h)) is
> true as per before 1st ASSERT handling.
>=20
> Regards,
> Bharat
>=20
> >
> > > > Hello there,
> > > >
> > > > as this is a thread about ath9k and ARM64, i'm not sure if i
> > > > should answer here or not, but i have similar "stalls" with ath9k
> > > > on x86_64 (starting with 4.9rc), stack trace is posted down below
> > > > where the original
> > ARM64 stall traces are.
> > > >
> > > > Greetings,
> > > >
> > > > Tobias
> > > >
> > > >
> > > > On 08.12.2016 18:36, Kalle Valo wrote:
> > > > > Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> writes:
> > > > >
> > > > >> > [+cc Kalle, ath9k list]
> > > > > Thanks, but please also CC linux-wireless. Full thread below for
> > > > > the folks there.
> > > > >
> > > > >>> On Thu, Dec 08, 2016 at 01:49:42PM +0000, Bharat Kumar Gogada
> > wrote:
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> Did anyone test Atheros ATH9
> > > > >>>> driver(drivers/net/wireless/ath/ath9k/)
> > > > >>>> on ARM64. The end point is TP link wifi card with which
> > > > >>>> supports only legacy interrupts.
> > > > >>> If it works on other arches and the arm64 PCI enumeration
> > > > >>> works, my first guess would be an INTx issue, e.g., maybe the
> > > > >>> driver is waiting for an interrupt that never arrives.
> > > > >> We are not sure for now.
> > > > >>>> We are trying to test it on ARM64 with
> > > > >>>> (drivers/pci/host/pcie-xilinx-nwl.c) as root port.
> > > > >>>>
> > > > >>>> EP is getting enumerated and able to link up.
> > > > >>>>
> > > > >>>> But when we start scan system gets hanged.
> > > > >>> When you say the system hangs when you start a scan, I assume
> > > > >>> you mean a wifi scan, not the PCI enumeration. A problem with
> > > > >>> a wifi scan might cause a *process* to hang, but it shouldn't
> > > > >>> hang the entire system.
> > > > >>>
> > > > >> Yes wifi scan.
> > > > >>>> When we took trace we see that after we start scan assert
> > > > >>>> message is sent but there is no de assert from end point.
> > > > >>> Are you talking about a trace from a PCIe analyzer? Do you
> > > > >>> see an Assert_INTx PCIe message on the link?
> > > > >>>
> > > > >> Yes lecroy trace, yes we do see Assert_INTx and Deassert_INTx
> > > > >> happening
> > > > when we do interface link up.
> > > > >> When we have less debug prints in Atheros driver, and do wifi
> > > > >> scan we see Assert_INTx but never Deassert_INTx,
> > > > >>>> What might cause end point not sending de assert ?
> > > > >>> If the endpoint doesn't send a Deassert_INTx message, I expect
> > > > >>> that would mean the driver didn't service the interrupt and
> > > > >>> remove the condition that caused the device to assert the
> > > > >>> interrupt in the first place.
> > > > >>>
> > > > >>> If the driver didn't receive the interrupt, it couldn't
> > > > >>> service it, of course. You could add a printk in the ath9k
> > > > >>> interrupt service routine to see if you ever get there.
> > > > >>>
> > > > >> The interrupt behavior is changing w.r.t amount of debug prints
> > > > >> we add. (I kept many prints to aid debug)
> > > > >> root@Xilinx-ZCU102-2016_3:~# iw dev
> > > > wlan0 scan
> > > > >> [ 83.064675] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.069486] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.074257] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.078260] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.083107] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.087882] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.095450] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.099557] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.103721] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.107887] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.112748] AR_SREV_9100 0
> > > > >> [ 83.115438] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.119607] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.124389] ath9k_hw_intrpend 762
> > > > >> [ 83.127761] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.131234] ath9k_hw_intrpend 767
> > > > >> [ 83.134628] ath_isr 603
> > > > >> [ 83.137134] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.141995] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.146771] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.150864] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.154971] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.159135] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.163300] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.168161] AR_SREV_9100 0
> > > > >> [ 83.170852] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.170855] ath9k_hw_intrpend 762
> > > > >> [ 83.178398] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.181873] ath9k_hw_intrpend 767
> > > > >> [ 83.185265] ath_isr 603
> > > > >> [ 83.187773] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.192635] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.197411] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.201414] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.206258] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.210368] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.214531] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.218698] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.223558] AR_SREV_9100 0
> > > > >> [ 83.226243] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.226246] ath9k_hw_intrpend 762
> > > > >> [ 83.233794] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.237268] ath9k_hw_intrpend 767
> > > > >> [ 83.240661] ath_isr 603
> > > > >> [ 83.243169] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.248030] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.252806] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.256811] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.261651] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.265753] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.269919] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.274083] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.278945] AR_SREV_9100 0
> > > > >> [ 83.281630] ath9k_hw_enable_interrupts 848
> > > > >> [ 83.281633] ath9k_hw_intrpend 762
> > > > >> [ 83.281634] (AR_SREV_9340(ah) val 0
> > > > >> [ 83.281637] ath9k_hw_intrpend 767
> > > > >> [ 83.281648] ath_isr 603
> > > > >> [ 83.281649] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.281651] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.281654] ath9k_hw_kill_interrupts 793
> > > > >> [ 83.312192] ath9k: ath9k_ioread32 ffffff800a400024
> > > > >> [ 83.317030] ath9k_hw_enable_interrupts 821
> > > > >> [ 83.321132] ath9k_hw_enable_interrupts 825
> > > > >> [ 83.325297] ath9k_hw_enable_interrupts 832
> > > > >> [ 83.329463] ath9k: ath9k_iowrite32 ffffff800a400024
> > > > >> [ 83.334324] AR_SREV_9100 0
> > > > >> [ 83.337014] ath9k_hw_enable_interrupts 848
> > > > >> ..
> > > > >> ..
> > > > >> This log continues until I turn off board without obtaining scan=
ning
> result.
> > > > >>
> > > > >> In between I get following cpu stall outputs :
> > > > >> 230.457179] INFO: rcu_sched self-detected stall on CPU
> > > > >> [ 230.457185] 2-...: (31314 ticks this GP)
> > > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D36713
> > > > >> [ 230.457189] (t=3D36756 jiffies g=3D161 c=3D160 q=3D16169)
> > > > >> [ 230.457191] Task dump for CPU 2:
> > > > >> [ 230.457196] kworker/u8:4 R running task 0 1342 =
2
> > 0x00000002
> > > > >> [ 230.457207] Workqueue: phy0 ieee80211_scan_work [
> > > > >> 230.457208] Call trace:
> > > > >> [ 230.457214] [<ffffff8008089860>] dump_backtrace+0x0/0x198 [
> > > > >> 230.457219] [<ffffff8008089a0c>] show_stack+0x14/0x20 [
> > > > >> 230.457224] [<ffffff80080c0930>] sched_show_task+0x98/0xf8 [
> > > > >> 230.457228] [<ffffff80080c2628>] dump_cpu_task+0x40/0x50 [
> > > > >> 230.457233] [<ffffff80080e14a8>] rcu_dump_cpu_stacks+0xa0/0xf0
> > > > >> [ 230.457239] [<ffffff80080e4cd8>]
> > > > >> rcu_check_callbacks+0x468/0x748 [ 230.457243]
> > > > >> [<ffffff80080e7cfc>]
> > > > >> update_process_times+0x3c/0x68 [ 230.457249]
> > > > >> [<ffffff80080f6dfc>] tick_sched_handle.isra.5+0x3c/0x50
> > > > >> [ 230.457253] [<ffffff80080f6e54>] tick_sched_timer+0x44/0x90
> > > > >> [ 230.457257] [<ffffff80080e86b0>]
> > > > >> __hrtimer_run_queues+0xf0/0x178
> > > > >> ** 10 printk messages dropped ** [ 230.457302] f8c0:
> > > > >> 0000000000000000 0000000005f5e0ff 000000000001379a
> > > > 3866666666666620 [
> > > > >> 230.457306] f8e0: ffffff800a1b4065 0000000000000006
> > > > >> ffffff800a129000
> > > > >> ffffffc87b8010a8 [ 230.457310] f900: ffffff808a1b4057
> > > > >> ffffff800a1c3000 ffffff800a1b3000 ffffff800a13b000 [
> > > > >> 230.457314]
> > > > >> f920: 0000000000000140 0000000000000006 ffffff800a1b3b10
> > > > >> ffffff800a1c39e8 [ 230.457318] f940: 000000000000002f
> > > > >> ffffff800a1b8a98 ffffff800a1b3ae8 ffffffc87b07f990 [
> > > > >> 230.457322]
> > > > >> f960: ffffff80080d6230 ffffffc87b07f990 ffffff80080d6234
> > > > >> 0000000060000145
> > > > >> ** 1 printk messages dropped ** [ 230.457329]
> > > > >> [<ffffff8008085720>]
> > > > >> el1_irq+0xa0/0x100
> > > > >> ** 9 printk messages dropped ** [ 230.457373]
> > > > >> [<ffffff800885ad60>]
> > > > >> ieee80211_hw_config+0x50/0x290 [ 230.457377]
> > > > >> [<ffffff8008863690>]
> > > > >> ieee80211_scan_work+0x1f8/0x480 [ 230.457383]
> > > > >> [<ffffff80080b15d0>]
> > > > >> process_one_work+0x120/0x378 [ 230.457386]
> > > > >> [<ffffff80080b1870>]
> > > > >> worker_thread+0x48/0x4b0 [ 230.457391] [<ffffff80080b7108>]
> > > > >> kthread+0xd0/0xe8 [ 230.457395] [<ffffff8008085dd0>]
> > > > ret_from_fork+0x10/0x40
> > > > >> [ 230.480389] ath9k_hw_intrpend 762
> > > > >>
> > > > >>
> > > > >> [ 545.487987] ath9k: ath9k_ioread32 ffffff800a400024 [
> > > > >> 545.526189]
> > > > >> INFO: rcu_sched self-detected stall on CPU
> > > > >> [ 545.526195] 2-...: (97636 ticks this GP)
> > > > idle=3D2d1/140000000000001/0 softirq=3D1400/1400 fqs=3D115374
> > > > >> [ 545.526199] (t=3D115523 jiffies g=3D161 c=3D160 q=3D51066)
> > > > >> [ 545.526201] Task dump for CPU 2:
> > > > >> [ 545.526206] kworker/u8:4 R running task 0 1342 =
2
> > 0x00000002
> > > > >> ** 3 printk messages dropped ** [ 545.526231]
> > > > >> [<ffffff8008089a0c>]
> > > > >> show_stack+0x14/0x20
> > > > >> ** 9 printk messages dropped ** [ 545.526280]
> > > > >> [<ffffff80086a71e8>]
> > > > >> arch_timer_handler_phys+0x30/0x40 [ 545.526284]
> > > > >> [<ffffff80080dbe18>]
> > > > >> handle_percpu_devid_irq+0x78/0xa0 [ 545.526291]
> > > > >> [<ffffff80080d760c>]
> > > > >> generic_handle_irq+0x24/0x38 [ 545.526296]
> > > > >> [<ffffff80080d7944>]
> > > > >> __handle_domain_irq+0x5c/0xb8 [ 545.526299]
> > > > >> [<ffffff80080824bc>]
> > > > >> gic_handle_irq+0x64/0xc0 [ 545.526302] Exception
> > > > >> stack(0xffffffc87b07f870
> > > > to 0xffffffc87b07f990)
> > > > >> [ 545.526306] f860: 000000000=
0009732
> > ffffff800a1eaaa8
> > > > >> ** 8 printk messages dropped ** [ 545.526341] f980:
> > > > >> ffffff800a1c39e8
> > > > >> 0000000000000036 [ 545.526345] [<ffffff8008085720>]
> > > > >> el1_irq+0xa0/0x100 [ 545.526349] [<ffffff80080d6234>]
> > > > >> console_unlock+0x384/0x5b0 [ 545.526353] [<ffffff80080d673c>]
> > > > >> vprintk_emit+0x2dc/0x4b0 [ 545.526357] [<ffffff80080d6a50>]
> > > > >> vprintk_default+0x38/0x40 [ 545.526362] [<ffffff8008129704>]
> > > > >> printk+0x58/0x60 [ 545.526366] [<ffffff800859e3e4>]
> > > > >> ath9k_iowrite32+0x9c/0xa8 [ 545.526372] [<ffffff80085c7ca8>]
> > > > >> ath9k_hw_kill_interrupts+0x28/0xf0
> > > > >> [ 545.526376] [<ffffff80085a18ec>] ath_reset+0x24/0x68
> > > > >> ** 2 printk messages dropped ** [ 545.526391]
> > > > >> [<ffffff800885ad60>]
> > > > ieee80211_hw_config+0x50/0x290
> > > > >> ** 11 printk messages dropped ** [ 545.532834]
> > > > >> ath9k_hw_kill_interrupts
> > > > 793
> > > > >> [ 545.532890] ath9k_hw_enable_interrupts 821
> > > >
> > > > [ 81.876902] INFO: rcu_preempt detected stalls on CPUs/tasks:
> > > > [ 81.876912] Tasks blocked on level-0 rcu_node (CPUs 0-7): P0
> > > > [ 81.876932] (detected by 4, t=3D60002 jiffies, g=3D1873, c=
=3D1872, q=3D4967)
> > > > [ 81.876936] swapper/4 R running task 0 0 =
1
> > > > 0x00000000
> > > > [ 81.876941] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > > ffffffff81a3dc40
> > > > [ 81.876945] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > > ffffffff81a3dc40
> > > > [ 81.876948] 00000000ffffffff ffffffff810a7333 ffff88017ecee698
> > > > ffff88017edbc240
> > > > [ 81.876951] Call Trace:
> > > > [ 81.876970] <IRQ>
> > > > [ 81.876979] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > > [ 81.876983] [<ffffffff81101e46>] ?
> > > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > > [ 81.876989] [<ffffffff810a7333>] ? rcu_check_callbacks+0x6b3/0x=
8c0
> > > > [ 81.876993] [<ffffffff810b8350>] ?
> tick_sched_handle.isra.14+0x40/0x40
> > > > [ 81.876996] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x=
50
> > > > [ 81.876999] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > > [ 81.877002] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x=
150
> > > > [ 81.877004] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > > [ 81.877008] [<ffffffff81031b1e>] ?
> > > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > > [ 81.877012] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x=
90
> > > > [ 81.877013] <EOI>
> > > > [ 81.877017] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x=
1f0
> > > > [ 81.877019] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x=
1f0
> > > > [ 81.877021] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x21=
0
> > > > [ 81.877027] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > > [ 81.877029] swapper/4 R running task 0 0 =
1
> > > > 0x00000000
> > > > [ 81.877032] 0000000000000001 ffffffff810725f6 ffff88017edbc240
> > > > ffffffff81a3dc40
> > > > [ 81.877035] ffffffff81101e46 ffff88025ef173c0 ffffffff81a3dc40
> > > > ffffffff81a3dc40
> > > > [ 81.877038] 00000000ffffffff ffffffff810a7368 ffff88017ecee698
> > > > ffff88017edbc240
> > > > [ 81.877041] Call Trace:
> > > > [ 81.877045] <IRQ>
> > > > [ 81.877049] [<ffffffff810725f6>] ? sched_show_task+0xd6/0x140
> > > > [ 81.877051] [<ffffffff81101e46>] ?
> > > > rcu_print_detail_task_stall_rnp+0x40/0x61
> > > > [ 81.877055] [<ffffffff810a7368>] ? rcu_check_callbacks+0x6e8/0x=
8c0
> > > > [ 81.877058] [<ffffffff810b8350>] ?
> tick_sched_handle.isra.14+0x40/0x40
> > > > [ 81.877060] [<ffffffff810aa4c3>] ? update_process_times+0x23/0x=
50
> > > > [ 81.877063] [<ffffffff810b8383>] ? tick_sched_timer+0x33/0x60
> > > > [ 81.877065] [<ffffffff810aaf09>] ? __hrtimer_run_queues+0xb9/0x=
150
> > > > [ 81.877068] [<ffffffff810ab198>] ? hrtimer_interrupt+0x98/0x1a0
> > > > [ 81.877070] [<ffffffff81031b1e>] ?
> > > > smp_trace_apic_timer_interrupt+0x5e/0x90
> > > > [ 81.877073] [<ffffffff815b31bf>] ? apic_timer_interrupt+0x7f/0x=
90
> > > > [ 81.877074] <EOI>
> > > > [ 81.877076] [<ffffffff8147f28d>] ? cpuidle_enter_state+0x13d/0x=
1f0
> > > > [ 81.877078] [<ffffffff8147f289>] ? cpuidle_enter_state+0x139/0x=
1f0
> > > > [ 81.877080] [<ffffffff81088c19>] ? cpu_startup_entry+0x139/0x21=
0
> > > > [ 81.877084] [<ffffffff8102fc9e>] ? start_secondary+0x13e/0x170
> > > > [ 91.132787] INFO: rcu_preempt detected expedited stalls on
> > > > CPUs/tasks: { P0 } 63785 jiffies s: 505 root: 0x0/T
> > > > [ 91.132796] blocking rcu_node structures:
> > > >
> > > > >>
> > > > >>
> > > > >> But if we have less debug prints it does not reach EP handler
> > > > >> sometimes, due to following Condition in "kernel/irq/chip.c" in
> > > > >> function handle_simple_irq
> > > > >>
> > > > >> if (unlikely(!desc->action || irqd_irq_disabled(&desc->irq_data)=
)) {
> > > > >> desc->istate |=3D IRQS_PENDING;
> > > > >> goto out_unlock;
> > > > >> }
> > > > >> Here irqd_irq_disabled is being set to 1.
> > > > >>
> > > > >> With lesser debug prints it stops after following prints:
> > > > >> root@Xilinx-ZCU102-2016_3:~# iw dev wlan0 scan
> > > > >> [ 54.781045] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.785007] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.792535] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.796642] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.800807] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.804973] AR_SREV_9100 0
> > > > >> [ 54.807663] ath9k_hw_enable_interrupts 848
> > > > >> [ 54.811843] ath9k_hw_intrpend 762
> > > > >> [ 54.815211] (AR_SREV_9340(ah) val 0
> > > > >> [ 54.818684] ath9k_hw_intrpend 767
> > > > >> [ 54.822078] ath_isr 603
> > > > >> [ 54.824587] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.828601] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.832750] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.836916] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.841082] AR_SREV_9100 0
> > > > >> [ 54.843772] ath9k_hw_enable_interrupts 848
> > > > >> [ 54.843775] ath9k_hw_intrpend 762
> > > > >> [ 54.851319] (AR_SREV_9340(ah) val 0
> > > > >> [ 54.854793] ath9k_hw_intrpend 767
> > > > >> [ 54.858185] ath_isr 603
> > > > >> [ 54.860696] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.864776] ath9k_hw_enable_interrupts 821
> > > > >> [ 54.867061] ath9k_hw_kill_interrupts 793
> > > > >> [ 54.872870] ath9k_hw_enable_interrupts 825
> > > > >> [ 54.877036] ath9k_hw_enable_interrupts 832
> > > > >> [ 54.881202] AR_SREV_9100 0
> > > > >> [ 54.883892] ath9k_hw_enable_interrupts 848
> > > > >> [ 75.963129] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > > >> [ 75.968602] 0-...: (2 GPs behind) idle=3D9d5/140000000000001=
/0
> > > > softirq=3D1103/1109 fqs=3D519
> > > > >> [ 75.976675] (detected by 2, t=3D5274 jiffies, g=3D64, c=3D63=
, q=3D11)
> > > > >> [ 75.982485] Task dump for CPU 0:
> > > > >> [ 75.985696] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > > >> [ 75.992726] Call trace:
> > > > >> [ 75.995165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0
> > > > >> [ 76.000281] [<ffffffc87b830500>] 0xffffffc87b830500
> > > > >> [ 139.059027] INFO: rcu_sched detected stalls on CPUs/tasks:
> > > > >> [ 139.064430] 0-...: (2 GPs behind) idle=3D9d5/140000000000001=
/0
> > > > softirq=3D1103/1109 fqs=3D2097
> > > > >> [ 139.072593] (detected by 2, t=3D21049 jiffies, g=3D64, c=3D6=
3, q=3D11)
> > > > >> [ 139.078489] Task dump for CPU 0:
> > > > >> [ 139.081700] ksoftirqd/0 R running task 0 3 =
2 0x00000002
> > > > >> [ 139.088731] Call trace:
> > > > >> [ 139.091165] [<ffffff8008086b3c>] __switch_to+0xc4/0xd0 [
> > > > >> 139.096285] [<ffffffc87b830500>] 0xffffffc87b830500
> > > > >>
> > > > >>
> > > > >>>> We are not seeing any issues on 32-bit ARM platform and X86
> > > > >>>> platform.
> > > > >>> Can you collect a dmesg log (or, if the system hang means you
> > > > >>> can't collect that, a console log with "ignore_loglevel"), and =
"lspci -vv"
> > > > >>> output as root? That should have clues about whether the INTx
> > > > >>> got routed correctly. /proc/interrupts should also show
> > > > >>> whether we're receiving interrupts from the device.
> > > > >> Here is the lspci output:
> > > > >> 00:00.0 PCI bridge: Xilinx Corporation Device d022 (prog-if 00
> > > > >> [Normal
> > > > decode])
> > > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV-
> VGASnoop-
> > > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > > >> Latency: 0
> > > > >> Interrupt: pin A routed to IRQ 224
> > > > >> Bus: primary=3D00, secondary=3D01, subordinate=3D0c, sec-latenc=
y=3D0
> > > > >> I/O behind bridge: 00000000-00000fff
> > > > >> Memory behind bridge: e0000000-e00fffff
> > > > >> Prefetchable memory behind bridge: 00000000fff00000-
> > > > 00000000000fffff
> > > > >> Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- <SERR- <PERR-
> > > > >> BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> > > > >> PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> > > > >> Capabilities: [40] Power Management version 3
> > > > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=3D0mA
> > > > PME(D0+,D1+,D2+,D3hot+,D3cold-)
> > > > >> Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0
> PME-
> > > > >> Capabilities: [60] Express (v2) Root Port (Slot-), MSI 00
> > > > >> DevCap: MaxPayload 256 bytes, PhantFunc 0
> > > > >> ExtTag- RBE+
> > > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > > Unsupported-
> > > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
> NoSnoop+
> > > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> AuxPwr-
> > > > TransPend+
> > > > >> LnkCap: Port #0, Speed 5GT/s, Width x2, ASPM not
> supported,
> > > > Exit Latency L0s unlimited, L1 unlimited
> > > > >> ClockPM- Surprise- LLActRep- BwNot+
> ASPMOptComp+
> > > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
> CommClk-
> > > > >> ExtSynch- ClockPM- AutWidDis- BWInt-
> AutBWInt-
> > > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > > DLActive- BWMgmt- ABWMgmt-
> > > > >> RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal-
> PMEIntEna-
> > > > CRSVisible+
> > > > >> RootCap: CRSVisible+
> > > > >> RootSta: PME ReqID 0000, PMEStatus- PMEPending-
> > > > >> DevCap2: Completion Timeout: Range B, TimeoutDis+,
> LTR-,
> > > > OBFF Not Supported ARIFwd-
> > > > >> DevCtl2: Completion Timeout: 50us to 50ms,
> TimeoutDis-, LTR-,
> > > > OBFF Disabled ARIFwd-
> > > > >> LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance-
> SpeedDis-
> > > > >> Transmit Margin: Normal Operating Range,
> > > > EnterModifiedCompliance- ComplianceSOS-
> > > > >> Compliance De-emphasis: -6dB
> > > > >> LnkSta2: Current De-emphasis Level: -3.5dB,
> > > > EqualizationComplete-, EqualizationPhase1-
> > > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > > LinkEqualizationRequest-
> > > > >> Capabilities: [100 v1] Device Serial Number 00-00-00-00-00-00-
> 00-00
> > > > >> Capabilities: [10c v1] Virtual Channel
> > > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > > >> Ctrl: ArbSelect=3DFixed
> > > > >> Status: InProgress-
> > > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1
> RejSnoopTrans-
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> TWRR128-
> > > > WRR256-
> > > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > > >> Status: NegoPending- InProgress-
> > > > >> Capabilities: [128 v1] Vendor Specific Information: ID=3D1234
> > > > >> Rev=3D1
> > > > >> Len=3D018 <?>
> > > > >>
> > > > >> 01:00.0 Network controller: Qualcomm Atheros AR93xx Wireless
> > > > >> Network
> > > > Adapter (rev 01)
> > > > >> Subsystem: Qualcomm Atheros Device 3112
> > > > >> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV-
> VGASnoop-
> > > > ParErr- Stepping- SERR- FastB2B- DisINTx-
> > > > >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=3Dfast
> >TAbort-
> > > > <TAbort- <MAbort- >SERR- <PERR- INTx-
> > > > >> Latency: 0, Cache Line Size: 128 bytes
> > > > >> Interrupt: pin A routed to IRQ 224
> > > > >> Region 0: Memory at e0000000 (64-bit, non-prefetchable)
> [size=3D128K]
> > > > >> [virtual] Expansion ROM at e0020000 [disabled] [size=3D64K]
> > > > >> Capabilities: [40] Power Management version 3
> > > > >> Flags: PMEClk- DSI- D1+ D2- AuxCurrent=3D375mA
> > > > PME(D0+,D1+,D2-,D3hot+,D3cold-)
> > > > >> Status: D0 NoSoftRst- PME-Enable- DSel=3D0 DScale=3D0
> PME-
> > > > >> Capabilities: [50] MSI: Enable- Count=3D1/4 Maskable+ 64bit+
> > > > >> Address: 0000000000000000 Data: 0000
> > > > >> Masking: 00000000 Pending: 00000000
> > > > >> Capabilities: [70] Express (v2) Endpoint, MSI 00
> > > > >> DevCap: MaxPayload 128 bytes, PhantFunc 0,
> Latency
> > > > L0s <1us, L1 <8us
> > > > >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE+
> FLReset-
> > > > SlotPowerLimit 0.000W
> > > > >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
> > > > Unsupported-
> > > > >> RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
> NoSnoop-
> > > > >> MaxPayload 128 bytes, MaxReadReq 512 bytes
> > > > >> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq-
> AuxPwr-
> > > > TransPend-
> > > > >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,
> Exit
> > > > Latency L0s <2us, L1 <64us
> > > > >> ClockPM- Surprise- LLActRep- BwNot-
> ASPMOptComp-
> > > > >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled-
> CommClk-
> > > > >> ExtSynch- ClockPM- AutWidDis- BWInt-
> AutBWInt-
> > > > >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
> > > > DLActive- BWMgmt- ABWMgmt-
> > > > >> DevCap2: Completion Timeout: Not Supported,
> TimeoutDis+,
> > > > LTR-, OBFF Not Supported
> > > > >> DevCtl2: Completion Timeout: 50us to 50ms,
> TimeoutDis-, LTR-,
> > > > OBFF Disabled
> > > > >> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance-
> > > > SpeedDis-
> > > > >> Transmit Margin: Normal Operating Range,
> > > > EnterModifiedCompliance- ComplianceSOS-
> > > > >> Compliance De-emphasis: -6dB
> > > > >> LnkSta2: Current De-emphasis Level: -6dB,
> > > > EqualizationComplete-, EqualizationPhase1-
> > > > >> EqualizationPhase2-, EqualizationPhase3-,
> > > > LinkEqualizationRequest-
> > > > >> Capabilities: [100 v1] Advanced Error Reporting
> > > > >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > > >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
> > > > >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt-
> UnxCmplt-
> > > > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
> > > > >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > > NonFatalErr-
> > > > >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout-
> > > > NonFatalErr+
> > > > >> AERCap: First Error Pointer: 00, GenCap-
> CGenEn-
> > > > ChkCap- ChkEn-
> > > > >> Capabilities: [140 v1] Virtual Channel
> > > > >> Caps: LPEVC=3D0 RefClk=3D100ns PATEntryBits=3D1
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> > > > >> Ctrl: ArbSelect=3DFixed
> > > > >> Status: InProgress-
> > > > >> VC0: Caps: PATOffset=3D00 MaxTimeSlots=3D1
> RejSnoopTrans-
> > > > >> Arb: Fixed- WRR32- WRR64- WRR128-
> TWRR128-
> > > > WRR256-
> > > > >> Ctrl: Enable+ ID=3D0 ArbSelect=3DFixed TC/VC=3Dff
> > > > >> Status: NegoPending- InProgress-
> > > > >> Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-
> 00-00
> > > > >> Kernel driver in use: ath9k
> > > > >>
> > > > >> Here is the cat /proc/interrupts (after we do interface up):
> > > > >>
> > > > >> root@:~# ifconfig wlan0 up
> > > > >> [ 1548.926601] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not
> > > > >> ready root@Xilinx-ZCU102-2016_3:~# cat /proc/interrupts
> > > > >> CPU0 CPU1 CPU2 CPU3
> > > > >> 1: 0 0 0 0 GICv2 29 =
Edge arch_timer
> > > > >> 2: 19873 20058 19089 17435 GICv2 30 =
Edge
> arch_timer
> > > > >> 12: 0 0 0 0 GICv2 156 =
Level zynqmp-dma
> > > > >> 13: 0 0 0 0 GICv2 157 =
Level zynqmp-dma
> > > > >> 14: 0 0 0 0 GICv2 158 =
Level zynqmp-dma
> > > > >> 15: 0 0 0 0 GICv2 159 =
Level zynqmp-dma
> > > > >> 16: 0 0 0 0 GICv2 160 =
Level zynqmp-dma
> > > > >> 17: 0 0 0 0 GICv2 161 =
Level zynqmp-dma
> > > > >> 18: 0 0 0 0 GICv2 162 =
Level zynqmp-dma
> > > > >> 19: 0 0 0 0 GICv2 163 =
Level zynqmp-dma
> > > > >> 20: 0 0 0 0 GICv2 164 =
Level Mali_GP_MMU,
> > > > Mali_GP, Mali_PP0_MMU, Mali_PP0, Mali_PP1_MMU, Mali_PP1
> > > > >> 30: 0 0 0 0 GICv2 95 =
Level eth0, eth0
> > > > >> 206: 314 0 0 0 GICv2 49 L=
evel cdns-i2c
> > > > >> 207: 40 0 0 0 GICv2 50 L=
evel cdns-i2c
> > > > >> 209: 0 0 0 0 GICv2 150 L=
evel nwl_pcie:misc
> > > > >> 214: 12 0 0 0 GICv2 47 L=
evel ff0f0000.spi
> > > > >> 215: 0 0 0 0 GICv2 58 L=
evel ffa60000.rtc
> > > > >> 216: 0 0 0 0 GICv2 59 L=
evel ffa60000.rtc
> > > > >> 217: 0 0 0 0 GICv2 165 L=
evel ahci-
> > > > ceva[fd0c0000.ahci]
> > > > >> 218: 61 0 0 0 GICv2 81 L=
evel mmc0
> > > > >> 219: 0 0 0 0 GICv2 187 L=
evel arm-smmu global
> > fault
> > > > >> 220: 471 0 0 0 GICv2 53 L=
evel xuartps
> > > > >> 223: 0 0 0 0 GICv2 154 L=
evel fd4c0000.dma
> > > > >> 224: 3 0 0 0 dummy 1 E=
dge ath9k
> > > > >> 225: 0 0 0 0 GICv2 97 L=
evel xhci-hcd:usb1
> > > > >>
> > > > >> Regards,
> > > > >> Bharat
> > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in t=
he body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v4 1/2] mmc: API for accessing host supported maximum segment count and size
From: Amitkumar Karwar @ 2016-12-22 9:09 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, Ulf Hansson
Cc: Nishant Sarmukadam, Wei-Ning Huang, linux-mmc@vger.kernel.org,
Cathy Luo, Xinming Hu
In-Reply-To: <1466069006-10757-1-git-send-email-akarwar@marvell.com>
Hi Ulf,
> From: Amitkumar Karwar [mailto:akarwar@marvell.com]
> Sent: Thursday, June 16, 2016 2:53 PM
> To: linux-wireless@vger.kernel.org
> Cc: Nishant Sarmukadam; Wei-Ning Huang; linux-mmc@vger.kernel.org;
> Cathy Luo; Xinming Hu; Amitkumar Karwar
> Subject: [PATCH v4 1/2] mmc: API for accessing host supported maximum
> segment count and size
>
> From: Xinming Hu <huxm@marvell.com>
>
> sdio device drivers need be able to get the host supported max_segs and
> max_seg_size, so that they know the buffer size to allocate while
> utilizing the scatter/gather DMA buffer list.
>
> This patch provides API for this purpose.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: v2 was submitted with minor improvement like replacing BUG_ON()
> with WARN_ON()
> v3: Addressed below review comments from Ulf Hansson
> a) In v3, patch has been split into two separate patches.
> b) Patch 1/2 introduces an API to fetch max_seg_size and max_segs
> c) Replaced WARN_ON() with proper error code when sg_ptr->length is
> invalid
> d) Instead of duplicating the code in mmc_io_rw_extended(), extra
> bool parameter
> has been added to this function and used it in new APIs for SG.
> v4: Removed WARN_ON() calls in newly added APIs. It's gets called in
> probe handler.
> Caller already takes care of it(Shawn Lin).
> ---
> drivers/mmc/core/sdio_io.c | 21
> +++++++++++++++++++++
> .../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 6 +++---
> include/linux/mmc/sdio_func.h | 3 +++
> 3 files changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/core/sdio_io.c b/drivers/mmc/core/sdio_io.c
> index 78cb4d5..b1ecacc 100644
> --- a/drivers/mmc/core/sdio_io.c
> +++ b/drivers/mmc/core/sdio_io.c
> @@ -720,3 +720,24 @@ int sdio_set_host_pm_flags(struct sdio_func *func,
> mmc_pm_flag_t flags)
> return 0;
> }
> EXPORT_SYMBOL_GPL(sdio_set_host_pm_flags);
> +
> +/**
> + * sdio_get_host_max_seg_size - get host maximum segment size
> + * @func: SDIO function attached to host
> + */
> +unsigned int sdio_get_host_max_seg_size(struct sdio_func *func) {
> + return func->card->host->max_seg_size; }
> +EXPORT_SYMBOL_GPL(sdio_get_host_max_seg_size);
> +
> +/**
> + * sdio_get_host_max_seg_count - get host maximum segment count
> + * @func: SDIO function attached to host
> + */
> +unsigned short sdio_get_host_max_seg_count(struct sdio_func *func) {
> + return func->card->host->max_segs;
> +}
> +EXPORT_SYMBOL_GPL(sdio_get_host_max_seg_count);
> +
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index c4b89d2..ba579f4 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -896,9 +896,9 @@ void brcmf_sdiod_sgtable_alloc(struct
> brcmf_sdio_dev *sdiodev)
> max_blocks = min_t(uint, host->max_blk_count, 511u);
> sdiodev->max_request_size = min_t(uint, host->max_req_size,
> max_blocks * func->cur_blksize);
> - sdiodev->max_segment_count = min_t(uint, host->max_segs,
> - SG_MAX_SINGLE_ALLOC);
> - sdiodev->max_segment_size = host->max_seg_size;
> + sdiodev->max_segment_count = min_t(uint, SG_MAX_SINGLE_ALLOC,
> + sdio_get_host_max_seg_count(func));
> + sdiodev->max_segment_size = sdio_get_host_max_seg_size(func);
>
> if (!sdiodev->sg_support)
> return;
> diff --git a/include/linux/mmc/sdio_func.h
> b/include/linux/mmc/sdio_func.h index aab032a..b2b91df 100644
> --- a/include/linux/mmc/sdio_func.h
> +++ b/include/linux/mmc/sdio_func.h
> @@ -159,4 +159,7 @@ extern void sdio_f0_writeb(struct sdio_func *func,
> unsigned char b, extern mmc_pm_flag_t sdio_get_host_pm_caps(struct
> sdio_func *func); extern int sdio_set_host_pm_flags(struct sdio_func
> *func, mmc_pm_flag_t flags);
>
> +unsigned short sdio_get_host_max_seg_count(struct sdio_func *func);
> +unsigned int sdio_get_host_max_seg_size(struct sdio_func *func);
> +
> #endif /* LINUX_MMC_SDIO_FUNC_H */
This has been pending for a while.
Any further review comments on this v4 patch series?
Regards,
Amitkumar Karwar
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Arend Van Spriel @ 2016-12-22 9:37 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
On 21-12-2016 23:23, Ozgur Karatas wrote:
>
> The patch fixed to struct uses in reg.c, I think doesn't need to be use to "struct".
> There is dataype not have to logical link and each is different definitons.
>
> I'm undecided on this patch. I compiled and didn't to errors.
There must be something wrong in the way you build stuff, but still just
looking at your patch it is fundamentally wrong, which is what makes
people say "do a basic C course". Let me try and explain below.
> Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
> ---
> net/wireless/reg.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..5b70970 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -490,7 +490,7 @@ static int reg_query_builtin(const char *alpha2)
> if (!regdom)
> return -ENODATA;
>
> - request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
> + request = kzalloc(sizeof(*reg_regdb_apply_request), GFP_KERNEL);
Making it more abstract to explain what you are doing:
x = foo(sizeof(T), GFP_KERNEL); where T is "struct Y".
which you change to:
x = foo(sizeof(*Y), GFP_KERNEL);
Y has no meaning for the sizeof operator and the compiler will yell at
it being an unknown identifier. In a lot of kernel code you will find:
x = foo(sizeof(*x), GFP_KERNEL);
which is probably the coding style fix you are attempting to make, but
miserably fail to do so. There is nothing linux kernel specific about
this. It is really fundamental knowledge of the C language. The correct
change for this instance is:
- request = kzalloc(sizeof(struct reg_regdb_apply_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*request), GFP_KERNEL);
Hope this helps to come up with a working V2 of this patch.
Regards,
Arend
^ permalink raw reply
* Question: Packet drop criterion
From: Ferran Quer i Guerrero @ 2016-12-22 12:34 UTC (permalink / raw)
To: linux-wireless
Hello everyone,
I would like to modify the retry threshold for dropping a packet using
mesh mode. I tried with iw
iw phy <phyname> set retry [short <limit>] [long <limit>]
with short and long limits equal to 10 first and later 5, but I couldn't
tell any effect. I'm checking by adding a printk in `status.c` and
manually shutting down (ifdown) the mesh-peered interface to cause
packet retries. It turns out that the tx report only appears when
`retry_count` is 28 (after many continued drops, it also appears at 23,
24, 25 or retries).=20
void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb=
)
{
/* ... */
if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
ieee80211_handle_filtered_frame(local, sta, skb);=
rcu_read_unlock();
return;
} else {
if (!acked)
sta->tx_retry_failed++;
sta->tx_retry_count +=3D retry_count;
/* Dirty debugging */
printk("Packet dropped. Retry count: %d",
retry_count);
}
rate_control_tx_status(local, sband, sta, skb);
if (ieee80211_vif_is_mesh(&sta->sdata->vif))
ieee80211s_update_metric(local, sta, skb);
/* ... */
}
I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
mesh point mode.
Did I get wrong the iw command?
Is it Minstrel who decides the retry trheshold?
Is it Atheros driver?
Does it have anything to do with mesh mode?
I'm trying to find the responsible at the source code, but haven't
succeeded yet, so I decided to write to yo.
Thank you very much
Ferran Quer
^ permalink raw reply
* pull-request: wireless-drivers 2016-12-22
From: Kalle Valo @ 2016-12-22 15:11 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
before the holidays a really small pull request for 4.10. I just want to
have the regressions in rtlwifi and ath9k fixed quickly so I send this
earlier than I normally would.
Please let me know if there are any problems.
Kalle
The following changes since commit ad688cdbb076833ba17fc65591cd0fe01900a5cf:
stmmac: fix memory barriers (2016-12-19 11:05:02 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2016-12-22
for you to fetch changes up to 22b68b93ae2506bd56ee3bf232a51bc8ab955b56:
rtlwifi: Fix kernel oops introduced with commit e49656147359 (2016-12-21 16:34:16 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
All small fixes this time, especially important are the regression
fixes for rtlwifi and ath9k.
----------------------------------------------------------------
Arend Van Spriel (2):
brcmfmac: fix memory leak in brcmf_cfg80211_attach()
brcmfmac: fix uninitialized field in scheduled scan ssid configuration
Ben Greear (1):
ath10k: free host-mem with DMA_BIRECTIONAL flag
Larry Finger (1):
rtlwifi: Fix kernel oops introduced with commit e49656147359
Tobias Klausmann (1):
ath9k: do not return early to fix rcu unlocking
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 7 +++++--
.../net/wireless/broadcom/brcm80211/brcmfmac/pno.c | 1 +
drivers/net/wireless/realtek/rtlwifi/core.c | 3 ++-
5 files changed, 10 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH] ath10k: merge extended peer info data with existing peers info
From: Mohammed Shafi Shajakhan @ 2016-12-22 15:48 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <2696316.Ugl5Pim1oL@debian64>
Hi Christian,
once again sorry for the delay
>
> On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > The 10.4 firmware adds extended peer information to the
> > > firmware's statistics payload. This additional info is
> > > stored as a separate data field. During review of
> > > "ath10k: add accounting for the extended peer statistics" [0]
> > >
> > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > lists are of little use:"... there is not much use in appending
> > > the extended peer stats (which gets periodically updated) to the
> > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > rid of the below (and the required cleanup as well)
> > >
> > > list_splice_tail_init(&stats.peers_extd,
> > > &ar->debug.fw_stats.peers_extd);
> > >
> > > since rx_duration is getting updated periodically to the per sta
> > > information."
> > >
> > > This patch replaces the extended peers list with a lookup and
> > > puts the retrieved data (rx_duration) into the existing
> > > ath10k_fw_stats_peer entry that was created earlier.
> >
> > [shafi] Its good to maintain the extended stats variable
> > and retain the two different functions to update rx_duration.
> >
> > a) extended peer stats supported - mainly for 10.4
> > b) extender peer stats not supported - for 10.2
> Well, I have to ask why you want to retain the two different
> functions to update the same arsta->rx_duration? I think a
> little bit of code that helps to explain what's on your mind
> (or how you would do it) would help immensely in this case.
> Since I have the feeling that this is the problem here.
> So please explain it in C(lang).
[shafi] I see you prefer to stuff the 'rx_duration' from
the extended stats to the existing global 'ath10k_peer_stats'
The idea of extended stats is, ideally its not going to stop
for 'rx_duration' . Extended stats is maintained as a seperate
list / entry for addition of new fields as well
>
> > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
> > > Cc: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
> > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > ---
> > > drivers/net/wireless/ath/ath10k/core.h | 2 --
> > > drivers/net/wireless/ath/ath10k/debug.c | 17 --------------
> > > drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > drivers/net/wireless/ath/ath10k/wmi.c | 34 ++++++++++++++++++++-------
> > > 4 files changed, 28 insertions(+), 57 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > };
> > >
> > > struct ath10k_fw_stats {
> > > - bool extended;
> > > struct list_head pdevs;
> > > struct list_head vdevs;
> > > struct list_head peers;
> > > - struct list_head peers_extd;
> > > };
> > >
> > > #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > index 82a4c67f3672..89f7fde77cdf 100644
> > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
> > > }
> > > }
> > >
> > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > -{
> > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > -
> > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > - list_del(&i->list);
> > > - kfree(i);
> > > - }
> > > -}
> > > -
> > > static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > > {
> > > spin_lock_bh(&ar->data_lock);
> > > ar->debug.fw_stats_done = false;
> > > - ar->debug.fw_stats.extended = false;
> >
> > [shafi] this looks fine, but not removing the 'extended' variable
> > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > arguably some what convoluted !
> I removed extended because it is now a write-only variable.
> So I figured, there's no point in keeping it around? I don't have
> access to the firmware interface documentation, so I don't know
> if there's a reason why it would be good to have it later.
> So please tell me, what information do we gain from it?
[shafi] while parsing the stats from 'wmi' we clearly mark there whether
the extended stats is available (or) not and if its there parse it and
deal with it seperately
>
> > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > *Fetch rx_duration from 'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > {certainly 'stats' object is for this particular update only, and freed
> > up later)
> > *Update immediately using 'ath10k_sta_update_rx_duration'
> >
> > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > for 10.2 and 10.4 (the later supporting extended peer stats)
>
> I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> (but with one extra __le32 for the rx_duration at the end.)
> This rx_duration is then used to set the rx_duration field in the
> generated ath10k_fw_stats_peer struct.
>
> 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> the communicating the rx_duration to the driver.
>
> Thing is, both function have the same signature. They produce the same
> struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> why does 10.4 need to have it's peer_extd infrastructure, when it can use
> the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
[shafi] agreed we need to fix that, it would have been easier if 10.2.4
and 10.4 had the same definitions.
>
> What's with the extra layers / HAL here? Because it looks like it's merged
> back together in the same manner into the same arsta->rx_duration?
> [ath10k_sta_update_stats_rx_duration() vs.
> ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
>
> > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > index c893314a191f..c7ec7b9e9b55 100644
> > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > @@ -3044,23 +3044,41 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
> > > if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
> > > return 0;
> > >
> > > - stats->extended = true;
> > > -
> > > for (i = 0; i < num_peer_stats; i++) {
> > > const struct wmi_10_4_peer_extd_stats *src;
> > > - struct ath10k_fw_extd_stats_peer *dst;
> > > + struct ath10k_fw_stats_peer *dst;
> > >
> > > src = (void *)skb->data;
> > > if (!skb_pull(skb, sizeof(*src)))
> > > return -EPROTO;
> > >
> > > - dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
> > > - if (!dst)
> > > - continue;
> > > + /* Because the stat data may exceed htc-wmi buffer
> > > + * limit the firmware might split the stats data
> > > + * and delivers it in multiple update events.
> > > + * if we can't find the entry in the current event
> > > + * payload, we have to look in main list as well.
> > > + */
[shafi] thanks ! sorry i might have missed this bug, did you happen
to see this condition being hit ?
> > > + list_for_each_entry(dst, &stats->peers, list) {
> > > + if (ether_addr_equal(dst->peer_macaddr,
> > > + src->peer_macaddr.addr))
> > > + goto found;
> > > + }
> > > +
[shafi] Again, we can simply cache the macaddress and rx_duration
and deal with it later, rather than doing the whole lookup here ?
Will it be an overhead for large number of clients ?
> > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > + list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > + if (ether_addr_equal(dst->peer_macaddr,
> > > + src->peer_macaddr.addr))
> > > + goto found;
> > > + }
> > > +#endif
[shafi] again, this could be handled seperately.
> > > +
> > > + ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > + "Orphaned extended stats entry for station %pM.\n",
> > > + src->peer_macaddr.addr);
> > > + continue;
> > >
> > > - ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > +found:
> > > dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > - list_add_tail(&dst->list, &stats->peers_extd);
> > > }
> > >
> > > return 0;
> >
> > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > over the existing peer_stats structure, the idea is to maintain uniformity
> > between the structures shared between ath10k and its corresponding to avoid
> > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > to correct me if any of my analysis is incorrect. thank you !
> Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make
> a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> that other functions can use, without caring about if the FW was 10.4
> or 10.2.4?
>
> There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> conveys any different information than the rx_duration in
> wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> ath10k_fw_stats_peer? And if not: why exactly?
>
[shafi] I will soon test your change and keep you posted. We will also
get Kalle's take/view on this.
regards,
shafi
^ permalink raw reply
* Re: pull-request: wireless-drivers 2016-12-22
From: David Miller @ 2016-12-22 16:16 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <8760mcrobk.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 22 Dec 2016 17:11:27 +0200
> before the holidays a really small pull request for 4.10. I just want to
> have the regressions in rtlwifi and ath9k fixed quickly so I send this
> earlier than I normally would.
>
> Please let me know if there are any problems.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] ath10k: merge extended peer info data with existing peers info
From: Christian Lamparter @ 2016-12-22 17:58 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: linux-wireless, ath10k, Kalle Valo, michal.kazior
In-Reply-To: <20161222154801.GA16241@atheros-ThinkPad-T61>
Hello Shafi,
On Thursday, December 22, 2016 9:18:01 PM CET Mohammed Shafi Shajakhan wrote:
> > On Monday, December 19, 2016 10:19:57 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Sat, Dec 17, 2016 at 06:46:34PM +0100, Christian Lamparter wrote:
> > > > The 10.4 firmware adds extended peer information to the
> > > > firmware's statistics payload. This additional info is
> > > > stored as a separate data field. During review of
> > > > "ath10k: add accounting for the extended peer statistics" [0]
> > > >
> > > > Mohammed Shafi Shajakhan commented that the extended peer statistics
> > > > lists are of little use:"... there is not much use in appending
> > > > the extended peer stats (which gets periodically updated) to the
> > > > linked list '&ar->debug.fw_stats.peers_extd)' and should we get
> > > > rid of the below (and the required cleanup as well)
> > > >
> > > > list_splice_tail_init(&stats.peers_extd,
> > > > &ar->debug.fw_stats.peers_extd);
> > > >
> > > > since rx_duration is getting updated periodically to the per sta
> > > > information."
> > > >
> > > > This patch replaces the extended peers list with a lookup and
> > > > puts the retrieved data (rx_duration) into the existing
> > > > ath10k_fw_stats_peer entry that was created earlier.
> > >
> > > [shafi] Its good to maintain the extended stats variable
> > > and retain the two different functions to update rx_duration.
> > >
> > > a) extended peer stats supported - mainly for 10.4
> > > b) extender peer stats not supported - for 10.2
> > Well, I have to ask why you want to retain the two different
> > functions to update the same arsta->rx_duration? I think a
> > little bit of code that helps to explain what's on your mind
> > (or how you would do it) would help immensely in this case.
> > Since I have the feeling that this is the problem here.
> > So please explain it in C(lang).
>
> [shafi] I see you prefer to stuff the 'rx_duration' from
> the extended stats to the existing global 'ath10k_peer_stats'
> The idea of extended stats is, ideally its not going to stop
> for 'rx_duration' . Extended stats is maintained as a seperate
> list / entry for addition of new fields as well
I'm guessing you are trying to say here:
replace:
dst->rx_duration = __le32_to_cpu(src->rx_duration);
with
dst->rx_duration += __le32_to_cpu(src->rx_duration);
in ath10k_wmi_10_4_op_pull_fw_stats()?
Is this correct? If so then can you tell me why ath10k_wmi_10_4_op_pull_fw_stats()
is using for (i = 0; i < num_peer_stats; i++) to iterate over the extended peer
stats instead of looking up the number of extended peer items. Because this does
imply that there are the "same" (and every peer stat has a matching extended
peer stat)... (This will be important for the comment below - so ***).
Of course, if this isn't true then this is a bug and should be fixed because
otherwise the ath10k_wmi_10_4_op_pull_fw_stats functions might return -EPROTO
at some point which causes a "failed to pull fw stats: -71" and unprocessed/lost
stats.
> >
> > > > [0] <https://lkml.kernel.org/r/992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
> > > > Cc: Mohammed Shafi Shajakhan <mohammed@codeaurora.org>
> > > > Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> > > > ---
> > > > drivers/net/wireless/ath/ath10k/core.h | 2 --
> > > > drivers/net/wireless/ath/ath10k/debug.c | 17 --------------
> > > > drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-----------------------
> > > > drivers/net/wireless/ath/ath10k/wmi.c | 34 ++++++++++++++++++++-------
> > > > 4 files changed, 28 insertions(+), 57 deletions(-)
> > > >
> > > > diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
> > > > index 09ff8b8a6441..3fffbbb18c25 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/core.h
> > > > +++ b/drivers/net/wireless/ath/ath10k/core.h
> > > > @@ -268,11 +268,9 @@ struct ath10k_fw_stats_pdev {
> > > > };
> > > >
> > > > struct ath10k_fw_stats {
> > > > - bool extended;
> > > > struct list_head pdevs;
> > > > struct list_head vdevs;
> > > > struct list_head peers;
> > > > - struct list_head peers_extd;
> > > > };
> > > >
> > > > #define ATH10K_TPC_TABLE_TYPE_FLAG 1
> > > > diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> > > > index 82a4c67f3672..89f7fde77cdf 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/debug.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/debug.c
> > > > @@ -315,25 +315,13 @@ static void ath10k_fw_stats_peers_free(struct list_head *head)
> > > > }
> > > > }
> > > >
> > > > -static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
> > > > -{
> > > > - struct ath10k_fw_extd_stats_peer *i, *tmp;
> > > > -
> > > > - list_for_each_entry_safe(i, tmp, head, list) {
> > > > - list_del(&i->list);
> > > > - kfree(i);
> > > > - }
> > > > -}
> > > > -
> > > > static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
> > > > {
> > > > spin_lock_bh(&ar->data_lock);
> > > > ar->debug.fw_stats_done = false;
> > > > - ar->debug.fw_stats.extended = false;
> > >
> > > [shafi] this looks fine, but not removing the 'extended' variable
> > > from ath10k_fw_stats structure, I see the design for 'rx_duration'
> > > arguably some what convoluted !
> > I removed extended because it is now a write-only variable.
> > So I figured, there's no point in keeping it around? I don't have
> > access to the firmware interface documentation, so I don't know
> > if there's a reason why it would be good to have it later.
> > So please tell me, what information do we gain from it?
>
> [shafi] while parsing the stats from 'wmi' we clearly mark there whether
> the extended stats is available (or) not and if its there parse it and
> deal with it seperately
No, there's no difference between stats or extended stats (10.2.4 vs 10.4):
both ath10k_sta_update_extd_stats_rx_duration() [0]
and ath10k_sta_update_stats_rx_duration() [1] are adding the
ath10k_fw_stats_peer(_extd)->rx_duration to ath10k_sta->rx_duration.
With the merge of the peer stats and extended peer stats, this also
removed the only usage of stats->extended. And hence it becomes a
write-only variable. So there's no point in keeping it around ATM (as
all other extended peer stats entries aren't used).
> > > *We get periodic events from firmware updating 'ath10k_debug_fw_stats_process'
> > > *Fetch rx_duration from 'ath10k_wmi_pull_fw_stats(ar, skb, &stats)'
> > > {certainly 'stats' object is for this particular update only, and freed
> > > up later)
> > > *Update immediately using 'ath10k_sta_update_rx_duration'
> > >
> > > 'ath10k_wmi_pull_fw_stats' has a slightly different implementation
> > > for 10.2 and 10.4 (the later supporting extended peer stats)
> >
> > I see that 10.2.4's ath10k_wmi_10_2_4_op_pull_fw_stats()
> > passes the rx_duration as part of the wmi_10_2_4_ext_peer_stats
> > element which is basically a carbon-copy of wmi_10_2_4_peer_stats
> > (but with one extra __le32 for the rx_duration at the end.)
> > This rx_duration is then used to set the rx_duration field in the
> > generated ath10k_fw_stats_peer struct.
> >
> > 10.4's ath10k_wmi_10_4_op_pull_fw_stats() has a "fixed" wmi_10_4_peer_stats
> > element and uses an separate "fixed" wmi_10_4_peer_extd_stats element for
> > the communicating the rx_duration to the driver.
> >
> > Thing is, both function have the same signature. They produce the same
> > struct ath10k_fw_stats_peer for the given data in the sk_buff input. So
> > why does 10.4 need to have it's peer_extd infrastructure, when it can use
> > the existing rx_duration field in the *universal* ath10k_fw_stats_peer?
>
> [shafi] agreed we need to fix that, it would have been easier if 10.2.4
> and 10.4 had the same definitions.
Ok, I don't know the internals of the firmware to know what's the difference
between 10.2.4 and 10.4's rx_duration (how both firmwares define them
differently in this context) ? From what I can tell, it's just that
the entry has moved from the peer stats to extended peer stats.
Of course, this is based on the logic that both 10.2.4 and 10.4 rx_durations
end up being added to arsta->rx_duration in the same way. There's no scaling
or a comment that would indicate a difference.
> >
> > What's with the extra layers / HAL here? Because it looks like it's merged
> > back together in the same manner into the same arsta->rx_duration?
> > [ath10k_sta_update_stats_rx_duration() vs.
> > ath10k_sta_update_extd_stats_rx_duration() - they are almost carbon copies too]
> >
> > > > diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > index c893314a191f..c7ec7b9e9b55 100644
> > > > --- a/drivers/net/wireless/ath/ath10k/wmi.c
> > > > +++ b/drivers/net/wireless/ath/ath10k/wmi.c
> > > > @@ -3044,23 +3044,41 @@ static int ath10k_wmi_10_4_op_pull_fw_stats(struct ath10k *ar,
> > > > if ((stats_id & WMI_10_4_STAT_PEER_EXTD) == 0)
> > > > return 0;
> > > >
> > > > - stats->extended = true;
> > > > -
> > > > for (i = 0; i < num_peer_stats; i++) {
> > > > const struct wmi_10_4_peer_extd_stats *src;
> > > > - struct ath10k_fw_extd_stats_peer *dst;
> > > > + struct ath10k_fw_stats_peer *dst;
> > > >
> > > > src = (void *)skb->data;
> > > > if (!skb_pull(skb, sizeof(*src)))
> > > > return -EPROTO;
> > > >
> > > > - dst = kzalloc(sizeof(*dst), GFP_ATOMIC);
> > > > - if (!dst)
> > > > - continue;
> > > > + /* Because the stat data may exceed htc-wmi buffer
> > > > + * limit the firmware might split the stats data
> > > > + * and delivers it in multiple update events.
> > > > + * if we can't find the entry in the current event
> > > > + * payload, we have to look in main list as well.
> > > > + */
>
> [shafi] thanks ! sorry i might have missed this bug, did you happen
> to see this condition being hit ?
This was copied from ath10k_debug_fw_stats_process() [2]. I've added Michal
Kazior to the discussion since his patch "ath10k: fix fw stats processing"
added this in debug.c. I think he knows the firmware internals well enough
to tell if this is a problem or not. As it stands now, it is and will be
in the future.
> > > > + list_for_each_entry(dst, &stats->peers, list) {
> > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > + src->peer_macaddr.addr))
> > > > + goto found;
> > > > + }
> > > > +
>
> [shafi] Again, we can simply cache the macaddress and rx_duration
> and deal with it later, rather than doing the whole lookup here ?
> Will it be an overhead for large number of clients ?
Well, show me how you would do it more efficiently otherwise? I don't
see how you can cache the macaddress and rx_duration since you are
basically forced to process all the peer stats first and later all
the extended peer stats. They don't mix.
As for how expensive it is: From what I can tell, the 10.4 firmware
sends the stat events every few seconds. So they are not part of any
rx or tx hot-paths. The list_for_each within the for
(i = 0; i < num_peers;i++) is actually in the O(1) class as far
as both loops go. This might sound funny at first, but the number of
extended peer list is limited by TARGET_10_4_MAX_PEER_EXT_STATS to 16.
And thanks to (***) the limit of num_peers is also 16. Furthermore
we can add a if (ath10k_peer_stats_enabled(ar)) guard to skip it
entirely if the stats are disabled.
> > > > +#ifdef CONFIG_ATH10K_DEBUGFS
> > > > + list_for_each_entry(dst, &ar->debug.fw_stats.peers, list) {
> > > > + if (ether_addr_equal(dst->peer_macaddr,
> > > > + src->peer_macaddr.addr))
> > > > + goto found;
> > > > + }
> > > > +#endif
>
> [shafi] again, this could be handled seperately.
This is more expensive. As fw_stats.peers can contain more entries than 16.
However, this might be unnecessary if both peers and extended peers stats
entries in the wmi event are always for the same stations.
Note: There's an alternative way too. Instead of writing rx_duration into
ath10k_fw_stats, we could skip the middle man write it directly into
arsta->rx_duration. This would also mean that we can get rid of
ath10k_sta_update_extd_stats_rx_duration(), ath10k_sta_update_stats_rx_duration()
and ath10k_sta_update_rx_duration(). This has the benifit that we can
remove even more.
> > > > +
> > > > + ath10k_dbg(ar, ATH10K_DBG_WMI,
> > > > + "Orphaned extended stats entry for station %pM.\n",
> > > > + src->peer_macaddr.addr);
> > > > + continue;
> > > >
> > > > - ether_addr_copy(dst->peer_macaddr, src->peer_macaddr.addr);
> > > > +found:
> > > > dst->rx_duration = __le32_to_cpu(src->rx_duration);
> > > > - list_add_tail(&dst->list, &stats->peers_extd);
> > > > }
> > > >
> > > > return 0;
> > >
> > > [shafi] Yes i am bit concerned about this change making 10.4 to update
> > > over the existing peer_stats structure, the idea is to maintain uniformity
> > > between the structures shared between ath10k and its corresponding to avoid
> > > confusion/ bugs in the future. Kindly let me know your thoughts, feel free
> > > to correct me if any of my analysis is incorrect. thank you !
> > Isn't the point of the ath10k_wmi_10_*_op_pull_fw_stats() functions to make
> > a "universal" statistic (in your case a unified ath10k_fw_stats_peer structure)
> > that other functions can use, without caring about if the FW was 10.4
> > or 10.2.4?
> >
> > There's no indication that the rx_duration field in wmi_10_2_4_ext_peer_stats
> > conveys any different information than the rx_duration in
> > wmi_10_4_peer_extd_stats. So, what's going on here? Can't you just make
> > wmi_10_4_peer_extd_stats's rx_duration use the existing field in
> > ath10k_fw_stats_peer? And if not: why exactly?
> >
> [shafi] I will soon test your change and keep you posted. We will also
> get Kalle's take/view on this.
Ok. That said, I added him to the CC from the beginning and so far
he silently agreed.
Regards,
Christian
[0] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L21>
[1] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debugfs_sta.c#L40>
[2] <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath10k/debug.c#L360>
^ permalink raw reply
* Re: [PATCH 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-22 18:48 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, Lauro Ramos Venancio, Aloisio Almeida Jr,
Samuel Ortiz, Mark Rutland, netdev, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Mark Greer, Justin Bronder
In-Reply-To: <CAO7Z3WKmEbJCN_=srxTVKXvtz84vHGi41RS+9T7fmkmhRB6nEw@mail.gmail.com>
On Mon, Dec 19, 2016 at 5:23 PM, Geoff Lansberry <geoff@kuvee.com> wrote:
> I can make that change, however, I worry that it may be a bit
> misleading, since there are only two supported clock frequencies, but
> a number like that to me implies that it could be set to any number
> you want. I'm new at this, and so I'll go ahead and change it as you
> request, but I'd like to hear your thoughts on my concern.
Then the binding doc just needs to state what are the 2 valid frequencies.
Rob
^ permalink raw reply
* Re: Question: Packet drop criterion
From: Oleksij Rempel @ 2016-12-22 19:52 UTC (permalink / raw)
To: Ferran Quer i Guerrero, linux-wireless
In-Reply-To: <f4e6b348-fafb-1546-57cd-4623299b0abb@i2cat.net>
[-- Attachment #1.1: Type: text/plain, Size: 1757 bytes --]
Am 22.12.2016 um 13:34 schrieb Ferran Quer i Guerrero:
> Hello everyone,
>
> I would like to modify the retry threshold for dropping a packet using
> mesh mode. I tried with iw
>
> iw phy <phyname> set retry [short <limit>] [long <limit>]
>
> with short and long limits equal to 10 first and later 5, but I couldn't
> tell any effect. I'm checking by adding a printk in `status.c` and
> manually shutting down (ifdown) the mesh-peered interface to cause
> packet retries. It turns out that the tx report only appears when
> `retry_count` is 28 (after many continued drops, it also appears at 23,
> 24, 25 or retries).
>
> void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
> {
> /* ... */
> if (info->flags & IEEE80211_TX_STAT_TX_FILTERED) {
> ieee80211_handle_filtered_frame(local, sta, skb);
> rcu_read_unlock();
> return;
> } else {
> if (!acked)
> sta->tx_retry_failed++;
> sta->tx_retry_count += retry_count;
> /* Dirty debugging */
> printk("Packet dropped. Retry count: %d",
> retry_count);
> }
>
> rate_control_tx_status(local, sband, sta, skb);
> if (ieee80211_vif_is_mesh(&sta->sdata->vif))
> ieee80211s_update_metric(local, sta, skb);
> /* ... */
> }
>
> I'm using linux backports v3.12.8, ath9k wifi dongles, and interfaces on
> mesh point mode.
are you talking about usb dongles? If yes, then it is not ath9k
--
Regards,
Oleksij
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]
^ permalink raw reply
* [PATCH] ath10k: recal the txpower when removing interface
From: ryanhsu @ 2016-12-22 22:31 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
The txpower is being recalculated when adding interface to make sure
txpower won't overshoot the spec, and when removing the interface,
the txpower should again to be recalculated to restore the correct value
from the active interface list.
Following is one of the scenario
vdev0 is created as STA and connected: txpower:23
vdev1 is created as P2P_DEVICE for control interface: txpower:0
vdev2 is created as p2p go/gc interface: txpower is 21
So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
When we tear down the vdev2, the txpower needs to be recalculated to
re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
ath10k_pci mac vdev_id 0 txpower 23
... (adding interface)
ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
ath10k_pci mac vdev_id 2 txpower 21
ath10k_pci mac txpower 21
... (removing interface)
ath10k_pci mac vdev 2 delete (remove interface)
ath10k_pci vdev 1 txpower 0
ath10k_pci vdev 0 txpower 23
ath10k_pci mac txpower 23
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..6475dc8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5194,6 +5194,10 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
ath10k_warn(ar, "failed to recalc monitor: %d\n", ret);
}
+ ret = ath10k_mac_txpower_recalc(ar);
+ if (ret)
+ ath10k_warn(ar, "failed to recalc tx power: %d\n", ret);
+
spin_lock_bh(&ar->htt.tx_lock);
ath10k_mac_vif_tx_unlock_all(arvif);
spin_unlock_bh(&ar->htt.tx_lock);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] NFC: trf7970a: add device tree option for 27MHz clock
From: Rob Herring @ 2016-12-22 23:01 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1482380314-16440-1-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:32PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options to support hardware designs
> which use a 27.12MHz clock. This commit adds a device tree option
> 'clock-frequency' to support configuring the this chip for default
> 13.56MHz clock or the optional 27.12MHz clock.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 2 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nfc/trf7970a.c | 50 +++++++++++++++++-----
> 2 files changed, 41 insertions(+), 11 deletions(-)
^ permalink raw reply
* Re: [PATCH v3 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Rob Herring @ 2016-12-22 23:02 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo,
mark.rutland, netdev, devicetree, linux-kernel, mgreer, justin
In-Reply-To: <1482380314-16440-2-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:33PM -0500, Geoff Lansberry wrote:
> The TRF7970A has configuration options for supporting hardware designs
> with 1.8 Volt or 3.3 Volt IO. This commit adds a device tree option,
> using a fixed regulator binding, for setting the io voltage to match
> the hardware configuration. If no option is supplied it defaults to
> 3.3 volt configuration.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
> .../devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/nfc/trf7970a.c | 26 +++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] ath10k: ignore configuring the incorrect board_id
From: ryanhsu @ 2016-12-22 23:02 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: ryanhsu
From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
With command to get board_id from otp, in the case of following
boot get otp board id result 0x00000000 board_id 0 chip_id 0
boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
...
failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
ath10k/QCA6174/hw3.0/board-2.bin
The invalid board_id=0 will be used as index to search in the board-2.bin.
Ignore the case with board_id=0, as it means the otp is not carrying
the board id information.
Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 749e381..1bf67ad 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -694,8 +694,11 @@ static int ath10k_core_get_board_id_from_otp(struct ath10k *ar)
"boot get otp board id result 0x%08x board_id %d chip_id %d\n",
result, board_id, chip_id);
- if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0)
+ if ((result & ATH10K_BMI_BOARD_ID_STATUS_MASK) != 0 ||
+ (board_id == 0)) {
+ ath10k_warn(ar, "board id is not exist in otp, ignore it\n");
return -EOPNOTSUPP;
+ }
ar->id.bmi_ids_valid = true;
ar->id.bmi_board_id = board_id;
--
1.9.1
^ permalink raw reply related
* [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"
From: Colin King @ 2016-12-23 0:43 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, Kalle Valo,
Pieter-Paul Giesberts, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
brcmf_err error messages.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7ffc4ab..15eaf72 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3971,7 +3971,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
pval |= AES_ENABLED;
break;
default:
- brcmf_err("Ivalid unicast security info\n");
+ brcmf_err("Invalid unicast security info\n");
}
offset++;
}
@@ -4015,7 +4015,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
wpa_auth |= WPA2_AUTH_1X_SHA256;
break;
default:
- brcmf_err("Ivalid key mgmt info\n");
+ brcmf_err("Invalid key mgmt info\n");
}
offset++;
}
--
2.10.2
^ permalink raw reply related
* Re: ath10k mesh error 80MHz channel
From: Thiagarajan, Vasanthakumar @ 2016-12-23 5:18 UTC (permalink / raw)
To: Matteo Grandi, LinuxWireless Mailing List
In-Reply-To: <CAHdg3xb2TCo6-m36zvNS_SADPM+SxE4bg_aHRc+RBo3zOaGX=Q@mail.gmail.com>
T24gV2VkbmVzZGF5IDIxIERlY2VtYmVyIDIwMTYgMDg6NTEgUE0sIE1hdHRlbyBHcmFuZGkgd3Jv
dGU6DQo+IEhpIGFsbCBhZ2FpbiwganVzdCBhbiB1cGRhdGUgdG8gdGhlIHByZXZpb3VzIG1lc3Nh
Z2U6DQo+DQo+IGxvb2tpbmcgYXQgaXcgbGlzdCBJIGZvdW5kIHRoaXMgc2l0dWF0aW9uOg0KPg0K
PiAgICAgICAgICBGcmVxdWVuY2llczoNCj4gICAgICAgICAgICAgICogNTE4MCBNSHogWzM2XSAo
MjAuMCBkQm0pDQo+ICAgICAgICAgICAgICAqIDUyMDAgTUh6IFs0MF0gKDIwLjAgZEJtKQ0KPiAg
ICAgICAgICAgICAgKiA1MjIwIE1IeiBbNDRdICgyMC4wIGRCbSkNCj4gICAgICAgICAgICAgICog
NTI0MCBNSHogWzQ4XSAoMjAuMCBkQm0pDQo+ICAgICAgICAgICAgICAqIDUyNjAgTUh6IFs1Ml0g
KDIwLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTI4
MCBNSHogWzU2XSAoMjAuMCBkQm0pIChubyBJUiwgcmFkYXIgZGV0ZWN0aW9uKQ0KPiAgICAgICAg
ICAgICAgKiA1MzAwIE1IeiBbNjBdICgyMC4wIGRCbSkgKG5vIElSLCByYWRhciBkZXRlY3Rpb24p
DQo+ICAgICAgICAgICAgICAqIDUzMjAgTUh6IFs2NF0gKDIwLjAgZEJtKSAobm8gSVIsIHJhZGFy
IGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTUwMCBNSHogWzEwMF0gKDIzLjAgZEJtKSAo
bm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTUyMCBNSHogWzEwNF0g
KDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTU0
MCBNSHogWzEwOF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAg
ICAgICAgICogNTU2MCBNSHogWzExMl0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlv
bikNCj4gICAgICAgICAgICAgICogNTU4MCBNSHogWzExNl0gKDIzLjAgZEJtKSAobm8gSVIsIHJh
ZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTYwMCBNSHogWzEyMF0gKDIzLjAgZEJt
KSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTYyMCBNSHogWzEy
NF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICog
NTY0MCBNSHogWzEyOF0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAg
ICAgICAgICAgICogNTY2MCBNSHogWzEzMl0gKDIzLjAgZEJtKSAobm8gSVIsIHJhZGFyIGRldGVj
dGlvbikNCj4gICAgICAgICAgICAgICogNTY4MCBNSHogWzEzNl0gKDIzLjAgZEJtKSAobm8gSVIs
IHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTcwMCBNSHogWzE0MF0gKDIzLjAg
ZEJtKSAobm8gSVIsIHJhZGFyIGRldGVjdGlvbikNCj4gICAgICAgICAgICAgICogNTc0NSBNSHog
WzE0OV0gKGRpc2FibGVkKQ0KPiAgICAgICAgICAgICAgKiA1NzY1IE1IeiBbMTUzXSAoZGlzYWJs
ZWQpDQo+ICAgICAgICAgICAgICAqIDU3ODUgTUh6IFsxNTddIChkaXNhYmxlZCkNCj4gICAgICAg
ICAgICAgICogNTgwNSBNSHogWzE2MV0gKGRpc2FibGVkKQ0KPiAgICAgICAgICAgICAgKiA1ODI1
IE1IeiBbMTY1XSAoZGlzYWJsZWQpDQo+ICAgICAgU3VwcG9ydGVkIGNvbW1hbmRzOg0KPiAgICAg
ICAgICAgKiBuZXdfaW50ZXJmYWNlDQo+ICAgICAgICAgICAqIHNldF9pbnRlcmZhY2UNCj4gICAg
ICAgICAgICogbmV3X2tleQ0KPg0KPiBUaGUgbm8gSW5pdGlhbCBSYWRpYXRpb24gcHJldmVudCB0
aGUgaW50ZXJmYWNlIHRvIHN0YXJ0IHRyYW5zbWl0dGluZy4NCj4gSSdtIGFsbW9zdCBzdXJlIHRo
YXQgaXQncyBhIHJlZ3VsYXRvcnkgZG9tYWluIGlzc3VlLCBidXQgaSBhbHJlYWR5DQo+IHRyaWVk
IHRvIHJlaW5zdGFsbCB0aGUgQ1JEIEFnZW50LCBhbmQgZXZlbiBjaGFuZ2luZyB0aGUgcmVndWxh
dG9yeQ0KPiBkb21haW4gaXQgY2hhbmdlIG9ubHkgdGhlIGdsb2JhbCAoaS5lLiBDSCkgd2hpbGUg
dGhlIGl3IGxpc3QgcHJvdmlkZQ0KPiB0aGUgc2FtZSByZXN1bHRzLg0KPiByb290QE1yUHJvcGVy
On4jIGl3IHJlZyBnZXQNCj4gZ2xvYmFsDQo+IGNvdW50cnkgQ0g6IERGUy1FVFNJDQo+ICAgICAg
KDI0MDIgLSAyNDgyIEAgNDApLCAoTi9BLCAyMCksIChOL0EpDQo+ICAgICAgKDUxNzAgLSA1MjUw
IEAgODApLCAoTi9BLCAyMCksIChOL0EpLCBBVVRPLUJXDQo+ICAgICAgKDUyNTAgLSA1MzMwIEAg
ODApLCAoTi9BLCAyMCksICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+ICAgICAgKDU0OTAgLSA1NzEw
IEAgMTYwKSwgKE4vQSwgMjcpLCAoMCBtcyksIERGUw0KPiAgICAgICg1NzAwMCAtIDY2MDAwIEAg
MjE2MCksIChOL0EsIDQwKSwgKE4vQSkNCj4NCj4gcGh5IzENCj4gY291bnRyeSBVUzogREZTLUZD
Qw0KPiAgICAgICgyNDAyIC0gMjQ3MiBAIDQwKSwgKE4vQSwgMzApLCAoTi9BKQ0KPiAgICAgICg1
MTcwIC0gNTI1MCBAIDgwKSwgKE4vQSwgMjMpLCAoTi9BKSwgQVVUTy1CVw0KPiAgICAgICg1MjUw
IC0gNTMzMCBAIDgwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUywgQVVUTy1CVw0KPiAgICAgICg1
NDkwIC0gNTczMCBAIDE2MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMNCj4gICAgICAoNTczNSAt
IDU4MzUgQCA4MCksIChOL0EsIDMwKSwgKE4vQSkNCj4gICAgICAoNTcyNDAgLSA2MzcyMCBAIDIx
NjApLCAoTi9BLCA0MCksIChOL0EpDQo+DQo+IHBoeSMwDQo+IGNvdW50cnkgVVM6IERGUy1GQ0MN
Cj4gICAgICAoMjQwMiAtIDI0NzIgQCA0MCksIChOL0EsIDMwKSwgKE4vQSkNCj4gICAgICAoNTE3
MCAtIDUyNTAgQCA4MCksIChOL0EsIDIzKSwgKE4vQSksIEFVVE8tQlcNCj4gICAgICAoNTI1MCAt
IDUzMzAgQCA4MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMsIEFVVE8tQlcNCj4gICAgICAoNTQ5
MCAtIDU3MzAgQCAxNjApLCAoTi9BLCAyMyksICgwIG1zKSwgREZTDQo+ICAgICAgKDU3MzUgLSA1
ODM1IEAgODApLCAoTi9BLCAzMCksIChOL0EpDQo+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYw
KSwgKE4vQSwgNDApLCAoTi9BKQ0KPg0KPiBwaHkjMg0KPiBjb3VudHJ5IFVTOiBERlMtRkNDDQo+
ICAgICAgKDI0MDIgLSAyNDcyIEAgNDApLCAoTi9BLCAzMCksIChOL0EpDQo+ICAgICAgKDUxNzAg
LSA1MjUwIEAgODApLCAoTi9BLCAyMyksIChOL0EpLCBBVVRPLUJXDQo+ICAgICAgKDUyNTAgLSA1
MzMwIEAgODApLCAoTi9BLCAyMyksICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+ICAgICAgKDU0OTAg
LSA1NzMwIEAgMTYwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUw0KPiAgICAgICg1NzM1IC0gNTgz
NSBAIDgwKSwgKE4vQSwgMzApLCAoTi9BKQ0KPiAgICAgICg1NzI0MCAtIDYzNzIwIEAgMjE2MCks
IChOL0EsIDQwKSwgKE4vQSkNCj4NCj4gSXMgdGhlcmUgYSB3YXkgdG8gcmVtb3ZlIHRoZSBubyBJ
UiBmbGFncyBpbiB0aGUgYWxsb3dlZCBjaGFubmVscz8NCg0KDQpJIGFzc3VtZSB5b3UgYXJlIHRy
eWluZyB0byBicmluZyB1cCBtZXNoIG9uIG9uZSBvZiBERlMgY2hhbm5lbHMgd2hlcmUNCkNBQyBp
cyBtYW5kYXRvcnkgYmVmb3JlIHN0YXJ0aW5nIHRoZSBvcGVyYXRpb24uIFBlcmhhcHMgdHJ5IGNv
bXBsZXRpbmcNCkNBQyBvbiB0aGUgY2hhbm5lbCBhbmQgYnJpbmcgdXAgbWVzaC4NCg0KSWYgeW91
IHdhbnQgdG8gb3BlcmF0ZSBtZXNoIG5ldHdvcmsgb24gY2hhbm5lbCA1MiB3aXRoIDgwIE1oeiBi
YW5kd2lkdGgsDQp5b3UgbWF5IG5lZWQgdG8gcnVuIGNhYyBzb21ldGhpbmcgbGlrZSBiZWxvdyBm
cm9tIGl3IChhIHJlY2VudCBvbmUgd2hpY2ggaGFzDQpzdXBwb3J0IHRvIHRyaWdnZXIgQ0FDKS4N
Cg0Kc3VkbyBpdyB3bGFuWCBjYWMgdHJpZ2dlciBjaGFubmVsIDUyIDgwTUhaDQoNCg0KVmFzYW50
aA0KDQo+DQo+IDIwMTYtMTItMjEgMTU6MTkgR01UKzAxOjAwIE1hdHRlbyBHcmFuZGkgPGl1NWJk
cEBnbWFpbC5jb20+Og0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gSSdtIGNvbmZpZ3VyaW5nIGEgc2lt
cGxlIG1lc2ggbmV0d29yayB1c2luZyBmb3VyIG1pbmlQQ0llIGFkYXB0ZXJzDQo+PiAoQ29tcGV4
IFdMRTkwMFZYKSBvbiB0d28gR2F0ZXdvcmtzIFZlbnRhbmEgNTQxMCBib2FyZHMuDQo+PiBBY3R1
YWxseSwgYmFzZWQgb24gdGhlIGd1aWRlDQo+PiBodHRwczovL3dpcmVsZXNzLndpa2kua2VybmVs
Lm9yZy9lbi91c2Vycy9kcml2ZXJzL2F0aDEway9tZXNoDQo+PiBJIGRvbid0IGhhdmUgYW55IHBy
b2JsZW0gc2V0dGluZyB1cCB0aGUgbWVzaCBuZXR3b3JrIG9uIGNoYW5uZWxzIDM2LA0KPj4gMTQ5
LCAxNTMsIHJlc3BlY3RpdmVseSA1MTgwIDgwIDUyMTAsIDU3NDUgODAgNTc3NSwgYW5kIDU3NjUg
ODAgNTc5NQ0KPj4gKGV2ZW4gaWYgTUlNTyBpcyBub3Qgd29ya2luZykuDQo+Pg0KPj4gQnV0IHdo
aWxlIGNvbmZpZ3VyaW5nIHRoZSBpbnRlcmZhY2VzIHRvIHdvcmsgaW4gODBNSHogY2hhbm5lbA0K
Pj4gYmFuZHdpZHRoICg4MDIuMTFhYyB1c2luZyBhdGgxMGsgZHJpdmVyKSBvbiBhIGRpZmZlcmVu
dCBjaGFubmVsICBJDQo+PiBidW1wIGludG8gdGhlIGVycm9yOg0KPj4NCj4+IGNvbW1hbmQgZmFp
bGVkOiBJbnZhbGlkIGFyZ3VtZW50ICgtMjIpDQo+Pg0KPj4gaW1tZWRpYXRlbHkgYWZ0ZXIgbGF1
bmNoaW5nIHRoZSBjb21tYW5kICBmb3Igam9pbmluZyB0aGUgbWVzaDogaXcgZGV2DQo+PiA8aWZf
bmFtZT4gbWVzaCBqb2luIDxtZXNoX25hbWU+Lg0KPj4NCj4+IFRoZSBzeXNsb2cgcHJvdmlkZSBv
bmx5IHRoaXM6DQo+Pg0KPj4gRGVjIDIxIDEzOjUyOjAzIE1yUHJvcGVyIGtlcm5lbDogWyA3MjU3
LjA1ODYxN10gdXRpbC5jIHwNCj4+IGllZWU4MDIxMV9zZXRfd21tX2RlZmF1bHQ6IGFjPTAsIGVu
YWJsZV9xb3M9dHJ1ZSwgdmlmLnR5cGU9NywNCj4+IE5MODAyMTFfSUZUWVBFX1NUQVRJT049Mg0K
Pj4gRGVjIDIxIDEzOjUyOjAzIE1yUHJvcGVyIGtlcm5lbDogWyA3MjU3LjA1OTY1NF0gSVB2NjoN
Cj4+IEFERFJDT05GKE5FVERFVl9VUCk6IG1wcDE6IGxpbmsgaXMgbm90IHJlYWR5DQo+PiBEZWMg
MjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuMjA1OTExXSBhdGgxMGtfcGNpDQo+
PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykh
DQo+PiBEZWMgMjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuNTgxODk4XSBhdGgx
MGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jpbmcg
ZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDMgTXJQcm9wZXIga2VybmVsOiBbIDcyNTcuNjEz
NjI3XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsg
aWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQgTXJQcm9wZXIga2VybmVsOiBb
IDcyNTguMDg0NzMzXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29u
ZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQgTXJQcm9wZXIg
a2VybmVsOiBbIDcyNTguMTgwOTYzXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNo
YW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDQg
TXJQcm9wZXIga2VybmVsOiBbIDcyNTguMzI1MzgyXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAw
LjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEg
MTM6NTI6MDQgTXJQcm9wZXIga2VybmVsOiBbIDcyNTguNjYxNTM0XSBhdGgxMGtfcGNpDQo+PiAw
MDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+
PiBEZWMgMjEgMTM6NTI6MDUgTXJQcm9wZXIga2VybmVsOiBbIDcyNTkuMDI5NTI1XSBhdGgxMGtf
cGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJh
bWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDUgTXJQcm9wZXIga2VybmVsOiBbIDcyNTkuMzkyNTYz
XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdu
b3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDggTXJQcm9wZXIga2VybmVsOiBbIDcy
NjIuMzg2MTAxXSBhdGgxMGtfd2FybjogMTgNCj4+IGNhbGxiYWNrcyBzdXBwcmVzc2VkDQo+PiBE
ZWMgMjEgMTM6NTI6MDggTXJQcm9wZXIga2VybmVsOiBbIDcyNjIuMzg2MTU0XSBhdGgxMGtfcGNp
DQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUo
cykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjIuNzM3NTIwXSBh
dGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jp
bmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjIu
Nzg1NTk3XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJl
ZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVs
OiBbIDcyNjIuOTcxMTQ0XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwg
Y29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9w
ZXIga2VybmVsOiBbIDcyNjIuOTgxNDE0XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5v
IGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6
MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuMDkxNTc4XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3
OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMg
MjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNDQ1NjAzXSBhdGgxMGtfcGNpDQo+
PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykh
DQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNDU4NzI3XSBhdGgx
MGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdub3Jpbmcg
ZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBbIDcyNjMuNTgy
MTgwXSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsg
aWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MDkgTXJQcm9wZXIga2VybmVsOiBb
IDcyNjMuNTg5NjQ5XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29u
ZmlndXJlZDsgaWdub3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIg
a2VybmVsOiBbIDcyNjcuNzQyODM4XSBhdGgxMGtfd2FybjogNDQNCj4+IGNhbGxiYWNrcyBzdXBw
cmVzc2VkDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIga2VybmVsOiBbIDcyNjcuNzQyODg3
XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwgY29uZmlndXJlZDsgaWdu
b3JpbmcgZnJhbWUocykhDQo+PiBEZWMgMjEgMTM6NTI6MTQgTXJQcm9wZXIga2VybmVsOiBbIDcy
NjcuNzQ0NDY2XSBhdGgxMGtfcGNpDQo+PiAwMDAwOjA3OjAwLjA6IG5vIGNoYW5uZWwNCj4+DQo+
PiBEaWQgc29tZW9uZSBoYXZlIGEgc2ltaWxhciBpc3N1ZT8NCj4+IEFyZSB0aGVyZSwgbWF5YmUs
IHNvbWUgY2hhbm5lbHMgdGhhdCBldmVuIHByZXNlbnQgaW4gdGhlIHJlZ3VsYXRvcnkNCj4+IGRv
bWFpbiB3aXRoIHRoZSBAODAgZmxhZ3MgYXJlIG5vdCBjb25maWd1cmFibGUgaW4gdGhpcyB3YXk/
ICgzNiwgNTIsDQo+PiAxMDAsIDExNiwgMTMyLCAxNDkgc2hvdWxkIGJlIG9rLCBidXQgb25seSAz
NiBhbmQgMTQ5IHdvcmspDQo+PiBPciBtYXliZSBpdCdzIG15IHJlZy1kb21haW4gaXNzdWUgKHNl
ZSBiZWxvdyk/DQo+Pg0KPj4gcm9vdEBNclByb3Blcjp+IyBpdyByZWcgZ2V0DQo+PiBnbG9iYWwN
Cj4+IGNvdW50cnkgVVM6IERGUy1GQ0MNCj4+ICAgICAgKDI0MDIgLSAyNDcyIEAgNDApLCAoTi9B
LCAzMCksIChOL0EpDQo+PiAgICAgICg1MTcwIC0gNTI1MCBAIDgwKSwgKE4vQSwgMjMpLCAoTi9B
KSwgQVVUTy1CVw0KPj4gICAgICAoNTI1MCAtIDUzMzAgQCA4MCksIChOL0EsIDIzKSwgKDAgbXMp
LCBERlMsIEFVVE8tQlcNCj4+ICAgICAgKDU0OTAgLSA1NzMwIEAgMTYwKSwgKE4vQSwgMjMpLCAo
MCBtcyksIERGUw0KPj4gICAgICAoNTczNSAtIDU4MzUgQCA4MCksIChOL0EsIDMwKSwgKE4vQSkN
Cj4+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYwKSwgKE4vQSwgNDApLCAoTi9BKQ0KPj4NCj4+
IHBoeSMxDQo+PiBjb3VudHJ5IFVTOiBERlMtRkNDDQo+PiAgICAgICgyNDAyIC0gMjQ3MiBAIDQw
KSwgKE4vQSwgMzApLCAoTi9BKQ0KPj4gICAgICAoNTE3MCAtIDUyNTAgQCA4MCksIChOL0EsIDIz
KSwgKE4vQSksIEFVVE8tQlcNCj4+ICAgICAgKDUyNTAgLSA1MzMwIEAgODApLCAoTi9BLCAyMyks
ICgwIG1zKSwgREZTLCBBVVRPLUJXDQo+PiAgICAgICg1NDkwIC0gNTczMCBAIDE2MCksIChOL0Es
IDIzKSwgKDAgbXMpLCBERlMNCj4+ICAgICAgKDU3MzUgLSA1ODM1IEAgODApLCAoTi9BLCAzMCks
IChOL0EpDQo+PiAgICAgICg1NzI0MCAtIDYzNzIwIEAgMjE2MCksIChOL0EsIDQwKSwgKE4vQSkN
Cj4+DQo+PiBwaHkjMA0KPj4gY291bnRyeSBVUzogREZTLUZDQw0KPj4gICAgICAoMjQwMiAtIDI0
NzIgQCA0MCksIChOL0EsIDMwKSwgKE4vQSkNCj4+ICAgICAgKDUxNzAgLSA1MjUwIEAgODApLCAo
Ti9BLCAyMyksIChOL0EpLCBBVVRPLUJXDQo+PiAgICAgICg1MjUwIC0gNTMzMCBAIDgwKSwgKE4v
QSwgMjMpLCAoMCBtcyksIERGUywgQVVUTy1CVw0KPj4gICAgICAoNTQ5MCAtIDU3MzAgQCAxNjAp
LCAoTi9BLCAyMyksICgwIG1zKSwgREZTDQo+PiAgICAgICg1NzM1IC0gNTgzNSBAIDgwKSwgKE4v
QSwgMzApLCAoTi9BKQ0KPj4gICAgICAoNTcyNDAgLSA2MzcyMCBAIDIxNjApLCAoTi9BLCA0MCks
IChOL0EpDQo+Pg0KPj4gcGh5IzINCj4+IGNvdW50cnkgVVM6IERGUy1GQ0MNCj4+ICAgICAgKDI0
MDIgLSAyNDcyIEAgNDApLCAoTi9BLCAzMCksIChOL0EpDQo+PiAgICAgICg1MTcwIC0gNTI1MCBA
IDgwKSwgKE4vQSwgMjMpLCAoTi9BKSwgQVVUTy1CVw0KPj4gICAgICAoNTI1MCAtIDUzMzAgQCA4
MCksIChOL0EsIDIzKSwgKDAgbXMpLCBERlMsIEFVVE8tQlcNCj4+ICAgICAgKDU0OTAgLSA1NzMw
IEAgMTYwKSwgKE4vQSwgMjMpLCAoMCBtcyksIERGUw0KPj4gICAgICAoNTczNSAtIDU4MzUgQCA4
MCksIChOL0EsIDMwKSwgKE4vQSkNCj4+ICAgICAgKDU3MjQwIC0gNjM3MjAgQCAyMTYwKSwgKE4v
QSwgNDApLCAoTi9BKQ0KPj4NCj4+DQo+PiBUaGFua3MgYSBsb3QgZm9yIGV2ZXJ5IGhpbnQhDQo+
Pg0KPj4gTWF0dGVvDQo=
^ permalink raw reply
* [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: igor.mitsyanko.os @ 2016-12-23 15:12 UTC (permalink / raw)
To: linux-firmware
Cc: linux-wireless, Igor Mitsyanko, Kamlesh Rath, Sergey Matyukevich,
Avinash Patil, Igor Mitsyanko
In-Reply-To: <87d1hmnrqj.fsf@purkki.adurom.net>
From: Igor Mitsyanko <imitsyanko@quantenna.com>
QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
Signed-off-by: Kamlesh Rath <krath@quantenna.com>
Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
Signed-off-by: Avinash Patil <avinashp@quantenna.com>
Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
---
This is an RFC patch that we sent to linux-wireless mailing list a while ago,
and it spawned a discussion regarding whether GPL sources has to be submitted
together with this firmware. We would like to clarify with linux-firmware maintainers
to understnad what should be our actions to allow this to be accepted.
- firmware contains GPL components;
- LICENCE file states that sources for GPL components will be provided on request
to oslegal@quantenna.com
There was an opinion that it is not enough: precedent case like this with carl9170
firmware was resolved by submitting GPL sources into linux-firmware repository
itself.
Does the same applies to qsr10g firmware?
The SDK that we use to build it is quite heavy (> 100MB, but with toolchain).
Maybe we can take another approach to place SDK separately on Quantenna website
(as a compressed archive), and add a link in linux-firmware?
LICENCE.Quantenna_fmac | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
WHENCE | 9 ++++++
qtn/fmac_qsr10g.img | Bin 0 -> 9559676 bytes
3 files changed, 83 insertions(+)
create mode 100644 LICENCE.Quantenna_fmac
create mode 100644 qtn/fmac_qsr10g.img
diff --git a/LICENCE.Quantenna_fmac b/LICENCE.Quantenna_fmac
new file mode 100644
index 0000000..e6f9f72
--- /dev/null
+++ b/LICENCE.Quantenna_fmac
@@ -0,0 +1,74 @@
+Copyright (c) 2016, Quantenna, Inc.
+All rights reserved.
+
+Redistribution. Reproduction and redistribution in binary form, without
+modification, for use solely in conjunction with a Quantenna, Inc. chipset, is
+permitted provided that the following conditions are met:
+
+ - Redistributions must reproduce the above copyright notice and the
+ following disclaimer in the documentation and/or other materials provided
+ with the distribution.
+
+ - Neither the name of Quantenna, Inc. nor the names of its suppliers may be
+ used to endorse or promote products derived from this Software without
+ specific prior written permission.
+
+ - No reverse engineering, decompilation, or disassembly of this Software is
+ permitted, except and solely to the extent that such a restriction is
+ impermissible pursuant to applicable law or third party license.
+
+ - Your reproduction and distribution must comply with all applicable laws,
+ including without limitation all applicable U.S., European, and other
+ export laws.
+
+Limited Patent License. Subject to your compliance with all terms of this
+license, Quantenna, Inc. (“Licensor”) grants you (“Licensee”) a limited,
+worldwide, royalty-free, non-exclusive license under the Licensed Patents to
+make, have made, use, import, offer to sell and sell the Software solely in
+conjunction with a validly purchased Quantenna, Inc. chipset. No hardware
+per se is licensed hereunder.
+
+The term “Licensed Patents” as used in this agreement means only those patents
+or patent applications owned solely and exclusively by Licensor as of the date
+of Licensor’s submission of the Software that would necessarily be infringed by
+the operation of the Software, alone, or in combination with a supported
+version of the Linux operating system. The patent license shall not apply to
+any other combinations which include the Software. The term “Licensed Patents”
+expressly excludes any patent or patent application owned by any current or
+future affiliate of Quantenna, Inc. The term “Software” as used in this
+agreement means the unmodified firmware image submitted by Licensor, under the
+terms of this license, to
+git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git.
+
+Notwithstanding anything to the contrary herein, Licensor does not grant and
+Licensee does not receive, by virtue of this agreement or the Licensor’s
+submission of any Software, any license or other rights under any patent or
+patent application owned by any current or future affiliate of Licensor or any
+other entity (other than Licensor), whether expressly, impliedly, by virtue of
+estoppel or exhaustion, or otherwise. If Licensee has a separate agreement with
+Licensor covering use of the Software, then that separate agreement shall
+control.
+
+Open Source Software. The Software may include components that are licensed
+pursuant to open source software (“Open Source Components”). Information
+regarding the Open Source Components included with the Software is available
+upon request to oslegal@quantenna.com. To the extent such Open Source
+Components are required to be licensed to you under the terms of a separate
+license (such as an open source license) then such other terms shall apply, and
+nothing herein shall be deemed or interpreted to limit any rights you may have
+under any such applicable license.
+
+DISCLAIMER. THIS SOFTWARE (INCLUDING ANY APPLICABLE OPEN SOURCE COMPONENTS) IS
+PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
+IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFREINGEMENT ARE
+EXPRESSLY DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNERS, AUTHORS, OR
+CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
+IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
+OF SUCH DAMAGE, AND REGARDLESS OF ANY FAILURE OF ESSENTIAL PURPOSE OF ANY
+LIMITED REMEDY PROVIDED HEREIN.
+
diff --git a/WHENCE b/WHENCE
index 534c2da..78f6b73 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3347,3 +3347,12 @@ File: rockchip/dptx.bin
Version: 2.9
Licence: Redistributable. See LICENCE.rockchip for details.
+
+--------------------------------------------------------------------------
+
+Driver: qtnfmac - FullMAC driver for Quantenna QSR10G wireless card
+
+File: qtn/fmac_qsr10g.img
+
+Licence: Redistributable. See LICENCE.Quantenna_fmac for details.
+
diff --git a/qtn/fmac_qsr10g.img b/qtn/fmac_qsr10g.img
new file mode 100644
index 0000000..a65e6ec
Binary files /dev/null and b/qtn/fmac_qsr10g.img differ
--
2.7.4
^ permalink raw reply related
* Re: [RFC] qtn: add FullMAC firmware for Quantenna QSR10G wifi device
From: Christian Lamparter @ 2016-12-23 17:47 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: linux-firmware, linux-wireless, Igor Mitsyanko, Kamlesh Rath,
Sergey Matyukevich, Avinash Patil
In-Reply-To: <1482505955-9310-1-git-send-email-igor.mitsyanko.os@quantenna.com>
On Friday, December 23, 2016 6:12:35 PM CET igor.mitsyanko.os@quantenna.com wrote:
> From: Igor Mitsyanko <imitsyanko@quantenna.com>
>
> QSR10G is Quantenna's 8x8, 160M, 11ac WiFi card.
>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
> ---
> This is an RFC patch that we sent to linux-wireless mailing list a while ago,
> and it spawned a discussion regarding whether GPL sources has to be submitted
> together with this firmware. We would like to clarify with linux-firmware maintainers
> to understnad what should be our actions to allow this to be accepted.
> - firmware contains GPL components;
> - LICENCE file states that sources for GPL components will be provided on request
> to oslegal@quantenna.com
>
> There was an opinion that it is not enough: precedent case like this with carl9170
> firmware was resolved by submitting GPL sources into linux-firmware repository
> itself.
The ar9170-usb firmware was released as GPL v2.0 from the get-go.
<http://git.sipsolutions.net/ar9170-fw.git/commit/GPL?id=2e3574ce10c74a82047a06b046855de14d969948>
And this was never a problem. What is THE PROBLEM though:
"if all the patches from ar9170fw to carl9170fw and beyond (i.e new versions)
have to be added to linux-firmware.git." Or not.
That's why there was never a update to the carl9170fw.
So be prepared for this scenario too.
> Does the same applies to qsr10g firmware?
>
> The SDK that we use to build it is quite heavy (> 100MB, but with toolchain).
> Maybe we can take another approach to place SDK separately on Quantenna website
> (as a compressed archive), and add a link in linux-firmware?
Yes, I would like to know this as well.
Regards,
Christian
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix spelling mistakes on "Ivalid"
From: Arend Van Spriel @ 2016-12-23 19:38 UTC (permalink / raw)
To: Colin King, Franky Lin, Hante Meuleman, Kalle Valo,
Pieter-Paul Giesberts, Rafał Miłecki, linux-wireless,
brcm80211-dev-list.pdl, netdev
Cc: linux-kernel
In-Reply-To: <20161223004322.7300-1-colin.king@canonical.com>
On 23-12-2016 1:43, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fixes to spelling mistake "Ivalid" to "Invalid" in
> brcmf_err error messages.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> index 7ffc4ab..15eaf72 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -3971,7 +3971,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
> pval |= AES_ENABLED;
> break;
> default:
> - brcmf_err("Ivalid unicast security info\n");
> + brcmf_err("Invalid unicast security info\n");
> }
> offset++;
> }
> @@ -4015,7 +4015,7 @@ brcmf_configure_wpaie(struct brcmf_if *ifp,
> wpa_auth |= WPA2_AUTH_1X_SHA256;
> break;
> default:
> - brcmf_err("Ivalid key mgmt info\n");
> + brcmf_err("Invalid key mgmt info\n");
> }
> offset++;
> }
>
^ permalink raw reply
* Re: [PATCH v3 3/3] nfc: trf7970a: Prevent repeated polling from crashing the kernel
From: Mark Greer @ 2016-12-24 6:01 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin,
Jaret Cantu
In-Reply-To: <1482380314-16440-3-git-send-email-geoff@kuvee.com>
On Wed, Dec 21, 2016 at 11:18:34PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu <jaret.cantu@timesys.com>
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the state of the trf7970a is currently reading but
> another request has been made to send a command before it has finished.
>
> The solution is to properly kill the waiting reading (workqueue)
> before failing on the send.
>
> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
> ---
You've still provided virtually no information on the actual problem(s)
nor justified why you think this is the best solution. You're adding
code to a section of code that should _never_ be executed so the only
reasonable things I can infer is that there are, at least, two problems:
1) There is a bug causing execution to get into this block of code.
2) Once in this block of code, there is another bug.
You seem to be attempting to fix 2) and completely ignoring 1).
1) is the first bug that needs to be root-caused and fixed.
Also, what exactly is the "NULL dereference error" you mention?
Is this the neard crash you talked about in another thread or is
this a kernel crash? If it is the kernel crash, please post the
relevant information. If this is the neard crash - which seems
unlikely - then how can changing a section of kernel code that
shouldn't be executed in the first place fix that?
Mark
--
^ 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