* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Rob Herring @ 2017-09-01 21:38 UTC (permalink / raw)
To: Arend van Spriel
Cc: Antony Antony, Chen-Yu Tsai, Kalle Valo, Mark Rutland,
Icenowy Zheng, devicetree, Hans de Goede, linux-wireless,
Maxime Ripard
In-Reply-To: <bb53a79e-8045-3c9b-8c98-8d4815c3b57a@broadcom.com>
On Fri, Sep 1, 2017 at 2:10 PM, Arend van Spriel
<arend.vanspriel@broadcom.com> wrote:
> On 01-09-17 18:49, Rob Herring wrote:
>>
>> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
>>>
>>> hi,
>>>
>>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
>>>>
>>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org>
>>>> wrote:
>>>
>>>
>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>> @@ -6,7 +6,9 @@ connects the device to the system.
>>>>>
>>>>> Required properties:
>>>>>
>>>>> - - compatible : Should be "brcm,bcm4329-fmac".
>>>>> + - compatible : should be one of the following:
>>>>> + * "brcm,bcm4329-fmac"
>>>>> + * "brcm,bcm43430-fmac"
>>>>
>>>>
>>>> You updated the bindings, but not the driver. So it's not actually
>>>> going to work. More specifically, OOB interrupts won't work.
>>>>
>>>
>>> understood, ignore this patch for now. Thanks Chen-Yu.
>>>
>>>> IIRC, The compatible string for this particular case, as it was
>>>> originally proposed, only serves as a placeholder for the driver
>>>> to check against. None of the instances in sunxi device trees
>>>> match the actual chip model. Actual model matching is done
>>>> through SDIO, as you've already seen.
>>>
>>>
>>> yes it seems SDIO driveer code is smarter, once it initialize
>>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to
>>> locate
>>> firmware file.
>>>
>>> I also noticed other boards using bcm4329-fmac in similar situations.
>>> https://patchwork.kernel.org/patch/9739181/
>>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>>>
>>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see
>>> where
>>> it goes.
>>
>>
>> Adding the compatible or instead of? The former would be better. You
>> should still have the actual chip in case you do have some difference to
>> handle.
>
>
> Hi Rob,
>
> Actually the Broadcom wifi chips themselves are discoverable. So once the
> driver has access to the register space of the device it can determine the
> actual chip, its revision, and exactly what cores (and their revision) are
> present in the chip. Hence there is a single compatible string as there is
> no need to convey the same information through device tree data.
So if a chip has different power on/off sequencing you can discover that?
I realize that most often you don't need it, but a more specific
compatible is there in case you do and so it doesn't require a DTB
update to handle some difference. But you can keep using one
compatible because I can't really enforce any of that.
Rob
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Arend van Spriel @ 2017-09-01 21:30 UTC (permalink / raw)
To: Antony Antony
Cc: Rob Herring, Chen-Yu Tsai, Kalle Valo, Mark Rutland,
Icenowy Zheng, devicetree, Hans de Goede, linux-wireless,
Maxime Ripard
In-Reply-To: <20170901204030.2zpsoa4i53tdegs3@AntonyAntony.local>
On 01-09-17 22:40, Antony Antony wrote:
> On Fri, Sep 01, 2017 at 09:10:41PM +0200, Arend van Spriel wrote:
>> On 01-09-17 18:49, Rob Herring wrote:
>>> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
>>>> hi,
>>>>
>>>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
>>>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org> wrote:
>>>>
>>>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>>>> @@ -6,7 +6,9 @@ connects the device to the system.
>>>>>>
>>>>>> Required properties:
>>>>>>
>>>>>> - - compatible : Should be "brcm,bcm4329-fmac".
>>>>>> + - compatible : should be one of the following:
>>>>>> + * "brcm,bcm4329-fmac"
>>>>>> + * "brcm,bcm43430-fmac"
>>>>>
>>>>> You updated the bindings, but not the driver. So it's not actually
>>>>> going to work. More specifically, OOB interrupts won't work.
>>>>>
>>>>
>>>> understood, ignore this patch for now. Thanks Chen-Yu.
>>>>
>>>>> IIRC, The compatible string for this particular case, as it was
>>>>> originally proposed, only serves as a placeholder for the driver
>>>>> to check against. None of the instances in sunxi device trees
>>>>> match the actual chip model. Actual model matching is done
>>>>> through SDIO, as you've already seen.
>>>>
>>>> yes it seems SDIO driveer code is smarter, once it initialize
>>>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to locate
>>>> firmware file.
>>>>
>>>> I also noticed other boards using bcm4329-fmac in similar situations.
>>>> https://patchwork.kernel.org/patch/9739181/
>>>>
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>>>>
>>>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see where
>>>> it goes.
>>>
>>> Adding the compatible or instead of? The former would be better. You
>>> should still have the actual chip in case you do have some difference to
>>> handle.
>>
>> Hi Rob,
>>
>> Actually the Broadcom wifi chips themselves are discoverable. So once the
>> driver has access to the register space of the device it can determine the
>> actual chip, its revision, and exactly what cores (and their revision) are
>> present in the chip. Hence there is a single compatible string as there is
>> no need to convey the same information through device tree data.
>
> In my expereince this how it seems to work.
>
> I jsut discovered s/brcm,bcm4329-fmac/brcm/ can load the broadcom driver.
>
> brcmf: wifi@1 {
> reg = <1>;
> compatible = "brcm";
> };
>
> This looks better to me. Maxime, Would this work?
I have no idea what you are saying here. To what exactly do you apply
that substitute. In brcmfmac I have:
if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
!of_device_is_compatible(np, "brcm,bcm4329-fmac"))
return;
In my perception using "brcm" goes against DT compatible naming convention.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Antony Antony @ 2017-09-01 20:40 UTC (permalink / raw)
To: Arend van Spriel
Cc: Rob Herring, Antony Antony, Chen-Yu Tsai, Kalle Valo,
Mark Rutland, Icenowy Zheng, devicetree, Hans de Goede,
linux-wireless, Maxime Ripard
In-Reply-To: <bb53a79e-8045-3c9b-8c98-8d4815c3b57a@broadcom.com>
On Fri, Sep 01, 2017 at 09:10:41PM +0200, Arend van Spriel wrote:
> On 01-09-17 18:49, Rob Herring wrote:
> > On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
> > > hi,
> > >
> > > On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
> > > > On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org> wrote:
> > >
> > > > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > > > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > > > > @@ -6,7 +6,9 @@ connects the device to the system.
> > > > >
> > > > > Required properties:
> > > > >
> > > > > - - compatible : Should be "brcm,bcm4329-fmac".
> > > > > + - compatible : should be one of the following:
> > > > > + * "brcm,bcm4329-fmac"
> > > > > + * "brcm,bcm43430-fmac"
> > > >
> > > > You updated the bindings, but not the driver. So it's not actually
> > > > going to work. More specifically, OOB interrupts won't work.
> > > >
> > >
> > > understood, ignore this patch for now. Thanks Chen-Yu.
> > >
> > > > IIRC, The compatible string for this particular case, as it was
> > > > originally proposed, only serves as a placeholder for the driver
> > > > to check against. None of the instances in sunxi device trees
> > > > match the actual chip model. Actual model matching is done
> > > > through SDIO, as you've already seen.
> > >
> > > yes it seems SDIO driveer code is smarter, once it initialize
> > > brcm,bcm4329-fmac it ignore the DT info and read the chip details to locate
> > > firmware file.
> > >
> > > I also noticed other boards using bcm4329-fmac in similar situations.
> > > https://patchwork.kernel.org/patch/9739181/
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
> > >
> > > I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see where
> > > it goes.
> >
> > Adding the compatible or instead of? The former would be better. You
> > should still have the actual chip in case you do have some difference to
> > handle.
>
> Hi Rob,
>
> Actually the Broadcom wifi chips themselves are discoverable. So once the
> driver has access to the register space of the device it can determine the
> actual chip, its revision, and exactly what cores (and their revision) are
> present in the chip. Hence there is a single compatible string as there is
> no need to convey the same information through device tree data.
In my expereince this how it seems to work.
I jsut discovered s/brcm,bcm4329-fmac/brcm/ can load the broadcom driver.
brcmf: wifi@1 {
reg = <1>;
compatible = "brcm";
};
This looks better to me. Maxime, Would this work?
regards,
-antony
^ permalink raw reply
* Re: Incorrect mesh path seq num
From: Thomas Pedersen @ 2017-09-01 20:07 UTC (permalink / raw)
To: Greg Maitz; +Cc: linux-wireless
In-Reply-To: <CAG5S3ZTRe52qSWt6WEe6K78brrQqc7+HgN_8OQ+RKC9k1WUMCw@mail.gmail.com>
On Thu, Aug 31, 2017 at 11:30 PM, Greg Maitz <ghh19622@gmail.com> wrote:
> Hi guys,
>
> I'm seeing a problem when I work on the wireless mesh between two
> linux devices. The root node has 3.18 kernel while the next hop
> station runs 2.6.37 kernel. I found the mpath->sn value is incorrect
> most of the time on the device having 2.6.37 kernel. After examining
> the code, in function hwmp_route_info_get [mesh_hwmp.c], after
> mesh_path_lookup, the sequence number (i.e, mpath->sn) is incorrect.
> For instance, I see mpath->sn having value 0x30950000. It should be
> 0x9530, while the orig_sn is having value 0x9531.
Looks like an endianess bug. Are you testing on two platforms of
different endianess?
> This results in the
> last hop metric to become zero in function mesh_rx_path_sel_frame and
> hwmp_preq_frame_process doesn't get called. Is this a known problem?
> Can anyone provide suggestions to debug further?
--
thomas
^ permalink raw reply
* Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments
From: Jens Axboe @ 2017-09-01 20:07 UTC (permalink / raw)
To: Kees Cook, Thomas Gleixner
Cc: Krzysztof Halasa, Aditya Shankar, Ganesh Krishna,
Greg Kroah-Hartman, netdev, linux-wireless, devel, linux-kernel
In-Reply-To: <1504222183-61202-14-git-send-email-keescook@chromium.org>
On 08/31/2017 05:29 PM, Kees Cook wrote:
> Several timer users needlessly reset their .function/.data fields during
> their timer callback, but nothing else changes them. Some users do not
> use their .data field at all. Each instance is removed here.
For amiflop:
Acked-by: Jens Axboe <axboe@kernel.dk>
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: feature check for multi-scheduled scan fails on bcm4345 devices
From: Arend van Spriel @ 2017-09-01 20:04 UTC (permalink / raw)
To: Ian W MORRISON, kvalo, ian, linux-wireless
In-Reply-To: <3cfcb175-8031-f5a8-da51-d81fa2d331c8@gmail.com>
On 31-08-17 00:51, Ian W MORRISON wrote:
> The firmware feature check introduced for multi-scheduled scan is also
> failing for bcm4345 devices resulting in a firmware crash.
> The reason for this crash has not yet been root cause so this patch avoids
> the feature check for those device as a short-term fix.
Thanks. This is one of the few devices that I actually do not have on my
desk.
Acked-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Fixes: 9fe929aaace6 ("brcmfmac: add firmware feature detection for gscan feature")
> Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
> ---
> v2: Fixed tabs being replaced by spaces in patch submission
> Tested on MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices.
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend
From: Arend van Spriel @ 2017-09-01 20:02 UTC (permalink / raw)
To: Eric Bentley, Kalle Valo; +Cc: Steve deRosier, linux-wireless@vger.kernel.org
In-Reply-To: <AC37C967-209B-4BC3-9AF2-9CC4C27391C0@lairdtech.com>
On 01-09-17 15:00, Eric Bentley wrote:
> Return error when failing to set power management capabilities flag. This will
> cause the suspend to fail but the radio will continue to operate. Allowing this
> to fail without reporting error will cause the radio to be non-functional on
> resume as it will have lost power.
There is more to this story to tell. Initially, the suspend callback did
return an error upon failing to set the flags. This was dropped by
commit 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.") as
it set the flags only for wowl and that wowl would only be enabled if
the host supports the capability flags:
+#ifdef CONFIG_PM_SLEEP
+ /* wowl can be supported when KEEP_POWER is true and (WAKE_SDIO_IRQ
+ * is true or when platform data OOB irq is true).
+ */
+ if ((sdio_get_host_pm_caps(sdiodev->func[1]) & MMC_PM_KEEP_POWER) &&
+ ((sdio_get_host_pm_caps(sdiodev->func[1]) &
MMC_PM_WAKE_SDIO_IRQ) ||
+ (sdiodev->pdata->oob_irq_supported)))
+ bus_if->wowl_supported = true;
+#endif
However, MMC_PM_KEEP_POWER is also needed for the non-wowl case. I
restored that in commit bdf1340cf20f ("brcmfmac: fix sdio suspend and
resume"), but overlooked the error code return also needed to be restored.
Also note that the wifi chip (the term "radio" does not quite cover it)
has not really lost power. It is quite common that it is not powered
through the SDIO bus. With the power-sequence support in the MMC stack
these days the suspend may result in loss of power. Otherwise, it is
just the bus that loses power (and clock) and the flags affect what
tricks the MMC stack tries to pull to get the device accessible again
upon resume.
Maybe you can incorporate some of this in the commit message, but you
should at least add:
Fixes: 330b4e4be937 ("brcmfmac: Add wowl support for SDIO devices.")
Fixes: bdf1340cf20f ("brcmfmac: fix sdio suspend and resume")
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
> Signed-off-by: Eric Bentley eric.bentley@lairdtech.com
> ---
> v2: corrected errant ( with {
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Arend van Spriel @ 2017-09-01 19:10 UTC (permalink / raw)
To: Rob Herring, Antony Antony
Cc: Chen-Yu Tsai, Kalle Valo, Mark Rutland, Icenowy Zheng, devicetree,
Hans de Goede, linux-wireless, Maxime Ripard
In-Reply-To: <20170901164911.aiu5ej5u546z5kow@rob-hp-laptop>
On 01-09-17 18:49, Rob Herring wrote:
> On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
>> hi,
>>
>> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
>>> On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org> wrote:
>>
>>>> a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>> @@ -6,7 +6,9 @@ connects the device to the system.
>>>>
>>>> Required properties:
>>>>
>>>> - - compatible : Should be "brcm,bcm4329-fmac".
>>>> + - compatible : should be one of the following:
>>>> + * "brcm,bcm4329-fmac"
>>>> + * "brcm,bcm43430-fmac"
>>>
>>> You updated the bindings, but not the driver. So it's not actually
>>> going to work. More specifically, OOB interrupts won't work.
>>>
>>
>> understood, ignore this patch for now. Thanks Chen-Yu.
>>
>>> IIRC, The compatible string for this particular case, as it was
>>> originally proposed, only serves as a placeholder for the driver
>>> to check against. None of the instances in sunxi device trees
>>> match the actual chip model. Actual model matching is done
>>> through SDIO, as you've already seen.
>>
>> yes it seems SDIO driveer code is smarter, once it initialize
>> brcm,bcm4329-fmac it ignore the DT info and read the chip details to locate
>> firmware file.
>>
>> I also noticed other boards using bcm4329-fmac in similar situations.
>> https://patchwork.kernel.org/patch/9739181/
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>>
>> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see where
>> it goes.
>
> Adding the compatible or instead of? The former would be better. You
> should still have the actual chip in case you do have some difference to
> handle.
Hi Rob,
Actually the Broadcom wifi chips themselves are discoverable. So once
the driver has access to the register space of the device it can
determine the actual chip, its revision, and exactly what cores (and
their revision) are present in the chip. Hence there is a single
compatible string as there is no need to convey the same information
through device tree data.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments
From: Krzysztof Halasa @ 2017-09-01 17:59 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Aditya Shankar, Ganesh Krishna,
Greg Kroah-Hartman, Jens Axboe, netdev, linux-wireless, devel,
linux-kernel
In-Reply-To: <1504222183-61202-14-git-send-email-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> Several timer users needlessly reset their .function/.data fields during
> their timer callback, but nothing else changes them. Some users do not
> use their .data field at all. Each instance is removed here.
For *wan/hdlc*
Acked-by: Krzysztof Halasa <khc@pm.waw.pl>
> --- a/drivers/net/wan/hdlc_cisco.c
> +++ b/drivers/net/wan/hdlc_cisco.c
> @@ -276,8 +276,6 @@ static void cisco_timer(unsigned long arg)
> spin_unlock(&st->lock);
>
> st->timer.expires = jiffies + st->settings.interval * HZ;
> - st->timer.function = cisco_timer;
> - st->timer.data = arg;
> add_timer(&st->timer);
> }
>
> diff --git a/drivers/net/wan/hdlc_fr.c b/drivers/net/wan/hdlc_fr.c
> index de42faca076a..7da2424c28a4 100644
> --- a/drivers/net/wan/hdlc_fr.c
> +++ b/drivers/net/wan/hdlc_fr.c
> @@ -644,8 +644,6 @@ static void fr_timer(unsigned long arg)
> state(hdlc)->settings.t391 * HZ;
> }
>
> - state(hdlc)->timer.function = fr_timer;
> - state(hdlc)->timer.data = arg;
> add_timer(&state(hdlc)->timer);
> }
--
Krzysztof Halasa
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2017-09-01
From: David Miller @ 2017-09-01 17:36 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <878thyqygs.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Fri, 01 Sep 2017 17:34:43 +0300
> here's a pull request to net-next for 4.14. If the merge window opens on
> Sunday I'm planning to have this as the last one.
>
> Please let me know if there are any problems.
Ok, pulled, thanks.
^ permalink raw reply
* Re: [PATCH] Documentation: dt-binding: net: wireless: add bcm43430-fmac
From: Rob Herring @ 2017-09-01 16:49 UTC (permalink / raw)
To: Antony Antony
Cc: Chen-Yu Tsai, Kalle Valo, Mark Rutland, Icenowy Zheng, devicetree,
Hans de Goede, linux-wireless, Maxime Ripard
In-Reply-To: <20170830120218.ms3xuhp4qsibistv@AntonyAntony.local>
On Wed, Aug 30, 2017 at 02:02:18PM +0200, Antony Antony wrote:
> hi,
>
> On Wed, Aug 30, 2017 at 10:28:20AM +0800, Chen-Yu Tsai wrote:
> > On Wed, Aug 30, 2017 at 5:43 AM, Antony Antony <antony@phenome.org> wrote:
>
> > > a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > > +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> > > @@ -6,7 +6,9 @@ connects the device to the system.
> > >
> > > Required properties:
> > >
> > > - - compatible : Should be "brcm,bcm4329-fmac".
> > > + - compatible : should be one of the following:
> > > + * "brcm,bcm4329-fmac"
> > > + * "brcm,bcm43430-fmac"
> >
> > You updated the bindings, but not the driver. So it's not actually
> > going to work. More specifically, OOB interrupts won't work.
> >
>
> understood, ignore this patch for now. Thanks Chen-Yu.
>
> > IIRC, The compatible string for this particular case, as it was
> > originally proposed, only serves as a placeholder for the driver
> > to check against. None of the instances in sunxi device trees
> > match the actual chip model. Actual model matching is done
> > through SDIO, as you've already seen.
>
> yes it seems SDIO driveer code is smarter, once it initialize
> brcm,bcm4329-fmac it ignore the DT info and read the chip details to locate
> firmware file.
>
> I also noticed other boards using bcm4329-fmac in similar situations.
> https://patchwork.kernel.org/patch/9739181/
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts?h=v4.13-rc7
>
> I will resend "NanoPi NEO Plus2" dts with "brcm,bcm4329-fmac" and see where
> it goes.
Adding the compatible or instead of? The former would be better. You
should still have the actual chip in case you do have some difference to
handle.
Rob
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Larry Finger @ 2017-09-01 15:02 UTC (permalink / raw)
To: Kalle Valo, Stanislaw Gruszka; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <87y3pymqw2.fsf@purkki.adurom.net>
On 09/01/2017 09:31 AM, Kalle Valo wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> writes:
>
>> On Thu, Aug 31, 2017 at 10:33:28AM -0500, Larry Finger wrote:
>>> Should the patch to wireless-drivers be annotated with a Stable reference so
>>> that it is added to 4.12 and 4.13?
>>
>> According to Documentation/networking/netdev-FAQ.txt networking patches
>> should not be marked cc:stable, instead a decent commit log should
>> be written describing a bugfix. Which I believe it is done for
>> this patch.
>
> But that's for net and net-next trees, not for wireless trees. With
> wireless patches we use "Cc: stable@..." references.
I see that this patch was just pushed for 4.14. I hope it got the Stable
annotation at that time.
Larry
^ permalink raw reply
* pull-request: wireless-drivers-next 2017-09-01
From: Kalle Valo @ 2017-09-01 14:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's a pull request to net-next for 4.14. If the merge window opens on
Sunday I'm planning to have this as the last one.
Please let me know if there are any problems.
Kalle
The following changes since commit d081a16db80ef7a260fb178aa1199e01f7432625:
net: bcmgenet: Do not return from void function (2017-08-29 22:39:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2017-09-01
for you to fetch changes up to eb464d4a8d092a793b97b724cd3cc6eeb229232a:
Merge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git (2017-08-31 21:34:22 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.14
Few last patches for 4.14, nothing really major here.
Major changes:
wil6210
* support FW RSSI reporting (by mistake this was accidentally
mentioned already in the previous pull request, but now it's really
included)
* make debugfs optional, adds new Kconfig option CONFIG_WIL6210_DEBUGFS
qtnfmac
* implement 64-bit DMA support
----------------------------------------------------------------
Andy Shevchenko (1):
ath10k: switch to use new generic UUID API
Arvind Yadav (2):
ath6kl: constify usb_device_id
ath9k: constify usb_device_id
Bhumika Goyal (1):
ath9k: make ath_ps_ops structures as const
Bjorn Andersson (1):
wcn36xx: Introduce mutual exclusion of fw configuration
Dan Carpenter (2):
rsi: update some comments
rsi: missing unlocks on error paths
David Spinadel (1):
iwlwifi: mvm: Avoid deferring non bufferable frames
Dedy Lansky (4):
wil6210: support FW RSSI reporting
wil6210: store FW RF calibration result
wil6210: move pre-FW configuration to separate function
wil6210: clear PAL_UNIT_ICR part of device reset
Emmanuel Grumbach (1):
iwlwifi: mvm: bump API to 34 for 8000 and up
Erik Stromdahl (1):
ath10k: sdio: remove unused struct member
Gabriel Craciunescu (1):
ath10k: ath10k_htt_rx_amsdu_allowed() use ath10k_dbg()
Gidon Studinski (2):
wil6210: move vring_idle_trsh definition to wil6210_priv
wil6210: make debugfs compilation optional
Gustavo A. R. Silva (1):
rtlwifi: rtl8723be: fix duplicated code for different branches
Hamad Kadmany (2):
wil6210: protect against invalid length of tx management frame
wil6210: fix interface-up check
Hans de Goede (1):
brcmfmac: Log chip id and revision
Hauke Mehrtens (1):
ath10k: activate user space firmware loading again
Himanshu Jha (1):
rsi: remove memset before memcpy
Kalle Valo (2):
Merge tag 'iwlwifi-next-for-kalle-2017-08-30' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Lazar Alexei (1):
wil6210: align to latest auto generated wmi.h
Liad Kaufman (1):
iwlwifi: fix long debug print
Lior David (3):
wil6210: ratelimit errors in TX/RX interrupts
wil6210: increase connect timeout
wil6210: ensure P2P device is stopped before removing interface
Maya Erez (3):
wil6210: check no_fw_recovery in resume failure recovery
wil6210: add statistics for suspend time
wil6210: notify wiphy on wowlan support
Rakesh Pillai (1):
ath10k: fix memory leak in rx ring buffer allocation
Ryan Hsu (3):
ath10k: fix napi_poll budget overflow
ath10k: add the PCI PM core suspend/resume ops
ath10k: configure and enable the wakeup capability
Sergey Matyukevich (5):
qtnfmac: drop -D__CHECK_ENDIAN from cflags
qtnfmac: module param sanity check
qtnfmac: modify qtnf_map_bar not to return NULL
qtnfmac: fix free_xfer_buffer cleanup
qtnfmac: implement 64-bit dma support
Stanislaw Gruszka (1):
rt2800: fix TX_PIN_CFG setting for non MT7620 chips
drivers/net/wireless/ath/ath10k/core.c | 14 +-
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath10k/debug.c | 6 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 19 +-
drivers/net/wireless/ath/ath10k/mac.c | 1 +
drivers/net/wireless/ath/ath10k/pci.c | 50 +-
drivers/net/wireless/ath/ath10k/sdio.c | 4 -
drivers/net/wireless/ath/ath10k/sdio.h | 2 -
drivers/net/wireless/ath/ath10k/wow.c | 14 +
drivers/net/wireless/ath/ath10k/wow.h | 1 +
drivers/net/wireless/ath/ath6kl/usb.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 2 +-
drivers/net/wireless/ath/wcn36xx/main.c | 52 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 3 +
drivers/net/wireless/ath/wil6210/Kconfig | 12 +
drivers/net/wireless/ath/wil6210/Makefile | 2 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 84 ++-
drivers/net/wireless/ath/wil6210/debugfs.c | 27 +-
drivers/net/wireless/ath/wil6210/interrupt.c | 14 +-
drivers/net/wireless/ath/wil6210/main.c | 42 +-
drivers/net/wireless/ath/wil6210/pcie_bus.c | 3 +
drivers/net/wireless/ath/wil6210/pm.c | 27 +-
drivers/net/wireless/ath/wil6210/txrx.c | 6 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 20 +-
drivers/net/wireless/ath/wil6210/wmi.c | 14 +-
drivers/net/wireless/ath/wil6210/wmi.h | 720 ++++++++++++++-------
.../broadcom/brcm80211/brcmfmac/firmware.c | 3 +
drivers/net/wireless/intel/iwlwifi/cfg/8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 9 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 9 +-
drivers/net/wireless/quantenna/qtnfmac/Makefile | 4 -
.../net/wireless/quantenna/qtnfmac/pearl/pcie.c | 101 ++-
.../wireless/quantenna/qtnfmac/pearl/pcie_ipc.h | 10 +-
.../quantenna/qtnfmac/pearl/pcie_regs_pearl.h | 1 +
drivers/net/wireless/ralink/rt2x00/rt2800lib.c | 5 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/dm.c | 8 +-
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 25 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 1 -
drivers/net/wireless/rsi/rsi_91x_usb.c | 1 -
43 files changed, 931 insertions(+), 401 deletions(-)
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Kalle Valo @ 2017-09-01 14:31 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Larry Finger, Helmut Schaa, linux-wireless
In-Reply-To: <20170901085738.GA18397@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> writes:
> On Thu, Aug 31, 2017 at 10:33:28AM -0500, Larry Finger wrote:
>> Should the patch to wireless-drivers be annotated with a Stable reference so
>> that it is added to 4.12 and 4.13?
>
> According to Documentation/networking/netdev-FAQ.txt networking patches
> should not be marked cc:stable, instead a decent commit log should
> be written describing a bugfix. Which I believe it is done for
> this patch.
But that's for net and net-next trees, not for wireless trees. With
wireless patches we use "Cc: stable@..." references.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] brcmfmac: Correctly fail to suspend when SDIO does not support power on suspend
From: Eric Bentley @ 2017-09-01 13:00 UTC (permalink / raw)
To: Kalle Valo
Cc: Steve deRosier, linux-wireless@vger.kernel.org,
arend.vanspriel@broadcom.com
UmV0dXJuIGVycm9yIHdoZW4gZmFpbGluZyB0byBzZXQgcG93ZXIgbWFuYWdlbWVudCBjYXBhYmls
aXRpZXMgZmxhZy4gIFRoaXMgd2lsbA0KY2F1c2UgdGhlIHN1c3BlbmQgdG8gZmFpbCBidXQgdGhl
IHJhZGlvIHdpbGwgY29udGludWUgdG8gb3BlcmF0ZS4gIEFsbG93aW5nIHRoaXMNCnRvIGZhaWwg
d2l0aG91dCByZXBvcnRpbmcgZXJyb3Igd2lsbCBjYXVzZSB0aGUgcmFkaW8gdG8gYmUgbm9uLWZ1
bmN0aW9uYWwgb24gDQpyZXN1bWUgYXMgaXQgd2lsbCBoYXZlIGxvc3QgcG93ZXIuDQoNClNpZ25l
ZC1vZmYtYnk6IEVyaWMgQmVudGxleSBlcmljLmJlbnRsZXlAbGFpcmR0ZWNoLmNvbQ0KLS0tDQp2
MjogY29ycmVjdGVkIGVycmFudCAoIHdpdGggew0KLS0tDQpkcml2ZXJzL25ldC93aXJlbGVzcy9i
cm9hZGNvbS9icmNtODAyMTEvYnJjbWZtYWMvYmNtc2RoLmMgfCA0ICsrKy0NCjEgZmlsZSBjaGFu
Z2VkLCAzIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCg0KZGlmZiAtLWdpdCBhL2RyaXZl
cnMvbmV0L3dpcmVsZXNzL2Jyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9iY21zZGguYyBiL2Ry
aXZlcnMvbmV0L3dpcmVsZXNzL2Jyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9iY21zZGguYw0K
aW5kZXggNzIxMzliNS4uMmY3ZDAzZiAxMDA2NDQNCi0tLSBhL2RyaXZlcnMvbmV0L3dpcmVsZXNz
L2Jyb2FkY29tL2JyY204MDIxMS9icmNtZm1hYy9iY21zZGguYw0KKysrIGIvZHJpdmVycy9uZXQv
d2lyZWxlc3MvYnJvYWRjb20vYnJjbTgwMjExL2JyY21mbWFjL2JjbXNkaC5jDQpAQCAtMTI2NCw4
ICsxMjY0LDEwIEBAIHN0YXRpYyBpbnQgYnJjbWZfb3BzX3NkaW9fc3VzcGVuZChzdHJ1Y3QgZGV2
aWNlICpkZXYpDQogICAgICAgICAgICAgICAgIGVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAg
ICBzZGlvX2ZsYWdzIHw9IE1NQ19QTV9XQUtFX1NESU9fSVJROw0KICAgICAgICAgfQ0KLSAgICAg
ICBpZiAoc2Rpb19zZXRfaG9zdF9wbV9mbGFncyhzZGlvZGV2LT5mdW5jWzFdLCBzZGlvX2ZsYWdz
KSkNCisgICAgICAgaWYgKHNkaW9fc2V0X2hvc3RfcG1fZmxhZ3Moc2Rpb2Rldi0+ZnVuY1sxXSwg
c2Rpb19mbGFncykpIHsNCiAgICAgICAgICAgICAgICAgYnJjbWZfZXJyKCJGYWlsZWQgdG8gc2V0
IHBtX2ZsYWdzICV4XG4iLCBzZGlvX2ZsYWdzKTsNCisgICAgICAgICAgICAgICByZXR1cm4gLUVJ
TlZBTDsNCisgICAgICAgfQ0KICAgICAgICAgcmV0dXJuIDA7DQp9DQotLQ0KMi42LjAuR0lUDQoN
Cg==
^ permalink raw reply
* Re: RT2870 failure in kernel 4.12.8
From: Stanislaw Gruszka @ 2017-09-01 8:57 UTC (permalink / raw)
To: Larry Finger; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <26ef3184-a19e-1bb7-7aa4-4e8647210763@lwfinger.net>
On Thu, Aug 31, 2017 at 10:33:28AM -0500, Larry Finger wrote:
> Should the patch to wireless-drivers be annotated with a Stable reference so
> that it is added to 4.12 and 4.13?
According to Documentation/networking/netdev-FAQ.txt networking patches
should not be marked cc:stable, instead a decent commit log should
be written describing a bugfix. Which I believe it is done for
this patch.
Thanks
Stanislaw
^ permalink raw reply
* [bug report] iwlwifi: mvm: add station before allocating a queue
From: Dan Carpenter @ 2017-09-01 8:30 UTC (permalink / raw)
To: shaul.triebitz; +Cc: linux-wireless
Hello Shaul Triebitz,
The patch 732d06e9d9cf: "iwlwifi: mvm: add station before allocating
a queue" from Jul 10, 2017, leads to the following static checker
warning:
drivers/net/wireless/intel/iwlwifi/mvm/sta.c:1312 iwl_mvm_add_int_sta_common()
error: uninitialized symbol 'status'.
drivers/net/wireless/intel/iwlwifi/mvm/sta.c
1281 static int iwl_mvm_add_int_sta_common(struct iwl_mvm *mvm,
1282 struct iwl_mvm_int_sta *sta,
1283 const u8 *addr,
1284 u16 mac_id, u16 color)
1285 {
1286 struct iwl_mvm_add_sta_cmd cmd;
1287 int ret;
1288 u32 status;
^^^^^^^^^^
1289
1290 lockdep_assert_held(&mvm->mutex);
1291
1292 memset(&cmd, 0, sizeof(cmd));
1293 cmd.sta_id = sta->sta_id;
1294 cmd.mac_id_n_color = cpu_to_le32(FW_CMD_ID_AND_COLOR(mac_id,
1295 color));
1296 if (fw_has_api(&mvm->fw->ucode_capa, IWL_UCODE_TLV_API_STA_TYPE))
1297 cmd.station_type = sta->type;
1298
1299 if (!iwl_mvm_has_new_tx_api(mvm))
1300 cmd.tfd_queue_msk = cpu_to_le32(sta->tfd_queue_msk);
1301 cmd.tid_disable_tx = cpu_to_le16(0xffff);
1302
1303 if (addr)
1304 memcpy(cmd.addr, addr, ETH_ALEN);
1305
1306 ret = iwl_mvm_send_cmd_pdu_status(mvm, ADD_STA,
1307 iwl_mvm_add_sta_cmd_size(mvm),
1308 &cmd, &status);
^^^^^^
1309 if (ret)
1310 return ret;
1311
1312 switch (status & IWL_ADD_STA_STATUS_MASK) {
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1313 case ADD_STA_SUCCESS:
1314 IWL_DEBUG_INFO(mvm, "Internal station added.\n");
1315 return 0;
1316 default:
1317 ret = -EIO;
1318 IWL_ERR(mvm, "Add internal station failed, status=0x%x\n",
1319 status);
1320 break;
1321 }
1322 return ret;
1323 }
The problem here is this code from iwl_mvm_send_cmd_status()
drivers/net/wireless/intel/iwlwifi/mvm/utils.c
157 cmd->flags |= CMD_WANT_SKB;
158
159 ret = iwl_trans_send_cmd(mvm->trans, cmd);
160 if (ret == -ERFKILL) {
161 /*
162 * The command failed because of RFKILL, don't update
163 * the status, leave it as success and return 0.
164 */
165 return 0;
We return zero without setting "status". Shouldn't we set *status = 0;?
166 } else if (ret) {
167 return ret;
168 }
169
170 pkt = cmd->resp_pkt;
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: fix long debug print
From: Joe Perches @ 2017-09-01 8:21 UTC (permalink / raw)
To: Kalle Valo; +Cc: Luca Coelho, linux-wireless, Liad Kaufman
In-Reply-To: <87k21irg1g.fsf@kamboji.qca.qualcomm.com>
On Fri, 2017-09-01 at 11:15 +0300, Kalle Valo wrote:
> Joe Perches <joe@perches.com> writes:
> > On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
> > > On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> > > > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > > > > From: Liad Kaufman <liad.kaufman@intel.com>
> > > > > There is a debug print that sometimes reaches over
> > > > > 110 chars, thus generating a warning in those cases.
[]
> > It might make sense to add a comment to describe these
> > trace events coming from TRACE_EVENT(iwlwifi_dbg,
> >
> > All the IWL_DEBUG_<foo> use this trace message maximum.
>
> Unfortunately the patch is already commited to wireless-drivers-next so
> we can't change the commit log anymore.
No worries about the commit.
It'd be useful to add a comment to the code.
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: fix long debug print
From: Kalle Valo @ 2017-09-01 8:15 UTC (permalink / raw)
To: Joe Perches; +Cc: Luca Coelho, linux-wireless, Liad Kaufman
In-Reply-To: <1504246520.2361.3.camel@perches.com>
Joe Perches <joe@perches.com> writes:
> On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
>> On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
>> > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
>> > > From: Liad Kaufman <liad.kaufman@intel.com>
>> > >
>> > > There is a debug print that sometimes reaches over
>> > > 110 chars, thus generating a warning in those cases.
>> >
>> > What emits a warning here?
>>
>> We have a WARN_ON in iwl-devtrace-msg.h:
>>
>> #define MAX_MSG_LEN 110
>
> OK, thanks for the hint.
>
> The commit message is a bit obscure.
>
> It might make sense to add a comment to describe these
> trace events coming from TRACE_EVENT(iwlwifi_dbg,
>
> All the IWL_DEBUG_<foo> use this trace message maximum.
Unfortunately the patch is already commited to wireless-drivers-next so
we can't change the commit log anymore.
--
Kalle Valo
^ permalink raw reply
* [PATCH] iw: Null check before accessing n_mcs variable
From: Amit Khatri @ 2017-09-01 6:10 UTC (permalink / raw)
To: johannes@sipsolutions.net; +Cc: linux-wireless@vger.kernel.org, Nitin Jhanwar
In-Reply-To: <CGME20170901061008epcms5p5fdd787910f9698c511e01a134afe90ea@epcms5p5>
From: Amit Khatri <amit.khatri@samsung.com>
Date: Thu, 24 Aug 2017 00:16:26 -0700
Subject: [PATCH] iw: Null check before accessing n_mcs variable
If all cases will fail n_mcs variable fail to get any assignement
and remain NULL. so better to check NULL before dereference.
Signed-off-by: Amit Khatri <amit.khatri@samsung.com>
---
bitrate.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/bitrate.c b/bitrate.c
index 4a026a4..3e58337 100644
--- a/bitrate.c
+++ b/bitrate.c
@@ -185,7 +185,8 @@ static int handle_bitrates(struct nl80211_state *state,
return 1;
if (tmpl < 0 || tmpl > 255)
return 1;
- mcs[(*n_mcs)++] = tmpl;
+ if(n_mcs!=NULL)
+ mcs[(*n_mcs)++] = tmpl;
break;
case S_VHT:
if (*vht_argc >= VHT_ARGC_MAX)
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2] ath9k: remove cast to void pointer
From: Himanshu Jha @ 2017-09-01 6:43 UTC (permalink / raw)
To: kvalo; +Cc: ath9k-devel, linux-wireless, linux-kernel, joe, Himanshu Jha
casting to void pointer from any pointer type and vice-versa is done
implicitly and therefore casting is not needed in such a case.
Done using Coccinellle.
Semantic Patch used :
@r@
expression x;
void* e;
type T;
identifier f;
@@
(
*((T *)e)
|
((T *)x)[...]
|
((T *)x)->f
|
- (T *)
e
)
Signed-off-by: Himanshu Jha <himanshujha199640@gmail.com>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 4 ++--
drivers/net/wireless/ath/ath9k/dfs.c | 2 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 8 ++++----
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 24 ++++++++++++------------
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 6 +++---
drivers/net/wireless/ath/ath9k/init.c | 8 ++++----
drivers/net/wireless/ath/ath9k/main.c | 2 +-
drivers/net/wireless/ath/ath9k/mci.c | 2 +-
drivers/net/wireless/ath/ath9k/wmi.c | 4 ++--
11 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index b3f20b3..e1fe7a7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -480,7 +480,7 @@ EXPORT_SYMBOL(ath9k_hw_addrxbuf_edma);
int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
void *buf_addr)
{
- struct ar9003_rxs *rxsp = (struct ar9003_rxs *) buf_addr;
+ struct ar9003_rxs *rxsp = buf_addr;
unsigned int phyerr;
if ((rxsp->status11 & AR_RxDone) == 0)
@@ -610,7 +610,7 @@ void ath9k_hw_setup_statusring(struct ath_hw *ah, void *ts_start,
ah->ts_paddr_start = ts_paddr_start;
ah->ts_paddr_end = ts_paddr_start + (size * sizeof(struct ar9003_txs));
ah->ts_size = size;
- ah->ts_ring = (struct ar9003_txs *) ts_start;
+ ah->ts_ring = ts_start;
ath9k_hw_reset_txstatus_ring(ah);
}
diff --git a/drivers/net/wireless/ath/ath9k/dfs.c b/drivers/net/wireless/ath/ath9k/dfs.c
index 1ece42c..40a397f 100644
--- a/drivers/net/wireless/ath/ath9k/dfs.c
+++ b/drivers/net/wireless/ath/ath9k/dfs.c
@@ -326,7 +326,7 @@ void ath9k_dfs_process_phyerr(struct ath_softc *sc, void *data,
if (ard.ext_rssi & 0x80)
ard.ext_rssi = 0;
- vdata_end = (char *)data + datalen;
+ vdata_end = data + datalen;
ard.pulse_bw_info = vdata_end[-1];
ard.pulse_length_ext = vdata_end[-2];
ard.pulse_length_pri = vdata_end[-3];
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 0d9687a..71d1725 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -424,7 +424,7 @@ static int hif_usb_send_tx(struct hif_device_usb *hif_dev, struct sk_buff *skb)
static void hif_usb_start(void *hif_handle)
{
- struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle;
+ struct hif_device_usb *hif_dev = hif_handle;
unsigned long flags;
hif_dev->flags |= HIF_USB_START;
@@ -436,7 +436,7 @@ static void hif_usb_start(void *hif_handle)
static void hif_usb_stop(void *hif_handle)
{
- struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle;
+ struct hif_device_usb *hif_dev = hif_handle;
struct tx_buf *tx_buf = NULL, *tx_buf_tmp = NULL;
unsigned long flags;
@@ -457,7 +457,7 @@ static void hif_usb_stop(void *hif_handle)
static int hif_usb_send(void *hif_handle, u8 pipe_id, struct sk_buff *skb)
{
- struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle;
+ struct hif_device_usb *hif_dev = hif_handle;
int ret = 0;
switch (pipe_id) {
@@ -492,7 +492,7 @@ static inline bool check_index(struct sk_buff *skb, u8 idx)
static void hif_usb_sta_drain(void *hif_handle, u8 idx)
{
- struct hif_device_usb *hif_dev = (struct hif_device_usb *)hif_handle;
+ struct hif_device_usb *hif_dev = hif_handle;
struct sk_buff *skb, *tmp;
unsigned long flags;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
index 2c0e4d2..f20c839 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
@@ -384,7 +384,7 @@ void ath9k_htc_set_tsfadjust(struct ath9k_htc_priv *priv,
static void ath9k_htc_beacon_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
{
- bool *beacon_configured = (bool *)data;
+ bool *beacon_configured = data;
struct ath9k_htc_vif *avp = (struct ath9k_htc_vif *) vif->drv_priv;
if (vif->type == NL80211_IFTYPE_STATION &&
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index defacc6..9e0c237 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -233,7 +233,7 @@ static void ath9k_reg_notifier(struct wiphy *wiphy,
static unsigned int ath9k_regread(void *hw_priv, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
__be32 val, reg = cpu_to_be32(reg_offset);
@@ -255,7 +255,7 @@ static unsigned int ath9k_regread(void *hw_priv, u32 reg_offset)
static void ath9k_multi_regread(void *hw_priv, u32 *addr,
u32 *val, u16 count)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
__be32 tmpaddr[8];
@@ -301,7 +301,7 @@ static void ath9k_regwrite_multi(struct ath_common *common)
static void ath9k_regwrite_single(void *hw_priv, u32 val, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
const __be32 buf[2] = {
@@ -322,7 +322,7 @@ static void ath9k_regwrite_single(void *hw_priv, u32 val, u32 reg_offset)
static void ath9k_regwrite_buffer(void *hw_priv, u32 val, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
@@ -345,7 +345,7 @@ static void ath9k_regwrite_buffer(void *hw_priv, u32 val, u32 reg_offset)
static void ath9k_regwrite(void *hw_priv, u32 val, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
@@ -357,7 +357,7 @@ static void ath9k_regwrite(void *hw_priv, u32 val, u32 reg_offset)
static void ath9k_enable_regwrite_buffer(void *hw_priv)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
@@ -366,7 +366,7 @@ static void ath9k_enable_regwrite_buffer(void *hw_priv)
static void ath9k_regwrite_flush(void *hw_priv)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
@@ -383,7 +383,7 @@ static void ath9k_regwrite_flush(void *hw_priv)
static void ath9k_reg_rmw_buffer(void *hw_priv,
u32 reg_offset, u32 set, u32 clr)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
u32 rsp_status;
@@ -421,7 +421,7 @@ static void ath9k_reg_rmw_buffer(void *hw_priv,
static void ath9k_reg_rmw_flush(void *hw_priv)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
u32 rsp_status;
@@ -453,7 +453,7 @@ static void ath9k_reg_rmw_flush(void *hw_priv)
static void ath9k_enable_rmw_buffer(void *hw_priv)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
@@ -466,7 +466,7 @@ static void ath9k_enable_rmw_buffer(void *hw_priv)
static u32 ath9k_reg_rmw_single(void *hw_priv,
u32 reg_offset, u32 set, u32 clr)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
struct register_rmw buf, buf_ret;
@@ -490,7 +490,7 @@ static u32 ath9k_reg_rmw_single(void *hw_priv,
static u32 ath9k_reg_rmw(void *hw_priv, u32 reg_offset, u32 set, u32 clr)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) common->priv;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index a553c91..f808e58 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1483,7 +1483,7 @@ static void ath9k_htc_set_bssid(struct ath9k_htc_priv *priv)
static void ath9k_htc_bss_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
{
- struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)data;
+ struct ath9k_htc_priv *priv = data;
struct ath_common *common = ath9k_hw_common(priv->ah);
struct ieee80211_bss_conf *bss_conf = &vif->bss_conf;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index b38a586..2682da0 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -641,7 +641,7 @@ static struct sk_buff* ath9k_htc_tx_get_packet(struct ath9k_htc_priv *priv,
void ath9k_htc_txstatus(struct ath9k_htc_priv *priv, void *wmi_event)
{
- struct wmi_event_txstatus *txs = (struct wmi_event_txstatus *)wmi_event;
+ struct wmi_event_txstatus *txs = wmi_event;
struct __wmi_event_txstatus *__txs;
struct sk_buff *skb;
struct ath9k_htc_tx_event *tx_pend;
@@ -684,7 +684,7 @@ void ath9k_htc_txstatus(struct ath9k_htc_priv *priv, void *wmi_event)
void ath9k_htc_txep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id, bool txok)
{
- struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *) drv_priv;
+ struct ath9k_htc_priv *priv = drv_priv;
struct ath9k_htc_tx_ctl *tx_ctl;
struct sk_buff_head *epid_queue;
@@ -1103,7 +1103,7 @@ void ath9k_rx_tasklet(unsigned long data)
void ath9k_htc_rxep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id)
{
- struct ath9k_htc_priv *priv = (struct ath9k_htc_priv *)drv_priv;
+ struct ath9k_htc_priv *priv = drv_priv;
struct ath_hw *ah = priv->ah;
struct ath_common *common = ath9k_hw_common(ah);
struct ath9k_htc_rxbuf *rxbuf = NULL, *tmp_buf = NULL;
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index fd9a618..b46f982 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -117,7 +117,7 @@ static struct ath_ps_ops ath9k_ps_ops = {
static void ath9k_iowrite32(void *hw_priv, u32 val, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;
@@ -132,7 +132,7 @@ static void ath9k_iowrite32(void *hw_priv, u32 val, u32 reg_offset)
static unsigned int ath9k_ioread32(void *hw_priv, u32 reg_offset)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;
u32 val;
@@ -172,7 +172,7 @@ static unsigned int __ath9k_reg_rmw(struct ath_softc *sc, u32 reg_offset,
static unsigned int ath9k_reg_rmw(void *hw_priv, u32 reg_offset, u32 set, u32 clr)
{
- struct ath_hw *ah = (struct ath_hw *) hw_priv;
+ struct ath_hw *ah = hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;
unsigned long uninitialized_var(flags);
@@ -275,7 +275,7 @@ int ath_descdma_setup(struct ath_softc *sc, struct ath_descdma *dd,
if (!dd->dd_desc)
return -ENOMEM;
- ds = (u8 *) dd->dd_desc;
+ ds = dd->dd_desc;
ath_dbg(common, CONFIG, "%s DMA map: %p (%u) -> %llx (%u)\n",
name, ds, (u32) dd->dd_desc_len,
ito64(dd->dd_desc_paddr), /*XXX*/(u32) dd->dd_desc_len);
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 8b4ac7f..9c24bc0 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1193,7 +1193,7 @@ void ath9k_calculate_summary_state(struct ath_softc *sc,
static void ath9k_tpc_vif_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
{
- int *power = (int *)data;
+ int *power = data;
if (*power < vif->bss_conf.txpower)
*power = vif->bss_conf.txpower;
diff --git a/drivers/net/wireless/ath/ath9k/mci.c b/drivers/net/wireless/ath/ath9k/mci.c
index cf23fd8..39d46c2 100644
--- a/drivers/net/wireless/ath/ath9k/mci.c
+++ b/drivers/net/wireless/ath/ath9k/mci.c
@@ -453,7 +453,7 @@ int ath_mci_setup(struct ath_softc *sc)
mci->sched_buf.bf_len = ATH_MCI_SCHED_BUF_SIZE;
mci->gpm_buf.bf_len = ATH_MCI_GPM_BUF_SIZE;
- mci->gpm_buf.bf_addr = (u8 *)mci->sched_buf.bf_addr + mci->sched_buf.bf_len;
+ mci->gpm_buf.bf_addr = mci->sched_buf.bf_addr + mci->sched_buf.bf_len;
mci->gpm_buf.bf_paddr = mci->sched_buf.bf_paddr + mci->sched_buf.bf_len;
ret = ar9003_mci_setup(sc->sc_ah, mci->gpm_buf.bf_paddr,
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index 64a354f..b0b5579 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -159,7 +159,7 @@ void ath9k_wmi_event_tasklet(unsigned long data)
switch (cmd_id) {
case WMI_SWBA_EVENTID:
- swba = (struct wmi_event_swba *) wmi_event;
+ swba = wmi_event;
ath9k_htc_swba(priv, swba);
break;
case WMI_FATAL_EVENTID:
@@ -207,7 +207,7 @@ static void ath9k_wmi_rsp_callback(struct wmi *wmi, struct sk_buff *skb)
static void ath9k_wmi_ctrl_rx(void *priv, struct sk_buff *skb,
enum htc_endpoint_id epid)
{
- struct wmi *wmi = (struct wmi *) priv;
+ struct wmi *wmi = priv;
struct wmi_cmd_hdr *hdr;
u16 cmd_id;
--
2.7.4
^ permalink raw reply related
* Incorrect mesh path seq num
From: Greg Maitz @ 2017-09-01 6:30 UTC (permalink / raw)
To: linux-wireless
Hi guys,
I'm seeing a problem when I work on the wireless mesh between two
linux devices. The root node has 3.18 kernel while the next hop
station runs 2.6.37 kernel. I found the mpath->sn value is incorrect
most of the time on the device having 2.6.37 kernel. After examining
the code, in function hwmp_route_info_get [mesh_hwmp.c], after
mesh_path_lookup, the sequence number (i.e, mpath->sn) is incorrect.
For instance, I see mpath->sn having value 0x30950000. It should be
0x9530, while the orig_sn is having value 0x9531. This results in the
last hop metric to become zero in function mesh_rx_path_sel_frame and
hwmp_preq_frame_process doesn't get called. Is this a known problem?
Can anyone provide suggestions to debug further?
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: fix long debug print
From: Joe Perches @ 2017-09-01 6:15 UTC (permalink / raw)
To: Luca Coelho, kvalo; +Cc: linux-wireless, Liad Kaufman
In-Reply-To: <1504244238.31031.24.camel@coelho.fi>
On Fri, 2017-09-01 at 08:37 +0300, Luca Coelho wrote:
> On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> > On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > > From: Liad Kaufman <liad.kaufman@intel.com>
> > >
> > > There is a debug print that sometimes reaches over
> > > 110 chars, thus generating a warning in those cases.
> >
> > What emits a warning here?
>
> We have a WARN_ON in iwl-devtrace-msg.h:
>
> #define MAX_MSG_LEN 110
OK, thanks for the hint.
The commit message is a bit obscure.
It might make sense to add a comment to describe these
trace events coming from TRACE_EVENT(iwlwifi_dbg,
All the IWL_DEBUG_<foo> use this trace message maximum.
^ permalink raw reply
* Re: [PATCH 1/2] iwlwifi: fix long debug print
From: Luca Coelho @ 2017-09-01 5:37 UTC (permalink / raw)
To: Joe Perches, kvalo; +Cc: linux-wireless, Liad Kaufman
In-Reply-To: <1504216665.2786.48.camel@perches.com>
On Thu, 2017-08-31 at 14:57 -0700, Joe Perches wrote:
> On Fri, 2017-08-25 at 11:27 +0300, Luca Coelho wrote:
> > From: Liad Kaufman <liad.kaufman@intel.com>
> >
> > There is a debug print that sometimes reaches over
> > 110 chars, thus generating a warning in those cases.
>
> What emits a warning here?
We have a WARN_ON in iwl-devtrace-msg.h:
#define MAX_MSG_LEN 110
DECLARE_EVENT_CLASS(iwlwifi_msg_event,
TP_PROTO(struct va_format *vaf),
TP_ARGS(vaf),
TP_STRUCT__entry(
__dynamic_array(char, msg, MAX_MSG_LEN)
),
TP_fast_assign(
WARN_ON_ONCE(vsnprintf(__get_dynamic_array(msg),
MAX_MSG_LEN, vaf->fmt,
*vaf->va) >= MAX_MSG_LEN);
),
TP_printk("%s", __get_str(msg))
);
We limit all our tracing messages to 110 bytes. Anything longer than
that starts getting annoying to read. In mac80211 we limit it even
further, to 100 bytes, so this is not unique to the iwlwifi driver.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] Correctly fail to suspend when SDIO does not support power on suspend
From: Kalle Valo @ 2017-09-01 5:30 UTC (permalink / raw)
To: Eric Bentley
Cc: Steve deRosier, linux-wireless@vger.kernel.org,
arend.vanspriel@broadcom.com
In-Reply-To: <F895C8CD-1D0E-46CB-9C12-5B4775E76217@lairdtech.com>
Eric Bentley <Eric.Bentley@lairdtech.com> writes:
> Return error when failing to set power management capabilities flag. This will cause the suspend to fail but the radio
> will continue to operate. Allowing this to fail without reporting error will cause the radio to be non-functional on
> resume as it will have lost power.
>
> Signed-off-by: Eric Bentley eric.bentley@lairdtech.com
Word wrap the commit log to 72 chars (or so) per line. Also add a prefix
to the title:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#commit_title_is_wrong
--
Kalle Valo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox