* 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: 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 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: [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
* [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
* [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 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
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 23:01 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <601101482360611@web25o.yandex.ru>
My previous patch is invalid, I'm sorry.
The last patc will be fellow because "regulatory_request" is defined as a "static struct".
Signed-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/reg.c | 10 +++++-----
2 files changed, 2 insertions(+), 2 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);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 23:16 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <1482361572.28171.8.camel@tiscali.nl>
22.12.2016, 01:06, "Paul Bolle" <pebolle@tiscali.nl>:
> On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
>> I don't have a problem with C programming
>
> I'm sorry, but you do need to learn C, at a basic level, first.
Hmm, I don't like to discussion but I'm an assertive on C/C++.
So, I'm not into the Linux kernel, I writing code with C/C++ for many years.
I'm having trouble using Linux tools and trying to learn git/diff/format-patch/etc.
Also, I'm reading over 600 e-mails per day and I'm reading to Documentation (kernel). I learn :)
I don't have to problem with C, you can see my early codes and software (github).
I need to get a good sense of the coding style and Documentation.
And thank you.
Regards
> Paul Bolle
~Ozgur
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Paul Bolle @ 2016-12-21 23:06 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <601101482360611@web25o.yandex.ru>
On Thu, 2016-12-22 at 01:50 +0300, Ozgur Karatas wrote:
> I don't have a problem with C programming
I'm sorry, but you do need to learn C, at a basic level, first.
Paul Bolle
^ permalink raw reply
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:50 UTC (permalink / raw)
To: Paul Bolle, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <1482359625.28171.2.camel@tiscali.nl>
22.12.2016, 00:34, "Paul Bolle" <pebolle@tiscali.nl>:
> On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
>> I compiled and didn't to errors.
>
> Really?
I'm very sorry. The "regulatory_request" is defined a static struct. I missed.
line: static struct regulatory_request core_request_world = {
I send to wrong line please can ignore last message and should be fix to as follows:
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);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
> $ make net/wireless/reg.o
> CHK include/config/kernel.release
> CHK include/generated/uapi/linux/version.h
> CHK include/generated/utsrelease.h
> CHK include/generated/bounds.h
> CHK include/generated/timeconst.h
> CHK include/generated/asm-offsets.h
> CALL scripts/checksyscalls.sh
> CC net/wireless/reg.o
> 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);
> ^~~~~~~~~~~~~~~~~~
> scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
> make[1]: *** [net/wireless/reg.o] Error 1
> Makefile:1640: recipe for target 'net/wireless/reg.o' failed
> make: *** [net/wireless/reg.o] Error 2
$ make M=net/wireless/
CC net/wireless//core.o
CC net/wireless//sysfs.o
CC net/wireless//radiotap.o
CC net/wireless//util.o
CC net/wireless//reg.o
CC net/wireless//scan.o
CC net/wireless//nl80211.o
CC net/wireless//mlme.o
CC net/wireless//ibss.o
CC net/wireless//sme.o
CC net/wireless//chan.o
CC net/wireless//ethtool.o
CC net/wireless//mesh.o
CC net/wireless//ap.o
CC net/wireless//trace.o
CC net/wireless//ocb.o
LD net/wireless//cfg80211.o
LD net/wireless//built-in.o
Building modules, stage 2.
MODPOST 0 modules
$ make net/wireless/reg.o
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* Memory power savings
*
> Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
I don't have a problem with C programming, So only I'm learning the kernel.
Also, this is a lie if say "I'm expert to C".
I think be re-learned every day. wrong?
> Paul Bolle
Regards,
~ Ozgur
^ permalink raw reply related
* Re: [PATCH 2/2] net: wireless: fix to uses struct
From: Paul Bolle @ 2016-12-21 22:33 UTC (permalink / raw)
To: Ozgur Karatas, johannes, David Miller
Cc: Thomas Gleixner, linux-wireless, netdev, linux-kernel
In-Reply-To: <608881482358981@web17g.yandex.ru>
On Thu, 2016-12-22 at 00:23 +0200, Ozgur Karatas wrote:
> I compiled and didn't to errors.
Really?
$ make net/wireless/reg.o
CHK include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
CHK include/generated/bounds.h
CHK include/generated/timeconst.h
CHK include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC net/wireless/reg.o
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);
^~~~~~~~~~~~~~~~~~
scripts/Makefile.build:293: recipe for target 'net/wireless/reg.o' failed
make[1]: *** [net/wireless/reg.o] Error 1
Makefile:1640: recipe for target 'net/wireless/reg.o' failed
make: *** [net/wireless/reg.o] Error 2
Didn't Thomas Gleixner suggest that you do a basic C course just yesterday?
Paul Bolle
^ permalink raw reply
* [PATCH 2/2] net: wireless: fix to uses struct
From: Ozgur Karatas @ 2016-12-21 22:23 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
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.
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);
if (!request)
return -ENOMEM;
@@ -2291,7 +2291,7 @@ static int regulatory_hint_core(const char *alpha2)
{
struct regulatory_request *request;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2313,7 +2313,7 @@ int regulatory_hint_user(const char *alpha2,
if (WARN_ON(!alpha2))
return -EINVAL;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2385,7 +2385,7 @@ int regulatory_hint(struct wiphy *wiphy, const char *alpha2)
wiphy->regulatory_flags &= ~REGULATORY_CUSTOM_REG;
- request = kzalloc(sizeof(struct regulatory_request), GFP_KERNEL);
+ request = kzalloc(sizeof(*regulatory_request), GFP_KERNEL);
if (!request)
return -ENOMEM;
@@ -2661,7 +2661,7 @@ int regulatory_hint_found_beacon(struct wiphy *wiphy,
if (processing)
return 0;
- reg_beacon = kzalloc(sizeof(struct reg_beacon), gfp);
+ reg_beacon = kzalloc(sizeof(*reg_beacon), gfp);
if (!reg_beacon)
return -ENOMEM;
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] net: wireless: fixed to checkpatch errors
From: Ozgur Karatas @ 2016-12-21 22:13 UTC (permalink / raw)
To: johannes, David Miller; +Cc: linux-wireless, netdev, linux-kernel
Fixed to checkpatch errors, Normally, comment's */ had to be finish on the next line.
The patch fix to readability and Coding Style.
Sİgned-off-by: Ozgur Karatas <okaratas@member.fsf.org>
---
net/wireless/chan.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 5497d022..8c7ac7f 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -891,7 +891,8 @@ cfg80211_get_chan_state(struct wireless_dev *wdev,
: CHAN_MODE_EXCLUSIVE;
/* consider worst-case - IBSS can try to return to the
- * original user-specified channel as creator */
+ * original user-specified channel as creator
+ */
if (wdev->ibss_dfs_possible)
*radar_detect |= BIT(wdev->chandef.width);
return;
--
2.1.4
^ permalink raw reply related
* [PATCH] rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
From: Larry Finger @ 2016-12-21 17:18 UTC (permalink / raw)
To: kvalo, Linus Torvalds
Cc: devel, linux-wireless, Larry Finger, linux-kernel, driver-devel
These drivers need to be able to reference "struct ieee80211_hw" from
the driver's private data, and vice versa. The USB driver failed to
store the address of ieee80211_hw in the private data. Although this
bug has been present for a long time, it was not exposed until
commit ba9f93f82aba ("rtlwifi: Fix enter/exit power_save").
Fixes: ba9f93f82aba ("rtlwifi: Fix enter/exit power_save")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Kalle,
This patch needs to be included in 4.10.
Larry
---
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 40160c7..bf00399 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -1047,6 +1047,7 @@ int rtl_usb_probe(struct usb_interface *intf,
return -ENOMEM;
}
rtlpriv = hw->priv;
+ rtlpriv->hw = hw;
rtlpriv->usb_data = kzalloc(RTL_USB_MAX_RX_COUNT * sizeof(u32),
GFP_KERNEL);
if (!rtlpriv->usb_data)
--
2.10.2
^ permalink raw reply related
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Mark Greer @ 2016-12-21 16:13 UTC (permalink / raw)
To: Geoff Lansberry
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <32FAB08E-BE8E-4127-80A6-013300B43BD0@kuvee.com>
On Wed, Dec 21, 2016 at 06:47:36AM -0500, Geoff Lansberry wrote:
> Thanks Mark. Should I resubmit patches with the requested edits today, or wait a bit for more comments? What is the desired etiquette?
Its up to you. I don't think there are any hard & fast rules on this.
If it were me, I would likely spin a new version today because there are
several responses already and it lets people review them at their leisure
over the holidays.
Just a thought - you may want to consider separating the third patch from
the other two. The problems the first two solve are well understood and
have reasonable solutions (I believe). The third one - for me, at least -
tries to fix a problem that is not well understood yet.
Mark
--
^ permalink raw reply
* Re: ath10k mesh error 80MHz channel
From: Matteo Grandi @ 2016-12-21 15:21 UTC (permalink / raw)
To: LinuxWireless Mailing List
In-Reply-To: <CAHdg3xaR=KZBOisPSPtamRquce_wLPrCrXPm9Co5OWw5cOu0jw@mail.gmail.com>
Hi all again, just an update to the previous message:
looking at iw list I found this situation:
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
* 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
* 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
* 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
* 5500 MHz [100] (23.0 dBm) (no IR, radar detection)
* 5520 MHz [104] (23.0 dBm) (no IR, radar detection)
* 5540 MHz [108] (23.0 dBm) (no IR, radar detection)
* 5560 MHz [112] (23.0 dBm) (no IR, radar detection)
* 5580 MHz [116] (23.0 dBm) (no IR, radar detection)
* 5600 MHz [120] (23.0 dBm) (no IR, radar detection)
* 5620 MHz [124] (23.0 dBm) (no IR, radar detection)
* 5640 MHz [128] (23.0 dBm) (no IR, radar detection)
* 5660 MHz [132] (23.0 dBm) (no IR, radar detection)
* 5680 MHz [136] (23.0 dBm) (no IR, radar detection)
* 5700 MHz [140] (23.0 dBm) (no IR, radar detection)
* 5745 MHz [149] (disabled)
* 5765 MHz [153] (disabled)
* 5785 MHz [157] (disabled)
* 5805 MHz [161] (disabled)
* 5825 MHz [165] (disabled)
Supported commands:
* new_interface
* set_interface
* new_key
The no Initial Radiation prevent the interface to start transmitting.
I'm almost sure that it's a regulatory domain issue, but i already
tried to reinstall the CRD Agent, and even changing the regulatory
domain it change only the global (i.e. CH) while the iw list provide
the same results.
root@MrProper:~# iw reg get
global
country CH: DFS-ETSI
(2402 - 2482 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 20), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
(5490 - 5710 @ 160), (N/A, 27), (0 ms), DFS
(57000 - 66000 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#2
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
Is there a way to remove the no IR flags in the allowed channels?
Thanks a lot again
Matteo
2016-12-21 15:19 GMT+01:00 Matteo Grandi <iu5bdp@gmail.com>:
> Dear all,
>
> I'm configuring a simple mesh network using four miniPCIe adapters
> (Compex WLE900VX) on two Gateworks Ventana 5410 boards.
> Actually, based on the guide
> https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
> I don't have any problem setting up the mesh network on channels 36,
> 149, 153, respectively 5180 80 5210, 5745 80 5775, and 5765 80 5795
> (even if MIMO is not working).
>
> But while configuring the interfaces to work in 80MHz channel
> bandwidth (802.11ac using ath10k driver) on a different channel I
> bump into the error:
>
> command failed: Invalid argument (-22)
>
> immediately after launching the command for joining the mesh: iw dev
> <if_name> mesh join <mesh_name>.
>
> The syslog provide only this:
>
> Dec 21 13:52:03 MrProper kernel: [ 7257.058617] util.c |
> ieee80211_set_wmm_default: ac=0, enable_qos=true, vif.type=7,
> NL80211_IFTYPE_STATION=2
> Dec 21 13:52:03 MrProper kernel: [ 7257.059654] IPv6:
> ADDRCONF(NETDEV_UP): mpp1: link is not ready
> Dec 21 13:52:03 MrProper kernel: [ 7257.205911] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:03 MrProper kernel: [ 7257.581898] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:03 MrProper kernel: [ 7257.613627] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:04 MrProper kernel: [ 7258.084733] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:04 MrProper kernel: [ 7258.180963] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:04 MrProper kernel: [ 7258.325382] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:04 MrProper kernel: [ 7258.661534] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:05 MrProper kernel: [ 7259.029525] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:05 MrProper kernel: [ 7259.392563] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:08 MrProper kernel: [ 7262.386101] ath10k_warn: 18
> callbacks suppressed
> Dec 21 13:52:08 MrProper kernel: [ 7262.386154] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7262.737520] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7262.785597] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7262.971144] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7262.981414] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7263.091578] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7263.445603] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7263.458727] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7263.582180] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:09 MrProper kernel: [ 7263.589649] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:14 MrProper kernel: [ 7267.742838] ath10k_warn: 44
> callbacks suppressed
> Dec 21 13:52:14 MrProper kernel: [ 7267.742887] ath10k_pci
> 0000:07:00.0: no channel configured; ignoring frame(s)!
> Dec 21 13:52:14 MrProper kernel: [ 7267.744466] ath10k_pci
> 0000:07:00.0: no channel
>
> Did someone have a similar issue?
> Are there, maybe, some channels that even present in the regulatory
> domain with the @80 flags are not configurable in this way? (36, 52,
> 100, 116, 132, 149 should be ok, but only 36 and 149 work)
> Or maybe it's my reg-domain issue (see below)?
>
> root@MrProper:~# iw reg get
> global
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#1
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#0
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#2
> country US: DFS-FCC
> (2402 - 2472 @ 40), (N/A, 30), (N/A)
> (5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
> (5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
> (5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
> (5735 - 5835 @ 80), (N/A, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
>
> Thanks a lot for every hint!
>
> Matteo
^ permalink raw reply
* Re: rtlwifi: Fix kernel oops introduced with commit e49656147359
From: Kalle Valo @ 2016-12-21 14:35 UTC (permalink / raw)
To: Larry Finger
Cc: Linus Torvalds, devel, linux-wireless, Larry Finger, linux-kernel,
driver-devel, Stable, Wei Yongjun
In-Reply-To: <20161220023812.5999-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> With commit e49656147359 {"rtlwifi: Use dev_kfree_skb_irq instead of
> kfree_skb"), the method used to free an skb was changed because the
> kfree_skb() was inside a spinlock. What was forgotten is that kfree_skb()
> guards against a NULL value for the argument. Routine dev_kfree_skb_irq()
> does not, and a test is needed to prevent kernel panics.
>
> Fixes: e49656147359 ("rtlwifi: Use dev_kfree_skb_irq instead of kfree_skb")
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.9+
> Cc: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied to wireless-drivers.git, thanks.
22b68b93ae25 rtlwifi: Fix kernel oops introduced with commit e49656147359
--
https://patchwork.kernel.org/patch/9481055/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] ath9k: do not return early to fix rcu unlocking
From: Kalle Valo @ 2016-12-21 14:29 UTC (permalink / raw)
To: Tobias Klausmann
Cc: kvalo, helgaas, linux-kernel, linux-pci, marc.zyngier,
janusz.dziedzic, ath9k-devel, linux-wireless, rmanohar,
bharat.kumar.gogada, Tobias Klausmann, # v4 . 9
In-Reply-To: <20161213170807.4853-1-tobias.johannes.klausmann@mni.thm.de>
Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> wrote:
> Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
> where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
> returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
> and suspicious RCU usage:
>
> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.9.0-rc8 #11 Not tainted
> -------------------------------
> kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
>
> other info that might help us debug this:
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/7/0:
> #0:
> (
> rcu_read_lock
> ){......}
> , at:
> [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]
>
> stack backtrace:
> CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
> Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
> ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
> ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
> ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
> Call Trace:
> <IRQ>
> [<ffffffff8132b1e5>] dump_stack+0x68/0x93
> [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
> [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
> [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
> [<ffffffff81058631>] irq_exit+0x61/0xd0
> [<ffffffff81018d25>] do_IRQ+0x65/0x110
> [<ffffffff81672189>] common_interrupt+0x89/0x89
> <EOI>
> [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
> [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
> [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
> [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
> [<ffffffff810336f8>] start_secondary+0x148/0x170
>
> Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
> Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
> Cc: <stable@vger.kernel.org> # v4.9
> Acked-by: Felix Fietkau <nbd@nbd.name>
Patch applied to ath-current branch of ath.git, thanks.
d1f1c0e289e1 ath9k: do not return early to fix rcu unlocking
--
https://patchwork.kernel.org/patch/9472709/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* ath10k mesh error 80MHz channel
From: Matteo Grandi @ 2016-12-21 14:19 UTC (permalink / raw)
To: LinuxWireless Mailing List
Dear all,
I'm configuring a simple mesh network using four miniPCIe adapters
(Compex WLE900VX) on two Gateworks Ventana 5410 boards.
Actually, based on the guide
https://wireless.wiki.kernel.org/en/users/drivers/ath10k/mesh
I don't have any problem setting up the mesh network on channels 36,
149, 153, respectively 5180 80 5210, 5745 80 5775, and 5765 80 5795
(even if MIMO is not working).
But while configuring the interfaces to work in 80MHz channel
bandwidth (802.11ac using ath10k driver) on a different channel I
bump into the error:
command failed: Invalid argument (-22)
immediately after launching the command for joining the mesh: iw dev
<if_name> mesh join <mesh_name>.
The syslog provide only this:
Dec 21 13:52:03 MrProper kernel: [ 7257.058617] util.c |
ieee80211_set_wmm_default: ac=0, enable_qos=true, vif.type=7,
NL80211_IFTYPE_STATION=2
Dec 21 13:52:03 MrProper kernel: [ 7257.059654] IPv6:
ADDRCONF(NETDEV_UP): mpp1: link is not ready
Dec 21 13:52:03 MrProper kernel: [ 7257.205911] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:03 MrProper kernel: [ 7257.581898] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:03 MrProper kernel: [ 7257.613627] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:04 MrProper kernel: [ 7258.084733] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:04 MrProper kernel: [ 7258.180963] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:04 MrProper kernel: [ 7258.325382] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:04 MrProper kernel: [ 7258.661534] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:05 MrProper kernel: [ 7259.029525] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:05 MrProper kernel: [ 7259.392563] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:08 MrProper kernel: [ 7262.386101] ath10k_warn: 18
callbacks suppressed
Dec 21 13:52:08 MrProper kernel: [ 7262.386154] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7262.737520] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7262.785597] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7262.971144] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7262.981414] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7263.091578] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7263.445603] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7263.458727] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7263.582180] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:09 MrProper kernel: [ 7263.589649] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:14 MrProper kernel: [ 7267.742838] ath10k_warn: 44
callbacks suppressed
Dec 21 13:52:14 MrProper kernel: [ 7267.742887] ath10k_pci
0000:07:00.0: no channel configured; ignoring frame(s)!
Dec 21 13:52:14 MrProper kernel: [ 7267.744466] ath10k_pci
0000:07:00.0: no channel
Did someone have a similar issue?
Are there, maybe, some channels that even present in the regulatory
domain with the @80 flags are not configurable in this way? (36, 52,
100, 116, 132, 149 should be ok, but only 36 and 149 work)
Or maybe it's my reg-domain issue (see below)?
root@MrProper:~# iw reg get
global
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#0
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
phy#2
country US: DFS-FCC
(2402 - 2472 @ 40), (N/A, 30), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5735 - 5835 @ 80), (N/A, 30), (N/A)
(57240 - 63720 @ 2160), (N/A, 40), (N/A)
Thanks a lot for every hint!
Matteo
^ permalink raw reply
* [PATCH] ath10k: support dev_coredump for crash dump
From: Kalle Valo @ 2016-12-21 12:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
From: Arun Khandavalli <akhandav@qti.qualcomm.com>
Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
devcoredump device. Dump can be read from userspace for further analysis from:
/sys/class/devcoredump/devcd*/data
As until now we have provided the firmware crash dump file via fw_crash_dump
debugfs keep it still available but deprecate and a warning print that the user
should switch to using dev_coredump.
Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
might be systems which want to get the firmware crash dump but not enable
debugfs. How to handle memory consumption is also something which needs to be
taken into account.
Signed-off-by: Arun Khandavalli <akhandav@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: rebase, fixes, improve commit log]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 6 ++++
drivers/net/wireless/ath/ath10k/debug.c | 43 +++++++++++++++++++++++++++++--
drivers/net/wireless/ath/ath10k/debug.h | 8 ++++++
3 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 749e381edd38..3319db178c2e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1510,6 +1510,7 @@ static int ath10k_init_hw_params(struct ath10k *ar)
static void ath10k_core_restart(struct work_struct *work)
{
struct ath10k *ar = container_of(work, struct ath10k, restart_work);
+ int ret;
set_bit(ATH10K_FLAG_CRASH_FLUSH, &ar->dev_flags);
@@ -1561,6 +1562,11 @@ static void ath10k_core_restart(struct work_struct *work)
}
mutex_unlock(&ar->conf_mutex);
+
+ ret = ath10k_debug_fw_devcoredump(ar);
+ if (ret)
+ ath10k_warn(ar, "failed to send firmware crash dump via devcoredump: %d",
+ ret);
}
static void ath10k_core_set_coverage_class_work(struct work_struct *work)
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index 82a4c67f3672..e1a70dffc52a 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -21,6 +21,7 @@
#include <linux/utsname.h>
#include <linux/crc32.h>
#include <linux/firmware.h>
+#include <linux/devcoredump.h>
#include "core.h"
#include "debug.h"
@@ -721,7 +722,8 @@ struct ath10k_fw_crash_data *
}
EXPORT_SYMBOL(ath10k_debug_get_new_fw_crash_data);
-static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
+static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar,
+ bool mark_read)
{
struct ath10k_fw_crash_data *crash_data = ar->debug.fw_crash_data;
struct ath10k_dump_file_data *dump_data;
@@ -790,19 +792,54 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar)
sizeof(crash_data->registers));
sofar += sizeof(*dump_tlv) + sizeof(crash_data->registers);
- ar->debug.fw_crash_data->crashed_since_read = false;
+ ar->debug.fw_crash_data->crashed_since_read = !mark_read;
spin_unlock_bh(&ar->data_lock);
return dump_data;
}
+int ath10k_debug_fw_devcoredump(struct ath10k *ar)
+{
+ struct ath10k_dump_file_data *dump;
+ void *dump_ptr;
+ u32 dump_len;
+
+ /* To keep the dump file available also for debugfs don't mark the
+ * file read, only debugfs should do that.
+ */
+ dump = ath10k_build_dump_file(ar, false);
+ if (!dump) {
+ ath10k_warn(ar, "no crash dump data found for devcoredump");
+ return -ENODATA;
+ }
+
+ /* Make a copy of the dump file for dev_coredumpv() as during the
+ * transition period we need to own the original file. Once
+ * fw_crash_dump debugfs file is removed no need to have a copy
+ * anymore.
+ */
+ dump_len = le32_to_cpu(dump->len);
+ dump_ptr = vzalloc(dump_len);
+
+ if (!dump_ptr)
+ return -ENOMEM;
+
+ memcpy(dump_ptr, dump, dump_len);
+
+ dev_coredumpv(ar->dev, dump_ptr, dump_len, GFP_KERNEL);
+
+ return 0;
+}
+
static int ath10k_fw_crash_dump_open(struct inode *inode, struct file *file)
{
struct ath10k *ar = inode->i_private;
struct ath10k_dump_file_data *dump;
- dump = ath10k_build_dump_file(ar);
+ ath10k_warn(ar, "fw_crash_dump debugfs file is deprecated, please use /sys/class/devcoredump instead.");
+
+ dump = ath10k_build_dump_file(ar, true);
if (!dump)
return -ENODATA;
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 335512b11ca2..2368f47314ae 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -84,6 +84,9 @@ struct ath10k_fw_crash_data *
ath10k_debug_get_new_fw_crash_data(struct ath10k *ar);
void ath10k_debug_dbglog_add(struct ath10k *ar, u8 *buffer, int len);
+
+int ath10k_debug_fw_devcoredump(struct ath10k *ar);
+
#define ATH10K_DFS_STAT_INC(ar, c) (ar->debug.dfs_stats.c++)
void ath10k_debug_get_et_strings(struct ieee80211_hw *hw,
@@ -166,6 +169,11 @@ static inline u32 ath10k_debug_get_fw_dbglog_level(struct ath10k *ar)
return 0;
}
+static inline int ath10k_debug_fw_devcoredump(struct ath10k *ar)
+{
+ return 0;
+}
+
#define ATH10K_DFS_STAT_INC(ar, c) do { } while (0)
#define ath10k_debug_get_et_strings NULL
^ permalink raw reply related
* skb truesize bug related to ath10k
From: Ben Greear @ 2016-12-21 12:10 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
This warning is from the code below. Anyone seen this recently?
And, what sorts of code problems can generate this type of error? We
seem to have a way to reproduce this by bringing down and up many
station vdevs over and over again, so I can probably fix/test it if I
can understand the problem better.
We see this on QCA 9880 and 9984 NICs, so it is probably not firmware
specific issue. We have not seen this on 4.4 kernel, but we do see it
in our 4.7.
} else {
if (skb_shinfo(to)->nr_frags +
skb_shinfo(from)->nr_frags > MAX_SKB_FRAGS)
return false;
delta = from->truesize - SKB_TRUESIZE(skb_end_offset(from));
}
WARN_ON_ONCE(delta < len);
Dec 18 22:40:36 ct524-9933 kernel: WARNING: CPU: 7 PID: 0 at /home/greearb/git/linux-4.7.dev.y/net/core/skbuff.c:4283 skb_try_coalesce+0x402/0x410
Dec 18 22:40:36 ct524-9933 kernel: Modules linked in: nf_conntrack_netlink nf_conntrack nfnetlink wanlink(O) nf_defrag_ipv4 macvlan pktgen fuse vfat fat
coretemp intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm irqbypass ath10k_pci ath10k_core ath mac80211 iTCO_wdt iTCO_vendor_support ipmi_ssif
cfg80211 hci_uart joydev i2c_i801 btbcm btqca btintel ie31200_edac bluetooth edac_core shpchp acpi_als tpm_tis kfifo_buf pinctrl_sunrisepoint intel_lpss_acpi
ipmi_msghandler tpm industrialio video pinctrl_intel intel_lpss acpi_power_meter sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc 8021q garp stp llc mrp
ast drm_kms_helper ttm drm igb i2c_algo_bit ixgbe mdio hwmon dca ptp pps_core i2c_hid i2c_core fjes efivarfs ipv6 [last unloaded: nfnetlink]
Dec 18 22:40:36 ct524-9933 kernel: CPU: 7 PID: 0 Comm: swapper/7 Tainted: G O 4.7.10+ #46
Dec 18 22:40:36 ct524-9933 kernel: Hardware name: Supermicro Super Server/X11SSM, BIOS 1.0b 12/29/2015
Dec 18 22:40:36 ct524-9933 kernel: 0000000000000000 ffff8804779c3688 ffffffff81409351 0000000000000000
Dec 18 22:40:36 ct524-9933 kernel: 0000000000000000 ffff8804779c36c8 ffffffff81103976 000010bb779c36a8
Dec 18 22:40:36 ct524-9933 kernel: ffff88007ce1f800 00000000000005a8 ffff8804779c3724 ffff880075b85000
Dec 18 22:40:36 ct524-9933 kernel: Call Trace:
Dec 18 22:40:36 ct524-9933 kernel: <IRQ> [<ffffffff81409351>] dump_stack+0x63/0x82
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81103976>] __warn+0xc6/0xe0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81103a48>] warn_slowpath_null+0x18/0x20
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81760c62>] skb_try_coalesce+0x402/0x410
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817c7b79>] tcp_try_coalesce+0x39/0xa0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81761671>] ? skb_checksum+0x21/0x30
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817c8322>] tcp_queue_rcv+0x52/0x140
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817cee84>] tcp_rcv_established+0x364/0x6f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817d9286>] tcp_v4_do_rcv+0x136/0x210
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817dab49>] tcp_v4_rcv+0x8d9/0xaf0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8180a7f2>] ? iptable_filter_hook+0x22/0x60
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4bdb>] ip_local_deliver_finish+0x9b/0x1f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4edb>] ip_local_deliver+0x5b/0xd0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4b40>] ? ip_rcv_finish+0x3f0/0x3f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b486a>] ip_rcv_finish+0x11a/0x3f0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b51af>] ip_rcv+0x25f/0x380
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817b4750>] ? inet_del_offload+0x40/0x40
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81773cb4>] __netif_receive_skb_core+0x684/0xa80
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8124925a>] ? kmem_cache_free+0x17a/0x180
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817740c3>] __netif_receive_skb+0x13/0x60
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81774133>] netif_receive_skb_internal+0x23/0x90
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff817741b7>] netif_receive_skb+0x17/0x80
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a08d07>] ieee80211_deliver_skb+0x157/0x1b0 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0ad9a>] ieee80211_rx_handlers+0xa8a/0x2560 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8155717a>] ? dma_pte_clear_level+0x14a/0x190
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0d077>] ieee80211_prepare_and_rx_handle+0x597/0x10a0 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0a0ddfa>] ieee80211_rx_napi+0x27a/0x930 [mac80211]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c179cc>] ath10k_process_rx+0x2ac/0x4a0 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c17bf5>] ath10k_htt_rx_h_deliver+0x35/0x80 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffffa0c1a421>] ath10k_htt_txrx_compl_task+0xc91/0xe60 [ath10k_core]
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81108afb>] tasklet_action+0x10b/0x120
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81108eca>] __do_softirq+0xca/0x2b0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff811091e9>] irq_exit+0x89/0x90
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8102e69f>] do_IRQ+0x4f/0xd0
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8184db42>] common_interrupt+0x82/0x82
Dec 18 22:40:36 ct524-9933 kernel: <EOI> [<ffffffff816e8020>] ? cpuidle_enter_state+0x110/0x290
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff816e81c2>] cpuidle_enter+0x12/0x20
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81144bb5>] call_cpuidle+0x25/0x40
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff81144f72>] cpu_startup_entry+0x2b2/0x370
Dec 18 22:40:36 ct524-9933 kernel: [<ffffffff8104d8cd>] start_secondary+0x14d/0x170
Dec 18 22:40:36 ct524-9933 kernel: ---[ end trace fa9eabf037886c79 ]---
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 2/3] NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
From: Geoff Lansberry @ 2016-12-21 11:47 UTC (permalink / raw)
To: Mark Greer
Cc: linux-wireless, lauro.venancio, aloisio.almeida, sameo, robh+dt,
mark.rutland, netdev, devicetree, linux-kernel, justin
In-Reply-To: <20161221022347.GB5444@animalcreek.com>
Thanks Mark. Should I resubmit patches with the requested edits today, or w=
ait a bit for more comments? What is the desired etiquette?
> On Dec 20, 2016, at 9:23 PM, Mark Greer <mgreer@animalcreek.com> wrote:
>=20
>> On Tue, Dec 20, 2016 at 11:16:31AM -0500, Geoff Lansberry wrote:
>> From: Geoff Lansberry <geoff@kuvee.com>
>>=20
>> 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.
>=20
> Sign-off ?? Same comment for you other patches.
>=20
> <time passes>
>=20
> Okay I see you have it at the end of the patch. It should be here.
> 'git commit -s' is your friend.
>=20
>> ---
>> .../devicetree/bindings/net/nfc/trf7970a.txt | 4 ++--
>> drivers/nfc/trf7970a.c | 28 +++++++++++++++++=
++++-
>> 2 files changed, 29 insertions(+), 3 deletions(-)
>>=20
>> diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Doc=
umentation/devicetree/bindings/net/nfc/trf7970a.txt
>> index e262ac1..b5777d8 100644
>> --- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
>> @@ -21,9 +21,9 @@ 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 trf7970=
a is 13560000Hz or 27120000Hz
>>=20
>> -
>> Example (for ARM-based BeagleBone with TRF7970A on SPI1):
>>=20
>> &spi1 {
>> @@ -41,11 +41,11 @@ Example (for ARM-based BeagleBone with TRF7970A on SP=
I1):
>> <&gpio2 5 GPIO_ACTIVE_LOW>;
>> vin-supply =3D <&ldo3_reg>;
>> vin-voltage-override =3D <5000000>;
>> + vdd-io-supply =3D <&ldo2_reg>;
>> autosuspend-delay =3D <30000>;
>> irq-status-read-quirk;
>> en2-rf-quirk;
>> t5t-rmb-extra-byte-quirk;
>> - vdd_io_1v8;
>=20
> It was already mentioned but this shouldn't have been added in the
> previous patch so it shouldn't be here now.
>=20
>> clock-frequency =3D <27120000>;
>> status =3D "okay";
>> };
>> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
>> index 4e051e9..8a88195 100644
>> --- a/drivers/nfc/trf7970a.c
>> +++ b/drivers/nfc/trf7970a.c
>=20
>> @@ -2062,6 +2068,7 @@ static int trf7970a_probe(struct spi_device *spi)
>> return ret;
>> }
>>=20
>> +
>=20
> Please don't add an extra blank line.
>=20
>> of_property_read_u32(np, "clock-frequency", &clk_freq);
>> if ((clk_freq !=3D TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
>> (clk_freq !=3D TRF7970A_27MHZ_CLOCK_FREQUENCY)) {
>> @@ -2105,6 +2112,25 @@ static int trf7970a_probe(struct spi_device *spi)
>> if (uvolts > 4000000)
>> trf->chip_status_ctrl =3D TRF7970A_CHIP_STATUS_VRS5_3;
>>=20
>> + trf->regulator =3D devm_regulator_get(&spi->dev, "vdd-io");
>> + if (IS_ERR(trf->regulator)) {
>> + ret =3D PTR_ERR(trf->regulator);
>> + dev_err(trf->dev, "Can't get VDD_IO regulator: %d\n", ret);
>> + goto err_destroy_lock;
>> + }
>> +
>> + ret =3D regulator_enable(trf->regulator);
>> + if (ret) {
>> + dev_err(trf->dev, "Can't enable VDD_IO: %d\n", ret);
>> + goto err_destroy_lock;
>> + }
>> +
>> +
>=20
> Please don't add an extra blank line.
>=20
>> + if (regulator_get_voltage(trf->regulator) =3D=3D 1800000) {
>> + trf->io_ctrl =3D TRF7970A_REG_IO_CTRL_IO_LOW;
>> + dev_dbg(trf->dev, "trf7970a config vdd_io to 1.8V\n");
>> + }
>> +
>> trf->ddev =3D nfc_digital_allocate_device(&trf7970a_nfc_ops,
>> TRF7970A_SUPPORTED_PROTOCOLS,
>> NFC_DIGITAL_DRV_CAPS_IN_CRC |
>> --=20
>> Signed-off-by: Geoff Lansberry <geoff@kuvee.com>
>=20
> Your 'Signed-off-by:' goes at the end of the commit description not here.
>=20
> Overall, I think you did the right thing (unless someone disagrees).
> Just some minor issues.
>=20
> Mark
> --
^ permalink raw reply
* [RFC] nl80211: allow multiple active scheduled scan requests
From: Arend van Spriel @ 2016-12-21 10:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel, Dmitry Shmidt
In-Reply-To: <1481645071.20412.30.camel@sipsolutions.net>
This patch implements the idea to have multiple scheduled scan requests
running concurrently. It mainly illustrates how to deal with the incoming
request from user-space in terms of backward compatibility. In order to
use multiple scheduled scans user-space needs to provide a flag attribute
NL80211_ATTR_SCHED_SCAN_MULTI to indicate support. If not the request is
treated as a legacy scan.
Cc: Dmitry Shmidt <dimitrysh@google.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
Hi Johannes,
Did a bit of coding on the Universal/multi-scheduled scan idea. This
just deals with handling requests. Not sure if I got the RCU stuff
right so any remarks are welcome.
Regards,
Arend
---
include/net/cfg80211.h | 7 ++++
include/uapi/linux/nl80211.h | 12 ++++++-
net/wireless/core.c | 30 ++++++++++------
net/wireless/core.h | 10 +++++-
net/wireless/nl80211.c | 38 ++++++++++++++++++--
net/wireless/scan.c | 83 +++++++++++++++++++++++++++++++++++---------
6 files changed, 148 insertions(+), 32 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 814be4b..f5c0592 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1594,6 +1594,7 @@ struct cfg80211_sched_scan_plan {
/**
* struct cfg80211_sched_scan_request - scheduled scan request description
*
+ * @reqid: identifies this request.
* @ssids: SSIDs to scan for (passed in the probe_reqs in active scans)
* @n_ssids: number of SSIDs
* @n_channels: total number of channels to scan
@@ -1622,12 +1623,14 @@ struct cfg80211_sched_scan_plan {
* @rcu_head: RCU callback used to free the struct
* @owner_nlportid: netlink portid of owner (if this should is a request
* owned by a particular socket)
+ * @list: for keeping list of requests.
* @delay: delay in seconds to use before starting the first scan
* cycle. The driver may ignore this parameter and start
* immediately (or at any other time), if this feature is not
* supported.
*/
struct cfg80211_sched_scan_request {
+ u64 reqid;
struct cfg80211_ssid *ssids;
int n_ssids;
u32 n_channels;
@@ -1651,6 +1654,7 @@ struct cfg80211_sched_scan_request {
unsigned long scan_start;
struct rcu_head rcu_head;
u32 owner_nlportid;
+ struct list_head list;
/* keep last */
struct ieee80211_channel *channels[0];
@@ -3415,6 +3419,8 @@ struct wiphy_iftype_ext_capab {
* this variable determines its size
* @max_scan_ssids: maximum number of SSIDs the device can scan for in
* any given scan
+ * @max_sched_scan_reqs: maximum number of scheduled scan requests that
+ * the device can run concurrently.
* @max_sched_scan_ssids: maximum number of SSIDs the device can scan
* for in any given scheduled scan
* @max_match_sets: maximum number of match sets the device can handle
@@ -3547,6 +3553,7 @@ struct wiphy {
int bss_priv_size;
u8 max_scan_ssids;
+ u8 max_sched_scan_reqs;
u8 max_sched_scan_ssids;
u8 max_match_sets;
u16 max_scan_ie_len;
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 6b76e3b..4045058 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -351,7 +351,9 @@
* are used. Extra IEs can also be passed from the userspace by
* using the %NL80211_ATTR_IE attribute. The first cycle of the
* scheduled scan can be delayed by %NL80211_ATTR_SCHED_SCAN_DELAY
- * is supplied.
+ * is supplied. If the device supports multiple concurrent scheduled
+ * scans, it will allow such when the caller provides the flag attribute
+ * %NL80211_ATTR_SCHED_SCAN_MULTI to indicate user-space support for it.
* @NL80211_CMD_STOP_SCHED_SCAN: stop a scheduled scan. Returns -ENOENT if
* scheduled scan is not running. The caller may assume that as soon
* as the call returns, it is safe to start a new scheduled scan again.
@@ -1980,6 +1982,11 @@ enum nl80211_commands {
* @NL80211_ATTR_BSSID: The BSSID of the AP. Note that %NL80211_ATTR_MAC is also
* used in various commands/events for specifying the BSSID.
*
+ * @NL80211_ATTR_SCHED_SCAN_MULTI: flag attribute which user-space shall use to
+ * indicate that it supports multiple active scheduled scan requests.
+ * @NL80211_ATTR_SCHED_SCAN_MAX_REQS: indicates maximum number of scheduled
+ * scan request that may be active for the device (u8).
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -2386,6 +2393,9 @@ enum nl80211_attrs {
NL80211_ATTR_BSSID,
+ NL80211_ATTR_SCHED_SCAN_MULTI,
+ NL80211_ATTR_SCHED_SCAN_MAX_REQS,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 158c59e..1584234 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -346,13 +346,17 @@ static void cfg80211_destroy_iface_wk(struct work_struct *work)
static void cfg80211_sched_scan_stop_wk(struct work_struct *work)
{
struct cfg80211_registered_device *rdev;
+ struct cfg80211_sched_scan_request *pos, *tmp;
rdev = container_of(work, struct cfg80211_registered_device,
sched_scan_stop_wk);
rtnl_lock();
- __cfg80211_stop_sched_scan(rdev, false);
+ /* request gets removed from list so need safe iterator */
+ list_for_each_entry_safe(pos, tmp, &rdev->sched_scan_req_list, list) {
+ cfg80211_stop_sched_scan_req(rdev, pos, false);
+ }
rtnl_unlock();
}
@@ -436,6 +440,7 @@ struct wiphy *wiphy_new_nm(const struct cfg80211_ops *ops, int sizeof_priv,
spin_lock_init(&rdev->beacon_registrations_lock);
spin_lock_init(&rdev->bss_lock);
INIT_LIST_HEAD(&rdev->bss_list);
+ INIT_LIST_HEAD(&rdev->sched_scan_req_list);
INIT_WORK(&rdev->scan_done_wk, __cfg80211_scan_done);
INIT_WORK(&rdev->sched_scan_results_wk, __cfg80211_sched_scan_results);
INIT_LIST_HEAD(&rdev->mlme_unreg);
@@ -690,6 +695,10 @@ int wiphy_register(struct wiphy *wiphy)
(wiphy->bss_select_support & ~(BIT(__NL80211_BSS_SELECT_ATTR_AFTER_LAST) - 2))))
return -EINVAL;
+ if ((wiphy->flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN) &&
+ !wiphy->max_sched_scan_reqs)
+ wiphy->max_sched_scan_reqs = 1;
+
if (wiphy->addresses)
memcpy(wiphy->perm_addr, wiphy->addresses[0].addr, ETH_ALEN);
@@ -1000,7 +1009,7 @@ void __cfg80211_leave(struct cfg80211_registered_device *rdev,
struct wireless_dev *wdev)
{
struct net_device *dev = wdev->netdev;
- struct cfg80211_sched_scan_request *sched_scan_req;
+ struct cfg80211_sched_scan_request *pos, *tmp;
ASSERT_RTNL();
ASSERT_WDEV_LOCK(wdev);
@@ -1011,9 +1020,10 @@ void __cfg80211_leave(struct cfg80211_registered_device *rdev,
break;
case NL80211_IFTYPE_P2P_CLIENT:
case NL80211_IFTYPE_STATION:
- sched_scan_req = rtnl_dereference(rdev->sched_scan_req);
- if (sched_scan_req && dev == sched_scan_req->dev)
- __cfg80211_stop_sched_scan(rdev, false);
+ list_for_each_entry_safe(pos, tmp, &rdev->sched_scan_req_list, list) {
+ if (dev == pos->dev)
+ cfg80211_stop_sched_scan_req(rdev, pos, false);
+ }
#ifdef CONFIG_CFG80211_WEXT
kfree(wdev->wext.ie);
@@ -1088,7 +1098,7 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
struct net_device *dev = netdev_notifier_info_to_dev(ptr);
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct cfg80211_registered_device *rdev;
- struct cfg80211_sched_scan_request *sched_scan_req;
+ struct cfg80211_sched_scan_request *pos, *tmp;
if (!wdev)
return NOTIFY_DONE;
@@ -1155,10 +1165,10 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
___cfg80211_scan_done(rdev, false);
}
- sched_scan_req = rtnl_dereference(rdev->sched_scan_req);
- if (WARN_ON(sched_scan_req &&
- sched_scan_req->dev == wdev->netdev)) {
- __cfg80211_stop_sched_scan(rdev, false);
+ list_for_each_entry_safe(pos, tmp,
+ &rdev->sched_scan_req_list, list) {
+ if (WARN_ON(pos && pos->dev == wdev->netdev))
+ cfg80211_stop_sched_scan_req(rdev, pos, false);
}
rdev->opencount--;
diff --git a/net/wireless/core.h b/net/wireless/core.h
index 9820fa2..951954b 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -73,6 +73,8 @@ struct cfg80211_registered_device {
u32 bss_generation;
struct cfg80211_scan_request *scan_req; /* protected by RTNL */
struct sk_buff *scan_msg;
+ u8 sched_scan_req_count;
+ struct list_head sched_scan_req_list;
struct cfg80211_sched_scan_request __rcu *sched_scan_req;
unsigned long suspend_at;
struct work_struct scan_done_wk;
@@ -419,9 +421,15 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
void __cfg80211_scan_done(struct work_struct *wk);
void ___cfg80211_scan_done(struct cfg80211_registered_device *rdev,
bool send_message);
+void cfg80211_add_sched_scan_req(struct cfg80211_registered_device *rdev,
+ struct cfg80211_sched_scan_request *req);
+bool cfg80211_legacy_sched_scan_active(struct cfg80211_registered_device *rdev);
void __cfg80211_sched_scan_results(struct work_struct *wk);
+int cfg80211_stop_sched_scan_req(struct cfg80211_registered_device *rdev,
+ struct cfg80211_sched_scan_request *req,
+ bool driver_initiated);
int __cfg80211_stop_sched_scan(struct cfg80211_registered_device *rdev,
- bool driver_initiated);
+ u64 reqid, bool driver_initiated);
void cfg80211_upload_connect_keys(struct wireless_dev *wdev);
int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
struct net_device *dev, enum nl80211_iftype ntype,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 3df85a7..f1b253c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -405,6 +405,7 @@ enum nl80211_multicast_groups {
[NL80211_ATTR_FILS_NONCES] = { .len = 2 * FILS_NONCE_LEN },
[NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = { .type = NLA_FLAG, },
[NL80211_ATTR_BSSID] = { .len = ETH_ALEN },
+ [NL80211_ATTR_SCHED_SCAN_MULTI] = { .type = NLA_FLAG },
};
/* policy for the key attributes */
@@ -1463,6 +1464,8 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *rdev,
rdev->wiphy.coverage_class) ||
nla_put_u8(msg, NL80211_ATTR_MAX_NUM_SCAN_SSIDS,
rdev->wiphy.max_scan_ssids) ||
+ nla_put_u8(msg, NL80211_ATTR_SCHED_SCAN_MAX_REQS,
+ rdev->wiphy.max_sched_scan_reqs) ||
nla_put_u8(msg, NL80211_ATTR_MAX_NUM_SCHED_SCAN_SSIDS,
rdev->wiphy.max_sched_scan_ssids) ||
nla_put_u16(msg, NL80211_ATTR_MAX_SCAN_IE_LEN,
@@ -7185,9 +7188,17 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
!rdev->ops->sched_scan_start)
return -EOPNOTSUPP;
- if (rdev->sched_scan_req)
+ /*
+ * allow only one legacy scheduled scan if user-space
+ * does not indicate multiple scheduled scan support.
+ */
+ if (!info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI] &&
+ cfg80211_legacy_sched_scan_active(rdev))
return -EINPROGRESS;
+ if (rdev->sched_scan_req_count == rdev->wiphy.max_sched_scan_reqs)
+ return -ENOSPC;
+
sched_scan_req = nl80211_parse_sched_scan(&rdev->wiphy, wdev,
info->attrs);
@@ -7195,6 +7206,12 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
if (err)
goto out_err;
+ /* leave request id zero for legacy request */
+ if (info->attrs[NL80211_ATTR_SCHED_SCAN_MULTI]) {
+ while (!sched_scan_req->reqid)
+ sched_scan_req->reqid = rdev->wiphy.cookie_counter++;
+ }
+
err = rdev_sched_scan_start(rdev, dev, sched_scan_req);
if (err)
goto out_free;
@@ -7205,7 +7222,7 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
if (info->attrs[NL80211_ATTR_SOCKET_OWNER])
sched_scan_req->owner_nlportid = info->snd_portid;
- rcu_assign_pointer(rdev->sched_scan_req, sched_scan_req);
+ cfg80211_add_sched_scan_req(rdev, sched_scan_req);
nl80211_send_sched_scan(rdev, dev,
NL80211_CMD_START_SCHED_SCAN);
@@ -7220,13 +7237,28 @@ static int nl80211_start_sched_scan(struct sk_buff *skb,
static int nl80211_stop_sched_scan(struct sk_buff *skb,
struct genl_info *info)
{
+ struct cfg80211_sched_scan_request *req;
struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ u64 cookie;
if (!(rdev->wiphy.flags & WIPHY_FLAG_SUPPORTS_SCHED_SCAN) ||
!rdev->ops->sched_scan_stop)
return -EOPNOTSUPP;
- return __cfg80211_stop_sched_scan(rdev, false);
+ if (info->attrs[NL80211_ATTR_COOKIE]) {
+ cookie = nla_get_u64(info->attrs[NL80211_ATTR_COOKIE]);
+ return __cfg80211_stop_sched_scan(rdev, cookie, false);
+ } else {
+ req = list_first_or_null_rcu(&rdev->sched_scan_req_list,
+ struct cfg80211_sched_scan_request,
+ list);
+ if (!req || req->reqid ||
+ (req->owner_nlportid &&
+ req->owner_nlportid != info->snd_portid))
+ return -ENOENT;
+
+ return cfg80211_stop_sched_scan_req(rdev, req, false);
+ }
}
static int nl80211_start_radar_detection(struct sk_buff *skb,
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index b5bd58d..942059e1 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -249,6 +249,46 @@ void cfg80211_scan_done(struct cfg80211_scan_request *request,
}
EXPORT_SYMBOL(cfg80211_scan_done);
+void cfg80211_add_sched_scan_req(struct cfg80211_registered_device *rdev,
+ struct cfg80211_sched_scan_request *req)
+{
+ if (req->reqid)
+ list_add_tail_rcu(&req->list, &rdev->sched_scan_req_list);
+ else
+ list_add_rcu(&req->list, &rdev->sched_scan_req_list);
+ rdev->sched_scan_req_count++;
+}
+
+static void cfg80211_del_sched_scan_req(struct cfg80211_registered_device *rdev,
+ struct cfg80211_sched_scan_request *req)
+{
+ list_del_rcu(&req->list);
+ kfree_rcu(req, rcu_head);
+ synchronize_rcu();
+ rdev->sched_scan_req_count--;
+}
+
+static struct cfg80211_sched_scan_request *
+cfg80211_find_sched_scan_req(struct cfg80211_registered_device *rdev, u64 reqid)
+{
+ struct cfg80211_sched_scan_request *pos;
+ list_for_each_entry(pos, &rdev->sched_scan_req_list, list) {
+ if (pos->reqid == reqid)
+ return pos;
+ }
+ return ERR_PTR(-ENOENT);
+}
+
+bool cfg80211_legacy_sched_scan_active(struct cfg80211_registered_device *rdev)
+{
+ struct cfg80211_sched_scan_request *req;
+
+ req = list_first_or_null_rcu(&rdev->sched_scan_req_list,
+ struct cfg80211_sched_scan_request, list);
+ /* request id 0 indicates legacy request in progress */
+ return req && !req->reqid;
+}
+
void __cfg80211_sched_scan_results(struct work_struct *wk)
{
struct cfg80211_registered_device *rdev;
@@ -295,7 +335,7 @@ void cfg80211_sched_scan_stopped_rtnl(struct wiphy *wiphy)
trace_cfg80211_sched_scan_stopped(wiphy);
- __cfg80211_stop_sched_scan(rdev, true);
+ __cfg80211_stop_sched_scan(rdev, 0, true);
}
EXPORT_SYMBOL(cfg80211_sched_scan_stopped_rtnl);
@@ -307,34 +347,43 @@ void cfg80211_sched_scan_stopped(struct wiphy *wiphy)
}
EXPORT_SYMBOL(cfg80211_sched_scan_stopped);
-int __cfg80211_stop_sched_scan(struct cfg80211_registered_device *rdev,
- bool driver_initiated)
+int cfg80211_stop_sched_scan_req(struct cfg80211_registered_device *rdev,
+ struct cfg80211_sched_scan_request *req,
+ bool driver_initiated)
{
- struct cfg80211_sched_scan_request *sched_scan_req;
- struct net_device *dev;
-
ASSERT_RTNL();
- if (!rdev->sched_scan_req)
- return -ENOENT;
-
- sched_scan_req = rtnl_dereference(rdev->sched_scan_req);
- dev = sched_scan_req->dev;
-
if (!driver_initiated) {
- int err = rdev_sched_scan_stop(rdev, dev);
+ int err = rdev_sched_scan_stop(rdev, req->dev);
if (err)
return err;
}
- nl80211_send_sched_scan(rdev, dev, NL80211_CMD_SCHED_SCAN_STOPPED);
+ nl80211_send_sched_scan(rdev, req->dev, NL80211_CMD_SCHED_SCAN_STOPPED);
- RCU_INIT_POINTER(rdev->sched_scan_req, NULL);
- kfree_rcu(sched_scan_req, rcu_head);
+ cfg80211_del_sched_scan_req(rdev, req);
return 0;
}
+int __cfg80211_stop_sched_scan(struct cfg80211_registered_device *rdev,
+ u64 reqid, bool driver_initiated)
+{
+ struct cfg80211_sched_scan_request *sched_scan_req;
+
+ ASSERT_RTNL();
+
+ if (!rdev->sched_scan_req_count)
+ return -ENOENT;
+
+ sched_scan_req = cfg80211_find_sched_scan_req(rdev, reqid);
+ if (IS_ERR(sched_scan_req))
+ return PTR_ERR(sched_scan_req);
+
+ return cfg80211_stop_sched_scan_req(rdev, sched_scan_req,
+ driver_initiated);
+}
+
void cfg80211_bss_age(struct cfg80211_registered_device *rdev,
unsigned long age_secs)
{
@@ -1078,7 +1127,7 @@ struct cfg80211_bss *
else
rcu_assign_pointer(tmp.pub.beacon_ies, ies);
rcu_assign_pointer(tmp.pub.ies, ies);
-
+
memcpy(tmp.pub.bssid, mgmt->bssid, ETH_ALEN);
tmp.pub.channel = channel;
tmp.pub.scan_width = data->scan_width;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Arend Van Spriel @ 2016-12-21 9:18 UTC (permalink / raw)
To: Malinen, Jouni, Johannes Berg
Cc: Vamsi, Krishna, linux-wireless@vger.kernel.org
In-Reply-To: <20161220205221.GB9756@jouni.qca.qualcomm.com>
On 20-12-2016 21:52, Malinen, Jouni wrote:
> On Fri, Dec 16, 2016 at 10:56:51AM +0100, Johannes Berg wrote:
>> On Thu, 2016-12-15 at 11:06 +0000, Malinen, Jouni wrote:
>>> Maybe the nl80211.h description was not clear enough, but the
>>> comments in cfg80211.h should be quite clear on how this was designed
>>> to work at the implementation level:
>>>
>>> "If the current connected BSS is in the 2.4 GHz band, other BSSs in
>>> the 2.4 GHz band to be reported should have better RSSI by
>>> @relative_rssi and other BSSs in the 5 GHz band to be reported should
>>> have better RSSI by (@relative_rssi - @relative_rssi_5g_pref).
>>> If the current connected BSS is in the 5 GHz band, other BSSs in the
>>> 2.4 GHz band to be reported should have better RSSI by
>>> (@relative_rssi + @relative_rssi_5g_pref) and other BSSs in the 5 GHz
>>> band to be reported should have better RSSI by by @relative_rssi."
>>
>> Oh, right. Should probably be in nl80211.h too, to set expectations
>> from userspace.
>
> Sure, we can update that in the next revision.
>
>>> At minimum, we would need to clearly document struct
>>> nl80211_bss_select_rssi_adjust, but even if we do, I'm not sure it
>>> really is ideal mechanism to move to now that I realized it is not an
>>> array, but a single band,delta pair.
>>
>> We can move to an array easily in the future by extending the attribute
>> length and advertising the number of array entries that are supported,
>> if that's your biggest concern? I don't see it as being very useful
>> right now since I don't think we'll see offloaded roaming between 2.4/5
>> and 60 GHz anytime soon. This may change when we add more bands later,
>> I suppose.
>
> Hmm.. So do you want us to move to using this packed struct in the new
> attribute instead of using a signed 8-bit integer as the variable value?
That was my suggestion so it is more clear what user-space wants by
making it specify the band explicitly. So in the explanation above
reference to "5g" should be "specified band" etc. Whether you reuse the
packed struct nl80211_bss_select_rssi_adjust or come up with a new
(identical?) one is irrelevant to me.
Also I don't see the array issue. @relative_rssi_5g_pref with s8 value
seems same as @rssi_adjust with (band=5g, s8 value) packed together. Or
am I missing something here.
>>> If we are talking only about roaming within an ESS (a single SSID),
>>> that would sound clear, but which relative RSSI rules would apply if
>>> there are match sets for both the currently connected SSID and
>>> another SSID that the candidate BSS is for?
>>
>> Right, I see how this might become a problem. I generally see no issue
>> with supporting multiple matchsets with different SSIDs but all having
>> the "relative to connected BSS RSSI filter" (which would disregard the
>> SSID specified in the matchset), but this then would become a problem
>> when multiple matchsets are specified with *different* such RSSI
>> filters, e.g. one matchset would specify that you want a 5G preference
>> of 10dB, but the other would specify a preference of only 5dB.
>>
>> Conceptually in this approach, that would be supported, but firmware
>> likely would not be able to express this, I suppose?
>
> That's certainly not at the level we were planning on implementing.. :)
Right. So having "relative rssi" matchset attribute is off the table as
far as I am concerned.
>>> I think I'm missing something here.. Where would the threshold value
>>> (how much better new BSS needs to be) be stored? And do we really
>>> want something like the combination of
>>> NL80211_BSS_SELECT_ATTR_BAND_PREF and
>>> NL80211_BSS_SELECT_ATTR_RSSI_ADJUST which seems to be two different
>>> ways of doing band preference (the former without specifying delta
>>> and the latter with specific delta)? Or am I still not understanding
>>> how NL80211_BSS_SELECT_ATTR_* really works?
It is documented here:
/**
* enum nl80211_bss_select_attr - attributes for bss selection.
*
[...]
*
* One and only one of these attributes are found within
%NL80211_ATTR_BSS_SELECT
* for %NL80211_CMD_CONNECT. It specifies the required BSS selection
behaviour
* which the driver shall use.
*/
It is checked in nl80211.c [1]
>> No, you're right, I missed the "better by" threshold.
>>
>> I think between that (unless we add that, we could technically extend
>> flag attributes to allow them being an int as well, or add a new one)
>> and the fact that the device may not support different relative RSSI
>> matches in different matchsets, I'm almost convinced that adding new
>> attributes is better.
>
> I'm not completely sure how to interpret all this and also the last
> email from Arend in this thread. Could either (or both :) of you provide
> more detailed suggestion on what exactly you would like us to change, if
> anything, in the attribute design now so that we can try to close on
> this?
To summarize: 1) stick with the new attributes on request level (so not
matchset level), 2) use packed struct for @relative_rssi_5g_pref.
Regards,
Arend
[1] http://lxr.free-electrons.com/source/net/wireless/nl80211.c#L6382
^ 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