* Re: [1/7] brcmfmac: handle FWHALT mailbox indication
From: Kalle Valo @ 2017-11-08 12:05 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <5A02DCC0.8000406@broadcom.com>
Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> Hi Kalle,
>
> I was preparing a new patch series and got a bit confused. Turns out
> there was a series still pending in patchwork.
>
> https://patchwork.kernel.org/patch/9948825/
That's not pending, it's in "Changes Requested" meaning that I have
dropped them:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#checking_state_of_patches_from_patchwork
"Deferred" is the state when patch is pending an action from me. Yes,
patchwork state names suck :)
> So I applied the pending series on wireless-drivers-next and it
> compiles fine. So what I think happened is that the series depended on
> a patch that was submitted to wireless-drivers at that time. Can these
> patches be taken now or do I need to resubmit.
To keep things simple I would prefer you resubmit them. I'm at Netdev
2.2 right now so on a quite tight schedule to get everything ready
before the weekend when the merge window opens.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Simon Shields @ 2017-11-08 11:43 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
devicetree, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Stefan Wahren
In-Reply-To: <5A02DE93.8030502@broadcom.com>
Hi Arend,
On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote:
> + Stefan
>
> On 11/7/2017 2:31 PM, Simon Shields wrote:
> > Hi Arend,
> >
> > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
> > > On 11/6/2017 12:27 PM, Simon Shields wrote:
> > > > On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
> > > > > On 11/4/2017 2:24 PM, Simon Shields wrote:
> > > > > > Some boards use an external 32khz clock for low-power
> > > > > > mode timing. Make sure the clock is powered on while the chipset
> > > > > > is active.
> > > > >
> > > > > Do you have such a board? With the little documentation I can get my hands
> > > > > on here I wonder whether the clock needs to be enabled before the device is
> > > > > powered. If you have the hardware I would like to check some registers in
> > > > > the device.
> > > > >
> > > >
> > > > Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
> > > > with this patch and one more that enables the WL_REG_EN pin when
> > > > brcmfmac is probed.
> > >
> > > Ok. So this is exactly the thing I was wondering about. So it makes me
> > > curious how the WL_REG_EN patch looks like. Can you provide that?
> > >
> >
> > Here[0] is a link to the patch in its current state. Obviously, it's not
> > ready at all for mainlining :-)
> >
> > [0]: https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch
>
> Thanks. Indeed doing it in module_init of brcmfmac is not going to fly.
> Actually the MMC stack has a mechanism to power the SDIO device. This can be
> configured through the device tree [1]. I just checked and it actually
> includes specifying the external clock as well.
>
It looks like mmc-pwrseq-simple would handle the clock case, but it
doesn't handle the regulator properly: it sets the GPIO to high before
powering on, then lowers it immediately after powering it on.
I guess a simpler approach here would be to extend pwrseq-simple to behave
as we need it to.
> Regards,
> Arend
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
Cheers,
Simon
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Stanislaw Gruszka @ 2017-11-08 11:35 UTC (permalink / raw)
To: Richard Genoud; +Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1510139235.10467.1.camel@gmail.com>
On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> > No, that not I wanted you to do. Please remove those options and just
> > do
> > below on tracing directory.
> >
> > echo 0 > tracing_on
> > cat trace > /dev/null
> > echo "function_graph" > current_tracer
> > echo "rt2*" > set_ftrace_filter
> > echo 1 > tracing_on
> > echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> > echo 0 > tracing_on
> > cat trace > ~/trace.txt
>
> Well, there's clearly a misunderstanding here :
> After the command "echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind"
> I can't type *anything*
> The only thing I can do is plug off the board.
> This command never returns, so I can't stop the tracing...
>
> Or I missed something ?
>
> (maybe if there was more than one CPU on the board, I could do
> something, but that's not the case)
I was not aware that soft-lock up can hung the system.
Below patch should prevent/help with the issue. This is
not right fix, it's for futher debugging.
Regards
Stanislaw
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
index e2f4f5778267..d76ca608c722 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c
@@ -321,8 +321,8 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry *entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV)
- clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
+ printk("submit TX urb ERROR %d\n", status);
+ clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
set_bit(ENTRY_DATA_IO_FAILED, &entry->flags);
rt2x00lib_dmadone(entry);
}
@@ -410,8 +410,8 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry *entry, void *data)
status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC);
if (status) {
- if (status == -ENODEV)
- clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
+ printk("submit RX urb ERROR %d\n", status);
+ clear_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags);
set_bit(ENTRY_DATA_IO_FAILED, &entry->flags);
rt2x00lib_dmadone(entry);
}
^ permalink raw reply related
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Richard Genoud @ 2017-11-08 11:07 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20171108103729.GA2641@redhat.com>
Le mercredi 08 novembre 2017 à 11:37 +0100, Stanislaw Gruszka a écrit :
> On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a
> > écrit :
> > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > > 3 short articles how to configure and use ftrace are here:
> > > > > https://lwn.net/Articles/365835/
> > > > > https://lwn.net/Articles/366796/
> > > > > https://lwn.net/Articles/370423/
> > > > >
> > > >
> > > > I tried with ftrace, but I don't think there's a way to dump
> > > > the
> > > > trace
> > > > when there's a soft lock-up
> > > > (I can't do anything after the unbind, even the heartbeat led
> > > > stopped blinking).
> > > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but
> > > > there's no
> > > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> > >
> > > You should configure function trace with rt2x* functions. After
> > > that
> > > start tracing, unbind the device, then stop tracing and provide
> > > trace
> > > output.
> >
> > Ok, I found a way to display the trace (after the unbind, the board
> > is
> > frozen and I can't type anything).
> > Adding
> > CONFIG_SOFTLOCKUP_DETECTOR=y
> > CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
> > along with echo 1 > /proc/sys/kernel/ftrace_dump_on_oops does the
> > trick
>
> No, that not I wanted you to do. Please remove those options and just
> do
> below on tracing directory.
>
> echo 0 > tracing_on
> cat trace > /dev/null
> echo "function_graph" > current_tracer
> echo "rt2*" > set_ftrace_filter
> echo 1 > tracing_on
> echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> echo 0 > tracing_on
> cat trace > ~/trace.txt
Well, there's clearly a misunderstanding here :
After the command "echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind"
I can't type *anything*
The only thing I can do is plug off the board.
This command never returns, so I can't stop the tracing...
Or I missed something ?
(maybe if there was more than one CPU on the board, I could do
something, but that's not the case)
>
> and provide trace.txt to me (can be in private email if big).
>
> Thanks
> Stanislaw
Thanks,
Richard.
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Stanislaw Gruszka @ 2017-11-08 10:41 UTC (permalink / raw)
To: Richard Genoud; +Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1510053227.24015.3.camel@gmail.com>
On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Articles/365835/
> > > > https://lwn.net/Articles/366796/
> > > > https://lwn.net/Articles/370423/
> > > >
> > >
> > > I tried with ftrace, but I don't think there's a way to dump the
> > > trace
> > > when there's a soft lock-up
> > > (I can't do anything after the unbind, even the heartbeat led
> > > stopped blinking).
> > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> >
> > You should configure function trace with rt2x* functions. After that
> > start tracing, unbind the device, then stop tracing and provide trace
> > output.
> Here is another trace, with rt2* as function filter.
> (sorry for the noise)
>
> Dumping ftrace buffer:
> ---------------------------------
> CPU:0 [LOST 3606923 EVENTS]
> 0) 0.000 us | } /* rt2x00usb_clear_entry */
> 0) 0.000 us | } /* rt2x00lib_rxdone */
> 0) 0.000 us | rt2x00queue_get_entry();
> 0) | rt2x00lib_rxdone() {
> 0) 0.000 us | rt2x00queue_index_inc();
> 0) | rt2x00usb_clear_entry() {
> 0) | rt2x00usb_kick_rx_entry() {
We do that only if:
if (test_bit(DEVICE_STATE_PRESENT, &rt2x00dev->flags) &&
test_bit(DEVICE_STATE_ENABLED_RADIO, &rt2x00dev->flags))
rt2x00dev->ops->lib->clear_entry(entry);
so looks like DEVICE_STATE_PRESENT is not cleared. That mean
usb driver do not call disconnect callback on unbind. That seems
to be usb driver bug. Anyway please provide requested traces,
so I will see what happen.
Stanislaw
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Arend van Spriel @ 2017-11-08 10:38 UTC (permalink / raw)
To: Simon Shields
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
devicetree, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng, Stefan Wahren
In-Reply-To: <20171107133112.GA1323@lineageos.org>
+ Stefan
On 11/7/2017 2:31 PM, Simon Shields wrote:
> Hi Arend,
>
> On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
>> On 11/6/2017 12:27 PM, Simon Shields wrote:
>>> On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
>>>> On 11/4/2017 2:24 PM, Simon Shields wrote:
>>>>> Some boards use an external 32khz clock for low-power
>>>>> mode timing. Make sure the clock is powered on while the chipset
>>>>> is active.
>>>>
>>>> Do you have such a board? With the little documentation I can get my hands
>>>> on here I wonder whether the clock needs to be enabled before the device is
>>>> powered. If you have the hardware I would like to check some registers in
>>>> the device.
>>>>
>>>
>>> Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
>>> with this patch and one more that enables the WL_REG_EN pin when
>>> brcmfmac is probed.
>>
>> Ok. So this is exactly the thing I was wondering about. So it makes me
>> curious how the WL_REG_EN patch looks like. Can you provide that?
>>
>
> Here[0] is a link to the patch in its current state. Obviously, it's not
> ready at all for mainlining :-)
>
> [0]: https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch
Thanks. Indeed doing it in module_init of brcmfmac is not going to fly.
Actually the MMC stack has a mechanism to power the SDIO device. This
can be configured through the device tree [1]. I just checked and it
actually includes specifying the external clock as well.
Regards,
Arend
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Stanislaw Gruszka @ 2017-11-08 10:37 UTC (permalink / raw)
To: Richard Genoud; +Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <1510052483.24015.1.camel@gmail.com>
On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Articles/365835/
> > > > https://lwn.net/Articles/366796/
> > > > https://lwn.net/Articles/370423/
> > > >
> > >
> > > I tried with ftrace, but I don't think there's a way to dump the
> > > trace
> > > when there's a soft lock-up
> > > (I can't do anything after the unbind, even the heartbeat led
> > > stopped blinking).
> > > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
> >
> > You should configure function trace with rt2x* functions. After that
> > start tracing, unbind the device, then stop tracing and provide trace
> > output.
> Ok, I found a way to display the trace (after the unbind, the board is
> frozen and I can't type anything).
> Adding
> CONFIG_SOFTLOCKUP_DETECTOR=y
> CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
> along with echo 1 > /proc/sys/kernel/ftrace_dump_on_oops does the trick
No, that not I wanted you to do. Please remove those options and just do
below on tracing directory.
echo 0 > tracing_on
cat trace > /dev/null
echo "function_graph" > current_tracer
echo "rt2*" > set_ftrace_filter
echo 1 > tracing_on
echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
echo 0 > tracing_on
cat trace > ~/trace.txt
and provide trace.txt to me (can be in private email if big).
Thanks
Stanislaw
^ permalink raw reply
* RE: [1/7] brcmfmac: handle FWHALT mailbox indication
From: Arend van Spriel @ 2017-11-08 10:30 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
Hi Kalle,
I was preparing a new patch series and got a bit confused. Turns out
there was a series still pending in patchwork.
https://patchwork.kernel.org/patch/9948825/
So I applied the pending series on wireless-drivers-next and it compiles
fine. So what I think happened is that the series depended on a patch
that was submitted to wireless-drivers at that time. Can these patches
be taken now or do I need to resubmit.
Regards,
Arend
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Kalle Valo @ 2017-11-08 0:30 UTC (permalink / raw)
To: Stefan Wahren
Cc: brcm80211-dev-list.pdl, Franky Lin, linux-wireless, Chi-Hsien Lin,
Wright Feng, brcm80211-dev-list, Arend van Spriel, Simon Shields,
Hante Meuleman
In-Reply-To: <964084973.5481.1510037571344@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi,
>
>> Kalle Valo <kvalo@codeaurora.org> hat am 7. November 2017 um 03:18 geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>> >> Simon Shields <simon@lineageos.org> hat am 4. November 2017 um 14:24 geschrieben:
>> >>
>> >>
>> >> Some boards use an external 32khz clock for low-power
>> >> mode timing. Make sure the clock is powered on while the chipset
>> >> is active.
>> >>
>> >> Signed-off-by: Simon Shields <simon@lineageos.org>
>> >> ---
>> >> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
>> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
>> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
>> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
>> >> 4 files changed, 19 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> >> index b2bd4704f859..37add5e29272 100644
>> >> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> >> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>> >> @@ -17,6 +17,8 @@ Optional properties:
>> >> When not specified the device will use in-band SDIO interrupts.
>> >> - interrupt-names : name of the out-of-band interrupt, which must be set
>> >> to "host-wake".
>> >> + - clocks : external 32khz clock
>> >> + - clock-names : name of the external 32khz clock, must be "32khz"
>> >
>> > sorry for the nitpicking, but according to the datasheet [1] it's
>> > 32768 Hz. Apart from that i suggest to use a functional name for the
>> > clock like "low_power" or something else, which is more flexible and
>> > future-proof.
>> >
>> > Btw this binding needs to be a separate patch, which should go to the
>> > devicetree guys.
>>
>> Previously I have applied binding documentation changes which the DT
>> maintainers have acked, that's why I specifically asked to Cc device
>> tree list. Has something changed?
>
> as long as the changes has been acked this should be okay. I was
> referring to point 1 in this guideline [1].
>
> [1] -
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt?h=v4.14-rc8
Ah, that's a good point. Splitting the patch does make sense.
--
Kalle Valo
^ permalink raw reply
* [RFC] wireless-regdb: apply 5.8GHz SRD rules to EU/EEA countries (ETSI EN 300 440)
From: Ryan Mounce @ 2017-11-07 23:59 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless, Ryan Mounce
EN 300 440 is a harmonised standard applicable in all EU and EEA countries.
https://ec.europa.eu/growth/single-market/european-standards/harmonised-standards/red_en
Signed-off-by: Ryan Mounce <ryan@mounce.com.au>
---
db.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/db.txt b/db.txt
index 10c84ee..ee24749 100644
--- a/db.txt
+++ b/db.txt
@@ -82,6 +82,8 @@ country AT: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -134,6 +136,8 @@ country BE: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -319,6 +323,8 @@ country CY: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -331,6 +337,8 @@ country CZ: DFS-ETSI
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (500 mW), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -376,6 +384,8 @@ country DK: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -411,6 +421,8 @@ country EE: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -447,6 +459,8 @@ country FI: DFS-ETSI
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -462,6 +476,8 @@ country FR: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -470,6 +486,8 @@ country GB: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -517,6 +535,8 @@ country GR: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -556,6 +576,8 @@ country HR: DFS-ETSI
(5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -571,6 +593,8 @@ country HU: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -584,6 +608,8 @@ country IE: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -606,6 +632,8 @@ country IS: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -614,6 +642,8 @@ country IT: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -721,6 +751,8 @@ country LI: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
country LK: DFS-FCC
(2402 - 2482 @ 40), (20)
@@ -742,6 +774,8 @@ country LT: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -750,6 +784,8 @@ country LU: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -758,6 +794,8 @@ country LV: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -849,6 +887,8 @@ country MT: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -990,6 +1030,8 @@ country PL: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -1011,6 +1053,8 @@ country PT: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -1043,6 +1087,8 @@ country RO: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -1083,6 +1129,8 @@ country SE: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -1103,6 +1151,8 @@ country SI: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -1111,6 +1161,8 @@ country SK: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+ # SRD harmonised in EU/EEA (ETSI EN 300 440)
+ (5725 - 5875 @ 80), (14)
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
--
2.13.6 (Apple Git-96)
^ permalink raw reply related
* Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
From: Doug Anderson @ 2017-11-07 21:15 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: Brian Norris, linux-wireless@vger.kernel.org, Cathy Luo,
Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <a4c65d325abd4d4eb45d8cb3cd172df3@SC-EXCH02.marvell.com>
Hi,
On Tue, Nov 7, 2017 at 8:25 AM, Ganapathi Bhat <gbhat@marvell.com> wrote:
> Hi Doug/Brian,
>
> Thanks a lot for the comments and the discussion. First of all we will abort the change added by this patch as we don't need rx_pkt_lock acquired to protect the deleted item. Next, we will prepare below changes to address the concerns discussed:
> 1. Move rx_pkt_lock from mwifiex_private to rx_reorder_tbl
...or, possibly, remove rx_pkt_lock completely. See my other response...
-Doug
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
From: Doug Anderson @ 2017-11-07 21:13 UTC (permalink / raw)
To: Brian Norris
Cc: Ganapathi Bhat, linux-wireless@vger.kernel.org, Cathy Luo,
Xinming Hu, Zhiyuan Yang, James Cao, Mangesh Malusare,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <20171107022508.GA42502@google.com>
Hi,
On Mon, Nov 6, 2017 at 6:25 PM, Brian Norris <briannorris@chromium.org> wrote:
> Hi Doug and Ganapathi,
>
> On Mon, Nov 06, 2017 at 04:42:20PM -0800, Doug Anderson wrote:
>> Hi,
>>
>> Please take the review below with a grain of salt since I'm not
>> terribly familiar with this driver. I thought I might be able to help
>> since I had previously looked at some of the spinlock stuff, but after
>> digging through the below I'm not 100% convinced I understand this
>> driver enough to do a quick review...
>>
>> On Thu, Nov 2, 2017 at 3:30 AM, Ganapathi Bhat <gbhat@marvell.com> wrote:
>> > Hi Brian,
>> >
>> >> On Tue, Oct 31, 2017 at 03:12:45PM +0530, Ganapathi Bhat wrote:
>> >> > From: Karthik Ananthapadmanabha <karthida@marvell.com>
>> >> >
>> >> > Fix the incorrect usage of rx_pkt_lock spinlock. Realsing the spinlock
>> >> > while the element is still in process is unsafe. The lock must be
>> >> > released only after the element processing is complete.
>> >> >
>> >> > Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
>> >> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
>> >> > ---
>> >> > drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 5 +++--
>> >> > 1 file changed, 3 insertions(+), 2 deletions(-)
>> >> >
>> >> > diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> >> > b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> >> > index 1edcdda..0149c4a 100644
>> >> > --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> >> > +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
>> >> > @@ -124,9 +124,10 @@ static int mwifiex_11n_dispatch_pkt(struct
>> >> mwifiex_private *priv, void *payload)
>> >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
>> >> > tbl->rx_reorder_ptr[i] = NULL;
>> >> > }
>> >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> >>
>> >> So, what is this lock protecting? Is it for protecting the packet itself, or for
>> >> protecting the ring buffer?
>> >
>> > This lock is protecting the ring buffer but with the current change, we are trying also to protect the packet too.
>>
>> What are you trying to protect the packet from? In other words: what
>> other code is trying to make changes to the same structure? I'd agree
>
> Agreed on this question. I don't understand what, specifically, about
> "the packet" you're trying to protect, nor what other code might be
> accessing it.
>
>> with Brian that on first glance nobody else can have a reference to
>> this packet since we've removed it from the global list. If you're
>
> Right, if we're safely removing it from the pseudo ring buffer, then
> nobody else should have access to it now.
>
>> trying to protect something internal to this structure or something
>> global to mwifiex then it seems like you'd want a different lock...
>>
>>
>> >> As I read it, it's just the latter, since once we've
>> >> removed it from the ring buffer (and are about to dispatch it up toward the
>> >> networking layer), it's handled only by a single context (or else, protected via
>> >> some other common lock(s)).
>> >>
>> >> If I'm correct above, then I think the current code here is actually safe, since
>> >> it holds the lock while removing from the ring buffer -- after it's removed
>> >> from the ring, there's no way another thread can find this payload, and so we
>> >> can release the lock.
>> >
>> > There are cases where the ring buffer is iterated by cfg80211 thread:
>> > mwifiex_cfg80211_tdls_oper => mwifiex_tdls_oper => mwifiex_tdls_process_disable_link => mwifiex_11n_cleanup_reorder_tbl => mwifiex_del_rx_reorder_entry => mwifiex_11n_dispatch_pkt_until_start_win => {iterates the ring buffer}
>> > So, at worst case we can have two threads (main & cfg80211) running mwifiex_11n_dispatch_pkt_until_start_win(), iterating the ring buffer.
>>
>> Let me see if I'm understanding properly.
>>
>> There's a global (one for the whole driver) list called the
>
> Just a point of order: it's a single list for each 'mwifiex_private' --
> there can actually be multiple virtual interfaces attached to each
> physical wiphy interface, and each virtual interface gets a
> 'mwifiex_private' instance. But otherwise, your descriptions are
> accurate I believe.
Ah, thanks for clarification! :)
>> "rx_reorder_tbl_ptr". Insertion, deletion, and iteration of elements
>> into this list are protected by the global "rx_reorder_tbl_lock" so we
>> don't corrupt the linked list structure.
>>
>> The actual elements in the "rx_reorder_tbl_ptr" are _not_ protected by
>> the global "rx_reorder_tbl_lock". I make this statement because I see
>> mwifiex_11n_get_rx_reorder_tbl() which drops the lock before returning
>> an entry.
>
> Actually, patch 3 is changing that one :)
The patch 3 that you said introduces a deadlock? ;)
>> ...and it seems sane that there could be a separate (more
>> fine grained) lock protecting these elements. It is OK to keep a
>> pointer to an element in this list without holding the lock--even if
>> it's removed from the list the pointer is still valid. Presumably
>> full deletion of the element (and any other access of members of the
>> element) is protected by some other lock.
>
> Aiee! You have too much faith. mwifiex_11n_del_rx_reorder_tbl_by_ta() ->
> mwifiex_del_rx_reorder_entry(), for instance, has *very* bad handling of
> this lock. It looks like:
> (a) it does a series of acquire/release pairs on this lock while still
> retaining the mwifiex_rx_reorder_tbl pointer. That's bad.
> (b) it doesn't have any other lock to protect deletion; it *hopes* that
> it cleared out the remaining packets in its buffer
> (mwifiex_11n_dispatch_pkt_until_start_win()); but it doesn't hold any
> other relevant locks between that and this:
>
> spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> list_del(&tbl->list);
> spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> kfree(tbl->rx_reorder_ptr);
> kfree(tbl);
>
> That's pretty bad.
>
> I think it's best to work toward holding that lock while anyone is accessing
> the entry. So we should only drop the lock when we're done accessing the
> element, or when we've removed it from the list.
OK, sounds good. I guess that'll have to be prototyped and so we can
see if it's possible to do without running into deadlocks.
One question I have: do we ever actually do anything serious with one
of these elements when it's _not_ in the list? As far as I can tell
entries are added to "priv->rx_reorder_tbl_ptr" at creation time and
removed at deletion time.
If that's true and we start holding the "rx_reorder_tbl_lock" whenever
we're accessing the linked list _or_ the contents then we can actually
just get rid of the "rx_pkt_lock" because whenever we grab rx_pkt_lock
we're guaranteed to already be holding the rx_reorder_tbl_lock.
I guess I'd have to see this prototyped to see if it really works.
>> Each element in the "rx_reorder_tbl_ptr" list is a "struct
>> mwifiex_rx_reorder_tbl". It contains a pseudo-circular buffer
>> (win_size elements big) "tbl->rx_reorder_ptr[]". Insertions and
>> deletions from the pseudo-circular buffer are supposed to be protected
>> by the global "rx_pkt_lock".
>
> Seems right to me.
>
>> In general if you hold an "index" into
>> this buffer you should be holding the "rx_pkt_lock",
>
> Sure.
>
>> but if you hold
>> one of the elements (each element is a pointer) then you presumably
>> don't need the "rx_pkt_lock" (if you do, I'd be curious as to why).
>
> You mean, "if you hold one of these elements [and have removed it from the ring
> buffer]" then you don't need the lock? If so, I agree.
>
>> Did I get that right?
>>
>>
>> So overall the "rx_pkt_lock" seems a bit fishy to me.
>>
>> My first clue that something seems wrong is that "rx_pkt_lock" is
>> global (one for the whole driver) but seems to be protecting something
>> that is more fine-grained. Locks really ought to be part of the
>> structure whose elements they are protecting. Said another way, I'd
>> expect "rx_pkt_lock" NOT to be in "priv" but for there to be a
>> separate instance of "rx_pkt_lock" inside each "struct
>> mwifiex_rx_reorder_tbl". That would make it much more obvious what
>> was being protected and also would allow different tables to be worked
>> on at the same time.
>>
>> NOTE: it's probably not the end of the world if there's a single
>> global "rx_pkt_lock", it's just less ideal and not all that different
>> than having one big lock protecting everything in the driver.
>
> Agreed on the above 2 paragraphs. At a minimum, rx_pkt_lock should be
> documented better. But part of that documentation is typically putting the lock
> near what it's protecting.
>
> But overall, I'm not sure we're getting much interesting concurrency
> here at all, and so I'm not sure if all the (poort attempt at)
> fine-grained locking is even helpful. Ganapathi only pointed out
> cfg80211 TDLS operations as the "2nd thread of execution" besides the
> mwifiex "main thread" -- this thread is only used for configuration
> (e.g., setup, teardown, and configuration of TDLS links). And any time
> we're holding the "fine grained" rx_pkt_lock, we already are holdling
> the larger table lock.
>
>> The other thing that is fishy is that "rx_pkt_lock" doesn't seem to be
>> reliably protecting, again as Brian pointed out. Specifically:
>>
>> * It seems like "start_win" is supposed to be protected by
>> "rx_pkt_lock" too, but it's not in
>> mwifiex_11n_dispatch_pkt_until_start_win() (and many other places, I
>> didn't check). In general any place where we're holding an _index_
>> into the table seems like it should have the "rx_pkt_lock" and
>> "start_win" is an index. Why do I say this? If you are holding an
>> _index_ and something is deleted from the list (or shuffled) then the
>> index just won't be valid anymore. Thus if others can be inserting /
>> removing / shuffling the list then holding an index isn't safe without
>> the lock.
>
> Agreed.
>
>> * There are several places that access "rx_reorder_ptr" without
>> grabbing "rx_pkt_lock". That seems wrong. For instance,
>> mwifiex_get_rx_reorder_tbl(), but probably other places too.
>
> Ah, yes.
>
>> * Functions like mwifiex_11n_find_last_seq_num() seem quite confused.
>> They act on a table entry but for some reason grab the
>> "rx_reorder_tbl_lock", which was supposed to be protecting the linked
>> list (I think).
>
> Agreed.
>
>> Worse yet mwifiex_11n_find_last_seq_num() returns an
>> _index_ into the pseudo-queue. I don't think that is a super valid
>> thing to do unless you assume that the caller has the
>> rx_reorder_tbl_lock, which it doesn't. Probably
>> mwifiex_11n_find_last_seq_num() should require the caller hold
>> "rx_pkt_lock".
>
> I'm not sure the right solution here, but it does look wrong today. The
> only saving grace here would be if we don't care about this being
> slightly inaccurate. For instance, I *think* it's fine to return some of
> this out of order.
>
> On a similar note: why does mwifiex_11n_dispatch_pkt_until_start_win()
> release rx_pkt_lock in between each index (i.e., the "for (i = 0; i <
> pkt_to_send; ++i)" loop)? That means that the entire ring buffer
> indexing could change underneath our feet. I'm not sure this is
> technically unsafe (we do still grab the lock and do NULL checks), but
> it might still cause undesireable results around what packets get
> dispatched or now -- i.e., we might not *really* be honoring the window
> arguments that were passed in.
Yeah, it's pretty silly. It would get fixed if you held the lock
during the whole time you held onto an index (since "i" is an index).
...but maybe we'll just get rid of the rx_pkt_lock anyway in which
case it won't matter?
Speaking of silly things in that function though, right now we have:
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
rx_tmp_ptr = NULL;
if (tbl->rx_reorder_ptr[i]) {
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
}
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
if (rx_tmp_ptr)
mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
Since mwifiex_11n_dispatch_pkt() actually checks for a NULL parameter
and there's no reason to say (a = NULL; if b != NULL then a = b), the
above is actually just:
spin_lock_irqsave(&priv->rx_pkt_lock, flags);
rx_tmp_ptr = tbl->rx_reorder_ptr[i];
tbl->rx_reorder_ptr[i] = NULL;
spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
...but that's just an optimization.
>> >> On a related note: I don't actually see the ring buffer *insertion* being
>> >> protected by this rx_pkt_lock, so is it really useful? See
>> >> mwifiex_11n_rx_reorder_pkt(). Perhaps the correct lock is actually
>> >> rx_reorder_tbl_lock()? Except that serves multiple purposes it seems...
>> >
>> > Right, ring buffer insertion is not protected. I think we should be using both rx_reorder_tbl_lock(which is already present) and rx_pkt_lock(we need to add) during insertion (mwifiex_11n_rx_reorder_pkt()).
>>
>> As far as I see mwifiex_11n_rx_reorder_pkt() doesn't hold
>> "rx_reorder_tbl_lock" for the whole function. It just grabs it to
>> search the linked list and then drops it. Is that right? Seems OK
>> given my current (limited) understanding but it sounded like you were
>> expecting it to be held for the whole function?
>
> I think patch 3 fixes that? It tries to grab the lock for (almost) the
> entire function.
>
>> IMHO then it needs to grab "rx_pkt_lock" before the access to
>> tbl->start_win, but I haven't looked at everything fully.
>>
>>
>> > Also, we should be using rx_pkt_lock instead of rx_reorder_tbl_lock in mwifiex_11n_find_last_seq_num().
>> >>
>> >> Another thought: from what I can tell, all of these operations are
>> >> *only* performed on the main thread, so there's actually no concurrency
>> >> involved at all. So we also could probably drop this lock entirely...
>> >
>> > Let us know your inputs on above observations.
>>
>> Not sure if my thoughts above made sense or were useful. Hopefully I
>> didn't sound too stupid... ;)
>
> Not stupid to me. Thanks for looking.
>
> Brian
>
>> >> I guess the real point is: can you explain better what you intend this lock to
>> >> do? Then we can review whether you're accomplishing your intention, or
>> >> whether we should improve the usage of this lock in some other way, or
>> >> perhaps even kill it entirely.
>> >>
>> >> Thanks,
>> >> Brian
>> >>
>> >> > if (rx_tmp_ptr)
>> >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
>> >> > +
>> >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> >> > }
>> >> >
>> >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags); @@ -167,8 +168,8 @@
>> >> > static int mwifiex_11n_dispatch_pkt(struct mwifiex_private *priv, void
>> >> *payload)
>> >> > }
>> >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
>> >> > tbl->rx_reorder_ptr[i] = NULL;
>> >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
>> >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
>> >> > }
>> >> >
>> >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags);
>> >> > --
>> >> > 1.9.1
>> >> >
>> >
>> > Regards,
>> > Ganapathi
^ permalink raw reply
* [PATCH] zd1201: remove unused variable framelen
From: Colin King @ 2017-11-07 18:56 UTC (permalink / raw)
To: Kalle Valo, linux-wireless, netdev; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Variable framelen is assigned but never read, hence it is redundant
and can be removed. Cleans up clang warning:
drivers/net/wireless/zydas/zd1201.c:234:3: warning: Value stored
to 'framelen' is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/zydas/zd1201.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/zydas/zd1201.c b/drivers/net/wireless/zydas/zd1201.c
index 581e8577a221..253403899fe9 100644
--- a/drivers/net/wireless/zydas/zd1201.c
+++ b/drivers/net/wireless/zydas/zd1201.c
@@ -230,8 +230,7 @@ static void zd1201_usbrx(struct urb *urb)
/* Info frame */
if (type == ZD1201_PACKET_INQUIRE) {
int i = 0;
- unsigned short infotype, framelen, copylen;
- framelen = le16_to_cpu(*(__le16*)&data[4]);
+ unsigned short infotype, copylen;
infotype = le16_to_cpu(*(__le16*)&data[6]);
if (infotype == ZD1201_INF_LINKSTATUS) {
--
2.14.1
^ permalink raw reply related
* RE: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in 11n_rxreorder.c
From: Ganapathi Bhat @ 2017-11-07 16:25 UTC (permalink / raw)
To: Brian Norris, Doug Anderson
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Xinming Hu,
Zhiyuan Yang, James Cao, Mangesh Malusare,
Karthik Doddayennegere Ananthapadmanabha
In-Reply-To: <20171107022508.GA42502@google.com>
Hi Doug/Brian,
Thanks a lot for the comments and the discussion. First of all we will abort the change added by this patch as we don't need rx_pkt_lock acquired to protect the deleted item. Next, we will prepare below changes to address the concerns discussed:
1. Move rx_pkt_lock from mwifiex_private to rx_reorder_tbl
2. Protect all (missing) cases of rx_reorder_ptr array (creation/insertion/iteration) with rx_pkt_lock
3. Protect start_win with rx_pkt_lock
4. Use rx_pkt_lock instead of rx_reorder_tbl_lock in mwifiex_11n_find_last_seq_num ()
5. Protect mwifiex_11n_find_last_seq_num() with rx_pkt_lock
6. Hold rx_pkt_lock for the entire function mwifiex_11n_dispatch_pkt_until_start_win ()
Above changes are mentioned below under their respective comments. Kindly go through:
> Subject: Re: [EXT] Re: [PATCH 1/3] mwifiex: cleanup rx_pkt_lock usage in
> 11n_rxreorder.c
>
> Hi Doug and Ganapathi,
>
> On Mon, Nov 06, 2017 at 04:42:20PM -0800, Doug Anderson wrote:
> > Hi,
> >
> > Please take the review below with a grain of salt since I'm not
> > terribly familiar with this driver. I thought I might be able to help
> > since I had previously looked at some of the spinlock stuff, but after
> > digging through the below I'm not 100% convinced I understand this
> > driver enough to do a quick review...
> >
> > On Thu, Nov 2, 2017 at 3:30 AM, Ganapathi Bhat <gbhat@marvell.com>
> wrote:
> > > Hi Brian,
> > >
> > >> On Tue, Oct 31, 2017 at 03:12:45PM +0530, Ganapathi Bhat wrote:
> > >> > From: Karthik Ananthapadmanabha <karthida@marvell.com>
> > >> >
> > >> > Fix the incorrect usage of rx_pkt_lock spinlock. Realsing the
> > >> > spinlock while the element is still in process is unsafe. The
> > >> > lock must be released only after the element processing is complete.
> > >> >
> > >> > Signed-off-by: Karthik Ananthapadmanabha <karthida@marvell.com>
> > >> > Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> > >> > ---
> > >> > drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 5 +++--
> > >> > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > >> > b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > >> > index 1edcdda..0149c4a 100644
> > >> > --- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > >> > +++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c
> > >> > @@ -124,9 +124,10 @@ static int mwifiex_11n_dispatch_pkt(struct
> > >> mwifiex_private *priv, void *payload)
> > >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
> > >> > tbl->rx_reorder_ptr[i] = NULL;
> > >> > }
> > >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> > >>
> > >> So, what is this lock protecting? Is it for protecting the packet
> > >> itself, or for protecting the ring buffer?
> > >
> > > This lock is protecting the ring buffer but with the current change, we are
> trying also to protect the packet too.
> >
> > What are you trying to protect the packet from? In other words: what
> > other code is trying to make changes to the same structure? I'd agree
>
> Agreed on this question. I don't understand what, specifically, about "the
> packet" you're trying to protect, nor what other code might be accessing it.
>
> > with Brian that on first glance nobody else can have a reference to
> > this packet since we've removed it from the global list. If you're
>
> Right, if we're safely removing it from the pseudo ring buffer, then nobody
> else should have access to it now.
>
> > trying to protect something internal to this structure or something
> > global to mwifiex then it seems like you'd want a different lock...
> >
> >
> > >> As I read it, it's just the latter, since once we've removed it
> > >> from the ring buffer (and are about to dispatch it up toward the
> > >> networking layer), it's handled only by a single context (or else,
> > >> protected via some other common lock(s)).
> > >>
> > >> If I'm correct above, then I think the current code here is
> > >> actually safe, since it holds the lock while removing from the ring
> > >> buffer -- after it's removed from the ring, there's no way another
> > >> thread can find this payload, and so we can release the lock.
> > >
> > > There are cases where the ring buffer is iterated by cfg80211 thread:
> > > mwifiex_cfg80211_tdls_oper => mwifiex_tdls_oper =>
> > > mwifiex_tdls_process_disable_link =>
> > >mwifiex_11n_cleanup_reorder_tbl => mwifiex_del_rx_reorder_entry =>
> > >mwifiex_11n_dispatch_pkt_until_start_win => {iterates the ring buffer} So,
> > >at worst case we can have two threads (main & cfg80211) running
> > >mwifiex_11n_dispatch_pkt_until_start_win(), iterating the ring buffer.
> >
> > Let me see if I'm understanding properly.
> >
> > There's a global (one for the whole driver) list called the
>
> Just a point of order: it's a single list for each 'mwifiex_private' -- there can
> actually be multiple virtual interfaces attached to each physical wiphy
> interface, and each virtual interface gets a 'mwifiex_private' instance. But
> otherwise, your descriptions are accurate I believe.
>
> > "rx_reorder_tbl_ptr". Insertion, deletion, and iteration of elements
> > into this list are protected by the global "rx_reorder_tbl_lock" so we
> > don't corrupt the linked list structure.
> >
> > The actual elements in the "rx_reorder_tbl_ptr" are _not_ protected by
> > the global "rx_reorder_tbl_lock". I make this statement because I see
> > mwifiex_11n_get_rx_reorder_tbl() which drops the lock before returning
> > an entry.
>
> Actually, patch 3 is changing that one :)
>
> > ...and it seems sane that there could be a separate (more fine
> > grained) lock protecting these elements. It is OK to keep a pointer
> > to an element in this list without holding the lock--even if it's
> > removed from the list the pointer is still valid. Presumably full
> > deletion of the element (and any other access of members of the
> > element) is protected by some other lock.
>
> Aiee! You have too much faith. mwifiex_11n_del_rx_reorder_tbl_by_ta() ->
> mwifiex_del_rx_reorder_entry(), for instance, has *very* bad handling of
> this lock. It looks like:
> (a) it does a series of acquire/release pairs on this lock while still retaining the
> mwifiex_rx_reorder_tbl pointer. That's bad.
> (b) it doesn't have any other lock to protect deletion; it *hopes* that it
> cleared out the remaining packets in its buffer
> (mwifiex_11n_dispatch_pkt_until_start_win()); but it doesn't hold any other
> relevant locks between that and this:
>
> spin_lock_irqsave(&priv->rx_reorder_tbl_lock, flags);
> list_del(&tbl->list);
> spin_unlock_irqrestore(&priv->rx_reorder_tbl_lock, flags);
>
> kfree(tbl->rx_reorder_ptr);
> kfree(tbl);
>
> That's pretty bad.
>
> I think it's best to work toward holding that lock while anyone is accessing the
> entry. So we should only drop the lock when we're done accessing the
> element, or when we've removed it from the list.
>
> > Each element in the "rx_reorder_tbl_ptr" list is a "struct
> > mwifiex_rx_reorder_tbl". It contains a pseudo-circular buffer
> > (win_size elements big) "tbl->rx_reorder_ptr[]". Insertions and
> > deletions from the pseudo-circular buffer are supposed to be protected
> > by the global "rx_pkt_lock".
>
> Seems right to me.
>
> > In general if you hold an "index" into this buffer you should be
> > holding the "rx_pkt_lock",
>
> Sure.
>
> > but if you hold
> > one of the elements (each element is a pointer) then you presumably
> > don't need the "rx_pkt_lock" (if you do, I'd be curious as to why).
>
> You mean, "if you hold one of these elements [and have removed it from
> the ring buffer]" then you don't need the lock? If so, I agree.
>
> > Did I get that right?
> >
Yes. Actually, I got this now. We removed it from ring buffer and no more locking needed for this element. Sorry Brian for unnecessary confusions. Somehow I missed the point that the element is being deleted.
> >
> > So overall the "rx_pkt_lock" seems a bit fishy to me.
> >
> > My first clue that something seems wrong is that "rx_pkt_lock" is
> > global (one for the whole driver) but seems to be protecting something
> > that is more fine-grained. Locks really ought to be part of the
> > structure whose elements they are protecting. Said another way, I'd
> > expect "rx_pkt_lock" NOT to be in "priv" but for there to be a
> > separate instance of "rx_pkt_lock" inside each "struct
> > mwifiex_rx_reorder_tbl". That would make it much more obvious what
> > was being protected and also would allow different tables to be worked
> > on at the same time.
> >
> > NOTE: it's probably not the end of the world if there's a single
> > global "rx_pkt_lock", it's just less ideal and not all that different
> > than having one big lock protecting everything in the driver.
>
> Agreed on the above 2 paragraphs. At a minimum, rx_pkt_lock should be
> documented better. But part of that documentation is typically putting the
> lock near what it's protecting.
>
Will address this with change #1
> But overall, I'm not sure we're getting much interesting concurrency here at
> all, and so I'm not sure if all the (poort attempt at) fine-grained locking is
> even helpful. Ganapathi only pointed out
> cfg80211 TDLS operations as the "2nd thread of execution" besides the
> mwifiex "main thread" -- this thread is only used for configuration (e.g.,
> setup, teardown, and configuration of TDLS links). And any time we're
> holding the "fine grained" rx_pkt_lock, we already are holdling the larger
> table lock.
>
> > The other thing that is fishy is that "rx_pkt_lock" doesn't seem to be
> > reliably protecting, again as Brian pointed out. Specifically:
> >
> > * It seems like "start_win" is supposed to be protected by
> > "rx_pkt_lock" too, but it's not in
> > mwifiex_11n_dispatch_pkt_until_start_win() (and many other places, I
> > didn't check). In general any place where we're holding an _index_
> > into the table seems like it should have the "rx_pkt_lock" and
> > "start_win" is an index. Why do I say this? If you are holding an
> > _index_ and something is deleted from the list (or shuffled) then the
> > index just won't be valid anymore. Thus if others can be inserting /
> > removing / shuffling the list then holding an index isn't safe without
> > the lock.
>
> Agreed.
Will address this with change #3
>
> > * There are several places that access "rx_reorder_ptr" without
> > grabbing "rx_pkt_lock". That seems wrong. For instance,
> > mwifiex_get_rx_reorder_tbl(), but probably other places too.
>
> Ah, yes.
>
Will address this with change #2
> > * Functions like mwifiex_11n_find_last_seq_num() seem quite confused.
> > They act on a table entry but for some reason grab the
> > "rx_reorder_tbl_lock", which was supposed to be protecting the linked
> > list (I think).
>
> Agreed.
>
Will address this with change #4
> > Worse yet mwifiex_11n_find_last_seq_num() returns an _index_ into the
> > pseudo-queue. I don't think that is a super valid thing to do unless
> > you assume that the caller has the rx_reorder_tbl_lock, which it
> > doesn't. Probably
> > mwifiex_11n_find_last_seq_num() should require the caller hold
> > "rx_pkt_lock".
>
Will address this with change #5
> I'm not sure the right solution here, but it does look wrong today. The only
> saving grace here would be if we don't care about this being slightly
> inaccurate. For instance, I *think* it's fine to return some of this out of order.
>
> On a similar note: why does mwifiex_11n_dispatch_pkt_until_start_win()
> release rx_pkt_lock in between each index (i.e., the "for (i = 0; i <
> pkt_to_send; ++i)" loop)? That means that the entire ring buffer indexing
> could change underneath our feet. I'm not sure this is technically unsafe (we
> do still grab the lock and do NULL checks), but it might still cause undesireable
> results around what packets get dispatched or now -- i.e., we might not
> *really* be honoring the window arguments that were passed in.
>
Will address this with change #6
> > >> On a related note: I don't actually see the ring buffer *insertion*
> > >> being protected by this rx_pkt_lock, so is it really useful? See
> > >> mwifiex_11n_rx_reorder_pkt(). Perhaps the correct lock is actually
> > >> rx_reorder_tbl_lock()? Except that serves multiple purposes it seems...
> > >
> > > Right, ring buffer insertion is not protected. I think we should be using
> both rx_reorder_tbl_lock(which is already present) and rx_pkt_lock(we
> need to add) during insertion (mwifiex_11n_rx_reorder_pkt()).
> >
> > As far as I see mwifiex_11n_rx_reorder_pkt() doesn't hold
> > "rx_reorder_tbl_lock" for the whole function. It just grabs it to
> > search the linked list and then drops it. Is that right? Seems OK
> > given my current (limited) understanding but it sounded like you were
> > expecting it to be held for the whole function?
>
> I think patch 3 fixes that? It tries to grab the lock for (almost) the entire
> function.
>
> > IMHO then it needs to grab "rx_pkt_lock" before the access to
> > tbl->start_win, but I haven't looked at everything fully.
> >
> >
> > > Also, we should be using rx_pkt_lock instead of rx_reorder_tbl_lock in
> mwifiex_11n_find_last_seq_num().
> > >>
> > >> Another thought: from what I can tell, all of these operations are
> > >> *only* performed on the main thread, so there's actually no
> > >> concurrency involved at all. So we also could probably drop this lock
> entirely...
> > >
> > > Let us know your inputs on above observations.
> >
> > Not sure if my thoughts above made sense or were useful. Hopefully I
> > didn't sound too stupid... ;)
>
> Not stupid to me. Thanks for looking.
>
Thanks for all the reviews.
> Brian
>
> > >> I guess the real point is: can you explain better what you intend
> > >> this lock to do? Then we can review whether you're accomplishing
> > >> your intention, or whether we should improve the usage of this lock
> > >> in some other way, or perhaps even kill it entirely.
Brian,
I got it. This change is not needed.
Also, let us know if above changes are all that we needed OR if above changes still fail to accurately address the things mentioned here.
> > >>
> > >> Thanks,
> > >> Brian
> > >>
> > >> > if (rx_tmp_ptr)
> > >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
> > >> > +
> > >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> > >> > }
> > >> >
> > >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags); @@ -167,8
> > >> > +168,8 @@ static int mwifiex_11n_dispatch_pkt(struct
> > >> > mwifiex_private *priv, void
> > >> *payload)
> > >> > }
> > >> > rx_tmp_ptr = tbl->rx_reorder_ptr[i];
> > >> > tbl->rx_reorder_ptr[i] = NULL;
> > >> > - spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> > >> > mwifiex_11n_dispatch_pkt(priv, rx_tmp_ptr);
> > >> > + spin_unlock_irqrestore(&priv->rx_pkt_lock, flags);
> > >> > }
> > >> >
> > >> > spin_lock_irqsave(&priv->rx_pkt_lock, flags);
> > >> > --
> > >> > 1.9.1
> > >> >
> > >
> > > Regards,
> > > Ganapathi
^ permalink raw reply
* Update regulatory rules for Denmark (DK) on 2.4 and 5GHz
From: Per Mejdal Rasmussen @ 2017-11-07 14:48 UTC (permalink / raw)
To: seth.forshee; +Cc: wireless-regdb, linux-wireless
Hi
I have taken the time research which frequencies and power levels are
allowed for WiFi in Denmark. So db.txt for wireless-regdb can be updated.
Allowed WiFi frequencies in Denmark for WiFi:
---------------------------------------------
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
5725,0-5875,0 MHz
57-66 GHz
Source: https://www.retsinformation.dk/Forms/R0710.aspx?id=189932
Search for "RLAN". The website is owned by the Danish government.
Maximum transmission strength and usage
---------------------------------------
2400-2483,5 MHz ? mW/MHz 100 mW EIRP
5150-5250 MHz 10 mW/MHz 200 mW EIRP Both in/outdoor allowed
5470-5725 MHz 50 mW/MHz 1 W EIRP Both in/outdoor allowed
5725-5875 MHz 200 mW/MHz 4 W EIRP BFWA only, 5795-5815 excluded
5725-5875 MHz ? mW/MHz 25 mW EIRP Short range devices
57-66 GHz 20 mW/MHz 10 W EIRP No fixed outdoor install
DFS is required for 5250-5350, 5470-5725 and because of ETSI EN 301 893
DFS is required for 5725-5875 for BFWA, because of ETSI EN 302 502
Sources:
5GHz:
https://erhvervsstyrelsen.dk/sites/default/files/007_interface-datanet_5-6_ghz.pdf.pdf
60GHz:
https://erhvervsstyrelsen.dk/sites/default/files/radiograenseflader-63.pdf
The website is owned by the Danish government.
Outdated content of db.txt:
---------------------------
country DK: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
Suggested fix:
--------------
country DK: DFS-ETSI
(2400 - 2483.5 @ 40), (20)
(5150 - 5250 @ 80), (23), AUTO-BW
(5250 - 5350 @ 80), (23), DFS, AUTO-BW
(5470 - 5725 @ 160), (30), DFS
# Short Range Devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (14)
# Broadband Fixed Wireless Access (ETSI EN 302 502)
(5725 - 5795 @ 40), (36), PTP_ONLY, DFS
(5815 - 5875 @ 40), (36), PTP_ONLY, DFS
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40), NO-OUTDOOR
History of WiFi frequencies in Denmark for WiFi:
------------------------------------------------
From 1999-09-07:
2400,0-2483,5 MHz
5150,0-5250,0 MHz
From 2000-03-30
2400,0-2483,5 MHz
5150,0-5350,0 MHz
From 2002-12-10
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
17,1-17,3 GHz
From 2006-11-07
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
5725,0-5925,0 MHz
17,1-17,3 GHz
From 2007-09-20
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
5725,0-5875,0 MHz
17,1-17,3 GHz
From 2008-06-11
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
5725,0-5875,0 MHz
From 2009-11-27 (current)
2400,0-2483,5 MHz
5150,0-5350,0 MHz
5470,0-5725,0 MHz
5725,0-5875,0 MHz
57-66 GHz
--
Per Mejdal Rasmussen
http://personprofil.aau.dk/109070
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Simon Shields @ 2017-11-07 13:31 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
devicetree, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng
In-Reply-To: <5A019463.9060701@broadcom.com>
Hi Arend,
On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
> On 11/6/2017 12:27 PM, Simon Shields wrote:
> > On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
> > > On 11/4/2017 2:24 PM, Simon Shields wrote:
> > > > Some boards use an external 32khz clock for low-power
> > > > mode timing. Make sure the clock is powered on while the chipset
> > > > is active.
> > >
> > > Do you have such a board? With the little documentation I can get my hands
> > > on here I wonder whether the clock needs to be enabled before the device is
> > > powered. If you have the hardware I would like to check some registers in
> > > the device.
> > >
> >
> > Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
> > with this patch and one more that enables the WL_REG_EN pin when
> > brcmfmac is probed.
>
> Ok. So this is exactly the thing I was wondering about. So it makes me
> curious how the WL_REG_EN patch looks like. Can you provide that?
>
Here[0] is a link to the patch in its current state. Obviously, it's not
ready at all for mainlining :-)
[0]: https://github.com/fourkbomb/linux/commit/436e59e58b44d856c186fc4767560cecbcbc0c59.patch
> > Without this patch (and only enabling WL_REG_EN), the chip is detected but
> > attempting to initialise it fails with a bunch of timeouts.
>
> I would be interested in seeing a detailed log of that. Could you provide
> that? You need to build the driver with CONFIG_BRCMDBG and pass module
> parameter 'debug=0x1416' upon insmod/modprobe.
Certainly:
[ 0.000000] Booting Linux on physical CPU 0xa00
[ 0.000000] Linux version 4.14.0-rc8-16239-g648339c97218-dirty (simon@archbox) (gcc version 7.2.0 (Buildroot 2017.08.1-g57ac0de)) #28 SMP PREEMPT Wed Nov 8 00:19:16 AEDT 2017
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Samsung T03G (GT-N7100) based on MIDAS
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 96 MiB at 0x79c00000
[ 0.000000] Samsung CPU ID: 0xe4412211
[ 0.000000] On node 0 totalpages: 261632
[ 0.000000] free_area_init_node: node 0, pgdat c0c52d40, node_mem_map deff7000
[ 0.000000] Normal zone: 1008 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 129024 pages, LIFO batch:31
[ 0.000000] HighMem zone: 132608 pages, LIFO batch:31
[ 0.000000] Running under secure firmware.
[ 0.000000] random: fast init done
[ 0.000000] percpu: Embedded 16 pages/cpu @def70000 s35672 r8192 d21672 u65536
[ 0.000000] pcpu-alloc: s35672 r8192 d21672 u65536 alloc=16*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260624
[ 0.000000] Kernel command line: console=ram loglevel=4 sec_debug.level=0 sec_watchdog.sec_pet=5 androidboot.debug_level=0x4f4c sec_log=0x100000@0x46000000 s3cfb.bootloaderfb=0x5ec00000 lcdtype=96 consoleblank=0 lpcharge=0 lpj=3981312 vmalloc=144m oops=panic pmic_info=67 cordon=5c0811cff7d6af7a5dacedab1b4aadf7 connie=GT-I9300_OPEN_EUR_e0f9225b82d5640974bd1e8552938c7d androidboot.emmc_checksum=3 androidboot.odin_download=1 androidboot.bootloader=I9300XXUGMK6 androidboot.serialno=4df7658224facfb9 snd_soc_core.pmdown_time=1000 console=tty0 androidboot.hardware=smdk4x12 androidboot.selinux=permissive vmalloc=512m consoleblank=0
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] Memory: 924848K/1046528K available (7168K kernel code, 393K rwdata, 2580K rodata, 1024K init, 463K bss, 23376K reserved, 98304K cma-reserved, 432128K highmem)
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xe0000000 - 0xff800000 ( 504 MB)
lowmem : 0xc0000000 - 0xdf800000 ( 504 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc0800000 (8160 kB)
.init : 0xc0b00000 - 0xc0c00000 (1024 kB)
.data : 0xc0c00000 - 0xc0c62678 ( 394 kB)
.bss : 0xc0c6ad74 - 0xc0cdeb6c ( 464 kB)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C: platform modifies aux control register: 0x02070000 -> 0x3e470001
[ 0.000000] L2C: platform provided aux values permit register corruption.
[ 0.000000] L2C: DT/platform modifies aux control register: 0x02070000 -> 0x3e470001
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310: enabling full line of zeros but not enabled in Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 8 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x4100c4c8, AUX_CTRL 0x7e470001
[ 0.000000] Exynos4x12 clocks: sclk_apll = 400000000, sclk_mpll = 800000000
sclk_epll = 96000000, sclk_vpll = 108000000, arm_clk = 800000000
[ 0.000000] Switching to timer-based delay loop, resolution 41ns
[ 0.000000] clocksource: mct-frc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.000005] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000307] Console: colour dummy device 80x30
[ 0.000351] console [tty0] enabled
[ 0.000373] Calibrating delay loop (skipped) preset value.. 796.26 BogoMIPS (lpj=3981312)
[ 0.000385] pid_max: default: 32768 minimum: 301
[ 0.000460] Security Framework initialized
[ 0.000467] SELinux: Initializing.
[ 0.000533] SELinux: Starting in permissive mode
[ 0.000571] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.000579] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.001181] CPU: Testing write buffer coherency: ok
[ 0.001680] CPU0: thread -1, cpu 0, socket 10, mpidr 80000a00
[ 0.040040] Setting up static identity map for 0x40100000 - 0x40100060
[ 0.060002] Hierarchical SRCU implementation.
[ 0.100003] smp: Bringing up secondary CPUs ...
[ 0.170431] CPU1: thread -1, cpu 1, socket 10, mpidr 80000a01
[ 0.240358] CPU2: thread -1, cpu 2, socket 10, mpidr 80000a02
[ 0.310334] CPU3: thread -1, cpu 3, socket 10, mpidr 80000a03
[ 0.310439] smp: Brought up 1 node, 4 CPUs
[ 0.310448] SMP: Total of 4 processors activated (3185.04 BogoMIPS).
[ 0.310453] CPU: All CPU(s) started in SVC mode.
[ 0.311319] devtmpfs: initialized
[ 0.328843] VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
[ 0.329097] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.329114] futex hash table entries: 1024 (order: 4, 65536 bytes)
[ 0.332515] pinctrl core: initialized pinctrl subsystem
[ 0.333481] /lcd0-power-domain@10023C80 has as child subdomain: /tv-power-domain@10023C20.
[ 0.334606] NET: Registered protocol family 16
[ 0.337012] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.338217] cpuidle: using governor menu
[ 0.353786] gpio gpiochip0: (gpa0): added GPIO chardev (254:0)
[ 0.353796] gpiochip_setup_dev: registered GPIOs 0 to 7 on device: gpiochip0 (gpa0)
[ 0.353948] gpio gpiochip1: (gpa1): added GPIO chardev (254:1)
[ 0.353957] gpiochip_setup_dev: registered GPIOs 8 to 13 on device: gpiochip1 (gpa1)
[ 0.354102] gpio gpiochip2: (gpb): added GPIO chardev (254:2)
[ 0.354110] gpiochip_setup_dev: registered GPIOs 14 to 21 on device: gpiochip2 (gpb)
[ 0.354244] gpio gpiochip3: (gpc0): added GPIO chardev (254:3)
[ 0.354252] gpiochip_setup_dev: registered GPIOs 22 to 26 on device: gpiochip3 (gpc0)
[ 0.354397] gpio gpiochip4: (gpc1): added GPIO chardev (254:4)
[ 0.354405] gpiochip_setup_dev: registered GPIOs 27 to 31 on device: gpiochip4 (gpc1)
[ 0.354541] gpio gpiochip5: (gpd0): added GPIO chardev (254:5)
[ 0.354549] gpiochip_setup_dev: registered GPIOs 32 to 35 on device: gpiochip5 (gpd0)
[ 0.354690] gpio gpiochip6: (gpd1): added GPIO chardev (254:6)
[ 0.354698] gpiochip_setup_dev: registered GPIOs 36 to 39 on device: gpiochip6 (gpd1)
[ 0.354833] gpio gpiochip7: (gpf0): added GPIO chardev (254:7)
[ 0.354841] gpiochip_setup_dev: registered GPIOs 40 to 47 on device: gpiochip7 (gpf0)
[ 0.354982] gpio gpiochip8: (gpf1): added GPIO chardev (254:8)
[ 0.354990] gpiochip_setup_dev: registered GPIOs 48 to 55 on device: gpiochip8 (gpf1)
[ 0.355136] gpio gpiochip9: (gpf2): added GPIO chardev (254:9)
[ 0.355144] gpiochip_setup_dev: registered GPIOs 56 to 63 on device: gpiochip9 (gpf2)
[ 0.355278] gpio gpiochip10: (gpf3): added GPIO chardev (254:10)
[ 0.355286] gpiochip_setup_dev: registered GPIOs 64 to 69 on device: gpiochip10 (gpf3)
[ 0.355441] gpio gpiochip11: (gpj0): added GPIO chardev (254:11)
[ 0.355449] gpiochip_setup_dev: registered GPIOs 70 to 77 on device: gpiochip11 (gpj0)
[ 0.355584] gpio gpiochip12: (gpj1): added GPIO chardev (254:12)
[ 0.355592] gpiochip_setup_dev: registered GPIOs 78 to 82 on device: gpiochip12 (gpj1)
[ 0.359090] gpio gpiochip13: (gpk0): added GPIO chardev (254:13)
[ 0.359100] gpiochip_setup_dev: registered GPIOs 83 to 89 on device: gpiochip13 (gpk0)
[ 0.359248] gpio gpiochip14: (gpk1): added GPIO chardev (254:14)
[ 0.359256] gpiochip_setup_dev: registered GPIOs 90 to 96 on device: gpiochip14 (gpk1)
[ 0.359392] gpio gpiochip15: (gpk2): added GPIO chardev (254:15)
[ 0.359400] gpiochip_setup_dev: registered GPIOs 97 to 103 on device: gpiochip15 (gpk2)
[ 0.359533] gpio gpiochip16: (gpk3): added GPIO chardev (254:16)
[ 0.359541] gpiochip_setup_dev: registered GPIOs 104 to 110 on device: gpiochip16 (gpk3)
[ 0.359681] gpio gpiochip17: (gpl0): added GPIO chardev (254:17)
[ 0.359689] gpiochip_setup_dev: registered GPIOs 111 to 117 on device: gpiochip17 (gpl0)
[ 0.359823] gpio gpiochip18: (gpl1): added GPIO chardev (254:18)
[ 0.359831] gpiochip_setup_dev: registered GPIOs 118 to 119 on device: gpiochip18 (gpl1)
[ 0.359975] gpio gpiochip19: (gpl2): added GPIO chardev (254:19)
[ 0.360020] gpiochip_setup_dev: registered GPIOs 120 to 127 on device: gpiochip19 (gpl2)
[ 0.360161] gpio gpiochip20: (gpm0): added GPIO chardev (254:20)
[ 0.360170] gpiochip_setup_dev: registered GPIOs 128 to 135 on device: gpiochip20 (gpm0)
[ 0.360313] gpio gpiochip21: (gpm1): added GPIO chardev (254:21)
[ 0.360321] gpiochip_setup_dev: registered GPIOs 136 to 142 on device: gpiochip21 (gpm1)
[ 0.360465] gpio gpiochip22: (gpm2): added GPIO chardev (254:22)
[ 0.360473] gpiochip_setup_dev: registered GPIOs 143 to 147 on device: gpiochip22 (gpm2)
[ 0.360609] gpio gpiochip23: (gpm3): added GPIO chardev (254:23)
[ 0.360617] gpiochip_setup_dev: registered GPIOs 148 to 155 on device: gpiochip23 (gpm3)
[ 0.360765] gpio gpiochip24: (gpm4): added GPIO chardev (254:24)
[ 0.360773] gpiochip_setup_dev: registered GPIOs 156 to 163 on device: gpiochip24 (gpm4)
[ 0.360906] gpio gpiochip25: (gpy0): added GPIO chardev (254:25)
[ 0.360914] gpiochip_setup_dev: registered GPIOs 164 to 169 on device: gpiochip25 (gpy0)
[ 0.361048] gpio gpiochip26: (gpy1): added GPIO chardev (254:26)
[ 0.361056] gpiochip_setup_dev: registered GPIOs 170 to 173 on device: gpiochip26 (gpy1)
[ 0.361204] gpio gpiochip27: (gpy2): added GPIO chardev (254:27)
[ 0.361212] gpiochip_setup_dev: registered GPIOs 174 to 179 on device: gpiochip27 (gpy2)
[ 0.361346] gpio gpiochip28: (gpy3): added GPIO chardev (254:28)
[ 0.361354] gpiochip_setup_dev: registered GPIOs 180 to 187 on device: gpiochip28 (gpy3)
[ 0.361510] gpio gpiochip29: (gpy4): added GPIO chardev (254:29)
[ 0.361518] gpiochip_setup_dev: registered GPIOs 188 to 195 on device: gpiochip29 (gpy4)
[ 0.361661] gpio gpiochip30: (gpy5): added GPIO chardev (254:30)
[ 0.361670] gpiochip_setup_dev: registered GPIOs 196 to 203 on device: gpiochip30 (gpy5)
[ 0.361804] gpio gpiochip31: (gpy6): added GPIO chardev (254:31)
[ 0.361812] gpiochip_setup_dev: registered GPIOs 204 to 211 on device: gpiochip31 (gpy6)
[ 0.361953] gpio gpiochip32: (gpx0): added GPIO chardev (254:32)
[ 0.361962] gpiochip_setup_dev: registered GPIOs 212 to 219 on device: gpiochip32 (gpx0)
[ 0.362103] gpio gpiochip33: (gpx1): added GPIO chardev (254:33)
[ 0.362111] gpiochip_setup_dev: registered GPIOs 220 to 227 on device: gpiochip33 (gpx1)
[ 0.362255] gpio gpiochip34: (gpx2): added GPIO chardev (254:34)
[ 0.362264] gpiochip_setup_dev: registered GPIOs 228 to 235 on device: gpiochip34 (gpx2)
[ 0.362398] gpio gpiochip35: (gpx3): added GPIO chardev (254:35)
[ 0.362406] gpiochip_setup_dev: registered GPIOs 236 to 243 on device: gpiochip35 (gpx3)
[ 0.364251] gpio gpiochip36: (gpz): added GPIO chardev (254:36)
[ 0.364261] gpiochip_setup_dev: registered GPIOs 244 to 250 on device: gpiochip36 (gpz)
[ 0.364274] genirq: irq_chip COMBINER did not update eff. affinity mask of irq 109
[ 0.365522] gpio gpiochip37: (gpv0): added GPIO chardev (254:37)
[ 0.365531] gpiochip_setup_dev: registered GPIOs 251 to 258 on device: gpiochip37 (gpv0)
[ 0.365669] gpio gpiochip38: (gpv1): added GPIO chardev (254:38)
[ 0.365678] gpiochip_setup_dev: registered GPIOs 259 to 266 on device: gpiochip38 (gpv1)
[ 0.365832] gpio gpiochip39: (gpv2): added GPIO chardev (254:39)
[ 0.365840] gpiochip_setup_dev: registered GPIOs 267 to 274 on device: gpiochip39 (gpv2)
[ 0.365975] gpio gpiochip40: (gpv3): added GPIO chardev (254:40)
[ 0.365983] gpiochip_setup_dev: registered GPIOs 275 to 282 on device: gpiochip40 (gpv3)
[ 0.366130] gpio gpiochip41: (gpv4): added GPIO chardev (254:41)
[ 0.366139] gpiochip_setup_dev: registered GPIOs 283 to 284 on device: gpiochip41 (gpv4)
[ 0.380631] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulators/voltage-regulator-0[0]' - status (0)
[ 0.380935] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulators/voltage-regulator-1[0]' - status (0)
[ 0.381213] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulators/voltage-regulator-2[0]' - status (0)
[ 0.382036] SCSI subsystem initialized
[ 0.382241] usbcore: registered new interface driver usbfs
[ 0.382283] usbcore: registered new interface driver hub
[ 0.382371] usbcore: registered new device driver usb
[ 0.382754] of_get_named_gpiod_flags: parsed 'gpios' property of node '/i2c-gpio-0[0]' - status (0)
[ 0.382794] of_get_named_gpiod_flags: parsed 'gpios' property of node '/i2c-gpio-0[1]' - status (0)
[ 0.383025] i2c-gpio i2c-gpio-0: using pins 143 (SDA) and 144 (SCL)
[ 0.383130] of_get_named_gpiod_flags: parsed 'gpios' property of node '/i2c-gpio-1[0]' - status (0)
[ 0.383156] of_get_named_gpiod_flags: parsed 'gpios' property of node '/i2c-gpio-1[1]' - status (0)
[ 0.383368] i2c-gpio i2c-gpio-1: using pins 53 (SDA) and 52 (SCL)
[ 0.383834] s3c-i2c 138a0000.i2c: slave address 0x10
[ 0.383845] s3c-i2c 138a0000.i2c: bus frequency set to 97 KHz
[ 0.384187] s3c-i2c 138a0000.i2c: i2c-4: S3C I2C adapter
[ 0.384436] s3c-i2c 138d0000.i2c: slave address 0x10
[ 0.384447] s3c-i2c 138d0000.i2c: bus frequency set to 97 KHz
[ 0.384762] s3c-i2c 138d0000.i2c: i2c-7: S3C I2C adapter
[ 0.385599] Advanced Linux Sound Architecture Driver Initialized.
[ 0.387236] clocksource: Switched to clocksource mct-frc
[ 0.387335] VFS: Disk quotas dquot_6.6.0
[ 0.387397] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 0.396505] NET: Registered protocol family 2
[ 0.397040] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.397089] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
[ 0.397177] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.397329] UDP hash table entries: 256 (order: 1, 12288 bytes)
[ 0.397356] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[ 0.397533] NET: Registered protocol family 1
[ 0.397783] Trying to unpack rootfs image as initramfs...
[ 1.581644] Freeing initrd memory: 1968K
[ 1.583150] audit: initializing netlink subsys (disabled)
[ 1.583327] audit: type=2000 audit(1.570:1): state=initialized audit_enabled=0 res=1
[ 1.583474] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[ 1.588830] romfs: ROMFS MTD (C) 2007 Red Hat, Inc.
[ 1.589082] fuse init (API version 7.26)
[ 1.589441] SELinux: Registering netfilter hooks
[ 1.593599] bounce: pool size: 64 pages
[ 1.593652] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 248)
[ 1.593660] io scheduler noop registered
[ 1.593666] io scheduler deadline registered
[ 1.593785] io scheduler cfq registered (default)
[ 1.593791] io scheduler mq-deadline registered
[ 1.593797] io scheduler kyber registered
[ 1.601487] dma-pl330 12680000.pdma: Loaded driver for PL330 DMAC-141330
[ 1.601499] dma-pl330 12680000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 1.603911] dma-pl330 12690000.pdma: Loaded driver for PL330 DMAC-141330
[ 1.603922] dma-pl330 12690000.pdma: DBUFF-32x4bytes Num_Chans-8 Num_Peri-32 Num_Events-32
[ 1.604765] dma-pl330 12850000.mdma: Loaded driver for PL330 DMAC-141330
[ 1.604776] dma-pl330 12850000.mdma: DBUFF-64x8bytes Num_Chans-8 Num_Peri-1 Num_Events-32
[ 1.664958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[ 1.667318] 13800000.serial: ttySAC0 at MMIO 0x13800000 (irq = 58, base_baud = 0) is a S3C6400/10
[ 1.667767] 13810000.serial: ttySAC1 at MMIO 0x13810000 (irq = 59, base_baud = 0) is a S3C6400/10
[ 1.668160] 13820000.serial: ttySAC2 at MMIO 0x13820000 (irq = 60, base_baud = 0) is a S3C6400/10
[ 1.668543] 13830000.serial: ttySAC3 at MMIO 0x13830000 (irq = 61, base_baud = 0) is a S3C6400/10
[ 1.670015] OF: graph: no port node found in /fimd@11c00000
[ 1.672174] [drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations
[ 1.672287] exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops)
[ 1.672293] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.672297] [drm] No driver support for vblank timestamp query.
[ 1.672767] [drm] Initialized exynos 1.0.0 20110530 for exynos-drm on minor 0
[ 1.683000] brd: module loaded
[ 1.690941] loop: module loaded
[ 1.691202] of_get_named_gpiod_flags: parsed 'wlf,ldo1ena' property of node '/i2c@138A0000/wm1811@1a[0]' - status (0)
[ 1.691214] of_get_named_gpiod_flags: can't parse 'wlf,ldo2ena' property of node '/i2c@138A0000/wm1811@1a[0]'
[ 1.692446] wm8994 4-001a: Failed to get supply 'DBVDD1': -517
[ 1.692474] wm8994 4-001a: Failed to get supplies: -517
[ 1.703645] VMPLL_1.0V_AP: Bringing 1100000uV into 1000000-1000000uV
[ 1.707962] VPLL_1.0V_AP: Bringing 1100000uV into 1000000-1000000uV
[ 1.713759] CAM_ISP_MIPI_1.2V: Bringing 1800000uV into 1200000-1200000uV
[ 1.718398] VABB1_1.95V: Bringing 1800000uV into 1950000-1950000uV
[ 1.726045] VABB2_1.95V: Bringing 1800000uV into 1950000-1950000uV
[ 1.735778] of_get_named_gpiod_flags: can't parse 'maxim,ena-gpios' property of node '/i2c@138D0000/max77686_pmic@09/voltage-regulators/LDO20[0]'
[ 1.736958] of_get_named_gpiod_flags: parsed 'maxim,ena-gpios' property of node '/i2c@138D0000/max77686_pmic@09/voltage-regulators/LDO21[0]' - status (0)
[ 1.738551] of_get_named_gpiod_flags: parsed 'maxim,ena-gpios' property of node '/i2c@138D0000/max77686_pmic@09/voltage-regulators/LDO22[0]' - status (0)
[ 1.741631] TSP_VDD_1.8V: Bringing 2200000uV into 1800000-1800000uV
[ 1.744774] LCD_VCC_3.3V: Bringing 3300000uV into 2800000-2800000uV
[ 1.765959] of_get_named_gpiod_flags: parsed 'maxim,ena-gpios' property of node '/i2c@138D0000/max77686_pmic@09/voltage-regulators/BUCK8[0]' - status (0)
[ 1.766857] VMEM_VDDF_3.0V: Bringing 3000000uV into 2850000-2850000uV
[ 1.769239] of_get_named_gpiod_flags: parsed 'maxim,ena-gpios' property of node '/i2c@138D0000/max77686_pmic@09/voltage-regulators/BUCK9[0]' - status (0)
[ 1.772374] max77693 9-0066: device ID: 0x4
[ 1.780763] s3c64xx-spi 13930000.spi: spi bus clock parent not specified, using clock at index 0 as parent
[ 1.780774] s3c64xx-spi 13930000.spi: number of chip select lines not specified, assuming 1 chip select line
[ 1.781167] of_get_named_gpiod_flags: parsed 'cs-gpios' property of node '/spi@13930000[0]' - status (0)
[ 1.782249] mdio_bus fixed-0: GPIO lookup for consumer reset
[ 1.782258] mdio_bus fixed-0: using lookup tables for GPIO lookup
[ 1.782266] mdio_bus fixed-0: lookup for GPIO reset failed
[ 1.782285] libphy: Fixed MDIO Bus: probed
[ 1.782291] tun: Universal TUN/TAP device driver, 1.6
[ 1.782507] PPP generic driver version 2.4.2
[ 1.782675] PPP BSD Compression module registered
[ 1.782681] PPP Deflate Compression module registered
[ 1.782696] PPP MPPE Compression module registered
[ 1.782847] brcmfmac: brcmfmac_module_init No platform data available.
[ 1.783232] usbcore: registered new interface driver r8152
[ 1.783345] usbcore: registered new interface driver asix
[ 1.783389] usbcore: registered new interface driver ax88179_178a
[ 1.783430] usbcore: registered new interface driver cdc_ether
[ 1.783472] usbcore: registered new interface driver smsc75xx
[ 1.783514] usbcore: registered new interface driver smsc95xx
[ 1.783548] usbcore: registered new interface driver net1080
[ 1.783581] usbcore: registered new interface driver cdc_subset
[ 1.783612] usbcore: registered new interface driver zaurus
[ 1.783666] usbcore: registered new interface driver cdc_ncm
[ 1.783958] dwc2 12480000.hsotg: mapped PA 12480000 to VA e0920000
[ 1.784472] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.784496] ehci-exynos: EHCI EXYNOS driver
[ 1.784796] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.784819] ohci-exynos: OHCI EXYNOS driver
[ 1.785152] usbcore: registered new interface driver usb-storage
[ 1.785239] gadgetfs: USB Gadget filesystem, version 24 Aug 2004
[ 1.786135] input: max77693-haptic as /devices/platform/i2c-gpio-0/i2c-9/9-0066/max77693-haptic/input/input0
[ 1.919336] max77686-rtc max77686-rtc: rtc core: registered max77686-rtc as rtc0
[ 1.921098] s3c-rtc 10070000.rtc: rtc disabled, re-enabling
[ 1.921151] s3c-rtc 10070000.rtc: warning: invalid RTC value so initializing it
[ 1.921202] rtc rtc1: invalid alarm value: 1900-1-1 0:0:0
[ 1.921381] s3c-rtc 10070000.rtc: rtc core: registered s3c as rtc1
[ 1.921843] i2c /dev entries driver
[ 1.923122] IR NEC protocol handler initialized
[ 1.923127] IR RC5(x/sz) protocol handler initialized
[ 1.923132] IR RC6 protocol handler initialized
[ 1.923136] IR JVC protocol handler initialized
[ 1.923140] IR Sony protocol handler initialized
[ 1.923144] IR SANYO protocol handler initialized
[ 1.923148] IR Sharp protocol handler initialized
[ 1.923152] IR MCE Keyboard/mouse protocol handler initialized
[ 1.923157] IR XMP protocol handler initialized
[ 1.925589] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info().
[ 1.926333] max17042 10-0036: SOC threshold INTR
[ 1.954629] s3c2410-wdt 10060000.watchdog: watchdog inactive, reset disabled, irq disabled
[ 1.955187] device-mapper: ioctl: 4.37.0-ioctl (2017-09-20) initialised: dm-devel@redhat.com
[ 1.959817] sdhci: Secure Digital Host Controller Interface driver
[ 1.959823] sdhci: Copyright(c) Pierre Ossman
[ 1.960270] of_get_named_gpiod_flags: parsed 'cd-gpios' property of node '/sdhci@12530000[0]' - status (0)
[ 1.960429] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (50000000 Hz)
[ 1.960472] s3c-sdhci 12530000.sdhci: GPIO lookup for consumer cd
[ 1.960480] s3c-sdhci 12530000.sdhci: using device tree for GPIO lookup
[ 1.960520] of_get_named_gpiod_flags: parsed 'cd-gpios' property of node '/sdhci@12530000[0]' - status (0)
[ 1.960541] s3c-sdhci 12530000.sdhci: Got CD GPIO
[ 1.960550] s3c-sdhci 12530000.sdhci: GPIO lookup for consumer wp
[ 1.960557] s3c-sdhci 12530000.sdhci: using device tree for GPIO lookup
[ 1.960566] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/sdhci@12530000[0]'
[ 1.960576] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/sdhci@12530000[0]'
[ 1.960583] s3c-sdhci 12530000.sdhci: using lookup tables for GPIO lookup
[ 1.960591] s3c-sdhci 12530000.sdhci: lookup for GPIO wp failed
[ 2.018318] mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA
[ 2.020256] s3c-sdhci 12540000.sdhci: clock source 2: mmc_busclk.2 (40000000 Hz)
[ 2.020395] s3c-sdhci 12540000.sdhci: GPIO lookup for consumer cd
[ 2.020427] s3c-sdhci 12540000.sdhci: using device tree for GPIO lookup
[ 2.020474] of_get_named_gpiod_flags: can't parse 'cd-gpios' property of node '/sdhci@12540000[0]'
[ 2.020513] of_get_named_gpiod_flags: can't parse 'cd-gpio' property of node '/sdhci@12540000[0]'
[ 2.020542] s3c-sdhci 12540000.sdhci: using lookup tables for GPIO lookup
[ 2.020573] s3c-sdhci 12540000.sdhci: lookup for GPIO cd failed
[ 2.020609] s3c-sdhci 12540000.sdhci: GPIO lookup for consumer wp
[ 2.020634] s3c-sdhci 12540000.sdhci: using device tree for GPIO lookup
[ 2.020671] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/sdhci@12540000[0]'
[ 2.020705] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/sdhci@12540000[0]'
[ 2.020730] s3c-sdhci 12540000.sdhci: using lookup tables for GPIO lookup
[ 2.020757] s3c-sdhci 12540000.sdhci: lookup for GPIO wp failed
[ 2.077438] mmc1: SDHCI controller on samsung-hsmmc [12540000.sdhci] using ADMA
[ 2.078046] Synopsys Designware Multimedia Card Interface Driver
[ 2.083469] dwmmc_exynos 12550000.mmc: 'num-slots' was deprecated.
[ 2.083964] dwmmc_exynos 12550000.mmc: IDMAC supports 32-bit address mode.
[ 2.084133] dwmmc_exynos 12550000.mmc: Using internal DMA controller.
[ 2.084157] dwmmc_exynos 12550000.mmc: Version ID is 240a
[ 2.084256] dwmmc_exynos 12550000.mmc: DW MMC controller at irq 117,32 bit host data width,128 deep fifo
[ 2.084637] dwmmc_exynos 12550000.mmc: GPIO lookup for consumer wp
[ 2.084706] dwmmc_exynos 12550000.mmc: using device tree for GPIO lookup
[ 2.084733] of_get_named_gpiod_flags: can't parse 'wp-gpios' property of node '/mmc@12550000[0]'
[ 2.084752] of_get_named_gpiod_flags: can't parse 'wp-gpio' property of node '/mmc@12550000[0]'
[ 2.084767] dwmmc_exynos 12550000.mmc: using lookup tables for GPIO lookup
[ 2.084784] dwmmc_exynos 12550000.mmc: lookup for GPIO wp failed
[ 2.084867] mmc_host mmc2: card is non-removable.
[ 2.097508] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 2.100081] mmc1: queuing unknown CIS tuple 0x80 (6 bytes)
[ 2.107332] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 400000Hz, actual 396825HZ div = 63)
[ 2.142700] max77693-led max77693-led: No DT child node found for connected LED(s).
[ 2.142768] max77693-led: probe of max77693-led failed with error -22
[ 2.145810] s5p-secss 10830000.sss: s5p-sss driver registered
[ 2.146489] usbcore: registered new interface driver usbhid
[ 2.146494] usbhid: USB HID core driver
[ 2.146981] ashmem: initialized
[ 2.159701] exynos-ppmu: new PPMU device registered 106a0000.ppmu_dmc0 (ppmu-event3-dmc0)
[ 2.159894] exynos-ppmu: new PPMU device registered 106b0000.ppmu_dmc1 (ppmu-event3-dmc1)
[ 2.160064] exynos-ppmu: new PPMU device registered 112a0000.ppmu_rightbus (ppmu-event3-rightbus)
[ 2.160243] exynos-ppmu: new PPMU device registered 116a0000.ppmu_leftbus0 (ppmu-event3-leftbus)
[ 2.160592] input: max77693-muic/dock as /devices/platform/i2c-gpio-0/i2c-9/9-0066/max77693-muic/input/input1
[ 2.177561] mmc1: new high speed SDIO card at address 0001
[ 2.178028] brcmfmac: brcmf_sdio_probe Enter
[ 2.178200] brcmfmac: F1 signature read @0x18000000=0x16034334
[ 2.178426] brcmfmac: brcmf_chip_recognition found AXI chip: BCM4334, rev=3
[ 2.180290] brcmfmac: brcmf_chip_cores_check [1 ] core 0x800:41 base 0x18000000 wrap 0x18100000
[ 2.180296] brcmfmac: brcmf_chip_cores_check [2 ] core 0x812:35 base 0x18001000 wrap 0x18101000
[ 2.180301] brcmfmac: brcmf_chip_cores_check [3 ] core 0x829:13 base 0x18002000 wrap 0x18102000
[ 2.180306] brcmfmac: brcmf_chip_cores_check [4 ] core 0x82a:7 base 0x18003000 wrap 0x18103000
[ 2.180311] brcmfmac: brcmf_chip_cores_check [5 ] core 0x80e:19 base 0x18004000 wrap 0x18104000
[ 2.180315] brcmfmac: brcmf_chip_cores_check [6 ] core 0x81a:14 base 0x18005000 wrap 0x18105000
[ 2.180320] brcmfmac: brcmf_chip_cores_check [7 ] core 0x135:0 base 0x00000000 wrap 0x18106000
[ 2.180324] brcmfmac: brcmf_chip_cores_check [8 ] core 0x135:0 base 0x00000000 wrap 0x18107000
[ 2.180328] brcmfmac: brcmf_chip_cores_check [9 ] core 0x240:0 base 0x00000000 wrap 0x18108000
[ 2.180331] brcmfmac: brcmf_chip_set_passive Enter
[ 2.181379] brcmfmac: brcmf_chip_get_raminfo RAM: base=0x0 size=524288 (0x80000) sr=32768 (0x8000)
[ 2.181451] brcmfmac: brcmf_chip_setup ccrev=41, pmurev=17, pmucaps=0x218e5f11
[ 2.181456] brcmfmac: brcmf_get_module_param Enter, bus=0, chip=17204, rev=3
[ 2.181556] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
[ 2.181562] brcmfmac: brcmf_sdio_kso_init Enter
[ 2.181657] brcmfmac: brcmf_sdio_drivestrengthinit SDIO: 3 mA (req=6 mA) drive strength selected, set to 0x00001801
[ 2.181802] brcmfmac: brcmf_attach Enter
[ 2.181836] brcmfmac: brcmf_proto_attach Enter
[ 2.181846] brcmfmac: brcmf_fweh_register event handler registered for PSM_WATCHDOG
[ 2.181937] brcmfmac: brcmf_sdio_probe completed!!
[ 2.181945] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac4334-sdio.bin for chip 0x004334(17204) rev 0x000003
[ 2.181963] brcmfmac: brcmf_fw_get_firmwares_pcie enter: dev=mmc1:0001:1
[ 2.182796] brcmfmac: brcmf_fw_request_code_done enter: dev=mmc1:0001:1
[ 2.182906] brcmfmac: brcmf_fw_request_nvram_done enter: dev=mmc1:0001:1
[ 2.182993] brcmfmac: brcmf_sdio_firmware_callback Enter: dev=mmc1:0001:1, err=0
[ 2.183083] brcmfmac: brcmf_sdio_download_code_file Enter
[ 2.191710] max77693-muic max77693-muic: CONTROL1 : 0x09, CONTROL2 : 0x04, state : attached
[ 2.191993] mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 52000000Hz, actual 50000000HZ div = 0)
[ 2.192209] mmc2: new DDR MMC card at address 0001
[ 2.192489] max77693-muic max77693-muic: device ID : 0x8d
[ 2.192514] mmcblk2: mmc2:0001 VTU00M 14.7 GiB
[ 2.192763] mmcblk2boot0: mmc2:0001 VTU00M partition 1 2.00 MiB
[ 2.192873] mmcblk2boot1: mmc2:0001 VTU00M partition 2 2.00 MiB
[ 2.192969] mmcblk2rpmb: mmc2:0001 VTU00M partition 3 128 KiB
[ 2.196344] mmcblk2: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12
[ 2.200494] u32 classifier
[ 2.200498] Actions configured
[ 2.200505] Netfilter messages via NETLINK v0.30.
[ 2.200659] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 2.201013] ctnetlink v0.93: registering with nfnetlink.
[ 2.201263] xt_time: kernel timezone is -0000
[ 2.201448] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 2.201825] arp_tables: arp_tables: (C) 2002 David S. Miller
[ 2.201889] Initializing XFRM netlink socket
[ 2.202154] NET: Registered protocol family 10
[ 2.202962] Segment Routing with IPv6
[ 2.203004] mip6: Mobile IPv6
[ 2.203020] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 2.203267] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 2.203617] NET: Registered protocol family 17
[ 2.203631] NET: Registered protocol family 15
[ 2.203647] Key type dns_resolver registered
[ 2.204058] Registering SWP/SWPB emulation handler
[ 2.204881] registered taskstats version 1
[ 2.209614] Key type encrypted registered
[ 2.217614] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x00000000; size=451566
[ 2.232041] of_get_named_gpiod_flags: parsed 'wlf,ldo1ena' property of node '/i2c@138A0000/wm1811@1a[0]' - status (0)
[ 2.232052] of_get_named_gpiod_flags: can't parse 'wlf,ldo2ena' property of node '/i2c@138A0000/wm1811@1a[0]'
[ 2.233616] wm8994 4-001a: 4-001a supply DBVDD2 not found, using dummy regulator
[ 2.233668] wm8994 4-001a: 4-001a supply DBVDD3 not found, using dummy regulator
[ 2.234209] wm8994 4-001a: 4-001a supply AVDD2 not found, using dummy regulator
[ 2.234254] wm8994 4-001a: 4-001a supply CPVDD not found, using dummy regulator
[ 2.234297] wm8994 4-001a: 4-001a supply SPKVDD1 not found, using dummy regulator
[ 2.234357] wm8994 4-001a: 4-001a supply SPKVDD2 not found, using dummy regulator
[ 2.238759] wm8994 4-001a: WM1811 revision D CUST_ID 00
[ 2.247688] wm8994 4-001a: No interrupt specified, no interrupts
[ 2.248012] gpiochip_find_base: found new base at 501
[ 2.248185] gpio gpiochip42: (wm8994): added GPIO chardev (254:42)
[ 2.248192] gpiochip_setup_dev: registered GPIOs 501 to 511 on device: gpiochip42 (wm8994)
[ 2.248452] dwc2 12480000.hsotg: mapped PA 12480000 to VA e0a00000
[ 2.248773] dwc2 12480000.hsotg: registering common handler for irq56
[ 2.251926] dwc2 12480000.hsotg: Forcing mode to device
[ 2.251940] dwc2 12480000.hsotg: Core Release: 2.81a (snpsid=4f54281a)
[ 2.251949] dwc2 12480000.hsotg: Forcing mode to device
[ 2.251976] dwc2 12480000.hsotg: dwc2_check_params: Invalid parameter g_np_tx_fifo_size=1024
[ 2.251989] dwc2 12480000.hsotg: NonPeriodic TXFIFO size: 768
[ 2.251997] dwc2 12480000.hsotg: RXFIFO size: 2048
[ 2.252034] dwc2 12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
[ 2.252422] dwc2 12480000.hsotg: DCFG=0x08200000, DCTL=0x00000000, DIEPMSK=00000000
[ 2.252432] dwc2 12480000.hsotg: GAHBCFG=0x00000000, GHWCFG1=0x00000000
[ 2.252441] dwc2 12480000.hsotg: GRXFSIZ=0x00001f00, GNPTXFSIZ=0x03001f00
[ 2.252449] dwc2 12480000.hsotg: DPTx[1] FSize=768, StAddr=0x00002200
[ 2.252458] dwc2 12480000.hsotg: DPTx[2] FSize=768, StAddr=0x00002500
[ 2.252466] dwc2 12480000.hsotg: DPTx[3] FSize=768, StAddr=0x00002800
[ 2.252474] dwc2 12480000.hsotg: DPTx[4] FSize=768, StAddr=0x00002b00
[ 2.252483] dwc2 12480000.hsotg: DPTx[5] FSize=768, StAddr=0x00002e00
[ 2.252490] dwc2 12480000.hsotg: DPTx[6] FSize=768, StAddr=0x00003100
[ 2.252497] dwc2 12480000.hsotg: DPTx[7] FSize=768, StAddr=0x00003400
[ 2.252505] dwc2 12480000.hsotg: DPTx[8] FSize=768, StAddr=0x00003700
[ 2.252512] dwc2 12480000.hsotg: DPTx[9] FSize=768, StAddr=0x00003a00
[ 2.252520] dwc2 12480000.hsotg: DPTx[10] FSize=768, StAddr=0x00003d00
[ 2.252528] dwc2 12480000.hsotg: DPTx[11] FSize=768, StAddr=0x00004000
[ 2.252535] dwc2 12480000.hsotg: DPTx[12] FSize=768, StAddr=0x00004300
[ 2.252543] dwc2 12480000.hsotg: DPTx[13] FSize=768, StAddr=0x00004600
[ 2.252550] dwc2 12480000.hsotg: DPTx[14] FSize=768, StAddr=0x00004900
[ 2.252557] dwc2 12480000.hsotg: DPTx[15] FSize=768, StAddr=0x00004c00
[ 2.252567] dwc2 12480000.hsotg: ep0-in: EPCTL=0x00008800, SIZ=0x00000000, DMA=0xca108aec
[ 2.252576] dwc2 12480000.hsotg: ep0-out: EPCTL=0x00008000, SIZ=0x00000000, DMA=0x0858fe3d
[ 2.252585] dwc2 12480000.hsotg: ep1-in: EPCTL=0x00001000, SIZ=0x00000000, DMA=0x5f061fcc
[ 2.252594] dwc2 12480000.hsotg: ep1-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xbd2da0ee
[ 2.252603] dwc2 12480000.hsotg: ep2-in: EPCTL=0x00001800, SIZ=0x00000000, DMA=0x12c10551
[ 2.252612] dwc2 12480000.hsotg: ep2-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x96c7b391
[ 2.252621] dwc2 12480000.hsotg: ep3-in: EPCTL=0x00002000, SIZ=0x00000000, DMA=0x25a20a5a
[ 2.252629] dwc2 12480000.hsotg: ep3-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xb869672a
[ 2.252638] dwc2 12480000.hsotg: ep4-in: EPCTL=0x00002800, SIZ=0x00000000, DMA=0xe75a0cbf
[ 2.252646] dwc2 12480000.hsotg: ep4-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x3a2b3b7d
[ 2.252655] dwc2 12480000.hsotg: ep5-in: EPCTL=0x00003000, SIZ=0x00000000, DMA=0x478441c5
[ 2.252663] dwc2 12480000.hsotg: ep5-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xf994de8c
[ 2.252672] dwc2 12480000.hsotg: ep6-in: EPCTL=0x00003800, SIZ=0x00000000, DMA=0x87bb2c4c
[ 2.252681] dwc2 12480000.hsotg: ep6-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x286fdecb
[ 2.252689] dwc2 12480000.hsotg: ep7-in: EPCTL=0x00004000, SIZ=0x00000000, DMA=0x5e590643
[ 2.252698] dwc2 12480000.hsotg: ep7-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x45f0caeb
[ 2.252706] dwc2 12480000.hsotg: ep8-in: EPCTL=0x00004800, SIZ=0x00000000, DMA=0x1431d08a
[ 2.252715] dwc2 12480000.hsotg: ep8-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x6a9627fe
[ 2.252723] dwc2 12480000.hsotg: ep9-in: EPCTL=0x00005000, SIZ=0x00000000, DMA=0x21ebd864
[ 2.252732] dwc2 12480000.hsotg: ep9-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x9bbc53a8
[ 2.252740] dwc2 12480000.hsotg: ep10-in: EPCTL=0x00005800, SIZ=0x00000000, DMA=0xa9a8bb29
[ 2.252749] dwc2 12480000.hsotg: ep10-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x87bcbc7a
[ 2.252757] dwc2 12480000.hsotg: ep11-in: EPCTL=0x00006000, SIZ=0x00000000, DMA=0xbe6c2047
[ 2.252766] dwc2 12480000.hsotg: ep11-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xbbf6eac3
[ 2.252775] dwc2 12480000.hsotg: ep12-in: EPCTL=0x00006800, SIZ=0x00000000, DMA=0xad8a5716
[ 2.252783] dwc2 12480000.hsotg: ep12-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xf87042d7
[ 2.252791] dwc2 12480000.hsotg: ep13-in: EPCTL=0x00007000, SIZ=0x00000000, DMA=0xcca18ad7
[ 2.252801] dwc2 12480000.hsotg: ep13-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xd44bdb2b
[ 2.252809] dwc2 12480000.hsotg: ep14-in: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x9e848cdc
[ 2.252818] dwc2 12480000.hsotg: ep14-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0x9597b4c9
[ 2.252827] dwc2 12480000.hsotg: ep15-in: EPCTL=0x00000800, SIZ=0x00000000, DMA=0x1ff1e418
[ 2.252835] dwc2 12480000.hsotg: ep15-out: EPCTL=0x00000000, SIZ=0x00000000, DMA=0xedcc8171
[ 2.252843] dwc2 12480000.hsotg: DVBUSDIS=0x000017d7, DVBUSPULSE=000005b8
[ 2.261064] ntc-thermistor thermistor-ap: Thermistor type: ncp15wb473 successfully probed.
[ 2.261502] ntc-thermistor thermistor-battery: Thermistor type: ncp15wb473 successfully probed.
[ 2.262947] exynos-bus: new bus device registered: bus_dmc (100000 KHz ~ 400000 KHz)
[ 2.263721] exynos-bus: new bus device registered: bus_acp (100000 KHz ~ 267000 KHz)
[ 2.264218] exynos-bus: new bus device registered: bus_c2c (100000 KHz ~ 400000 KHz)
[ 2.265478] exynos-bus: new bus device registered: bus_leftbus (100000 KHz ~ 200000 KHz)
[ 2.265985] exynos-bus: new bus device registered: bus_rightbus (100000 KHz ~ 200000 KHz)
[ 2.266616] exynos-bus: new bus device registered: bus_display (160000 KHz ~ 200000 KHz)
[ 2.267301] exynos-bus: new bus device registered: bus_fsys (100000 KHz ~ 134000 KHz)
[ 2.267962] exynos-bus: new bus device registered: bus_peri ( 50000 KHz ~ 100000 KHz)
[ 2.268441] exynos-bus: new bus device registered: bus_mfc (100000 KHz ~ 200000 KHz)
[ 2.270357] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/key-down[0]' - status (0)
[ 2.270386] gpio-239 (volume down): gpiod_set_debounce: missing set() or set_config() operations
[ 2.270591] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/key-up[0]' - status (0)
[ 2.270614] gpio-230 (volume up): gpiod_set_debounce: missing set() or set_config() operations
[ 2.270771] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/key-power[0]' - status (0)
[ 2.270786] gpio-235 (power): gpiod_set_debounce: missing set() or set_config() operations
[ 2.270942] of_get_named_gpiod_flags: parsed 'gpios' property of node '/gpio-keys/key-home[0]' - status (0)
[ 2.270969] gpio-213 (home): gpiod_set_debounce: missing set() or set_config() operations
[ 2.271273] input: gpio-keys as /devices/platform/gpio-keys/input/input2
[ 2.287847] brcmfmac: brcmf_sdio_download_nvram Enter
[ 2.288267] brcmfmac: brcmf_sdio_verifymemory Compare RAM dl & ul at 0x0007f920; size=1760
[ 2.288685] brcmfmac: brcmf_chip_set_active Enter
[ 2.298289] max77686-rtc max77686-rtc: setting system clock to 2017-11-07 13:22:58 UTC (1510060978)
[ 2.301611] CAM_SENSOR_A: disabling
[ 2.301618] CAM_AF: disabling
[ 2.302094] VMIPI_1.0V: disabling
[ 2.307836] VHSIC_1.8V: disabling
[ 2.311766] LCD_VCC_3.3V: disabling
[ 2.315651] vdd_g3d: disabling
[ 2.320587] CHARGER: disabling
[ 2.321614] ALSA device list:
[ 2.321622] No soundcards found.
[ 2.323811] Freeing unused kernel memory: 1024K
[ 3.305314] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 3.305410] brcmfmac: brcmf_sdio_firmware_callback failed: dev=mmc1:0001:1, err=0
[ 3.305513] brcmfmac: brcmf_sdio_remove Enter
[ 3.305530] brcmfmac: brcmf_detach Enter
[ 3.337439] brcmfmac: brcmf_bus_change_state 0 -> 0
[ 3.337472] brcmfmac: brcmf_sdio_bus_stop Enter
[ 4.350590] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 4.351662] brcmfmac: brcmf_proto_detach Enter
[ 4.351711] brcmfmac: brcmf_fweh_unregister event handler cleared for PSM_WATCHDOG
[ 5.360818] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50
[ 5.397630] brcmfmac: brcmf_chip_set_passive Enter
[ 5.401477] brcmfmac: brcmf_sdio_remove Disconnected
[ 18.746196] max77693-muic max77693-muic: external connector is detached(chg_type:0x0, prev_chg_type:0x0)
[ 20.467914] max77693-muic max77693-muic: external connector is attached (adc:0x1c, prev_adc:0x1c)
[ 20.467954] max77693-muic max77693-muic: external connector is attached (adc:0x1c)
[ 20.471246] max77693-muic max77693-muic: CONTROL1 : 0x1b, CONTROL2 : 0x04, state : attached
[ 22.249195] max77693-muic max77693-muic: external connector is attached (adc:0x1c, prev_adc:0x1c)
[ 22.249234] max77693-muic max77693-muic: external connector is attached (adc:0x1c)
[ 22.251415] max77693-muic max77693-muic: CONTROL1 : 0x1b, CONTROL2 : 0x04, state : attached
[ 40.512684] EXT4-fs (mmcblk2p9): couldn't mount as ext3 due to feature incompatibilities
[ 40.513928] EXT4-fs (mmcblk2p9): couldn't mount as ext2 due to feature incompatibilities
[ 40.528262] EXT4-fs (mmcblk2p9): warning: maximal mount count reached, running e2fsck is recommended
[ 40.530806] EXT4-fs (mmcblk2p9): recovery complete
[ 40.532291] EXT4-fs (mmcblk2p9): mounted filesystem with ordered data mode. Opts: (null)
>
> Regards,
> Arend
Cheers,
Simon
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Richard Genoud @ 2017-11-07 11:13 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20171107101320.GA12140@redhat.com>
Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > 3 short articles how to configure and use ftrace are here:
> > > https://lwn.net/Articles/365835/
> > > https://lwn.net/Articles/366796/
> > > https://lwn.net/Articles/370423/
> > >
> >
> > I tried with ftrace, but I don't think there's a way to dump the
> > trace
> > when there's a soft lock-up
> > (I can't do anything after the unbind, even the heartbeat led
> > stopped blinking).
> > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
>
> You should configure function trace with rt2x* functions. After that
> start tracing, unbind the device, then stop tracing and provide trace
> output.
Here is another trace, with rt2* as function filter.
(sorry for the noise)
Dumping ftrace buffer:
---------------------------------
CPU:0 [LOST 3606923 EVENTS]
0) 0.000 us | } /* rt2x00usb_clear_entry */
0) 0.000 us | } /* rt2x00lib_rxdone */
0) 0.000 us | rt2x00queue_get_entry();
0) | rt2x00lib_rxdone() {
0) 0.000 us | rt2x00queue_index_inc();
0) | rt2x00usb_clear_entry() {
0) | rt2x00usb_kick_rx_entry() {
0) | rt2x00lib_dmastart() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) | rt2x00lib_dmadone() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | rt2x00queue_get_entry();
0) | rt2x00lib_rxdone() {
0) 0.000 us | rt2x00queue_index_inc();
0) | rt2x00usb_clear_entry() {
0) | rt2x00usb_kick_rx_entry() {
0) | rt2x00lib_dmastart() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) | rt2x00lib_dmadone() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | rt2x00queue_get_entry();
0) | rt2x00lib_rxdone() {
0) 0.000 us | rt2x00queue_index_inc();
0) | rt2x00usb_clear_entry() {
0) | rt2x00usb_kick_rx_entry() {
0) | rt2x00lib_dmastart() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) | rt2x00lib_dmadone() {
0) 0.000 us | rt2x00queue_index_inc();
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
0) 0.000 us | }
>
> Thanks
> Stanislaw
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Arend van Spriel @ 2017-11-07 11:09 UTC (permalink / raw)
To: Simon Shields
Cc: linux-wireless, brcm80211-dev-list.pdl, brcm80211-dev-list,
devicetree, Franky Lin, Hante Meuleman, Chi-Hsien Lin,
Wright Feng
In-Reply-To: <20171106112726.GA25134@lineageos.org>
On 11/6/2017 12:27 PM, Simon Shields wrote:
> On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
>> On 11/4/2017 2:24 PM, Simon Shields wrote:
>>> Some boards use an external 32khz clock for low-power
>>> mode timing. Make sure the clock is powered on while the chipset
>>> is active.
>>
>> Do you have such a board? With the little documentation I can get my hands
>> on here I wonder whether the clock needs to be enabled before the device is
>> powered. If you have the hardware I would like to check some registers in
>> the device.
>>
>
> Yes. Trats2 (exynos4412-based) has such a setup. The BCM4334 works fine
> with this patch and one more that enables the WL_REG_EN pin when
> brcmfmac is probed.
Ok. So this is exactly the thing I was wondering about. So it makes me
curious how the WL_REG_EN patch looks like. Can you provide that?
> Without this patch (and only enabling WL_REG_EN), the chip is detected but
> attempting to initialise it fails with a bunch of timeouts.
I would be interested in seeing a detailed log of that. Could you
provide that? You need to build the driver with CONFIG_BRCMDBG and pass
module parameter 'debug=0x1416' upon insmod/modprobe.
Regards,
Arend
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Richard Genoud @ 2017-11-07 11:01 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20171107101320.GA12140@redhat.com>
Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > 3 short articles how to configure and use ftrace are here:
> > > https://lwn.net/Articles/365835/
> > > https://lwn.net/Articles/366796/
> > > https://lwn.net/Articles/370423/
> > >
> >
> > I tried with ftrace, but I don't think there's a way to dump the
> > trace
> > when there's a soft lock-up
> > (I can't do anything after the unbind, even the heartbeat led
> > stopped blinking).
> > I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> > /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
>
> You should configure function trace with rt2x* functions. After that
> start tracing, unbind the device, then stop tracing and provide trace
> output.
Ok, I found a way to display the trace (after the unbind, the board is
frozen and I can't type anything).
Adding
CONFIG_SOFTLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
along with echo 1 > /proc/sys/kernel/ftrace_dump_on_oops does the trick
(trace is after the stack dump)
# cd /sys/kernel/debug/tracing/
# echo 1 > /proc/sys/kernel/ftrace_dump_on_oops
#
# echo rt2x00usb* > set_ftrace_filter
# echo 0 > tracing_on
# echo function > current_tracer
# echo 1 > tracing_on
# echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
[board frozen]
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u2:3:188]
CPU: 0 PID: 188 Comm: kworker/u2:3 Not tainted 4.14.0-rc8-00040-g53fb1fe423ba #13
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
task: c7b34400 task.stack: c7b4e000
PC is at rb_commit+0x1a8/0x2e4
LR is at ring_buffer_unlock_commit+0x20/0xa4
pc : [<c006c694>] lr : [<c006d724>] psr: 80000013
sp : c7b4fda8 ip : 00000000 fp : c7b4fdc4
r10: c664ee34 r9 : c7b2ed18 r8 : 60000013
r7 : 001c4851 r6 : c780a0e0 r5 : c7319340 r4 : 00008a48
r3 : c7319340 r2 : c664e000 r1 : 00000e38 r0 : 00000e24
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 0005317f Table: 27270000 DAC: 00000053
CPU: 0 PID: 188 Comm: kworker/u2:3 Not tainted 4.14.0-rc8-00040-g53fb1fe423ba #13
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
[<c000fe00>] (unwind_backtrace) from [<c000dd94>] (show_stack+0x20/0x24)
[<c000dd94>] (show_stack) from [<c05a55e0>] (dump_stack+0x20/0x28)
[<c05a55e0>] (dump_stack) from [<c000b03c>] (show_regs+0x1c/0x20)
[<c000b03c>] (show_regs) from [<c0064c90>] (watchdog_timer_fn+0x148/0x1ac)
[<c0064c90>] (watchdog_timer_fn) from [<c0051dec>] (hrtimer_run_queues+0x128/0x250)
[<c0051dec>] (hrtimer_run_queues) from [<c00512e8>] (run_local_timers+0x18/0x68)
[<c00512e8>] (run_local_timers) from [<c0051370>] (update_process_times+0x38/0x6c)
[<c0051370>] (update_process_times) from [<c005e1c0>] (tick_nohz_handler+0xc0/0x10c)
[<c005e1c0>] (tick_nohz_handler) from [<c03a756c>] (ch2_irq+0x30/0x38)
[<c03a756c>] (ch2_irq) from [<c0046b00>] (__handle_irq_event_percpu+0x74/0x1dc)
[<c0046b00>] (__handle_irq_event_percpu) from [<c0046c94>] (handle_irq_event_percpu+0x2c/0x68)
[<c0046c94>] (handle_irq_event_percpu) from [<c0046d08>] (handle_irq_event+0x38/0x4c)
[<c0046d08>] (handle_irq_event) from [<c0049f54>] (handle_fasteoi_irq+0xa0/0x114)
[<c0049f54>] (handle_fasteoi_irq) from [<c0046320>] (generic_handle_irq+0x28/0x38)
[<c0046320>] (generic_handle_irq) from [<c00463c0>] (__handle_domain_irq+0x90/0xb8)
[<c00463c0>] (__handle_domain_irq) from [<c00094a4>] (aic_handle+0xb0/0xb8)
[<c00094a4>] (aic_handle) from [<c000ea68>] (__irq_svc+0x68/0x84)
Exception stack(0xc7b4fd58 to 0xc7b4fda0)
fd40: 00000e24 00000e38
fd60: c664e000 c7319340 00008a48 c7319340 c780a0e0 001c4851 60000013 c7b2ed18
fd80: c664ee34 c7b4fdc4 00000000 c7b4fda8 c006d724 c006c694 80000013 ffffffff
[<c000ea68>] (__irq_svc) from [<c006c694>] (rb_commit+0x1a8/0x2e4)
[<c006c694>] (rb_commit) from [<c006d724>] (ring_buffer_unlock_commit+0x20/0xa4)
[<c006d724>] (ring_buffer_unlock_commit) from [<c00756f4>] (trace_function+0xe0/0xf0)
[<c00756f4>] (trace_function) from [<c007c794>] (function_trace_call+0xbc/0x11c)
[<c007c794>] (function_trace_call) from [<c000f12c>] (ftrace_graph_call+0x0/0xc)
[<c000f12c>] (ftrace_graph_call) from [<c0337780>] (rt2x00usb_kick_rx_entry+0x14/0x118)
[<c0337780>] (rt2x00usb_kick_rx_entry) from [<c033834c>] (rt2x00usb_clear_entry+0x30/0x34)
[<c033834c>] (rt2x00usb_clear_entry) from [<c0332b10>] (rt2x00lib_rxdone+0x58c/0x5b8)
[<c0332b10>] (rt2x00lib_rxdone) from [<c03376ec>] (rt2x00usb_work_rxdone+0x60/0x7c)
[<c03376ec>] (rt2x00usb_work_rxdone) from [<c002ca64>] (process_one_work+0x1e4/0x3a0)
[<c002ca64>] (process_one_work) from [<c002cf28>] (worker_thread+0x2c8/0x45c)
[<c002cf28>] (worker_thread) from [<c0031f68>] (kthread+0x114/0x130)
[<c0031f68>] (kthread) from [<c000a4c8>] (ret_from_fork+0x14/0x2c)
Kernel panic - not syncing: softlockup: hung tasks
CPU: 0 PID: 188 Comm: kworker/u2:3 Tainted: G L 4.14.0-rc8-00040-g53fb1fe423ba #13
Hardware name: Atmel AT91SAM9
Workqueue: phy0 rt2x00usb_work_rxdone
[<c000fe00>] (unwind_backtrace) from [<c000dd94>] (show_stack+0x20/0x24)
[<c000dd94>] (show_stack) from [<c05a55e0>] (dump_stack+0x20/0x28)
[<c05a55e0>] (dump_stack) from [<c00187d0>] (panic+0xc8/0x260)
[<c00187d0>] (panic) from [<c0064cc8>] (watchdog_timer_fn+0x180/0x1ac)
[<c0064cc8>] (watchdog_timer_fn) from [<c0051dec>] (hrtimer_run_queues+0x128/0x250)
[<c0051dec>] (hrtimer_run_queues) from [<c00512e8>] (run_local_timers+0x18/0x68)
[<c00512e8>] (run_local_timers) from [<c0051370>] (update_process_times+0x38/0x6c)
[<c0051370>] (update_process_times) from [<c005e1c0>] (tick_nohz_handler+0xc0/0x10c)
[<c005e1c0>] (tick_nohz_handler) from [<c03a756c>] (ch2_irq+0x30/0x38)
[<c03a756c>] (ch2_irq) from [<c0046b00>] (__handle_irq_event_percpu+0x74/0x1dc)
[<c0046b00>] (__handle_irq_event_percpu) from [<c0046c94>] (handle_irq_event_percpu+0x2c/0x68)
[<c0046c94>] (handle_irq_event_percpu) from [<c0046d08>] (handle_irq_event+0x38/0x4c)
[<c0046d08>] (handle_irq_event) from [<c0049f54>] (handle_fasteoi_irq+0xa0/0x114)
[<c0049f54>] (handle_fasteoi_irq) from [<c0046320>] (generic_handle_irq+0x28/0x38)
[<c0046320>] (generic_handle_irq) from [<c00463c0>] (__handle_domain_irq+0x90/0xb8)
[<c00463c0>] (__handle_domain_irq) from [<c00094a4>] (aic_handle+0xb0/0xb8)
[<c00094a4>] (aic_handle) from [<c000ea68>] (__irq_svc+0x68/0x84)
Exception stack(0xc7b4fd58 to 0xc7b4fda0)
fd40: 00000e24 00000e38
fd60: c664e000 c7319340 00008a48 c7319340 c780a0e0 001c4851 60000013 c7b2ed18
fd80: c664ee34 c7b4fdc4 00000000 c7b4fda8 c006d724 c006c694 80000013 ffffffff
[<c000ea68>] (__irq_svc) from [<c006c694>] (rb_commit+0x1a8/0x2e4)
[<c006c694>] (rb_commit) from [<c006d724>] (ring_buffer_unlock_commit+0x20/0xa4)
[<c006d724>] (ring_buffer_unlock_commit) from [<c00756f4>] (trace_function+0xe0/0xf0)
[<c00756f4>] (trace_function) from [<c007c794>] (function_trace_call+0xbc/0x11c)
[<c007c794>] (function_trace_call) from [<c000f12c>] (ftrace_graph_call+0x0/0xc)
[<c000f12c>] (ftrace_graph_call) from [<c0337780>] (rt2x00usb_kick_rx_entry+0x14/0x118)
[<c0337780>] (rt2x00usb_kick_rx_entry) from [<c033834c>] (rt2x00usb_clear_entry+0x30/0x34)
[<c033834c>] (rt2x00usb_clear_entry) from [<c0332b10>] (rt2x00lib_rxdone+0x58c/0x5b8)
[<c0332b10>] (rt2x00lib_rxdone) from [<c03376ec>] (rt2x00usb_work_rxdone+0x60/0x7c)
[<c03376ec>] (rt2x00usb_work_rxdone) from [<c002ca64>] (process_one_work+0x1e4/0x3a0)
[<c002ca64>] (process_one_work) from [<c002cf28>] (worker_thread+0x2c8/0x45c)
[<c002cf28>] (worker_thread) from [<c0031f68>] (kthread+0x114/0x130)
[<c0031f68>] (kthread) from [<c000a4c8>] (ret_from_fork+0x14/0x2c)
Dumping ftrace buffer:
---------------------------------
CPU:0 [LOST 1781327 EVENTS]
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
kworker/-188 0.n.. 24110000us : rt2x00usb_kick_rx_entry <-rt2x00usb_clear_entry
kworker/-188 0.n.. 24110000us : rt2x00usb_clear_entry <-rt2x00lib_rxdone
[forever]
> Thanks
> Stanislaw
Thanks,
Richard
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Stanislaw Gruszka @ 2017-11-07 10:13 UTC (permalink / raw)
To: Richard Genoud; +Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <CACQ1gAi6XtjCHPji3BP71jDG7srg+BshesviasXiSqnw2zs9_Q@mail.gmail.com>
On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > 3 short articles how to configure and use ftrace are here:
> > https://lwn.net/Articles/365835/
> > https://lwn.net/Articles/366796/
> > https://lwn.net/Articles/370423/
> >
> I tried with ftrace, but I don't think there's a way to dump the trace
> when there's a soft lock-up
> (I can't do anything after the unbind, even the heartbeat led stopped blinking).
> I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
> /proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
You should configure function trace with rt2x* functions. After that
start tracing, unbind the device, then stop tracing and provide trace
output.
Thanks
Stanislaw
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Richard Genoud @ 2017-11-07 10:06 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Helmut Schaa, linux-kernel@vger.kernel.org, linux-wireless
In-Reply-To: <20171107085327.GA11380@redhat.com>
2017-11-07 9:53 GMT+01:00 Stanislaw Gruszka <sgruszka@redhat.com>:
> Hi
Hi !
>
> On Mon, Nov 06, 2017 at 04:57:09PM +0100, Richard Genoud wrote:
>> I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 (chipset 5370):
>>
>> # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308]
> ...
>> I can trigger this each time.
>
> I can not reproduce this on my system (I'm using 4.14.0-rc6, but I don't
> think it's an issue). I think the problem may be caused by usb
> host controler driver, which can be different on your system.
>
> Does ftrace work on your platform ? If so could you use ftrace
> to provide rt2x00 functions trace when the probllem happen ?
>
> 3 short articles how to configure and use ftrace are here:
> https://lwn.net/Articles/365835/
> https://lwn.net/Articles/366796/
> https://lwn.net/Articles/370423/
>
I tried with ftrace, but I don't think there's a way to dump the trace
when there's a soft lock-up
(I can't do anything after the unbind, even the heartbeat led stopped blinking).
I saw the /proc/sys/kernel/ftrace_dump_on_oops file, but there's no
/proc/sys/kernel/ftrace_dump_on_soft_lock-up file :)
Or I missed something in ftrace ?
Thanks !
Richard.
> Thanks
> Stanislaw
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Arend van Spriel @ 2017-11-07 9:01 UTC (permalink / raw)
To: Stefan Wahren, Kalle Valo
Cc: brcm80211-dev-list.pdl, Franky Lin, linux-wireless, Chi-Hsien Lin,
Wright Feng, brcm80211-dev-list, Simon Shields, Hante Meuleman
In-Reply-To: <964084973.5481.1510037571344@email.1und1.de>
On 11/7/2017 7:52 AM, Stefan Wahren wrote:
> Hi,
>
>> Kalle Valo <kvalo@codeaurora.org> hat am 7. November 2017 um 03:18 geschrieben:
>>
>>
>> Stefan Wahren <stefan.wahren@i2se.com> writes:
>>
>>>> Simon Shields <simon@lineageos.org> hat am 4. November 2017 um 14:24 geschrieben:
>>>>
>>>>
>>>> Some boards use an external 32khz clock for low-power
>>>> mode timing. Make sure the clock is powered on while the chipset
>>>> is active.
>>>>
>>>> Signed-off-by: Simon Shields <simon@lineageos.org>
>>>> ---
>>>> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
>>>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
>>>> 4 files changed, 19 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>> index b2bd4704f859..37add5e29272 100644
>>>> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
>>>> @@ -17,6 +17,8 @@ Optional properties:
>>>> When not specified the device will use in-band SDIO interrupts.
>>>> - interrupt-names : name of the out-of-band interrupt, which must be set
>>>> to "host-wake".
>>>> + - clocks : external 32khz clock
>>>> + - clock-names : name of the external 32khz clock, must be "32khz"
>>>
>>> sorry for the nitpicking, but according to the datasheet [1] it's
>>> 32768 Hz. Apart from that i suggest to use a functional name for the
>>> clock like "low_power" or something else, which is more flexible and
>>> future-proof.
It is called LPO (low-power oscillator) in our documentation so my
suggestion would be "ext-lpo". The recommended value is 32*1024 Hz, but
it is not a must.
>>>
>>> Btw this binding needs to be a separate patch, which should go to the
>>> devicetree guys.
>>
>> Previously I have applied binding documentation changes which the DT
>> maintainers have acked, that's why I specifically asked to Cc device
>> tree list. Has something changed?
>
> as long as the changes has been acked this should be okay. I was referring to point 1 in this guideline [1].
Yeah. As happens regularly in requirements management only the
requirement is documented and not the motivation behind it.
Regards,
Arend
> [1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt?h=v4.14-rc8
>
>>
>> --
>> Kalle Valo
^ permalink raw reply
* Re: Soft lockup in rt2x00usb_work_rxdone()
From: Stanislaw Gruszka @ 2017-11-07 8:53 UTC (permalink / raw)
To: Richard Genoud; +Cc: Helmut Schaa, linux-kernel, linux-wireless
In-Reply-To: <1509983829.10974.2.camel@gmail.com>
Hi
On Mon, Nov 06, 2017 at 04:57:09PM +0100, Richard Genoud wrote:
> I get a soft lock-up while unbinding the USB driver on a TP-Link TL-WN727Nv3 (chipset 5370):
>
> # echo 1-2.2 > /sys/bus/usb/drivers/usb/unbind
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u2:3:308]
...
> I can trigger this each time.
I can not reproduce this on my system (I'm using 4.14.0-rc6, but I don't
think it's an issue). I think the problem may be caused by usb
host controler driver, which can be different on your system.
Does ftrace work on your platform ? If so could you use ftrace
to provide rt2x00 functions trace when the probllem happen ?
3 short articles how to configure and use ftrace are here:
https://lwn.net/Articles/365835/
https://lwn.net/Articles/366796/
https://lwn.net/Articles/370423/
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH] brcmfmac: add support for external 32khz clock
From: Stefan Wahren @ 2017-11-07 6:52 UTC (permalink / raw)
To: Kalle Valo
Cc: brcm80211-dev-list.pdl, Franky Lin, linux-wireless, Chi-Hsien Lin,
Wright Feng, brcm80211-dev-list, Arend van Spriel, Simon Shields,
Hante Meuleman
In-Reply-To: <871slarfvd.fsf@purkki.adurom.net>
Hi,
> Kalle Valo <kvalo@codeaurora.org> hat am 7. November 2017 um 03:18 geschrieben:
>
>
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
> >> Simon Shields <simon@lineageos.org> hat am 4. November 2017 um 14:24 geschrieben:
> >>
> >>
> >> Some boards use an external 32khz clock for low-power
> >> mode timing. Make sure the clock is powered on while the chipset
> >> is active.
> >>
> >> Signed-off-by: Simon Shields <simon@lineageos.org>
> >> ---
> >> .../devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt | 2 ++
> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.h | 2 ++
> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 5 +++++
> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 10 ++++++++++
> >> 4 files changed, 19 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> index b2bd4704f859..37add5e29272 100644
> >> --- a/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> +++ b/Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt
> >> @@ -17,6 +17,8 @@ Optional properties:
> >> When not specified the device will use in-band SDIO interrupts.
> >> - interrupt-names : name of the out-of-band interrupt, which must be set
> >> to "host-wake".
> >> + - clocks : external 32khz clock
> >> + - clock-names : name of the external 32khz clock, must be "32khz"
> >
> > sorry for the nitpicking, but according to the datasheet [1] it's
> > 32768 Hz. Apart from that i suggest to use a functional name for the
> > clock like "low_power" or something else, which is more flexible and
> > future-proof.
> >
> > Btw this binding needs to be a separate patch, which should go to the
> > devicetree guys.
>
> Previously I have applied binding documentation changes which the DT
> maintainers have acked, that's why I specifically asked to Cc device
> tree list. Has something changed?
as long as the changes has been acked this should be okay. I was referring to point 1 in this guideline [1].
[1] - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt?h=v4.14-rc8
>
> --
> Kalle Valo
^ permalink raw reply
* Re: Need support for Intel new wifi module 9462NGW
From: Chris Chiu @ 2017-11-07 4:26 UTC (permalink / raw)
To: Luca Coelho
Cc: johannes.berg, linuxwifi, linux-wireless, Linux Upstreaming Team
In-Reply-To: <1509952948.4492.360.camel@coelho.fi>
Hi Luca,
I just tried the firmware but seems still something wrong. dmesg
shows me the following
[ 17.786041] Intel(R) Wireless WiFi driver for Linux
[ 17.786042] Copyright(c) 2003- 2015 Intel Corporation
[ 18.120052] iwlwifi 0000:00:0c.0: loaded firmware version
33.610294.0 op_mode iwlmvm
[ 20.995731] iwlwifi 0000:00:0c.0: Detected Intel(R) Dual Band
Wireless AC 9460, REV=0x318
[ 22.012109] iwlwifi 0000:00:0c.0: SecBoot CPU1 Status: 0x3, CPU2
Status: 0x2339
[ 22.012115] iwlwifi 0000:00:0c.0: Failed to start INIT ucode: -110
[ 22.024100] iwlwifi 0000:00:0c.0: Failed to run INIT ucode: -110
Any more information you need from me?
Chris
On Mon, Nov 6, 2017 at 3:22 PM, Luca Coelho <luca@coelho.fi> wrote:
> On Mon, 2017-11-06 at 11:22 +0800, Chris Chiu wrote:
>> Hi Luca,
>
> Hi Chris,
>
>
>> Any update for the firmware approval?
>
> Yes, I published it last Thursday. Sorry, I was in such a hurry that I
> forgot to tell you about it.
>
> You can find it here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/plain/iwlwifi-9260-th-b0-jf-b0-33.ucode?id=f132386b542b52ade0416ecb6cb7aef426f5d175
>
> Let me know how it goes.
>
> --
> Cheers,
> Luca.
^ 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