* Re: [v2,1/3] mwifiex: pcie: use posted write to wake up firmware
From: Kalle Valo @ 2017-01-20 9:46 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Cathy Luo, Dmitry Torokhov, Brian Norris
In-Reply-To: <20170113233538.36196-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Depending on system factors (e.g., the PCIe link PM state), the first
> read to wake up the Wifi firmware can take a long time. There is no
> reason to use a (blocking, non-posted) read at this point, so let's just
> use a write instead. Write vs. read doesn't matter functionality-wise --
> it's just a dummy operation. But let's make sure to re-write with the
> correct "ready" signature, since we check for that in other parts of the
> driver.
>
> This has been shown to decrease the time spent blocking in this function
> on RK3399.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
3 patches applied to wireless-drivers-next.git, thanks.
062e008a6e83 mwifiex: pcie: use posted write to wake up firmware
5d5ddb5e0d9b mwifiex: pcie: don't loop/retry interrupt status checks
fe1167883939 mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE()
--
https://patchwork.kernel.org/patch/9516615/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: mwifiex: don't complain about 'unknown event id: 0x63'
From: Kalle Valo @ 2017-01-20 9:47 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-kernel,
linux-wireless, Cathy Luo, Brian Norris
In-Reply-To: <20170114021657.147016-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> Marvell folks tell me this is a debugging event that the driver doesn't
> need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of
> these sorts of messages at (for instance) boot time:
>
> [ 13.825848] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
> [ 14.838561] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
> [ 14.850397] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
> [ 32.529923] mwifiex_pcie 0000:01:00.0: event: unknown event id: 0x63
>
> Let's handle this "event" with a much lower verbosity.
>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
0ed917d09d51 mwifiex: don't complain about 'unknown event id: 0x63'
--
https://patchwork.kernel.org/patch/9516687/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
From: Kalle Valo @ 2017-01-20 9:48 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-mmc, brcm80211-dev-list.pdl, linux-wireless, ulf.hansson,
arend.vanspriel, franky.lin, hante.meuleman, Martin Blumenstingl
In-Reply-To: <20170116101757.20483-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
> 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>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
> Tested-by: Andreas Färber <afaerber@suse.de>
Patch applied to wireless-drivers-next.git, thanks.
a62a77881b1b brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
--
https://patchwork.kernel.org/patch/9518447/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/5] rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
From: Kalle Valo @ 2017-01-20 9:49 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless
In-Reply-To: <20170117231856.5075-2-Jes.Sorensen@gmail.com>
Jes Sorensen <jes.sorensen@gmail.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> Device reported as working fine, so tell the driver not to warn about
> it being untested.
>
> Reported-by: Aex Aey <aexaey@gmail.com>
> Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
5 patches applied to wireless-drivers-next.git, thanks.
d607e396566a rtl8xxxu: Mark 8192eu device 0x0bda:0x818b as tested
c14239f23adb rtl8xxxu: Add another 8192eu device to the USB list
66dfa26ebca8 rtl8xxxu: Add USB ID for D-Link DWA-131 rev E1 (rtl8192eu)
5407fd7de69f rtl8xxxu: Add additional USB IDs for rtl8192eu devices
1ee83789fc1f rtl8xxxu: Update author/maintainer contact info
--
https://patchwork.kernel.org/patch/9522313/
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: fix incorrect event channel deduction
From: Kalle Valo @ 2017-01-20 10:03 UTC (permalink / raw)
To: Gavin Li
Cc: arend.vanspriel, franky.lin, hante.meuleman, linux-wireless,
brcm80211-dev-list.pdl, stable, Gavin Li
In-Reply-To: <20170117232405.7672-1-gavinli@thegavinli.com>
Gavin Li <gavinli@thegavinli.com> wrote:
> From: Gavin Li <git@thegavinli.com>
>
> brcmf_sdio_fromevntchan() was being called on the the data frame
> rather than the software header, causing some frames to be
> mischaracterized as on the event channel rather than the data channel.
>
> This fixes a major performance regression (due to dropped packets). With
> this patch the download speed jumped from 1Mbit/s back up to 40MBit/s due
> to the sheer amount of packets being incorrectly processed.
>
> Fixes: c56caa9db8ab ("brcmfmac: screening firmware event packet")
> Signed-off-by: Gavin Li <git@thegavinli.com>
> Cc: <stable@vger.kernel.org> # 4.7+
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> [kvalo@codeaurora.org: improve commit logs based on email discussion]
Patch applied to wireless-drivers-next.git, thanks.
8e290cecdd01 brcmfmac: fix incorrect event channel deduction
--
https://patchwork.kernel.org/patch/9522185/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2, 1/4] brcmfmac: drop unneeded function declarations from headers
From: Kalle Valo @ 2017-01-20 10:04 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: <20170118104854.32231-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Functions brcmf_c_prec_enq and brcmf_sdio_init don't exist so we
> really don't need their declarations. Function brcmf_parse_tlvs is used
> in cfg80211.c only so make it static and drop from header as well.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
4 patches applied to wireless-drivers-next.git, thanks.
c8d870794d5d brcmfmac: drop unneeded function declarations from headers
f5611e038172 brcmfmac: move brcmf_c_set_joinpref_default declaration to common.h
bfa7295e5b4d brcmfmac: drop brcmf_bus_detach and inline its code
e8cd47501fa0 brcmfmac: rename brcmf_bus_start function to brcmf_bus_started
--
https://patchwork.kernel.org/patch/9523097/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2, 1/3] rtlwifi: Download firmware as bytes rather than as dwords
From: Kalle Valo @ 2017-01-20 10:06 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Ping-Ke Shih
In-Reply-To: <20170119202808.27752-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> The firmware is read from disk as a little-endian byte string. The code
> that loads the firmware into the device transfers it as 4-byte quantities.
> The routines that write multi-byte quantities on BE hardware assume that
> the data are in CPU order, and automatically do the conversion to the LE
> order required by the device. As a result, the firmware is transmitted
> incorrectly. Rather than do multiple byte swaps on the data, the download
> routine is revised to transmit bytes rather than dwords. Although the
> number of I/O operations is increased, the firmware is not often loaded.
>
> All drivers have the same bug, and use essentially the same code to
> download firmware. These routines have been moved into rtlwifi.
>
> Some CamelCase variables have been renamed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
3 patches applied to wireless-drivers-next.git, thanks.
89d32c9071aa rtlwifi: Download firmware as bytes rather than as dwords
69d8597e9fe5 rtlwifi: rtl8192cu: Calculate descriptor checksum correctly for BE
106e0deca1ac rtlwifi: rtl8192cu: Convert driver to use common macros
--
https://patchwork.kernel.org/patch/9526749/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one
From: Arend Van Spriel @ 2017-01-20 10:13 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170118142703.9824-1-zajec5@gmail.com>
On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows simplifying the code by adding a simple IS_ENABLED check for
> CONFIG_BRCMDB symbol.
Nice!
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 6687812..1fe4aa9 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -45,20 +45,16 @@
> #undef pr_fmt
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#ifndef CONFIG_BRCM_TRACING
> /* Macro for error messages. net_ratelimit() is used when driver
> * debugging is not selected. When debugging the driver error
> * messages are as important as other tracing or even more so.
> */
> -#ifndef CONFIG_BRCM_TRACING
> -#ifdef CONFIG_BRCMDBG
> -#define brcmf_err(fmt, ...) pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
> -#else
> #define brcmf_err(fmt, ...) \
> do { \
> - if (net_ratelimit()) \
> + if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
> pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
> } while (0)
> -#endif
> #else
> __printf(2, 3)
> void __brcmf_err(const char *func, const char *fmt, ...);
>
^ permalink raw reply
* Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one
From: Arend Van Spriel @ 2017-01-20 10:14 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <da843f98-cd01-17f7-45cc-4530e8b87bfe@broadcom.com>
On 20-1-2017 11:13, Arend Van Spriel wrote:
> On 18-1-2017 15:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This allows simplifying the code by adding a simple IS_ENABLED check for
>> CONFIG_BRCMDB symbol.
Actually it should be CONFIG_BRCMDBG above.
Kalle,
Can you fix that in the commit message?
Regards,
Arend
> Nice!
>
> Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h | 8 ++------
>> 1 file changed, 2 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> index 6687812..1fe4aa9 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
>> @@ -45,20 +45,16 @@
>> #undef pr_fmt
>> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>
>> +#ifndef CONFIG_BRCM_TRACING
>> /* Macro for error messages. net_ratelimit() is used when driver
>> * debugging is not selected. When debugging the driver error
>> * messages are as important as other tracing or even more so.
>> */
>> -#ifndef CONFIG_BRCM_TRACING
>> -#ifdef CONFIG_BRCMDBG
>> -#define brcmf_err(fmt, ...) pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
>> -#else
>> #define brcmf_err(fmt, ...) \
>> do { \
>> - if (net_ratelimit()) \
>> + if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
>> pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
>> } while (0)
>> -#endif
>> #else
>> __printf(2, 3)
>> void __brcmf_err(const char *func, const char *fmt, ...);
>>
^ permalink raw reply
* Re: [v2, 1/3] rtlwifi: Redo debugging macros RTPRINT and RT_PRINT_DATA
From: Kalle Valo @ 2017-01-20 10:05 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Larry Finger, Ping-Ke Shih
In-Reply-To: <20170119172521.32643-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> These two debugging formss implement debugging using rather complicated
> macro constructions. These are replaced with compiled code that is easier
> to understand.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Ping-Ke Shih <pkshih@realtek.com>
3 patches applied to wireless-drivers-next.git, thanks.
102e295ed5a4 rtlwifi: Redo debugging macros RTPRINT and RT_PRINT_DATA
c34df318ec9f rtlwifi: Convert COMP_XX entries into a proper debugging mask
9336d376edf1 rtlwifi: Remove debugging entry in sysfs
--
https://patchwork.kernel.org/patch/9526577/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] brcmfmac: drop duplicated core selection from brcmf_pcie_attach
From: Arend Van Spriel @ 2017-01-20 10:19 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki,
Hante Meuleman
In-Reply-To: <20170119095125.12276-1-zajec5@gmail.com>
On 19-1-2017 10:51, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> It was left after reworking PCIe reset in commit 07fe2e38c7fd
> ("brcmfmac: Reset PCIE devices after recognition.").
>
> Cc: Hante Meuleman <hante.meuleman@broadcom.com>
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> index 19db8f2..6fae4cf 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
> @@ -601,7 +601,6 @@ static void brcmf_pcie_attach(struct brcmf_pciedev_info *devinfo)
> {
> u32 config;
>
> - brcmf_pcie_select_core(devinfo, BCMA_CORE_PCIE2);
> /* BAR1 window may not be sized properly */
> brcmf_pcie_select_core(devinfo, BCMA_CORE_PCIE2);
> brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_CONFIGADDR, 0x4e0);
>
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for BCM43455 with modalias sdio:c00v02D0dA9BF
From: Ulf Hansson @ 2017-01-20 10:29 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-mmc@vger.kernel.org, brcm80211-dev-list.pdl,
linux-wireless@vger.kernel.org, Kalle Valo, arend.vanspriel,
franky.lin, hante.meuleman
In-Reply-To: <20170116101757.20483-1-martin.blumenstingl@googlemail.com>
On 16 January 2017 at 11:17, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> 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: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> 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(+)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> index 72139b579b18..5bc2ba214735 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
> @@ -1104,6 +1104,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4345),
> + BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43455),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4354),
> BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4356),
> { /* end: all zeroes */ }
> diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
> index d43ef96bf075..71b113e1223f 100644
> --- a/include/linux/mmc/sdio_ids.h
> +++ b/include/linux/mmc/sdio_ids.h
> @@ -36,6 +36,7 @@
> #define SDIO_DEVICE_ID_BROADCOM_43362 0xa962
> #define SDIO_DEVICE_ID_BROADCOM_43430 0xa9a6
> #define SDIO_DEVICE_ID_BROADCOM_4345 0x4345
> +#define SDIO_DEVICE_ID_BROADCOM_43455 0xa9bf
> #define SDIO_DEVICE_ID_BROADCOM_4354 0x4354
> #define SDIO_DEVICE_ID_BROADCOM_4356 0x4356
>
> --
> 2.11.0
>
^ permalink raw reply
* Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages
From: Arend Van Spriel @ 2017-01-20 10:26 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170118142703.9824-2-zajec5@gmail.com>
On 18-1-2017 15:27, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This macro accepts an extra argument of struct brcmf_pub pointer. It
> allows referencing struct device and printing error using dev_err. This
> is very useful on devices with more than one wireless card suppored by
> brcmfmac. Thanks for dev_err it's possible to identify device that error
> is related to.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> I could convert few more brcmf_err calls to this new brcmf_err_pub but I don't
> want to spent too much time on this in case someone has a better idea.
>
> If you do, comment! :)
I do not, but still comment ;-). Like the idea. Was on our list because
it is damn convenient when testing on router with multiple devices. I
would prefer to replace the existing brcmf_err() rather than introducing
a new one and would like to do the same for brcmf_dbg(). However, not
all call sites have a struct brcmf_pub instance available. Everywhere
before completing brcmf_attach() that is.
Regards,
Arend
> Example
> Before:
> [ 14.735640] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [ 15.155732] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [ 15.535682] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> After:
> [ 14.746754] brcmfmac 0000:01:00.0: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [ 15.166854] brcmfmac 0001:03:00.0: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> [ 15.546807] brcmfmac 0001:04:00.0: brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
> ---
> .../wireless/broadcom/brcm80211/brcmfmac/common.c | 19 ++++++-------
> .../wireless/broadcom/brcm80211/brcmfmac/core.c | 31 +++++++++++-----------
> .../wireless/broadcom/brcm80211/brcmfmac/debug.h | 17 ++++++++----
> .../broadcom/brcm80211/brcmfmac/tracepoint.c | 4 +--
> 4 files changed, 40 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 5fb4a14..7a05de78 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -108,6 +108,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> {
> s8 eventmask[BRCMF_EVENTING_MASK_LEN];
> u8 buf[BRCMF_DCMD_SMLEN];
> + struct brcmf_pub *pub = ifp->drvr;
> struct brcmf_rev_info_le revinfo;
> struct brcmf_rev_info *ri;
> char *ptr;
> @@ -117,7 +118,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> err = brcmf_fil_iovar_data_get(ifp, "cur_etheraddr", ifp->mac_addr,
> sizeof(ifp->mac_addr));
> if (err < 0) {
> - brcmf_err("Retreiving cur_etheraddr failed, %d\n", err);
> + brcmf_err_pub(pub, "Retreiving cur_etheraddr failed, %d\n", err);
> goto done;
> }
> memcpy(ifp->drvr->mac, ifp->mac_addr, sizeof(ifp->drvr->mac));
> @@ -126,7 +127,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> &revinfo, sizeof(revinfo));
> ri = &ifp->drvr->revinfo;
> if (err < 0) {
> - brcmf_err("retrieving revision info failed, %d\n", err);
> + brcmf_err_pub(pub, "retrieving revision info failed, %d\n", err);
> } else {
> ri->vendorid = le32_to_cpu(revinfo.vendorid);
> ri->deviceid = le32_to_cpu(revinfo.deviceid);
> @@ -153,7 +154,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> strcpy(buf, "ver");
> err = brcmf_fil_iovar_data_get(ifp, "ver", buf, sizeof(buf));
> if (err < 0) {
> - brcmf_err("Retreiving version information failed, %d\n",
> + brcmf_err_pub(pub, "Retreiving version information failed, %d\n",
> err);
> goto done;
> }
> @@ -161,7 +162,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> strsep(&ptr, "\n");
>
> /* Print fw version info */
> - brcmf_err("Firmware version = %s\n", buf);
> + brcmf_err_pub(pub, "Firmware version = %s\n", buf);
>
> /* locate firmware version number for ethtool */
> ptr = strrchr(buf, ' ') + 1;
> @@ -170,7 +171,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> /* set mpc */
> err = brcmf_fil_iovar_int_set(ifp, "mpc", 1);
> if (err) {
> - brcmf_err("failed setting mpc\n");
> + brcmf_err_pub(pub, "failed setting mpc\n");
> goto done;
> }
>
> @@ -180,14 +181,14 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> err = brcmf_fil_iovar_data_get(ifp, "event_msgs", eventmask,
> BRCMF_EVENTING_MASK_LEN);
> if (err) {
> - brcmf_err("Get event_msgs error (%d)\n", err);
> + brcmf_err_pub(pub, "Get event_msgs error (%d)\n", err);
> goto done;
> }
> setbit(eventmask, BRCMF_E_IF);
> err = brcmf_fil_iovar_data_set(ifp, "event_msgs", eventmask,
> BRCMF_EVENTING_MASK_LEN);
> if (err) {
> - brcmf_err("Set event_msgs error (%d)\n", err);
> + brcmf_err_pub(pub, "Set event_msgs error (%d)\n", err);
> goto done;
> }
>
> @@ -195,7 +196,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_SCAN_CHANNEL_TIME,
> BRCMF_DEFAULT_SCAN_CHANNEL_TIME);
> if (err) {
> - brcmf_err("BRCMF_C_SET_SCAN_CHANNEL_TIME error (%d)\n",
> + brcmf_err_pub(pub, "BRCMF_C_SET_SCAN_CHANNEL_TIME error (%d)\n",
> err);
> goto done;
> }
> @@ -204,7 +205,7 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp)
> err = brcmf_fil_cmd_int_set(ifp, BRCMF_C_SET_SCAN_UNASSOC_TIME,
> BRCMF_DEFAULT_SCAN_UNASSOC_TIME);
> if (err) {
> - brcmf_err("BRCMF_C_SET_SCAN_UNASSOC_TIME error (%d)\n",
> + brcmf_err_pub(pub, "BRCMF_C_SET_SCAN_UNASSOC_TIME error (%d)\n",
> err);
> goto done;
> }
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> index b73a55b..a42007b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -59,7 +59,7 @@ struct brcmf_if *brcmf_get_ifp(struct brcmf_pub *drvr, int ifidx)
> s32 bsscfgidx;
>
> if (ifidx < 0 || ifidx >= BRCMF_MAX_IFS) {
> - brcmf_err("ifidx %d out of range\n", ifidx);
> + brcmf_err_pub(drvr, "ifidx %d out of range\n", ifidx);
> return NULL;
> }
>
> @@ -204,7 +204,8 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
>
> /* Can the device send data? */
> if (drvr->bus_if->state != BRCMF_BUS_UP) {
> - brcmf_err("xmit rejected state=%d\n", drvr->bus_if->state);
> + brcmf_err_pub(drvr, "xmit rejected state=%d\n",
> + drvr->bus_if->state);
> netif_stop_queue(ndev);
> dev_kfree_skb(skb);
> ret = -ENODEV;
> @@ -222,7 +223,7 @@ static netdev_tx_t brcmf_netdev_start_xmit(struct sk_buff *skb,
> dev_kfree_skb(skb);
> skb = skb2;
> if (skb == NULL) {
> - brcmf_err("%s: skb_realloc_headroom failed\n",
> + brcmf_err_pub(drvr, "%s: skb_realloc_headroom failed\n",
> brcmf_ifname(ifp));
> ret = -ENOMEM;
> goto done;
> @@ -466,7 +467,7 @@ static int brcmf_netdev_open(struct net_device *ndev)
>
> /* If bus is not ready, can't continue */
> if (bus_if->state != BRCMF_BUS_UP) {
> - brcmf_err("failed bus is not ready\n");
> + brcmf_err_pub(drvr, "failed bus is not ready\n");
> return -EAGAIN;
> }
>
> @@ -480,7 +481,7 @@ static int brcmf_netdev_open(struct net_device *ndev)
> ndev->features &= ~NETIF_F_IP_CSUM;
>
> if (brcmf_cfg80211_up(ndev)) {
> - brcmf_err("failed to bring up cfg80211\n");
> + brcmf_err_pub(drvr, "failed to bring up cfg80211\n");
> return -EIO;
> }
>
> @@ -525,7 +526,7 @@ int brcmf_net_attach(struct brcmf_if *ifp, bool rtnl_locked)
> else
> err = register_netdev(ndev);
> if (err != 0) {
> - brcmf_err("couldn't register the net device\n");
> + brcmf_err_pub(drvr, "couldn't register the net device\n");
> goto fail;
> }
>
> @@ -643,7 +644,7 @@ struct brcmf_if *brcmf_add_if(struct brcmf_pub *drvr, s32 bsscfgidx, s32 ifidx,
> */
> if (ifp) {
> if (ifidx) {
> - brcmf_err("ERROR: netdev:%s already exists\n",
> + brcmf_err_pub(drvr, "ERROR: netdev:%s already exists\n",
> ifp->ndev->name);
> netif_stop_queue(ifp->ndev);
> brcmf_net_detach(ifp->ndev, false);
> @@ -702,7 +703,7 @@ static void brcmf_del_if(struct brcmf_pub *drvr, s32 bsscfgidx,
> ifp = drvr->iflist[bsscfgidx];
> drvr->iflist[bsscfgidx] = NULL;
> if (!ifp) {
> - brcmf_err("Null interface, bsscfgidx=%d\n", bsscfgidx);
> + brcmf_err_pub(drvr, "Null interface, bsscfgidx=%d\n", bsscfgidx);
> return;
> }
> brcmf_dbg(TRACE, "Enter, bsscfgidx=%d, ifidx=%d\n", bsscfgidx,
> @@ -787,7 +788,7 @@ static int brcmf_inetaddr_changed(struct notifier_block *nb,
> ret = brcmf_fil_iovar_data_get(ifp, "arp_hostip", addr_table,
> sizeof(addr_table));
> if (ret) {
> - brcmf_err("fail to get arp ip table err:%d\n", ret);
> + brcmf_err_pub(drvr, "fail to get arp ip table err:%d\n", ret);
> return NOTIFY_OK;
> }
>
> @@ -804,7 +805,7 @@ static int brcmf_inetaddr_changed(struct notifier_block *nb,
> ret = brcmf_fil_iovar_data_set(ifp, "arp_hostip",
> &ifa->ifa_address, sizeof(ifa->ifa_address));
> if (ret)
> - brcmf_err("add arp ip err %d\n", ret);
> + brcmf_err_pub(drvr, "add arp ip err %d\n", ret);
> }
> break;
> case NETDEV_DOWN:
> @@ -816,7 +817,7 @@ static int brcmf_inetaddr_changed(struct notifier_block *nb,
> ret = brcmf_fil_iovar_data_set(ifp, "arp_hostip_clear",
> NULL, 0);
> if (ret) {
> - brcmf_err("fail to clear arp ip table err:%d\n",
> + brcmf_err_pub(drvr, "fail to clear arp ip table err:%d\n",
> ret);
> return NOTIFY_OK;
> }
> @@ -827,7 +828,7 @@ static int brcmf_inetaddr_changed(struct notifier_block *nb,
> &addr_table[i],
> sizeof(addr_table[i]));
> if (ret)
> - brcmf_err("add arp ip err %d\n",
> + brcmf_err_pub(drvr, "add arp ip err %d\n",
> ret);
> }
> }
> @@ -923,7 +924,7 @@ int brcmf_attach(struct device *dev, struct brcmf_mp_device *settings)
> /* Attach and link in the protocol */
> ret = brcmf_proto_attach(drvr);
> if (ret != 0) {
> - brcmf_err("brcmf_prot_attach failed\n");
> + brcmf_err_pub(drvr, "brcmf_prot_attach failed\n");
> goto fail;
> }
>
> @@ -1045,7 +1046,7 @@ int brcmf_bus_started(struct device *dev)
> return 0;
>
> fail:
> - brcmf_err("failed: %d\n", ret);
> + brcmf_err_pub(drvr, "failed: %d\n", ret);
> if (drvr->config) {
> brcmf_cfg80211_detach(drvr->config);
> drvr->config = NULL;
> @@ -1152,7 +1153,7 @@ int brcmf_netdev_wait_pend8021x(struct brcmf_if *ifp)
> MAX_WAIT_FOR_8021X_TX);
>
> if (!err)
> - brcmf_err("Timed out waiting for no pending 802.1x packets\n");
> + brcmf_err_pub(ifp->drvr, "Timed out waiting for no pending 802.1x packets\n");
>
> return !err;
> }
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> index 1fe4aa9..aab8c71 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.h
> @@ -50,16 +50,23 @@
> * debugging is not selected. When debugging the driver error
> * messages are as important as other tracing or even more so.
> */
> -#define brcmf_err(fmt, ...) \
> +#define __brcmf_err(dev, fmt, ...) \
> do { \
> if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
> - pr_err("%s: " fmt, __func__, ##__VA_ARGS__); \
> + dev_err(dev, "%s: " fmt, __func__, \
> + ##__VA_ARGS__); \
> } while (0)
> +#define brcmf_err(fmt, ...) \
> + __brcmf_err(NULL, fmt, ##__VA_ARGS__)
> +#define brcmf_err_pub(pub, fmt, ...) \
> + __brcmf_err(pub->bus_if->dev, fmt, ##__VA_ARGS__)
> #else
> -__printf(2, 3)
> -void __brcmf_err(const char *func, const char *fmt, ...);
> +__printf(3, 4)
> +void __brcmf_err(struct brcmf_pub *pub, const char *func, const char *fmt, ...);
> #define brcmf_err(fmt, ...) \
> - __brcmf_err(__func__, fmt, ##__VA_ARGS__)
> + __brcmf_err(NULL, __func__, fmt, ##__VA_ARGS__)
> +#define brcmf_err_pub(fmt, ...) \
> + __brcmf_err(pub, __func__, fmt, ##__VA_ARGS__)
> #endif
>
> #if defined(DEBUG) || defined(CONFIG_BRCM_TRACING)
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> index fe67559..3e8d60b 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/tracepoint.c
> @@ -21,7 +21,7 @@
> #include "tracepoint.h"
> #include "debug.h"
>
> -void __brcmf_err(const char *func, const char *fmt, ...)
> +void __brcmf_err(struct brcmf_pub *pub, const char *func, const char *fmt, ...)
> {
> struct va_format vaf = {
> .fmt = fmt,
> @@ -30,7 +30,7 @@ void __brcmf_err(const char *func, const char *fmt, ...)
>
> va_start(args, fmt);
> vaf.va = &args;
> - pr_err("%s: %pV", func, &vaf);
> + dev_err(pub ? pub->bus_if->dev, NULL, "%s: %pV", func, &vaf);
> trace_brcmf_err(func, &vaf);
> va_end(args);
> }
>
^ permalink raw reply
* Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one
From: Rafał Miłecki @ 2017-01-20 10:58 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <52453214-bab2-dc0b-c684-2389fe028442@broadcom.com>
On 20 January 2017 at 11:14, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 20-1-2017 11:13, Arend Van Spriel wrote:
>> On 18-1-2017 15:27, Rafa=C5=82 Mi=C5=82ecki wrote:
>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>
>>> This allows simplifying the code by adding a simple IS_ENABLED check fo=
r
>>> CONFIG_BRCMDB symbol.
>
> Actually it should be CONFIG_BRCMDBG above.
>
> Kalle,
>
> Can you fix that in the commit message?
It's only RFC, I'll make sure to fix that in final version
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH RFC 1/2] brcmfmac: merge two brcmf_err macros into one
From: Arend Van Spriel @ 2017-01-20 11:03 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <CACna6rwhe+Vupq=7CxQAQfRce2_gH7kNj1QwRyoCpTLms+mn5Q@mail.gmail.com>
On 20-1-2017 11:58, Rafał Miłecki wrote:
> On 20 January 2017 at 11:14, Arend Van Spriel
> <arend.vanspriel@broadcom.com> wrote:
>> On 20-1-2017 11:13, Arend Van Spriel wrote:
>>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>
>>>> This allows simplifying the code by adding a simple IS_ENABLED check for
>>>> CONFIG_BRCMDB symbol.
>>
>> Actually it should be CONFIG_BRCMDBG above.
>>
>> Kalle,
>>
>> Can you fix that in the commit message?
>
> It's only RFC, I'll make sure to fix that in final version
You're right. Missed that.
Regards,
Arend
^ permalink raw reply
* Re: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
From: Lino Sanfilippo @ 2017-01-20 11:14 UTC (permalink / raw)
To: Larry Finger
Cc: Bharat Kumar Gogada, chaoming_li, linux-wireless, linux-kernel,
kvalo, netdev, rgummal, Bharat Kumar Gogada
In-Reply-To: <b2e783f6-fa09-e287-8119-266299cdae22@lwfinger.net>
Hi,
>
>
> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
>
If you do this, please place the smp_rmb() before the if condition in the irq
handler like
smp_rmb();
if (rtlpci->irq_enabled == 0) {
return ret;
as I think that the suggestion I made before was not correct (sorry for the
confusion).
Regards,
Lino
^ permalink raw reply
* Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages
From: Rafał Miłecki @ 2017-01-20 11:17 UTC (permalink / raw)
To: Arend Van Spriel, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <8819000f-f70f-e8b3-ca52-eebf10a431ac@broadcom.com>
On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
> On 18-1-2017 15:27, Rafał Miłecki wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> This macro accepts an extra argument of struct brcmf_pub pointer. It
>> allows referencing struct device and printing error using dev_err. This
>> is very useful on devices with more than one wireless card suppored by
>> brcmfmac. Thanks for dev_err it's possible to identify device that error
>> is related to.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> I could convert few more brcmf_err calls to this new brcmf_err_pub but I don't
>> want to spent too much time on this in case someone has a better idea.
>>
>> If you do, comment! :)
>
> I do not, but still comment ;-). Like the idea. Was on our list because
> it is damn convenient when testing on router with multiple devices. I
> would prefer to replace the existing brcmf_err() rather than introducing
> a new one and would like to do the same for brcmf_dbg(). However, not
> all call sites have a struct brcmf_pub instance available. Everywhere
> before completing brcmf_attach() that is.
I decided to try new macro because:
1) I was too lazy to convert all calls at once
2) I could stick to brcmf_err when struct brcmf_pub isn't available yet
In theory we could pass NULL to dev_err, I'd result in something like:
[ 14.746754] (NULL device *): brcmf_c_preinit_dcmds: Firmware version = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
Unfortunately AFAIK it's not possible to handle
brcmf_err(NULL "Foo\n");
calls while keeping brcmf_err a macro.
I was thinking about something like:
#define brcmf_err(pub, fmt, ...) \
do { \
if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
dev_err(pub ? pub->bus_if->dev : NULL, \
"%s: " fmt, __func__, \
##__VA_ARGS__); \
} while (0)
but this wouldn't compile because for brcmf_err(NULL "Foo\n"); it would roll
out to:
dev_err(NULL ? NULL->bus_if->dev : NULL, "Foo\n");
I *can* support brcmf_err(NULL "Foo\n"); calls if I change brcmf_err from
macro to a function (inline probably). Do you think it's a good idea?
^ permalink raw reply
* Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages
From: Arend Van Spriel @ 2017-01-20 11:37 UTC (permalink / raw)
To: Rafał Miłecki, Kalle Valo
Cc: Franky Lin, Hante Meuleman, Pieter-Paul Giesberts, Franky Lin,
linux-wireless, brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <e67a5583-8a1b-b370-5dcb-8717197542fb@gmail.com>
On 20-1-2017 12:17, Rafał Miłecki wrote:
> On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
>> On 18-1-2017 15:27, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> This macro accepts an extra argument of struct brcmf_pub pointer. It
>>> allows referencing struct device and printing error using dev_err. This
>>> is very useful on devices with more than one wireless card suppored by
>>> brcmfmac. Thanks for dev_err it's possible to identify device that error
>>> is related to.
>>>
>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>> ---
>>> I could convert few more brcmf_err calls to this new brcmf_err_pub
>>> but I don't
>>> want to spent too much time on this in case someone has a better idea.
>>>
>>> If you do, comment! :)
>>
>> I do not, but still comment ;-). Like the idea. Was on our list because
>> it is damn convenient when testing on router with multiple devices. I
>> would prefer to replace the existing brcmf_err() rather than introducing
>> a new one and would like to do the same for brcmf_dbg(). However, not
>> all call sites have a struct brcmf_pub instance available. Everywhere
>> before completing brcmf_attach() that is.
>
> I decided to try new macro because:
> 1) I was too lazy to convert all calls at once
> 2) I could stick to brcmf_err when struct brcmf_pub isn't available yet
>
> In theory we could pass NULL to dev_err, I'd result in something like:
> [ 14.746754] (NULL device *): brcmf_c_preinit_dcmds: Firmware version
> = wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8e269
>
> Unfortunately AFAIK it's not possible to handle
> brcmf_err(NULL "Foo\n");
> calls while keeping brcmf_err a macro.
>
> I was thinking about something like:
> #define brcmf_err(pub, fmt, ...) \
> do { \
> if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
> dev_err(pub ? pub->bus_if->dev : NULL, \
> "%s: " fmt, __func__, \
> ##__VA_ARGS__); \
> } while (0)
>
> but this wouldn't compile because for brcmf_err(NULL "Foo\n"); it would
> roll
> out to:
> dev_err(NULL ? NULL->bus_if->dev : NULL, "Foo\n");
>
> I *can* support brcmf_err(NULL "Foo\n"); calls if I change brcmf_err from
> macro to a function (inline probably). Do you think it's a good idea?
I was wondering if brcmf_err(ptr, "bla\n") could determine the pointer
type and accept 'struct device *' and 'struct brcmf_pub *'. I think we
always have a struct device pointer. Only in brcmf_module_init() we do not.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] net: ethtool: avoid allocation failure for dump_regs
From: Kalle Valo @ 2017-01-20 11:44 UTC (permalink / raw)
To: David Miller; +Cc: linville, darcari, netdev, johannes.berg, linux-wireless
In-Reply-To: <20170119.142230.1012416564568457058.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Thu, 19 Jan 2017 20:08:30 +0200
>
>> "John W. Linville" <linville@tuxdriver.com> writes:
>>
>>> I forgot to Cc Johannes and Kalle...
>>
>> Also adding linux-wireless.
>>
>>> On Thu, Jan 19, 2017 at 09:15:09AM -0500, John W. Linville wrote:
>>>
>>>> I'm responsible for this mess. The original idea was for various
>>>> mac80211-based drivers to override the ethtool operation and provide
>>>> their own dump operation, but the mac80211 crowd never embraced
>>>> the idea.
>>>>
>>>> In the meantime, I added the default implementation which just
>>>> passed-up wdev->wiphy->hw_version as the version info for a 0-length
>>>> register dump. I then implemented a driver-specific regiser dump
>>>> handler for userland ethtool that would interpret the hardware version
>>>> information for the at76c50x-usb driver.
>>>>
>>>> So the net of it is, if we treat a return of 0 from get_regs_len()
>>>> as "not supported", we break this one driver-specific feature for
>>>> userland ethtool. Realistically, there are probably very few users
>>>> to care. But I can't guarantee that the number is zero.
>>
>> I know the number is not zero, because I remember using it years back
>> with something else than at76c50x-usb. But is the number more than one,
>> I don't know :)
>
> I'm trying to dig down and figure out why this problem is showing up now.
> ethtool_get_regs() has been using vzalloc() since 2011, and before that it
> used plain vmalloc().
>
> This code has therefore been using v{m,z}alloc() forever. What changed?
>
> The zero size check has been in the vmalloc implementation since at least
> 2009.
>
> I don't understand why this is all triggering and being noticed now. The
> whole ieee80211 "return zero length regs and return hw version in get_regs"
> thing should have been failing for at least 7 years now.
Maybe just nobody hasn't used it since? If my memory serves me right
(too often it does not) It's 6-7 years since I used this, and if the
kernel I worked on at the time was a year or two old, I might have used
a version without the zero size check.
But I'm just hand-waving here, I cannot be sure what's the last kernel I
used.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Kalle Valo @ 2017-01-20 12:51 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, ath10k
In-Reply-To: <1468933237-5226-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> wrote:
> Firmware files are versioned to prevent older
> driver instances to load unsupported firmware
> blobs. This is reflected with a fallback logic
> which attempts to load several firmware files.
>
> This however produced a lot of unnecessary
> warnings sometimes confusing users and leading
> them to rename firmware files making things even
> more confusing.
>
> Hence use request_firmware_direct() which does not
> produce extra warnings. This shouldn't really
> break anything because most modern systems don't
> rely on udev/hotplug helpers to load firmware
> files anymore.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
This ended into a rather long discussion, see the full thread from the patchwork link
below, but I'll try to summarise it here:
* Nobody stepped up and mentioned that they need/use the user fallback helper with ath10k.
* Felix confirmed that LEDE creates the calibration file before loading ath10k
so this should not break LEDE.
* This also fixes a 60 second delay per _each_ unexistent firmware/calibration
file with distros which have CONFIG_FW_LOADER_USER_HELPER_FALLBACK enabled,
RHEL being a notable example. Using ath10k with firmware-2.bin this might
end up into a five minute delay in boot.
* Luis is working on new drvdata interface for kernel, but that's not merged yet.
Based on this I think the right approach is to apply this patch. Any concerns?
While writing this I started to suspect is it just by accident that
request_firmware_direct() does not print any error messages and
request_firmware() again does print those? Let's hope nobody decides to change
that. And at least Luis' drvdata interface has a documented 'optional' flag,
so we can always switch to using that (once it's merged):
* struct drvdata_req_params - driver data request parameters
* @optional: if true it is not a hard requirement by the caller that this
* file be present. An error will not be recorded if the file is not
* found.
Michal, do you mind if I'll add more info to the commit log and submit this RFC
as a proper patch? It still seems to apply and work just fine.
--
https://patchwork.kernel.org/patch/9237095/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH RFC 2/2] brcmfmac: add brcmf_err_pub macro for better error messages
From: Rafał Miłecki @ 2017-01-20 12:52 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Kalle Valo, Franky Lin, Hante Meuleman, Pieter-Paul Giesberts,
Franky Lin, linux-wireless@vger.kernel.org,
open list:BROADCOM BRCM80211 IEEE802.11n WIRELESS DRIVER,
Rafał Miłecki
In-Reply-To: <668216db-8834-02e6-1b7c-9fbd05eeaf68@broadcom.com>
On 20 January 2017 at 12:37, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 20-1-2017 12:17, Rafa=C5=82 Mi=C5=82ecki wrote:
>> On 01/20/2017 11:26 AM, Arend Van Spriel wrote:
>>> On 18-1-2017 15:27, Rafa=C5=82 Mi=C5=82ecki wrote:
>>>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>>
>>>> This macro accepts an extra argument of struct brcmf_pub pointer. It
>>>> allows referencing struct device and printing error using dev_err. Thi=
s
>>>> is very useful on devices with more than one wireless card suppored by
>>>> brcmfmac. Thanks for dev_err it's possible to identify device that err=
or
>>>> is related to.
>>>>
>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>>> ---
>>>> I could convert few more brcmf_err calls to this new brcmf_err_pub
>>>> but I don't
>>>> want to spent too much time on this in case someone has a better idea.
>>>>
>>>> If you do, comment! :)
>>>
>>> I do not, but still comment ;-). Like the idea. Was on our list because
>>> it is damn convenient when testing on router with multiple devices. I
>>> would prefer to replace the existing brcmf_err() rather than introducin=
g
>>> a new one and would like to do the same for brcmf_dbg(). However, not
>>> all call sites have a struct brcmf_pub instance available. Everywhere
>>> before completing brcmf_attach() that is.
>>
>> I decided to try new macro because:
>> 1) I was too lazy to convert all calls at once
>> 2) I could stick to brcmf_err when struct brcmf_pub isn't available yet
>>
>> In theory we could pass NULL to dev_err, I'd result in something like:
>> [ 14.746754] (NULL device *): brcmf_c_preinit_dcmds: Firmware version
>> =3D wl0: Sep 18 2015 03:30:01 version 7.35.177.56 (r587209) FWID 01-6cb8=
e269
>>
>> Unfortunately AFAIK it's not possible to handle
>> brcmf_err(NULL "Foo\n");
>> calls while keeping brcmf_err a macro.
>>
>> I was thinking about something like:
>> #define brcmf_err(pub, fmt, ...) \
>> do { \
>> if (IS_ENABLED(CONFIG_BRCMDBG) || net_ratelimit()) \
>> dev_err(pub ? pub->bus_if->dev : NULL, \
>> "%s: " fmt, __func__, \
>> ##__VA_ARGS__); \
>> } while (0)
>>
>> but this wouldn't compile because for brcmf_err(NULL "Foo\n"); it would
>> roll
>> out to:
>> dev_err(NULL ? NULL->bus_if->dev : NULL, "Foo\n");
>>
>> I *can* support brcmf_err(NULL "Foo\n"); calls if I change brcmf_err fro=
m
>> macro to a function (inline probably). Do you think it's a good idea?
>
> I was wondering if brcmf_err(ptr, "bla\n") could determine the pointer
> type and accept 'struct device *' and 'struct brcmf_pub *'. I think we
> always have a struct device pointer. Only in brcmf_module_init() we do no=
t.
Is this possible with a macro? Could you point me to some example for
something like this?
Also is this acceptable for upstream code?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Michal Kazior @ 2017-01-20 12:56 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath10k@lists.infradead.org
In-Reply-To: <6e5d0596c4af46668c02356ba17a4e5f@euamsexm01a.eu.qualcomm.com>
On 20 January 2017 at 13:51, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> wrote:
>> Firmware files are versioned to prevent older
>> driver instances to load unsupported firmware
>> blobs. This is reflected with a fallback logic
>> which attempts to load several firmware files.
>>
>> This however produced a lot of unnecessary
>> warnings sometimes confusing users and leading
>> them to rename firmware files making things even
>> more confusing.
>>
>> Hence use request_firmware_direct() which does not
>> produce extra warnings. This shouldn't really
>> break anything because most modern systems don't
>> rely on udev/hotplug helpers to load firmware
>> files anymore.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> This ended into a rather long discussion, see the full thread from the pa=
tchwork link
> below, but I'll try to summarise it here:
>
> * Nobody stepped up and mentioned that they need/use the user fallback he=
lper with ath10k.
>
> * Felix confirmed that LEDE creates the calibration file before loading a=
th10k
> so this should not break LEDE.
>
> * This also fixes a 60 second delay per _each_ unexistent firmware/calibr=
ation
> file with distros which have CONFIG_FW_LOADER_USER_HELPER_FALLBACK enab=
led,
> RHEL being a notable example. Using ath10k with firmware-2.bin this mig=
ht
> end up into a five minute delay in boot.
>
> * Luis is working on new drvdata interface for kernel, but that's not mer=
ged yet.
>
> Based on this I think the right approach is to apply this patch. Any conc=
erns?
>
> While writing this I started to suspect is it just by accident that
> request_firmware_direct() does not print any error messages and
> request_firmware() again does print those? Let's hope nobody decides to c=
hange
> that. And at least Luis' drvdata interface has a documented 'optional' f=
lag,
> so we can always switch to using that (once it's merged):
>
> * struct drvdata_req_params - driver data request parameters
> * @optional: if true it is not a hard requirement by the caller that this
> * file be present. An error will not be recorded if the file is not
> * found.
>
> Michal, do you mind if I'll add more info to the commit log and submit th=
is RFC
> as a proper patch? It still seems to apply and work just fine.
I don't mind :)
Micha=C5=82
^ permalink raw reply
* Re: [PATCH v3] rt2x00: rt2800lib: add support for RT3352 with 20MHz crystal
From: Stanislaw Gruszka @ 2017-01-20 13:16 UTC (permalink / raw)
To: Daniel Golle
Cc: linux-wireless, Johannes Berg, roman, michel.stempin, c.mignanti,
evaxige, Kalle Valo, Felix Fietkau, John Crispin, Gabor Juhos
In-Reply-To: <20170119234239.GA22196@makrotopia.org>
Hi Daniel
On Fri, Jan 20, 2017 at 12:42:44AM +0100, Daniel Golle wrote:
> +int rt2800_probe_clk(struct rt2x00_dev *rt2x00dev)
> +{
> + struct hw_mode_spec *spec = &rt2x00dev->spec;
> + struct clk *clk = clk_get(rt2x00dev->dev, NULL);
> +
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + if (clk_get_rate(clk) == 20000000)
> + spec->clk_is_20mhz = 1;
> +
> + return 0;
> +}
> +
> int rt2800_probe_hw(struct rt2x00_dev *rt2x00dev)
> {
> int retval;
> @@ -7864,6 +7903,15 @@ int rt2800_probe_hw(struct rt2x00_dev *rt2x00dev)
> rt2800_register_write(rt2x00dev, GPIO_CTRL, reg);
>
> /*
> + * Probe SoC clock.
> + */
> + if (rt2x00_is_soc(rt2x00dev)) {
> + retval = rt2800_probe_clk(rt2x00dev);
> + if (retval)
> + return retval;
> + }
<snip>
> @@ -415,6 +416,7 @@ struct hw_mode_spec {
> const struct channel_info *channels_info;
>
> struct ieee80211_sta_ht_cap ht;
> + int clk_is_20mhz;
I dislike adding this variable to structure that is intended to describe
wireless capabilities. Additionally we do not actually "probe" the
clock but just read it value from rt2x00dev->dev, this can be handled
better. I'll post different patch reading clk and on top of if this
patch and "add support for RT5350 WiSoC" .
Regards
Stanislaw
^ permalink raw reply
* Re: [PATCH v3] rt2x00: add support for RT5350 WiSoC
From: Stanislaw Gruszka @ 2017-01-20 13:19 UTC (permalink / raw)
To: Daniel Golle
Cc: linux-wireless, Johannes Berg, roman, michel.stempin, c.mignanti,
evaxige, Kalle Valo, Felix Fietkau, John Crispin, Gabor Juhos
In-Reply-To: <20170119133834.GA17398@makrotopia.org>
On Thu, Jan 19, 2017 at 02:38:45PM +0100, Daniel Golle wrote:
> From: Michel Stempin <michel.stempin@wanadoo.fr>
>
> Support for the RT5350 WiSoC was added to OpenWrt after having a
> lengthy debate about the legality of the original submission, see
> https://lists.openwrt.org/pipermail/openwrt-devel/2013-January/018224.html
> MTK/Ralink Acked replied and says we can merge this patch under the GPL.
> https://dev.openwrt.org/changeset/36177
>
> Signed-off-by: Serge Vasilugin <vasilugin@yandex.ru>
> Tested-by: Michel Stempin <michel.stempin@wanadoo.fr>
> Acked-by: John Crispin <blogic@openwrt.org>
> [daniel@makrotopia.org: added commit message, cleaned up code]
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Patch is mark as from Michel but we have not sign off from Michel,
however after looking on the link we can find out that patch
was originally from Serge, from whom we have sign-off. I'll correct
that.
Stanislaw
^ permalink raw reply
* [PATCH v4 3/3] rt2x00: add support for RT5350 WiSoC
From: Stanislaw Gruszka @ 2017-01-20 13:28 UTC (permalink / raw)
To: linux-wireless
Cc: Helmut Schaa, Daniel Golle, Gabor Juhos, Serge Vasilugin,
Mathias Kresin, Michel Stempin, John Crispin
In-Reply-To: <1484918906-21856-1-git-send-email-sgruszka@redhat.com>
From: Serge Vasilugin <vasilugin@yandex.ru>
Support for the RT5350 WiSoC was added to OpenWrt after having a
lengthy debate about the legality of the original submission, see
https://lists.openwrt.org/pipermail/openwrt-devel/2013-January/018224.html
MTK/Ralink Acked replied and says we can merge this patch under the GPL.
https://dev.openwrt.org/changeset/36177
Signed-off-by: Serge Vasilugin <vasilugin@yandex.ru>
Tested-by: Michel Stempin <michel.stempin@wanadoo.fr>
Acked-by: John Crispin <blogic@openwrt.org>
[daniel@makrotopia.org: added commit message, cleaned up code]
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/ralink/rt2x00/rt2800.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 125 +++++++++++++++++++++++--
drivers/net/wireless/ralink/rt2x00/rt2x00.h | 1 +
3 files changed, 120 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800.h b/drivers/net/wireless/ralink/rt2x00/rt2800.h
index 1809690..256496b 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800.h
@@ -72,6 +72,7 @@
#define RF5592 0x000f
#define RF3070 0x3070
#define RF3290 0x3290
+#define RF5350 0x5350
#define RF5360 0x5360
#define RF5362 0x5362
#define RF5370 0x5370
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
index 5ae2950..755c093 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2800lib.c
@@ -2763,6 +2763,13 @@ static void rt2800_config_channel_rf53xx(struct rt2x00_dev *rt2x00dev,
rt2800_rfcsr_write(rt2x00dev, 59,
r59_non_bt[idx]);
+ } else if (rt2x00_rt(rt2x00dev, RT5350)) {
+ static const char r59_non_bt[] = {0x0b, 0x0b,
+ 0x0b, 0x0b, 0x0b, 0x0b, 0x0b, 0x0a,
+ 0x0a, 0x09, 0x08, 0x07, 0x07, 0x06};
+
+ rt2800_rfcsr_write(rt2x00dev, 59,
+ r59_non_bt[idx]);
}
}
}
@@ -3200,6 +3207,7 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
rt2800_config_channel_rf3322(rt2x00dev, conf, rf, info);
break;
case RF3070:
+ case RF5350:
case RF5360:
case RF5362:
case RF5370:
@@ -3218,6 +3226,7 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
if (rt2x00_rf(rt2x00dev, RF3070) ||
rt2x00_rf(rt2x00dev, RF3290) ||
rt2x00_rf(rt2x00dev, RF3322) ||
+ rt2x00_rf(rt2x00dev, RF5350) ||
rt2x00_rf(rt2x00dev, RF5360) ||
rt2x00_rf(rt2x00dev, RF5362) ||
rt2x00_rf(rt2x00dev, RF5370) ||
@@ -3475,7 +3484,8 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev,
/*
* Clear update flag
*/
- if (rt2x00_rt(rt2x00dev, RT3352)) {
+ if (rt2x00_rt(rt2x00dev, RT3352) ||
+ rt2x00_rt(rt2x00dev, RT5350)) {
rt2800_bbp_read(rt2x00dev, 49, &bbp);
rt2x00_set_field8(&bbp, BBP49_UPDATE_FLAG, 0);
rt2800_bbp_write(rt2x00dev, 49, bbp);
@@ -4356,6 +4366,7 @@ void rt2800_vco_calibration(struct rt2x00_dev *rt2x00dev)
case RF3053:
case RF3070:
case RF3290:
+ case RF5350:
case RF5360:
case RF5362:
case RF5370:
@@ -4738,6 +4749,8 @@ static int rt2800_init_registers(struct rt2x00_dev *rt2x00dev)
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00000000);
rt2800_register_write(rt2x00dev, TX_SW_CFG2, 0x00000000);
+ } else if (rt2x00_rt(rt2x00dev, RT5350)) {
+ rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000404);
} else {
rt2800_register_write(rt2x00dev, TX_SW_CFG0, 0x00000000);
rt2800_register_write(rt2x00dev, TX_SW_CFG1, 0x00080606);
@@ -5383,9 +5396,13 @@ static void rt2800_init_bbp_3352(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 82, 0x62);
- rt2800_bbp_write(rt2x00dev, 83, 0x6a);
-
- rt2800_bbp_write(rt2x00dev, 84, 0x99);
+ if (rt2x00_rt(rt2x00dev, RT5350)) {
+ rt2800_bbp_write(rt2x00dev, 83, 0x7a);
+ rt2800_bbp_write(rt2x00dev, 84, 0x9a);
+ } else {
+ rt2800_bbp_write(rt2x00dev, 83, 0x6a);
+ rt2800_bbp_write(rt2x00dev, 84, 0x99);
+ }
rt2800_bbp_write(rt2x00dev, 86, 0x38);
@@ -5399,9 +5416,13 @@ static void rt2800_init_bbp_3352(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 104, 0x92);
- rt2800_bbp_write(rt2x00dev, 105, 0x34);
-
- rt2800_bbp_write(rt2x00dev, 106, 0x05);
+ if (rt2x00_rt(rt2x00dev, RT5350)) {
+ rt2800_bbp_write(rt2x00dev, 105, 0x3c);
+ rt2800_bbp_write(rt2x00dev, 106, 0x03);
+ } else {
+ rt2800_bbp_write(rt2x00dev, 105, 0x34);
+ rt2800_bbp_write(rt2x00dev, 106, 0x05);
+ }
rt2800_bbp_write(rt2x00dev, 120, 0x50);
@@ -5426,6 +5447,16 @@ static void rt2800_init_bbp_3352(struct rt2x00_dev *rt2x00dev)
rt2800_bbp_write(rt2x00dev, 143, 0xa2);
rt2800_bbp_write(rt2x00dev, 148, 0xc8);
+
+ if (rt2x00_rt(rt2x00dev, RT5350)) {
+ /* Antenna Software OFDM */
+ rt2800_bbp_write(rt2x00dev, 150, 0x40);
+ /* Antenna Software CCK */
+ rt2800_bbp_write(rt2x00dev, 151, 0x30);
+ rt2800_bbp_write(rt2x00dev, 152, 0xa3);
+ /* Clear previously selected antenna */
+ rt2800_bbp_write(rt2x00dev, 154, 0);
+ }
}
static void rt2800_init_bbp_3390(struct rt2x00_dev *rt2x00dev)
@@ -5726,6 +5757,7 @@ static void rt2800_init_bbp(struct rt2x00_dev *rt2x00dev)
rt2800_init_bbp_3290(rt2x00dev);
break;
case RT3352:
+ case RT5350:
rt2800_init_bbp_3352(rt2x00dev);
break;
case RT3390:
@@ -6536,6 +6568,76 @@ static void rt2800_init_rfcsr_3593(struct rt2x00_dev *rt2x00dev)
/* TODO: enable stream mode support */
}
+static void rt2800_init_rfcsr_5350(struct rt2x00_dev *rt2x00dev)
+{
+ rt2800_rfcsr_write(rt2x00dev, 0, 0xf0);
+ rt2800_rfcsr_write(rt2x00dev, 1, 0x23);
+ rt2800_rfcsr_write(rt2x00dev, 2, 0x50);
+ rt2800_rfcsr_write(rt2x00dev, 3, 0x08);
+ rt2800_rfcsr_write(rt2x00dev, 4, 0x49);
+ rt2800_rfcsr_write(rt2x00dev, 5, 0x10);
+ rt2800_rfcsr_write(rt2x00dev, 6, 0xe0);
+ rt2800_rfcsr_write(rt2x00dev, 7, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 8, 0xf1);
+ rt2800_rfcsr_write(rt2x00dev, 9, 0x02);
+ rt2800_rfcsr_write(rt2x00dev, 10, 0x53);
+ rt2800_rfcsr_write(rt2x00dev, 11, 0x4a);
+ rt2800_rfcsr_write(rt2x00dev, 12, 0x46);
+ if (rt2800_clk_is_20mhz(rt2x00dev))
+ rt2800_rfcsr_write(rt2x00dev, 13, 0x1f);
+ else
+ rt2800_rfcsr_write(rt2x00dev, 13, 0x9f);
+ rt2800_rfcsr_write(rt2x00dev, 14, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 15, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 16, 0xc0);
+ rt2800_rfcsr_write(rt2x00dev, 18, 0x03);
+ rt2800_rfcsr_write(rt2x00dev, 19, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 20, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 21, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 22, 0x20);
+ rt2800_rfcsr_write(rt2x00dev, 23, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 24, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 25, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 26, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
+ rt2800_rfcsr_write(rt2x00dev, 28, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 29, 0xd0);
+ rt2800_rfcsr_write(rt2x00dev, 30, 0x10);
+ rt2800_rfcsr_write(rt2x00dev, 31, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 32, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 33, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 34, 0x07);
+ rt2800_rfcsr_write(rt2x00dev, 35, 0x12);
+ rt2800_rfcsr_write(rt2x00dev, 36, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 37, 0x08);
+ rt2800_rfcsr_write(rt2x00dev, 38, 0x85);
+ rt2800_rfcsr_write(rt2x00dev, 39, 0x1b);
+ rt2800_rfcsr_write(rt2x00dev, 40, 0x0b);
+ rt2800_rfcsr_write(rt2x00dev, 41, 0xbb);
+ rt2800_rfcsr_write(rt2x00dev, 42, 0xd5);
+ rt2800_rfcsr_write(rt2x00dev, 43, 0x9b);
+ rt2800_rfcsr_write(rt2x00dev, 44, 0x0c);
+ rt2800_rfcsr_write(rt2x00dev, 45, 0xa6);
+ rt2800_rfcsr_write(rt2x00dev, 46, 0x73);
+ rt2800_rfcsr_write(rt2x00dev, 47, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 48, 0x10);
+ rt2800_rfcsr_write(rt2x00dev, 49, 0x80);
+ rt2800_rfcsr_write(rt2x00dev, 50, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 51, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 52, 0x38);
+ rt2800_rfcsr_write(rt2x00dev, 53, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 54, 0x38);
+ rt2800_rfcsr_write(rt2x00dev, 55, 0x43);
+ rt2800_rfcsr_write(rt2x00dev, 56, 0x82);
+ rt2800_rfcsr_write(rt2x00dev, 57, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 58, 0x39);
+ rt2800_rfcsr_write(rt2x00dev, 59, 0x0b);
+ rt2800_rfcsr_write(rt2x00dev, 60, 0x45);
+ rt2800_rfcsr_write(rt2x00dev, 61, 0xd1);
+ rt2800_rfcsr_write(rt2x00dev, 62, 0x00);
+ rt2800_rfcsr_write(rt2x00dev, 63, 0x00);
+}
+
static void rt2800_init_rfcsr_5390(struct rt2x00_dev *rt2x00dev)
{
rt2800_rf_init_calibration(rt2x00dev, 2);
@@ -6773,6 +6875,9 @@ static void rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
case RT3593:
rt2800_init_rfcsr_3593(rt2x00dev);
break;
+ case RT5350:
+ rt2800_init_rfcsr_5350(rt2x00dev);
+ break;
case RT5390:
rt2800_init_rfcsr_5390(rt2x00dev);
break;
@@ -7152,6 +7257,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;
else
rf = rt2x00_get_field16(eeprom, EEPROM_NIC_CONF0_RF_TYPE);
@@ -7170,6 +7277,7 @@ static int rt2800_init_eeprom(struct rt2x00_dev *rt2x00dev)
case RF3290:
case RF3320:
case RF3322:
+ case RF5350:
case RF5360:
case RF5362:
case RF5370:
@@ -7673,6 +7781,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
case RF3290:
case RF3320:
case RF3322:
+ case RF5350:
case RF5360:
case RF5362:
case RF5370:
@@ -7809,6 +7918,7 @@ static int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
case RF3053:
case RF3070:
case RF3290:
+ case RF5350:
case RF5360:
case RF5362:
case RF5370:
@@ -7849,6 +7959,7 @@ static int rt2800_probe_rt(struct rt2x00_dev *rt2x00dev)
case RT3390:
case RT3572:
case RT3593:
+ case RT5350:
case RT5390:
case RT5392:
case RT5592:
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00.h b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
index b59e721..ea299c4 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00.h
@@ -170,6 +170,7 @@ struct rt2x00_chip {
#define RT3572 0x3572
#define RT3593 0x3593
#define RT3883 0x3883 /* WSOC */
+#define RT5350 0x5350 /* WSOC 2.4GHz */
#define RT5390 0x5390 /* 2.4GHz */
#define RT5392 0x5392 /* 2.4GHz */
#define RT5592 0x5592
--
1.8.3.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