* Re: mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
From: Kalle Valo @ 2017-01-17 12:03 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Cathy Luo, Brian Norris
In-Reply-To: <20170109233350.134036-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Similar to commit fcd2042e8d36 ("mwifiex: printk() overflow with 32-byte
> SSIDs"), we failed to account for the existence of 32-char SSIDs in our
> debugfs code. Unlike in that case though, we zeroed out the containing
> struct first, and I'm pretty sure we're guaranteed to have some padding
> after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes
> long).
>
> So, this is the difference between:
>
> # cat /sys/kernel/debug/mwifiex/mlan0/info
> ...
> essid="0123456789abcdef0123456789abcdef "
> ...
>
> and the correct output:
>
> # cat /sys/kernel/debug/mwifiex/mlan0/info
> ...
> essid="0123456789abcdef0123456789abcdef"
> ...
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
6183468a23fc mwifiex: debugfs: Fix (sometimes) off-by-1 SSID print
--
https://patchwork.kernel.org/patch/9506069/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V3] brcmfmac: avoid writing channel out of allocated array
From: Kalle Valo @ 2017-01-17 11:57 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170104110941.21261-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Our code was assigning number of channels to the index variable by
> default. If firmware reported channel we didn't predict this would
> result in using that initial index value and writing out of array. This
> never happened so far (we got a complete list of supported channels) but
> it means possible memory corruption so we should handle it anyway.
>
> This patch simply detects unexpected channel and ignores it.
>
> As we don't try to create new entry now, it's also safe to drop hw_value
> and center_freq assignment. For known channels we have these set anyway.
>
> I decided to fix this issue by assigning NULL or a target channel to the
> channel variable. This was one of possible ways, I prefefred this one as
> it also avoids using channel[index] over and over.
>
> Fixes: 58de92d2f95e ("brcmfmac: use static superset of channels for wiphy bands")
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Patch applied to wireless-drivers-next.git, thanks.
77c0d0cd10e7 brcmfmac: avoid writing channel out of allocated array
--
https://patchwork.kernel.org/patch/9496471/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] brcmfmac: don't preset all channels as disabled
From: Kalle Valo @ 2017-01-17 12:01 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170107203605.24866-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> During init we take care of regulatory stuff by disabling all
> unavailable channels (see brcmf_construct_chaninfo) so this predisabling
> them is not really required (and this patch won't change any behavior).
> It will on the other hand allow more detailed runtime control over
> channels which is the main reason for this change.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
2 patches applied to wireless-drivers-next.git, thanks.
9ea0c307609f brcmfmac: don't preset all channels as disabled
ab99063f8737 brcmfmac: setup wiphy bands after registering it first
--
https://patchwork.kernel.org/patch/9503277/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/9] rt2800usb: remove watchdog
From: Kalle Valo @ 2017-01-17 11:59 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-2-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On rt2800usb, if we do not get TX status from HW, we assume frames were
> posted and after entry->last_action timeout, we forcibly provide TX
> status to mac80211. So it's not possible to detect hardware TX hung
> based on the timeout. Additionally TXRQ_PCNT tells on number of frames
> in the Packet Buffer (buffer between bus interface and chip MAC
> subsystem), which can be non zero on normal conditions. To check HW hung
> we will need provide some different mechanism, for now remove watchdog
> as current implementation is wrong and not useful.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
8 patches applied to wireless-drivers-next.git, thanks.
480b468625da rt2800usb: remove watchdog
cfe82fbd8423 rt2800: increase TX timeout
15ec51b25e05 rt2x00: save conf settings before reset tuner
01d97ef4b25f rt2800: change default retry settings
e4019e7f9530 rt2800: tune TX_RTS_CFG config
170122169676 rt2800usb: mark tx failure on timeout
51583248187c rt2x00: do not flush empty queue
66ecec02e851 rt2800: set max_psdu to 3 on usb devices
--
https://patchwork.kernel.org/patch/9500917/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: fix uninitialized variable access in pcie_remove
From: Kalle Valo @ 2017-01-17 11:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Amitkumar Karwar, Arnd Bergmann, Nishant Sarmukadam, Brian Norris,
Xinming Hu, Cathy Luo, Shengzhen Li, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20170113153534.2617372-1-arnd@arndb.de>
Arnd Bergmann <arnd@arndb.de> wrote:
> Checking the firmware status from PCIe register only works
> if the register is available, otherwise we end up with
> random behavior:
>
> drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove':
> drivers/net/wireless/marvell/mwifiex/pcie.c:585:5: error: 'fw_status' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
> This makes sure we treat the absence of the register as a failure.
>
> Fixes: 045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patch applied to wireless-drivers-next.git, thanks.
0e8edb9aed03 mwifiex: fix uninitialized variable access in pcie_remove
--
https://patchwork.kernel.org/patch/9515899/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: linux-next: build warning after merge of the wireless-drivers-next tree
From: Kalle Valo @ 2017-01-17 11:49 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Wireless, linux-next, linux-kernel, Xinming Hu, Amitkumar Karwar
In-Reply-To: <87shonjcle.fsf@codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Stephen Rothwell <sfr@canb.auug.org.au> writes:
>
>> Hi all,
>>
>> After merging the wireless-drivers-next tree, today's linux-next build
>> (x86_64 allmodconfig) produced this warning:
>>
>> drivers/net/wireless/marvell/mwifiex/pcie.c: In function 'mwifiex_pcie_remove':
>> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status' may be used uninitialized in this function [-Wmaybe-uninitialized]
>> if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
>> ^
>>
>> Introduced by commit
>>
>> 045f0c1b5e26 ("mwifiex: get rid of global user_rmmod flag")
>>
>> This is not a false positive since "reg" could be NULL just above
>> (otherwise it would be tested for).
>
> Thanks, I noticed this myself yesterday (after I had applied the patch)
> and I have asked Marvell to send a fix.
I missed that Arnd had already sent a fix, I'll apply that one:
mwifiex: fix uninitialized variable access in pcie_remove
https://patchwork.kernel.org/patch/9515899/
--
Kalle Valo
^ permalink raw reply
* Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Kalle Valo @ 2017-01-17 11:10 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <01b93ecb7f4e43799ff6a9087daed1b5@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> Hi Kalle,
>
>> From: Kalle Valo [mailto:kvalo@codeaurora.org]
>> Sent: Thursday, January 12, 2017 8:25 PM
>> To: Amitkumar Karwar
>> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
>> rajatja@google.com; briannorris@google.com; dmitry.torokhov@gmail.com;
>> Xinming Hu
>> Subject: Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
>>
>> Amitkumar Karwar <akarwar@marvell.com> writes:
>>
>> >> But these didn't. Can you please rebase these and resubmit in one
>> >> patchset? Less conflicts that way.
>> >>
>> >
>> > The problem here is you tried to apply the patches in reverse order.
>> Sorry for the confusion.
>> > Please apply pending patches in below order.
>> >
>> > [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv ---
>> Apply this patch first.
>> > [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
>> > [v3,3/5] mwifiex: get rid of drv_info* adapter variables [v3,4/5]
>> > mwifiex: wait firmware dump complete during card remove process
>> > [v3,5/5] mwifiex: move pcie_work and related variables inside card
>> >
>> > [1/2] mwifiex: code rearrangement in pcie.c and sdio.c [2/2] mwifiex:
>> > get rid of global user_rmmod flag
>> >
>> > mwifiex: use module_*_driver helper macros
>> >
>> > [1/5] mwifiex: get rid of mwifiex_do_flr wrapper [2/5] mwifiex:
>> > cleanup in PCIe flr code path [3/5] mwifiex: sdio card reset
>> > enhancement [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
>> > [5/5] mwifiex: get rid of global save_adapter and sdio_work
>>
>> Thanks, now I was able to apply these but please do double check the
>> result in wireless-drivers-next.
>>
>> I also noticed a new warning:
>>
>> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
>> 'mwifiex_pcie_remove':
>> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status'
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
>>
>> Actually I'm not sure if this warning was caused by these patches as I
>> have recently updated my ancient gcc to a newer one (5.4.0), but please
>> take a look and send a fix if it's a valid warning.
>>
>
> Below CL fixes this warning.
>
> https://patchwork.kernel.org/patch/9515899/
Good, thanks. I'll apply that shortly.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata
From: Kalle Valo @ 2017-01-17 11:07 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, linux-mtd, linux-wireless,
Hauke Mehrtens, Rafał Miłecki
In-Reply-To: <20170116162818.12094-1-zajec5@gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> We have generic place & helpers for storing platform driver data so
> there is no reason for using custom priv pointer.
>
> This allows cleaning up struct bcma_sflash from unneeded fields.
>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
> ---
> Kalle: This is mtd focused patch, so I guess it should go through mtd tre=
e. Do
> you find bcma change important enough to care to Ack it? :)
Sure :)
Feel free to take the patch via mtd tree, I'm not expecting to see any
conflicts with this patch. For the bcma part:
Acked-by: Kalle Valo <kvalo@codeaurora.org>
--=20
Kalle Valo
^ permalink raw reply
* RE: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Amitkumar Karwar @ 2017-01-17 8:34 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <87lgugnx9f.fsf@kamboji.qca.qualcomm.com>
Hi Kalle,
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Thursday, January 12, 2017 8:25 PM
> To: Amitkumar Karwar
> Cc: linux-wireless@vger.kernel.org; Cathy Luo; Nishant Sarmukadam;
> rajatja@google.com; briannorris@google.com; dmitry.torokhov@gmail.com;
> Xinming Hu
> Subject: Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
>
> Amitkumar Karwar <akarwar@marvell.com> writes:
>
> >> But these didn't. Can you please rebase these and resubmit in one
> >> patchset? Less conflicts that way.
> >>
> >
> > The problem here is you tried to apply the patches in reverse order.
> Sorry for the confusion.
> > Please apply pending patches in below order.
> >
> > [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv ---
> Apply this patch first.
> > [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
> > [v3,3/5] mwifiex: get rid of drv_info* adapter variables [v3,4/5]
> > mwifiex: wait firmware dump complete during card remove process
> > [v3,5/5] mwifiex: move pcie_work and related variables inside card
> >
> > [1/2] mwifiex: code rearrangement in pcie.c and sdio.c [2/2] mwifiex:
> > get rid of global user_rmmod flag
> >
> > mwifiex: use module_*_driver helper macros
> >
> > [1/5] mwifiex: get rid of mwifiex_do_flr wrapper [2/5] mwifiex:
> > cleanup in PCIe flr code path [3/5] mwifiex: sdio card reset
> > enhancement [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
> > [5/5] mwifiex: get rid of global save_adapter and sdio_work
>
> Thanks, now I was able to apply these but please do double check the
> result in wireless-drivers-next.
>
> I also noticed a new warning:
>
> drivers/net/wireless/marvell/mwifiex/pcie.c: In function
> 'mwifiex_pcie_remove':
> drivers/net/wireless/marvell/mwifiex/pcie.c:303:5: warning: 'fw_status'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> if (fw_status == FIRMWARE_READY_PCIE && !adapter->mfg_mode) {
>
> Actually I'm not sure if this warning was caused by these patches as I
> have recently updated my ancient gcc to a newer one (5.4.0), but please
> take a look and send a fix if it's a valid warning.
>
Below CL fixes this warning.
https://patchwork.kernel.org/patch/9515899/
Regards,
Amitkumar
^ permalink raw reply
* Re: [PATCH v2 09/14] rt2x00: rt2x00pci: set PCI MWI only if supported
From: John Crispin @ 2017-01-17 7:34 UTC (permalink / raw)
To: Daniel Golle, Stanislaw Gruszka
Cc: linux-wireless, Johannes Berg, roman, michel.stempin, c.mignanti,
evaxige, Kalle Valo, Felix Fietkau, Gabor Juhos
In-Reply-To: <20170117015653.GF1912@makrotopia.org>
On 17/01/2017 02:56, Daniel Golle wrote:
> On Mon, Jan 16, 2017 at 11:08:57AM +0100, Stanislaw Gruszka wrote:
>> On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
>>> From: Claudio Mignanti <c.mignanti@gmail.com>
>>>
>>> This is needed for devices without support for PCI MWI. See also
>>> https://dev.openwrt.org/changeset/21850
>>>
>>> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>>> ---
>>> drivers/net/wireless/ralink/rt2x00/rt2x00pci.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
>>> index eb6dbcd4fddf..4becfeb75ba8 100644
>>> --- a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
>>> +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
>>> @@ -94,8 +94,10 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct rt2x00_ops *ops)
>>>
>>> pci_set_master(pci_dev);
>>>
>>> +#ifdef CONFIG_PCI_SET_MWI
>>> if (pci_set_mwi(pci_dev))
>>> rt2x00_probe_err("MWI not available\n");
>>> +#endif
>>
>> There is no CONFIG_PCI_SET_MWI in the kernel. This patch is either not
>> needed (pci subsystem has own PCI_DISABLE_MWI define) or wrong (we
>> should not call this function for some devices).
>
> Apparently we thus never enabled MWI on PCI devices. John Crispin has
> started to investigate why this patch was needed in first place, see
> http://lists.infradead.org/pipermail/lede-dev/2017-January/005400.html
>
> I suggest to drop it entirely until we figure out why it wasn't safe to
> use MWI at least on some platforms. Once we know more there might be
> a follow-up to selectively have the precompiler skip pci_set_mwi in
> case we really still need to do this.
> Aparently this was originally related to a compiler error on Kernel
> 2.6.30 when trying to build for Rt305x WiSoC platforms (which simply
> do not have any PCI bus and probably explicite support for SoC devices
> wasn't implemented in rt2x00 at the time).
>
>
here is the original thread related to this patch
http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2012-November/012227.html
John
> Cheers
>
>
> Daniel
>
>>
>> Stanislaw
^ permalink raw reply
* Re: [PATCH v2 09/14] rt2x00: rt2x00pci: set PCI MWI only if supported
From: Daniel Golle @ 2017-01-17 1:56 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Johannes Berg, roman, michel.stempin, c.mignanti,
evaxige, Kalle Valo, Felix Fietkau, John Crispin, Gabor Juhos
In-Reply-To: <20170116100856.GB6968@redhat.com>
On Mon, Jan 16, 2017 at 11:08:57AM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:06:25AM +0100, Daniel Golle wrote:
> > From: Claudio Mignanti <c.mignanti@gmail.com>
> >
> > This is needed for devices without support for PCI MWI. See also
> > https://dev.openwrt.org/changeset/21850
> >
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> > ---
> > drivers/net/wireless/ralink/rt2x00/rt2x00pci.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > index eb6dbcd4fddf..4becfeb75ba8 100644
> > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00pci.c
> > @@ -94,8 +94,10 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct rt2x00_ops *ops)
> >
> > pci_set_master(pci_dev);
> >
> > +#ifdef CONFIG_PCI_SET_MWI
> > if (pci_set_mwi(pci_dev))
> > rt2x00_probe_err("MWI not available\n");
> > +#endif
>
> There is no CONFIG_PCI_SET_MWI in the kernel. This patch is either not
> needed (pci subsystem has own PCI_DISABLE_MWI define) or wrong (we
> should not call this function for some devices).
Apparently we thus never enabled MWI on PCI devices. John Crispin has
started to investigate why this patch was needed in first place, see
http://lists.infradead.org/pipermail/lede-dev/2017-January/005400.html
I suggest to drop it entirely until we figure out why it wasn't safe to
use MWI at least on some platforms. Once we know more there might be
a follow-up to selectively have the precompiler skip pci_set_mwi in
case we really still need to do this.
Aparently this was originally related to a compiler error on Kernel
2.6.30 when trying to build for Rt305x WiSoC platforms (which simply
do not have any PCI bus and probably explicite support for SoC devices
wasn't implemented in rt2x00 at the time).
Cheers
Daniel
>
> Stanislaw
^ permalink raw reply
* Re: [PATCH v2 14/14] rt2x00: add support for RT5350 WiSoC
From: Daniel Golle @ 2017-01-17 1:48 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Johannes Berg, roman, michel.stempin, c.mignanti,
evaxige, Kalle Valo, Felix Fietkau, John Crispin, Gabor Juhos
In-Reply-To: <20170116101743.GF6968@redhat.com>
On Mon, Jan 16, 2017 at 11:17:44AM +0100, Stanislaw Gruszka wrote:
> On Mon, Jan 16, 2017 at 04:17:58AM +0100, Daniel Golle wrote:
> > @@ -7131,6 +7236,12 @@ static int rt2800_validate_eeprom(struct rt2x00_dev *rt2x00dev)
> > rt2x00_set_field16(&word, EEPROM_NIC_CONF0_RF_TYPE, RF2820);
> > rt2800_eeprom_write(rt2x00dev, EEPROM_NIC_CONF0, word);
> > rt2x00_eeprom_dbg(rt2x00dev, "Antenna: 0x%04x\n", word);
> > + } else if (rt2x00_rt(rt2x00dev, RT5350)) {
> > + rt2x00_set_field16(&word, EEPROM_NIC_CONF0_RXPATH, 1);
> > + rt2x00_set_field16(&word, EEPROM_NIC_CONF0_TXPATH, 1);
> > + rt2x00_set_field16(&word, EEPROM_NIC_CONF0_RF_TYPE, RF3320);
Good catch. This line was probably left over when trying to implement
support for RT5350 based on adding codepaths to RF3320 which ended up
messy... As EEPROM_NIC_CONF0_RF_TYPE aparently isn't used anywhere else
in the code apart from setting rf type which is later on overwritten
for RT5350 anyway. So no need to set it at all. I suggest to simply
drop that line.
>
> Here you set RF3320 ..
> > + rt2x00_eeprom_write(rt2x00dev, EEPROM_NIC_CONF0, word);
> > + rt2x00_eeprom_dbg(rt2x00dev, "Antenna: 0x%04x\n", word);
> > } else if (rt2x00_rt(rt2x00dev, RT2860) ||
> > rt2x00_rt(rt2x00dev, RT2872)) {
> > /*
> > @@ -7265,6 +7376,8 @@ static int rt2800_init_eeprom(struct rt2x00_dev *rt2x00dev)
> > rt2800_eeprom_read(rt2x00dev, EEPROM_CHIP_ID, &rf);
> > else if (rt2x00_rt(rt2x00dev, RT3352))
> > rf = RF3322;
> > + else if (rt2x00_rt(rt2x00dev, RT5350))
> > + rf = RF5350;
>
> and here RF5350. This does not seems to be correct.
>
> Stanislaw
^ permalink raw reply
* Re: brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
From: Andreas Färber @ 2017-01-17 0:19 UTC (permalink / raw)
To: Martin Blumenstingl, linux-mmc, brcm80211-dev-list.pdl,
linux-wireless, kvalo, ulf.hansson
Cc: arend.vanspriel, franky.lin, hante.meuleman
In-Reply-To: <20170116101757.20483-1-martin.blumenstingl@googlemail.com>
Hi Martin,
Am 16.01.2017 um 11:17 schrieb Martin Blumenstingl:
> BCM43455 is a more recent revision of the BCM4345. Some of the BCM43455
> got a dedicated SDIO device ID which is currently not supported by
> brcmfmac.
> Adding the new sdio_device_id to brcmfmac is enough to get the BCM43455
> supported because the chip itself is already supported (due to BCM4345
> support in the driver).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> ---
> This is the proper patch following the (short) discussion from [0]
>
> [0] https://marc.info/?l=linux-wireless&m=148455981002310&w=2
>
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 1 +
> include/linux/mmc/sdio_ids.h | 1 +
> 2 files changed, 2 insertions(+)
Reviewed-by: Andreas Färber <afaerber@suse.de>
I encountered the same ID on my R-Box Pro 3G and tested the exact same
patch based on [0] there:
[ +0,130866] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Mar 1 2015 07:29:38 version 7.45.18 (r538002) FWID 01-6a2c8ad4
...
[ +0,156118] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
(0x30 0x30)
...
[ +1,790419] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
(0x30 0x30)
Tested-by: Andreas Färber <afaerber@suse.de>
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Strange Behaviors in 802.11 Association MLME
From: Jinghao Shi @ 2017-01-16 21:16 UTC (permalink / raw)
To: linux-wireless; +Cc: Geoffrey Challen, Shuvendu Lahiri, Ranveer Chandra
Hi,
We're working on a formal validation framework for wireless protocol
implementations. We have performed experiments on the 802.11
association state machine and have found peculiar association
behaviors.We'd like to share our findings to the community and confirm
whether they reveal potential implementation bugs.
TLDR version: the client sends association request despite having
received association response from the AP, is this a bug?
We utilized a real time reactive packet jammer to create the following
packet loss pattern (the rate control policy was set to re-transmit
the packet at most once before reporting the packet as failed. This
may not be realistic in practice but helps reveal interesting
behaviors faster.)
- ASSOC_REQ (received by the AP, confirmed by the following ASSOC_RESP)
- ACK <---- JAMMED
- ASSOC_REQ_RETRY <----- JAMMED, the driver will declare this packet as failed
- ASSOC_RESP (received by the client, confirmed by the following ACK)
- ACK
- ASSOC_REQ <--- problematic packet
- ...
I'm also attaching a pcap capture during this session. Our current
conjecture is that the failure status of the ASSOC_REQ was delivered
to the mac80211 MLME entity before the reception of the ASSOC_RESP
packet.
Let us know if there's any other information we can collect to help
tracing down the issue.
Regards,
Jinghao Shi
PhD Student
University at Buffalo
^ permalink raw reply
* Re: Support of rtl8723bs
From: Larry Finger @ 2017-01-16 17:24 UTC (permalink / raw)
To: Jes Sorensen, Hanno Zulla; +Cc: Bastien Nocera, anthony.wong, linux-wireless
In-Reply-To: <wrfjpojn3zms.fsf@redhat.com>
On 01/16/2017 07:25 AM, Jes Sorensen wrote:
> Hanno Zulla <abos@hanno.de> writes:
>> Hi,
>>
>> has there been any progress on the rtl8723bs / sdio issue?
>>
>> There were no updates to this mailing list or the usual git repositories
>> since this was last discussed, unless I missed the proper place to look
>> for this.
>>
>> I'm sorry that I can't be more helpful with actual development, but am
>> eager to help with testing this device.
>>
>> Thank you,
>> Hanno
>
> Hanno,
>
> The 8723bs project is currently in idle mode, I haven't had time to
> spend time on it for the last couple of months.
I have also been busy.
Larry
^ permalink raw reply
* [PATCH V2] mtd: bcm47xxsflash: use platform_(set|get)_drvdata
From: Rafał Miłecki @ 2017-01-16 16:28 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen, Kalle Valo
Cc: linux-mtd, linux-wireless, Hauke Mehrtens,
Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
We have generic place & helpers for storing platform driver data so
there is no reason for using custom priv pointer.
This allows cleaning up struct bcma_sflash from unneeded fields.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
Kalle: This is mtd focused patch, so I guess it should go through mtd tree. Do
you find bcma change important enough to care to Ack it? :)
---
drivers/mtd/devices/bcm47xxsflash.c | 6 +++---
include/linux/bcma/bcma_driver_chipcommon.h | 3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/devices/bcm47xxsflash.c b/drivers/mtd/devices/bcm47xxsflash.c
index 514be04..4decd8c 100644
--- a/drivers/mtd/devices/bcm47xxsflash.c
+++ b/drivers/mtd/devices/bcm47xxsflash.c
@@ -284,7 +284,6 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
b47s = devm_kzalloc(dev, sizeof(*b47s), GFP_KERNEL);
if (!b47s)
return -ENOMEM;
- sflash->priv = b47s;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
@@ -334,6 +333,8 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
b47s->size = sflash->size;
bcm47xxsflash_fill_mtd(b47s, &pdev->dev);
+ platform_set_drvdata(pdev, b47s);
+
err = mtd_device_parse_register(&b47s->mtd, probes, NULL, NULL, 0);
if (err) {
pr_err("Failed to register MTD device: %d\n", err);
@@ -349,8 +350,7 @@ static int bcm47xxsflash_bcma_probe(struct platform_device *pdev)
static int bcm47xxsflash_bcma_remove(struct platform_device *pdev)
{
- struct bcma_sflash *sflash = dev_get_platdata(&pdev->dev);
- struct bcm47xxsflash *b47s = sflash->priv;
+ struct bcm47xxsflash *b47s = platform_get_drvdata(pdev);
mtd_device_unregister(&b47s->mtd);
iounmap(b47s->window);
diff --git a/include/linux/bcma/bcma_driver_chipcommon.h b/include/linux/bcma/bcma_driver_chipcommon.h
index b20e3d5..2f1c690 100644
--- a/include/linux/bcma/bcma_driver_chipcommon.h
+++ b/include/linux/bcma/bcma_driver_chipcommon.h
@@ -593,9 +593,6 @@ struct bcma_sflash {
u32 blocksize;
u16 numblocks;
u32 size;
-
- struct mtd_info *mtd;
- void *priv;
};
#endif
--
2.10.1
^ permalink raw reply related
* [PATCH] ath10k: dump Copy Engine registers during firmware crash
From: Kalle Valo @ 2017-01-16 15:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Dump Copy Engine source and destination ring addresses.
This is useful information to debug firmware crashes, assertes or hangs over long run
assessing the Copy Engine Register status. This also enables dumping CE
register status in debugfs Crash Dump file.
Screenshot:
ath10k_pci 0000:02:00.0: simulating hard firmware crash
ath10k_pci 0000:02:00.0: firmware crashed! (uuid 84901ff5-d33c-456e-93ee-0165dea643cf)
ath10k_pci 0000:02:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000
ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1
ath10k_pci 0000:02:00.0: firmware ver 10.2.4.70.59-2 api 5 features no-p2p,raw-mode,mfp,allows-mesh-bcast crc32 4159f498
ath10k_pci 0000:02:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08
ath10k_pci 0000:02:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1
ath10k_pci 0000:02:00.0: firmware register dump:
ath10k_pci 0000:02:00.0: [00]: 0x4100016C 0x00000000 0x009A0F2A 0x00000000
ath10k_pci 0000:02:00.0: [04]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [08]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [12]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [16]: 0x00000000 0x00000000 0x00000000 0x009A0F2A
ath10k_pci 0000:02:00.0: [20]: 0x00000000 0x00401930 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [24]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [28]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [32]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [36]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [40]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [44]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [48]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [52]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: [56]: 0x00000000 0x00000000 0x00000000 0x00000000
ath10k_pci 0000:02:00.0: Copy Engine register dump:
ath10k_pci 0000:02:00.0: [00]: 0x00057400 7 7 3 3
ath10k_pci 0000:02:00.0: [01]: 0x00057800 18 18 85 86
ath10k_pci 0000:02:00.0: [02]: 0x00057c00 49 49 48 49
ath10k_pci 0000:02:00.0: [03]: 0x00058000 16 16 17 16
ath10k_pci 0000:02:00.0: [04]: 0x00058400 4 4 44 4
ath10k_pci 0000:02:00.0: [05]: 0x00058800 12 12 11 12
ath10k_pci 0000:02:00.0: [06]: 0x00058c00 3 3 3 3
ath10k_pci 0000:02:00.0: [07]: 0x00059000 0 0 0 0
ieee80211 phy0: Hardware restart was requested
ath10k_pci 0000:02:00.0: device successfully recovered
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
[kvalo@qca.qualcomm.com: simplify the implementation]
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/ce.c | 39 +++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/ce.h | 4 ++-
drivers/net/wireless/ath/ath10k/core.h | 16 +++++++++++++
drivers/net/wireless/ath/ath10k/debug.c | 16 +++++++++++++
drivers/net/wireless/ath/ath10k/hw.h | 3 ++
drivers/net/wireless/ath/ath10k/pci.c | 1 +
6 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/ce.c b/drivers/net/wireless/ath/ath10k/ce.c
index 0b4d79659884..c04e68796a20 100644
--- a/drivers/net/wireless/ath/ath10k/ce.c
+++ b/drivers/net/wireless/ath/ath10k/ce.c
@@ -1130,3 +1130,42 @@ void ath10k_ce_free_pipe(struct ath10k *ar, int ce_id)
ce_state->src_ring = NULL;
ce_state->dest_ring = NULL;
}
+
+void ath10k_ce_dump_registers(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data)
+{
+ struct ath10k_pci *ar_pci = ath10k_pci_priv(ar);
+ struct ath10k_ce_crash_data ce;
+ u32 addr, id;
+
+ lockdep_assert_held(&ar->data_lock);
+
+ ath10k_err(ar, "Copy Engine register dump:\n");
+
+ spin_lock_bh(&ar_pci->ce_lock);
+ for (id = 0; id < CE_COUNT; id++) {
+ addr = ath10k_ce_base_address(ar, id);
+ ce.base_addr = cpu_to_le32(addr);
+
+ ce.src_wr_idx =
+ cpu_to_le32(ath10k_ce_src_ring_write_index_get(ar, addr));
+ ce.src_r_idx =
+ cpu_to_le32(ath10k_ce_src_ring_read_index_get(ar, addr));
+ ce.dst_wr_idx =
+ cpu_to_le32(ath10k_ce_dest_ring_write_index_get(ar, addr));
+ ce.dst_r_idx =
+ cpu_to_le32(ath10k_ce_dest_ring_read_index_get(ar, addr));
+
+ if (crash_data)
+ crash_data->ce_crash_data[id] = ce;
+
+ ath10k_err(ar, "[%02d]: 0x%08x %3u %3u %3u %3u", id,
+ le32_to_cpu(ce.base_addr),
+ le32_to_cpu(ce.src_wr_idx),
+ le32_to_cpu(ce.src_r_idx),
+ le32_to_cpu(ce.dst_wr_idx),
+ le32_to_cpu(ce.dst_r_idx));
+ }
+
+ spin_unlock_bh(&ar_pci->ce_lock);
+}
diff --git a/drivers/net/wireless/ath/ath10k/ce.h b/drivers/net/wireless/ath/ath10k/ce.h
index dfc098606bee..e76a98242b98 100644
--- a/drivers/net/wireless/ath/ath10k/ce.h
+++ b/drivers/net/wireless/ath/ath10k/ce.h
@@ -20,8 +20,6 @@
#include "hif.h"
-/* Maximum number of Copy Engine's supported */
-#define CE_COUNT_MAX 12
#define CE_HTT_H2T_MSG_SRC_NENTRIES 8192
/* Descriptor rings must be aligned to this boundary */
@@ -228,6 +226,8 @@ void ath10k_ce_per_engine_service_any(struct ath10k *ar);
void ath10k_ce_per_engine_service(struct ath10k *ar, unsigned int ce_id);
int ath10k_ce_disable_interrupts(struct ath10k *ar);
void ath10k_ce_enable_interrupts(struct ath10k *ar);
+void ath10k_ce_dump_registers(struct ath10k *ar,
+ struct ath10k_fw_crash_data *crash_data);
/* ce_attr.flags values */
/* Use NonSnooping PCIe accesses? */
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index c7664d6569fa..7a6fcea760f0 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -419,6 +419,21 @@ struct ath10k_vif_iter {
struct ath10k_vif *arvif;
};
+/* Copy Engine register dump, protected by ce-lock */
+struct ath10k_ce_crash_data {
+ __le32 base_addr;
+ __le32 src_wr_idx;
+ __le32 src_r_idx;
+ __le32 dst_wr_idx;
+ __le32 dst_r_idx;
+};
+
+struct ath10k_ce_crash_hdr {
+ __le32 ce_count;
+ __le32 reserved[3]; /* for future use */
+ struct ath10k_ce_crash_data entries[];
+};
+
/* used for crash-dump storage, protected by data-lock */
struct ath10k_fw_crash_data {
bool crashed_since_read;
@@ -426,6 +441,7 @@ struct ath10k_fw_crash_data {
uuid_le uuid;
struct timespec timestamp;
__le32 registers[REG_DUMP_COUNT_QCA988X];
+ struct ath10k_ce_crash_data ce_crash_data[CE_COUNT_MAX];
};
struct ath10k_debug {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
index b882b0892dcf..d5ff0f4ef5ce 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -41,6 +41,7 @@
*/
enum ath10k_fw_crash_dump_type {
ATH10K_FW_CRASH_DUMP_REGISTERS = 0,
+ ATH10K_FW_CRASH_DUMP_CE_DATA = 1,
ATH10K_FW_CRASH_DUMP_MAX,
};
@@ -729,6 +730,7 @@ 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_ce_crash_hdr *ce_hdr;
struct ath10k_dump_file_data *dump_data;
struct ath10k_tlv_dump_data *dump_tlv;
int hdr_len = sizeof(*dump_data);
@@ -737,6 +739,8 @@ static struct ath10k_dump_file_data *ath10k_build_dump_file(struct ath10k *ar,
len = hdr_len;
len += sizeof(*dump_tlv) + sizeof(crash_data->registers);
+ len += sizeof(*dump_tlv) + sizeof(*ce_hdr) +
+ CE_COUNT * sizeof(ce_hdr->entries[0]);
sofar += hdr_len;
@@ -795,6 +799,18 @@ 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);
+ dump_tlv = (struct ath10k_tlv_dump_data *)(buf + sofar);
+ dump_tlv->type = cpu_to_le32(ATH10K_FW_CRASH_DUMP_CE_DATA);
+ dump_tlv->tlv_len = cpu_to_le32(sizeof(*ce_hdr) +
+ CE_COUNT * sizeof(ce_hdr->entries[0]));
+ ce_hdr = (struct ath10k_ce_crash_hdr *)(dump_tlv->tlv_data);
+ ce_hdr->ce_count = cpu_to_le32(CE_COUNT);
+ memset(ce_hdr->reserved, 0, sizeof(ce_hdr->reserved));
+ memcpy(ce_hdr->entries, crash_data->ce_crash_data,
+ CE_COUNT * sizeof(ce_hdr->entries[0]));
+ sofar += sizeof(*dump_tlv) + sizeof(*ce_hdr) +
+ CE_COUNT * sizeof(ce_hdr->entries[0]);
+
ar->debug.fw_crash_data->crashed_since_read = !mark_read;
spin_unlock_bh(&ar->data_lock);
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 7feffec531cc..38aa7c95732e 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -578,6 +578,9 @@ ath10k_rx_desc_get_l3_pad_bytes(struct ath10k_hw_params *hw,
#define TARGET_10_4_IPHDR_PAD_CONFIG 1
#define TARGET_10_4_QWRAP_CONFIG 0
+/* Maximum number of Copy Engine's supported */
+#define CE_COUNT_MAX 12
+
/* Number of Copy Engines supported */
#define CE_COUNT ar->hw_values->ce_count
diff --git a/drivers/net/wireless/ath/ath10k/pci.c b/drivers/net/wireless/ath/ath10k/pci.c
index 93b9790cfe8d..95ccd6db7623 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -1474,6 +1474,7 @@ static void ath10k_pci_fw_crashed_dump(struct ath10k *ar)
ath10k_err(ar, "firmware crashed! (uuid %s)\n", uuid);
ath10k_print_driver_info(ar);
ath10k_pci_dump_registers(ar, crash_data);
+ ath10k_ce_dump_registers(ar, crash_data);
spin_unlock_bh(&ar->data_lock);
^ permalink raw reply related
* ANNOUNCE: Netdev 2.1 Call For Proposals Opened!
From: Jamal Hadi Salim @ 2017-01-16 15:00 UTC (permalink / raw)
To: netdev
Cc: netfilter-devel, netfilter, info, linux-wireless, tech-committee,
David Miller, Stephen Jaworski, Rob Echlin, lwn,
info@netdev01.org, tech-committee
Folks,
We are pleased to announce that the CFP for netdev 2.1 is now open.
Netdev 2.1 is a community-driven conference geared towards Linux
netheads. Linux kernel networking and user space utilization of the
interfaces to the Linux kernel networking subsystem are the focus.
If you are using Linux as a boot system for proprietary networking, then
this conference _may not be for you_.
Netdev2.1 will be held in Montreal April 6-8
For more details visit: www.netdevconf.org
Netdev 2.1 has a theme: IOT networking and DDOS.
Submissions in that area are highly encouraged.
Current topics include:
IOT networking.
DDOS.
Wireless.
Performance analysis and improvement.
Networking hardware and offload.
Netfilter.
Traffic control.
Different networking layers (L2/3, etc.).
Security.
Additional topics can be suggested.
Session submissions
--------------------
We encourage submission of paper and tutorial proposals, though we
*highly highly discourage* submission of recycled talks. Your proposals
will be evaluated by the technical committee that will provide prompt
feedback to you. If your proposal is approved, you will be requested to
submit your Camera-ready paper.
Unlike other conferences where only the schedule is announced,
proposals will be regularly announced as they get accepted on our
website and on relevant lists and twitter.
Please stay within the relevant topic focus and tie to FOSS Linux
networking to make it easier for the technical committee to provide
quick feedback. In order to give a talk you must be registered.
If your proposal is accepted you will not be charged a conference fee
or your conference fee will be refunded to you when your talk gets
accepted.
Types of proposals
-------------------
1. BoF
This serves to carry out initial discussions on some topic without any
pre-planned agenda. At least one person is responsible for introducing
the topic, chairing and moderating it. You have to list a few people
that will be planning to participate in the discussion. Expect people
from the public to participate actively in the discussions.
The lifetime of a BOF may be only one or two Netdev conference
gatherings. We discourage perpetual BOFs. BoFs don't need to have an
existing networking subsystem or mailing list. BOFs also don't need to
strive to be upgraded to be a Workshop in the future. Their longevity
could only be one conference. The sitting format could vary and be
either lecture or round table format depending on the proposal.
2. Talk
At least one person (of possibly multiple authors) is responsible for
the presentation. Details proposal/development plans to the public for
45 minutes.
A paper submission of the talk is expected (please use the provided
template). The paper has to be a minimum of two pages and not to exceed
10 pages (not including the references).
3. Tutorial
This implies planned agenda too.
Introduces audience to a topic.
Includes practical examples on using the functionality.
Functionality should already be in mainline or at least have been posted
already.
4. Workshops
Workshops are centered around existing networking subsystems.
Workshops are intended to be an extension of the mailing list in the
sense that many times previous discussions from the mailing list (or
that could otherwise have happened there) are taken to the round-table
to simplify the decision-making process.
The networking subsystem maintainer(s) should at least prepare a
list of agenda items well before the workshop takes place to allow
participants to come prepared; this makes the discussions most
productive.
Sometimes brain-storming sessions will also be appropriate where
being prepared is less important, for example for discussions
around new user requirements this can be very valuable.
At the workshop meeting itself discussions prevail and notes are
later sent back to the mailing list; presentations are typically
- at the discretion of the chairs - only used where needed to
clarify a problem statement for discussion.
Submiting Proposals
-------------------
Your proposal must be sent to tech-committee@netdevconf.org before
February 20, 2017 with the following format:
Title: Title of the proposal
Type: BoF, Talk, Tutorial.
Description: (350 words max).
Submitter names:
Estimated time: (talk = 45 minutes max., tutorial = 90 minutes max.).
Once your proposal is accepted, please prepare your paper based on the
conference template (odt or latex).
How to submit your paper
------------------------
Once your proposal is accepted and you have been invited to submit a
paper, please send the paper to both info@netdevconf.org and
tech-committee@netdevconf.org.
Deadlines
---------
February 20, 2017 Call for proposals close
Paper submission for review March 27, 2017
Slides submission April 3, 2017
How to submit your slides
-------------------------
If your slides of your talk are ready, please send the PDF to:
info@netdevconf.org.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ath10k: Search SMBIOS for OEM board file extension
From: Waldemar Rymarkiewicz @ 2017-01-16 14:58 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all, Valo, Kalle, ath10k, Bartosz Markowski, Chang, Robert,
Liu, Alan, linux-wireless
In-Reply-To: <201701150241.yCa5lXiT%fengguang.wu@intel.com>
On 14 January 2017 at 19:09, kbuild test robot <lkp@intel.com> wrote:
> Hi Waldemar,
>
> [auto build test WARNING on ath6kl/ath-next]
> [also build test WARNING on v4.10-rc3 next-20170113]
> [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/Waldemar-Rymarkiewicz/ath10k-Search-SMBIOS-for-OEM-board-file-extension/20170115-005232
> base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
> config: xtensa-allmodconfig (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 4.9.0
> reproduce:
> wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=xtensa
>
> All warnings (new ones prefixed by >>):
>
> drivers/net/wireless/ath/ath10k/core.c: In function 'ath10k_core_check_bdfext':
>>> drivers/net/wireless/ath/ath10k/core.c:754:2: warning: ignoring return value of 'strscpy', declared with attribute warn_unused_result [-Wunused-result]
> strscpy(ar->id.bdf_ext, bdf_ext + strlen(magic),
> ^
I will fix and send v2.
Thanks,
/Waldek
^ permalink raw reply
* Re: Searching new home for ath[59]k-devel mailing lists
From: Kalle Valo @ 2017-01-16 13:49 UTC (permalink / raw)
To: Michael Renzmann; +Cc: linux-wireless
In-Reply-To: <49712.217.24.3.26.1484568941.squirrel@webmail.madwifi-project.org>
Hi Michael,
"Michael Renzmann" <mrenzmann@madwifi-project.org> writes:
> Michael Renzmann wrote:
>> Someone should also update the "Mailing list" section of [1] accordingly.
>> I guess one needs to have a valid user account for that to do, and I don't
>> have one atm.
>
> I now have an account, but am not sure how to proceed.
>
> ath5k-devel is referenced on the ath5k driver page, and ath9k-devel is
> referenced by the driver pages of ath9k and ath9k_htc. All three pages
> have a section "Mailing list", that pages of other drivers (without
> dedicated lists) don't seem to have.
>
> Two options come to my mind:
>
> 1. Entirely remove the section "Mailing list".
>
> 2. Edit the section; point interested developers to the linux-wireless
> list for future discussion, and also reference the list archives of the
> old list for those who are interested in what was discussed in the past.
>
> Opinions or other suggestions, anyone?
I would go for option 2, not everyone know about linux-wireless mailing
list so better to document that properly in the wiki.
--
Kalle Valo
^ permalink raw reply
* Re: Support of rtl8723bs
From: Jes Sorensen @ 2017-01-16 13:25 UTC (permalink / raw)
To: Hanno Zulla; +Cc: Bastien Nocera, Larry Finger, anthony.wong, linux-wireless
In-Reply-To: <5ff75d7f-3017-1028-eacb-57e37f2c03c1@hanno.de>
Hanno Zulla <abos@hanno.de> writes:
> Hi,
>
> has there been any progress on the rtl8723bs / sdio issue?
>
> There were no updates to this mailing list or the usual git repositories
> since this was last discussed, unless I missed the proper place to look
> for this.
>
> I'm sorry that I can't be more helpful with actual development, but am
> eager to help with testing this device.
>
> Thank you,
> Hanno
Hanno,
The 8723bs project is currently in idle mode, I haven't had time to
spend time on it for the last couple of months.
Cheers,
Jes
^ permalink raw reply
* Re: Support of rtl8723bs
From: Hanno Zulla @ 2017-01-16 13:09 UTC (permalink / raw)
To: Jes Sorensen, Bastien Nocera; +Cc: Larry Finger, anthony.wong, linux-wireless
In-Reply-To: <wrfj4m5lhzja.fsf@redhat.com>
Hi,
has there been any progress on the rtl8723bs / sdio issue?
There were no updates to this mailing list or the usual git repositories
since this was last discussed, unless I missed the proper place to look
for this.
I'm sorry that I can't be more helpful with actual development, but am
eager to help with testing this device.
Thank you,
Hanno
^ permalink raw reply
* Re: Searching new home for ath[59]k-devel mailing lists
From: Michael Renzmann @ 2017-01-16 12:15 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <49460.217.24.3.26.1484376491.squirrel@webmail.madwifi-project.org>
Hi Kalle, hi all.
Michael Renzmann wrote:
> Someone should also update the "Mailing list" section of [1] accordingly.
> I guess one needs to have a valid user account for that to do, and I don't
> have one atm.
I now have an account, but am not sure how to proceed.
ath5k-devel is referenced on the ath5k driver page, and ath9k-devel is
referenced by the driver pages of ath9k and ath9k_htc. All three pages
have a section "Mailing list", that pages of other drivers (without
dedicated lists) don't seem to have.
Two options come to my mind:
1. Entirely remove the section "Mailing list".
2. Edit the section; point interested developers to the linux-wireless
list for future discussion, and also reference the list archives of the
old list for those who are interested in what was discussed in the past.
Opinions or other suggestions, anyone?
Bye, Mike
^ permalink raw reply
* [RFC V2 0/5] cfg80211: support multiple scheduled scans
From: Arend van Spriel @ 2017-01-16 11:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
After sending out the initial RFC for multiple scheduled scan support [1]
here a series that deal with it all (I hope) so including events and the
driver function call apis. Resending it due to build issue and it was based
on old mac80211-next master revision.
*Now* it does apply to the master branch of the mac80211-next repository.
Arend van Spriel (5):
nl80211: allow multiple active scheduled scan requests
nl80211: include request id in scheduled scan event messages
cfg80211: add request id parameter to .sched_scan_stop() signature
cfg80211: add request id to cfg80211_sched_scan_results() api
cfg80211: add request id in cfg80211_sched_scan_stopped{,_rtnl}() api
drivers/net/wireless/ath/ath6kl/cfg80211.c | 4 +-
drivers/net/wireless/ath/ath6kl/wmi.c | 2 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 10 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 8 +-
drivers/net/wireless/marvell/mwifiex/main.c | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_event.c | 2 +-
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 2 +-
include/net/cfg80211.h | 32 +++--
include/uapi/linux/nl80211.h | 12 +-
net/mac80211/cfg.c | 3 +-
net/mac80211/pm.c | 2 +-
net/mac80211/scan.c | 4 +-
net/mac80211/util.c | 2 +-
net/wireless/core.c | 31 +++--
net/wireless/core.h | 11 +-
net/wireless/nl80211.c | 62 +++++++---
net/wireless/nl80211.h | 3 +-
net/wireless/rdev-ops.h | 8 +-
net/wireless/scan.c | 135 +++++++++++++++------
net/wireless/trace.h | 54 ++++++---
21 files changed, 271 insertions(+), 120 deletions(-)
--
1.9.1
^ permalink raw reply
* [RFC V2 3/5] cfg80211: add request id parameter to .sched_scan_stop() signature
From: Arend van Spriel @ 2017-01-16 11:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1484566941-27000-1-git-send-email-arend.vanspriel@broadcom.com>
For multiple scheduled scan support the driver needs to know which
scheduled scan request is being stopped. Pass the request id in the
.sched_scan_stop() callback.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
---
drivers/net/wireless/ath/ath6kl/cfg80211.c | 2 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 6 +++---
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
include/net/cfg80211.h | 15 ++++++++-------
net/mac80211/cfg.c | 3 ++-
net/wireless/rdev-ops.h | 6 +++---
net/wireless/scan.c | 2 +-
net/wireless/trace.h | 10 +++++-----
8 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c b/drivers/net/wireless/ath/ath6kl/cfg80211.c
index b7fe0af..1509286 100644
--- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
+++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
@@ -3354,7 +3354,7 @@ static int ath6kl_cfg80211_sscan_start(struct wiphy *wiphy,
}
static int ath6kl_cfg80211_sscan_stop(struct wiphy *wiphy,
- struct net_device *dev)
+ struct net_device *dev, u64 reqid)
{
struct ath6kl_vif *vif = netdev_priv(dev);
bool stopped;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..8280f19 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3392,7 +3392,7 @@ static int brcmf_start_internal_escan(struct brcmf_if *ifp,
}
static int brcmf_cfg80211_sched_scan_stop(struct wiphy *wiphy,
- struct net_device *ndev)
+ struct net_device *ndev, u64 reqid)
{
struct brcmf_cfg80211_info *cfg = wiphy_to_cfg(wiphy);
struct brcmf_if *ifp = netdev_priv(ndev);
@@ -3595,7 +3595,7 @@ static s32 brcmf_cfg80211_resume(struct wiphy *wiphy)
cfg->wowl.pre_pmmode);
cfg->wowl.active = false;
if (cfg->wowl.nd_enabled) {
- brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev);
+ brcmf_cfg80211_sched_scan_stop(cfg->wiphy, ifp->ndev, 0);
brcmf_fweh_unregister(cfg->pub, BRCMF_E_PFN_NET_FOUND);
brcmf_fweh_register(cfg->pub, BRCMF_E_PFN_NET_FOUND,
brcmf_notify_sched_scan_results);
@@ -3679,7 +3679,7 @@ static s32 brcmf_cfg80211_suspend(struct wiphy *wiphy,
/* Stop scheduled scan */
if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_PNO))
- brcmf_cfg80211_sched_scan_stop(wiphy, ndev);
+ brcmf_cfg80211_sched_scan_stop(wiphy, ndev, 0);
/* end any scanning */
if (test_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 1e3bd43..243349476 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -2701,7 +2701,7 @@ static int mwifiex_set_ibss_params(struct mwifiex_private *priv,
* previous bgscan configuration in the firmware
*/
static int mwifiex_cfg80211_sched_scan_stop(struct wiphy *wiphy,
- struct net_device *dev)
+ struct net_device *dev, u64 reqid)
{
struct mwifiex_private *priv = mwifiex_netdev_get_priv(dev);
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 4b98ff8..0a65cfe 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2709,12 +2709,12 @@ struct cfg80211_nan_func {
* @set_cqm_txe_config: Configure connection quality monitor TX error
* thresholds.
* @sched_scan_start: Tell the driver to start a scheduled scan.
- * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan. This
- * call must stop the scheduled scan and be ready for starting a new one
- * before it returns, i.e. @sched_scan_start may be called immediately
- * after that again and should not fail in that case. The driver should
- * not call cfg80211_sched_scan_stopped() for a requested stop (when this
- * method returns 0.)
+ * @sched_scan_stop: Tell the driver to stop an ongoing scheduled scan with
+ * given request id. This call must stop the scheduled scan and be ready
+ * for starting a new one before it returns, i.e. @sched_scan_start may be
+ * called immediately after that again and should not fail in that case.
+ * The driver should not call cfg80211_sched_scan_stopped() for a requested
+ * stop (when this method returns 0).
*
* @mgmt_frame_register: Notify driver that a management frame type was
* registered. The callback is allowed to sleep.
@@ -3009,7 +3009,8 @@ struct cfg80211_ops {
int (*sched_scan_start)(struct wiphy *wiphy,
struct net_device *dev,
struct cfg80211_sched_scan_request *request);
- int (*sched_scan_stop)(struct wiphy *wiphy, struct net_device *dev);
+ int (*sched_scan_stop)(struct wiphy *wiphy, struct net_device *dev,
+ u64 reqid);
int (*set_rekey_data)(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_gtk_rekey_data *data);
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a0be2f6..85748d0 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2198,7 +2198,8 @@ static void ieee80211_abort_scan(struct wiphy *wiphy, struct wireless_dev *wdev)
}
static int
-ieee80211_sched_scan_stop(struct wiphy *wiphy, struct net_device *dev)
+ieee80211_sched_scan_stop(struct wiphy *wiphy, struct net_device *dev,
+ u64 reqid)
{
struct ieee80211_local *local = wiphy_priv(wiphy);
diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
index 9ada5e2..9da0701 100644
--- a/net/wireless/rdev-ops.h
+++ b/net/wireless/rdev-ops.h
@@ -809,11 +809,11 @@ static inline int rdev_get_antenna(struct cfg80211_registered_device *rdev,
}
static inline int rdev_sched_scan_stop(struct cfg80211_registered_device *rdev,
- struct net_device *dev)
+ struct net_device *dev, u64 reqid)
{
int ret;
- trace_rdev_sched_scan_stop(&rdev->wiphy, dev);
- ret = rdev->ops->sched_scan_stop(&rdev->wiphy, dev);
+ trace_rdev_sched_scan_stop(&rdev->wiphy, dev, reqid);
+ ret = rdev->ops->sched_scan_stop(&rdev->wiphy, dev, reqid);
trace_rdev_return_int(&rdev->wiphy, ret);
return ret;
}
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index f2b2064..04615338 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -423,7 +423,7 @@ int cfg80211_stop_sched_scan_req(struct cfg80211_registered_device *rdev,
ASSERT_RTNL();
if (!driver_initiated) {
- int err = rdev_sched_scan_stop(rdev, req->dev);
+ int err = rdev_sched_scan_stop(rdev, req->dev, req->reqid);
if (err)
return err;
}
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 7990c07..8c04685 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -576,11 +576,6 @@
TP_ARGS(wiphy, netdev)
);
-DEFINE_EVENT(wiphy_netdev_evt, rdev_sched_scan_stop,
- TP_PROTO(struct wiphy *wiphy, struct net_device *netdev),
- TP_ARGS(wiphy, netdev)
-);
-
DEFINE_EVENT(wiphy_netdev_evt, rdev_set_rekey_data,
TP_PROTO(struct wiphy *wiphy, struct net_device *netdev),
TP_ARGS(wiphy, netdev)
@@ -1610,6 +1605,11 @@
TP_ARGS(wiphy, netdev, id)
);
+DEFINE_EVENT(wiphy_netdev_id_evt, rdev_sched_scan_stop,
+ TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, u64 id),
+ TP_ARGS(wiphy, netdev, id)
+);
+
TRACE_EVENT(rdev_tdls_mgmt,
TP_PROTO(struct wiphy *wiphy, struct net_device *netdev,
u8 *peer, u8 action_code, u8 dialog_token,
--
1.9.1
^ permalink raw reply related
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