Guy Mishol
Cc: John Stultz
Cc: Ulf Hansson
Signed-off-by: Tony Lindgren
Changes since v2:
- Downgraded to clean-up from a fix as the race should never happen
Changes since v1:
- Add locking around clear_bit like we do elsewhere in the driver
---
drivers/net/wireless/ti/wlcore/main.c | 12
* Kalle Valo [191008 14:17]:
> Tony Lindgren writes:
>
> > * Tony Lindgren [191007 17:29]:
> >> We set WL1271_FLAG_IRQ_RUNNING in the beginning of wlcore_irq(), and test
> >> for it in wlcore_runtime_resume(). But WL1271_FLAG_IRQ_RUNNING currently
* Tony Lindgren [191007 17:29]:
> We set WL1271_FLAG_IRQ_RUNNING in the beginning of wlcore_irq(), and test
> for it in wlcore_runtime_resume(). But WL1271_FLAG_IRQ_RUNNING currently
> gets cleared too early by wlcore_irq_locked() before wlcore_irq() is done
> calling it. And th
igured as a level interrupt
instead of edge as an attempt to work around the ELP wake timeout errors.
Fixes: fa2648a34e73 ("wlcore: Add support for runtime PM")
Cc: Anders Roxell
Cc: Eyal Reizer
Cc: Guy Mishol
Cc: John Stultz
Cc: Ulf Hansson
Signed-off-by: Tony Lindgren
---
Chan
* Tony Lindgren [191007 08:38]:
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -692,6 +687,9 @@ static irqreturn_t wlcore_irq(int irq, void *cookie)
>
> mutex_unlock(&wl->mutex);
>
> +ou
igured as a level interrupt
instead of edge as an attempt to work around the ELP wake timeout errors.
Fixes: fa2648a34e73 ("wlcore: Add support for runtime PM")
Cc: Anders Roxell
Cc: Eyal Reizer
Cc: Guy Mishol
Cc: John Stultz
Cc: Ulf Hansson
Signed-off-by: Tony Lindgren
--
s.
Good to hear this got sorted out, thanks everybody.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:23]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Greg Kroah-Hartman [190122 15:22]:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Acked-by: Tony Lindgren
* Ulf Hansson [190121 06:41]:
> So, I have put together a debug patch, mostly to verify that things
> seems to be correct in regards to runtime PM. It should produce some
> prints to the log, particular during power on/off of the SDIO card and
> during probe of the wifi driver. Please re-run the t
* Kalle Valo [190118 15:37]:
> Anders Roxell writes:
>
> > On Wed, 16 Jan 2019 at 16:43, Tony Lindgren wrote:
> >>
> >> * Ulf Hansson [190116 11:37]:
> >> > During "wlan-up", we are programming the FW into the WiFi-chip. However,
> >&g
* Ulf Hansson [190118 15:09]:
> On Fri, 18 Jan 2019 at 13:09, Jan Kiszka wrote:
> > Yeah, I'm not claiming at all I know what I'm doing there, just that it
> > happens
> > to work.
>
> I see. Good to know, thanks!
This seems like some separate issue. I wonder if adding
another reset just befor
.811096] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
...
Thanks for fixing this issue properly, and feel free to add:
Tested-by: Tony Lindgren
* Ulf Hansson [190116 11:44]:
> On Tue, 15 Jan 2019 at 19:55, Tony Lindgren wrote:
> > # while [ 1 ]; do ifconfig wlan0 down; usleep 2; \
> > ifconfig wlan0 up; done
> >
> > Otherwise I get the following on warning pandaboard-es:
> >
> > W
Hi,
* Ulf Hansson [190115 15:04]:
> During "wlan-up", we are programming the FW into the WiFi-chip. However,
> re-programming the FW doesn't work, unless a power cycle of the WiFi-chip
> is made in-between the programmings.
>
> To conform to this requirement and to fix the regression in a simple
* Ulf Hansson [190102 12:02]:
>
> However, if this is about an out-of-band IRQ line, instead of using
> the SDIO IRQs on DAT1, I think management of that, belongs in the wlan
> (or gpiochip) layers.
Yes this can be handled at the gpiochip layer.
> We have to distinguish if "down" has a strict re
Hi,
* Ulf Hansson [181228 11:01]:
> On Sun, 23 Dec 2018 at 17:02, Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Reizer, Eyal [181223 07:38]:
> > > You are ok as long as the wlan_enable pin Does go down for a sufficient
> > > amount of time
> >
Hi,
* Reizer, Eyal [181223 07:38]:
> You are ok as long as the wlan_enable pin Does go down for a sufficient
> amount of time
> turning the wl18xx device off.
> The firmware can only be downloaded once after power on.
> In between down/up you have to make sure the wlan_enable is fully going
>
* Ulf Hansson [181220 10:15]:
> On Tue, 18 Dec 2018 at 16:54, Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Ulf Hansson [181218 12:34]:
> > > Instead, it looks like what you need, is a way to keep track of
> > > whether the SDIO card, became power
Hi,
* Ulf Hansson [181218 12:34]:
> Instead, it looks like what you need, is a way to keep track of
> whether the SDIO card, became power cycled or if it stayed powered on,
> when "ifconfig wlan0 up" is done. In case of a power cycle, you need
> to re-program the firmware, right?
Yeah mostly. Bu
l
Cc: Eyal Reizer
Cc: John Stultz
Cc: Ricardo Salveti
Cc: Ulf Hansson
Reported-by: Ricardo Salveti
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren
---
Uffe, do you have some better ideas on how to fix this issue?
---
drivers/net/wir
* Ricardo Salveti [181215 03:38]:
> On Fri, Dec 14, 2018 at 9:29 PM Tony Lindgren wrote:
> > * Ricardo Salveti [181214 12:42]:
> > > Basically since commit 60f36637bbbd ("wlcore: sdio: allow pm to handle
> > > sdio power") PM is now handling
* Ricardo Salveti [181214 12:42]:
> Hi,
>
> On Thu, Dec 13, 2018 at 12:45 PM Tony Lindgren wrote:
> > * Ricardo Salveti [181213 13:53]:
> > > I tried just increasing WL1271_PRE_POWER_ON_SLEEP from 20ms to 50ms
> > > (which gets used before calling wl
* Ricardo Salveti [181213 13:53]:
> I tried just increasing WL1271_PRE_POWER_ON_SLEEP from 20ms to 50ms
> (which gets used before calling wl12xx_sdio_power_on), and that was
> already enough to fix my issues on both hikey and beaglebone black
> wireless.
OK good to hear that helps :)
> Should we
* Anders Roxell [181211 23:45]:
> I have different serious, one when our board hangs on udhcpc [1], then I see
> wlcore and wl18xx_driver.
Hmm so on what SoC is this with? Adding Eyeal to Cc here too.
Regards,
Tony
> [8.824419] cfg80211: Loading compiled-in X.509 certificates for
> regulat
* Reizer, Eyal [181212 07:27]:
> I Just tried on an available am335x-evm using 4.20.0-rc1 which I believe has
> all the patches merged already.
> I am using the same script and not seeing any failure yet.
> See below:
>
> root@am335x-evm:/usr/share/wl18xx# uname -r
> 4.20.0-rc1-11287-gf487c00
>
* Ricardo Salveti [181211 20:45]:
> On Tue, Dec 11, 2018 at 6:23 PM Ricardo Salveti wrote:
> >
> > On Tue, Dec 11, 2018 at 6:12 PM Tony Lindgren wrote:
> > >
> > > * John Stultz [181211 19:51]:
> > > > On Tue, Dec 11, 2018 at 11:25 AM Ricardo Sal
* Ricardo Salveti [181211 21:51]:
> Tried to change back wl12xx_sdio_power_off to use pm_runtime_put_sync
> as a test, and noticed I always get -EBUSY when reproducing the hang,
> so it looks like this could be a race between pm_runtime_put/get when
> doing if down/up (and the side effect on the m
* John Stultz [181211 19:51]:
> On Tue, Dec 11, 2018 at 11:25 AM Ricardo Salveti
> wrote:
> > Then tried to reproduce with a simple 'while true; do ip link set dev
> > wlan0 down; ip link set dev wlan0 up; done;' and it was already enough
> > to cause the same hang. Adding a simple sleep 1 after
* Ricardo Salveti [181211 18:53]:
> Hi,
>
> On Tue, Dec 11, 2018 at 4:19 PM Tony Lindgren wrote:
> >
> > Hi,
> >
> > * Ricardo Salveti [181211 18:06]:
> > > John, did you have any similar issue on your test environment with
> > > kernel >=
Hi,
* Ricardo Salveti [181211 18:06]:
> John, did you have any similar issue on your test environment with
> kernel >= 4.19?
This sounds like the same issue that got fixed in the dts
earlier?
f904390ac8b2 ("arm64: dts: hikey: Define wl1835 power capabilities")
Regards,
Tony
Hi,
* Adam Ford [181130 13:16]:
> On Fri, Oct 5, 2018 at 3:33 AM Kalle Valo wrote:
> >
> > Tony Lindgren wrote:
> >
> > > We do not currently clear wl->elp_compl on ELP timeout and we have bogus
> > > lingering pointer that wlcore_irq then will
wlcore interrupt.
Note that eventually we should also allow configuring wlcore to use the
SDIO dat1 IRQ for wake-up, and in that case the the wakeirq should be
configured to be the padconf interrupt of the dat1 pin and not the
padconf interrupt of the OOB GPIO pin.
Cc: Eyal Reizer
Signed-off-by: Tony
owngrade the error to a
warning to prevent overly verbose output.
Cc: Eyal Reizer
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wir
* Kalle Valo [180627 15:44]:
>
> I'll do s/wclore/wlcore/ to the title.
OK thanks and sorry about that one.
Tony
r functions for the generic runtime PM calls. We would be getting
rid of any wrapper functions anyways.
After autoidle we should be able to start using Linux generic wakeirqs
for the padconf interrupt.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl18xx/debugfs.c| 26 +-
drivers/
t the firmware. And
only after that call pm_runtime_get_sync() when interrupts are enabled.
And only after that do the check for wl12xx_need_fw_change().
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 31 ---
1 file changed, 18 insertions(+
ff-by: Tony Lindgren
---
drivers/net/wireless/ti/wl18xx/debugfs.c| 9 +-
drivers/net/wireless/ti/wlcore/cmd.c| 3 +-
drivers/net/wireless/ti/wlcore/debugfs.c| 33 --
drivers/net/wireless/ti/wlcore/main.c | 111 +---
drivers/net/wireless/ti/wlcore/s
ntime PM support as the
custom PM code had it's own timer. We have not yet enabled runtime
PM autosuspend for wlcore and this is why this issue now shows up.
Let's fix the issues first before we enable runtime PM autosuspend.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl
allow ELP during suspend is completed before the system
suspend.
Signed-off-by: Eyal Reizer
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 51 +++
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore
apply this separately though in case others are hitting this issue.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
--- a/drivers/net/wireless
io: Warn about runtime PM suspend errors" that should
no longer be needed
Changes since v1:
- Fix issues reported by Eyal for recovery
- Add few patches for enable/disable issues found when using runtime PM
- Remove unused ps.h includes
Eyal Reizer (1):
wlcore: Use generic runtim
io_set_power() but
let's
fix that separately once we know exactly why we get the warning.
Reported-by: Eyal Reizer
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 10
* Reizer, Eyal [180614 11:32]:
> Hold on, I might have edited the wrong version of the file (main.c).
> Sorry about that. Working on too many branches/boards... :(
> Applied this change again and things look good now with the wl1281 based
> module.
Heh OK :) Sounds like time to post the whole s
Hi,
* Reizer, Eyal [180606 05:22]:
> Latest wl18xx firmware was running fine for two days without the crash, so it
> was indeed just a logging issue in this case.
OK good to hear.
> However, trying a wl1281 module and enabling PLT mode it boots ok but after a
> couple of seconds the below cra
* Tony Lindgren [180605 04:22]:
> * Reizer, Eyal [180603 06:07]:
> > I have noticed the following recovery a couple of times on my setup when
> > the board was
> > just sitting for a long time with just pings
> > It starts with a firmware recovery started fro
* Reizer, Eyal [180603 06:07]:
> I have noticed the following recovery a couple of times on my setup when the
> board was
> just sitting for a long time with just pings
> It starts with a firmware recovery started from the interrupt handler but the
> recovery fails
Sounds like the recovery ne
ff-by: Tony Lindgren
---
And here's the patch to test to enable autosuspend assuming people
don't find issues with the earlier patches in this series.
---
drivers/net/wireless/ti/wl18xx/debugfs.c| 9 +-
drivers/net/wireless/ti/wlcore/cmd.c| 3 +-
drivers/net/wireless/ti/w
t the firmware. And
only after that call pm_runtime_get_sync() when interrupts are enabled.
And only after that do the check for wl12xx_need_fw_change().
Signed-off-by: Tony Lindgren
---
Here's one more patch to test for this series.
---
drivers/net/wireless/ti/wlcore/m
* Tony Lindgren [180529 18:09]:
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
...
> +static int __maybe_unused wlcore_runtime_resume(struct device *dev)
> +{
> + struct wl1271 *wl = dev_get_drvdata(dev);
> + DECLARE_COMPLE
* Reizer, Eyal [180530 06:37]:
> > > >
> > > > With runtime PM enabled, we can now use generic calls to
> > > > pm_generic_runtime_suspend and pm_generic_runtime_resume for
> > enabling elp
> > > > during suspend when wowlan is enabled and waking the chip from elp
> > > > on resume.
> > >
> > > Sr
* Grygorii Strashko [180529 19:25]:
> On 05/29/2018 01:06 PM, Tony Lindgren wrote:
> > From: Eyal Reizer
> >
> > With runtime PM enabled, we can now use generic calls to
> > pm_generic_runtime_suspend and pm_generic_runtime_resume for enabling elp
> > during s
ntime PM support as the
custom PM code had it's own timer. We have not yet enabled runtime
PM autosuspend for wlcore and this is why this issue now shows up.
Let's fix the issues first before we enable runtime PM autosuspend.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl
r functions for the generic runtime PM calls. We would be getting
rid of any wrapper functions anyways.
After autoidle we should be able to start using Linux generic wakeirqs
for the padconf interrupt.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl18xx/debugfs.c| 26 +-
drivers/
io_set_power() but
let's
fix that separately once we know exactly why we get the warning.
Reported-by: Eyal Reizer
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 10
is used to allow ELP during suspend is completed before the system
suspend.
Signed-off-by: Eyal Reizer
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 51 +++
1 file changed, 13 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/ti
apply this separately though in case others are hitting this issue.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
--- a/drivers/net/wireless
patches for enable/disable issues found when using runtime PM
- Remove unused ps.h includes
Eyal Reizer (1):
wlcore: Use generic runtime pm calls for wowlan elp configuration
Tony Lindgren (5):
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
wlcore: Make sure PM cal
* Eyal Reizer [180524 11:38]:
> the wl pointer can be null In case only wlcore_sdio is probed while
> no WiLink module is successfully probed, as in the case of mounting a
> wl12xx module while using a device tree file configured with wl18xx
> related settings.
> In this case the system was crashi
gt; > > on resume.
> > > remove the custom API that was used to ensure that the command
> > > that is used to allow ELP during suspend is completed before the system
> > > suspend.
> > >
> > > Signed-off-by: Eyal Reizer
> > > ---
> &
* Reizer, Eyal [180523 12:45]:
> >
> > >
> > > Here's a modified version of your patch, does that put wlcore to
> > > idle with wowlan during suspend for you?
> > >
> >
> > Still no joy.
> > It suspends/resumes ok but leaves the firmware disabled from entering ELP.
>
> Spent some time on it tod
* Tony Lindgren [180522 15:03]:
> * Reizer, Eyal [180522 14:07]:
> > > > >
> > > > > OK try replacing the pm_runtime_put_noidle() above with just
> > > > > pm_runtime_put_sync(). The reason why I put noidle there was the
> > > > >
* Reizer, Eyal [180522 14:07]:
> > > >
> > > > OK try replacing the pm_runtime_put_noidle() above with just
> > > > pm_runtime_put_sync(). The reason why I put noidle there was the
> > > > wlcore_fw_sleep() call, with that gone put_sync should do the trick.
> > > >
> > >
> > > I have tried that al
* Reizer, Eyal [180522 13:50]:
> >
> > OK try replacing the pm_runtime_put_noidle() above with just
> > pm_runtime_put_sync(). The reason why I put noidle there was the
> > wlcore_fw_sleep() call, with that gone put_sync should do the trick.
> >
>
> I have tried that already. Same problem. The
* Reizer, Eyal [180522 06:42]:
> It still crash.
> The crash is different now.
> It also complains about:
> [ 60.544224] Unbalanced enable for IRQ 65
> Need down/up of the interface to recover after it.
Oh OK so no need for this patch and interrupts are already
enabled at that point. Sounds lik
* Kalle Valo [180522 08:05]:
> Tony Lindgren writes:
>
> > * Reizer, Eyal [180521 07:31]:
> >> > Here's a series of patches to add runtime PM support for wlcore. It does
> >> > not
> >> > yet implement autosuspend support, but let'
* Reizer, Eyal [180522 13:28]:
> Actually the below patch removing the call to wlcore_fw_sleep() avoids this
> error.
> The downside is that the wl8 firmware remains fully active during supend, so
> we
> Would need to find the root cause why the last call allowing the wilink8
> firmware
> To g
* Tony Lindgren [180521 16:40]:
> * Reizer, Eyal [180521 07:31]:
> > > Here's a series of patches to add runtime PM support for wlcore. It does
> > > not
> > > yet implement autosuspend support, but let's get this tested first as the
> > >
* Tony Lindgren [180517 18:53]:
> We may get -EBUSY from runtime PM and that most likely means some
> earlier wlcore command did not complete yet and further calls may
> fail. Let's add a warning to make it easier to track down and fix
> such issues in wlcore code.
Relate
* Reizer, Eyal [180521 07:31]:
> > Here's a series of patches to add runtime PM support for wlcore. It does not
> > yet implement autosuspend support, but let's get this tested first as the
> > autosuspend can mask enable/disable issues easily.
>
> Testing on BBB+WL1837 cape, scan, recovery, down
* Tony Lindgren [180517 18:52]:
> Hi all,
>
> Here's a series of patches to add runtime PM support for wlcore. It does not
> yet implement autosuspend support, but let's get this tested first as the
> autosuspend can mask enable/disable issues easily.
Sorry forgot to m
ery
- Add few patches for enable/disable issues found when using runtime PM
- Remove unused ps.h includes
Tony Lindgren (5):
wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()
wlcore: Make sure PM calls are paired
wlcore: Add support for runtime PM
wlcore: Fix misplac
We may get -EBUSY from runtime PM and that most likely means some
earlier wlcore command did not complete yet and further calls may
fail. Let's add a warning to make it easier to track down and fix
such issues in wlcore code.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/w
r functions for the generic runtime PM calls. We would be getting
rid of any wrapper functions anyways.
After autoidle we should be able to start using Linux generic wakeirqs
for the padconf interrupt.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl18xx/debugfs.c| 26 +-
drivers/
The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 10
ntime PM support as the
custom PM code had it's own timer. We have not yet enabled runtime
PM autosuspend for wlcore and this is why this issue now shows up.
Let's fix the issues first before we enable runtime PM autosuspend.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wl
apply this separately though in case others are hitting this issue.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/cmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/cmd.c
b/drivers/net/wireless/ti/wlcore/cmd.c
--- a/drivers/net/wireless
x27;s fix them
both though to avoid further confusion in the future.
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren
---
Changes since v1:
- Just ignore -EBUSY error for pm_runtime_put(), we're not checking
the return value for w
* Tony Lindgren [180515 16:15]:
> The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
> unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
> instead in preparation for changing things to use runtime PM.
>
> Signed-off-by: Tony Lindgr
* Tony Lindgren [180515 16:15]:
> The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
> unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
> instead in preparation for changing things to use runtime PM.
Looks like this causes at least a warn
* Tony Lindgren [180515 15:46]:
> We can have pm_runtime_get_sync() return 1, and we can have
> pm_runtime_put_sync() return -EBUSY. See rpm_suspend() and
> rpm_resume() for more information.
>
> Fix the issue by returning 0 from wl12xx_sdio_power_on() on success.
> And
* Michael Nazzareno Trimarchi [180515 16:19]:
> On Tue, May 15, 2018 at 6:13 PM, Tony Lindgren wrote:
> > @@ -315,15 +319,17 @@ static ssize_t dynamic_fw_traces_write(struct file
> > *file,
> > if (unlikely(wl->state != WLCORE_STATE_ON))
> >
lso remove WL1271_FLAG_ELP_REQUESTED
that is no longer needed.
Then eventually should allow us to use pm_runtime_autosuspend in
further patches instead of the custom handling. And we should be able
to start using Linux generic wakeirqs for the padconf interrupt.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless
The call to wl1271_ps_elp_wakeup() in wl12xx_queue_recovery_work() is
unpaired. Let's remove it and add paired calls to wl1271_recovery_work()
instead in preparation for changing things to use runtime PM.
Signed-off-by: Tony Lindgren
---
drivers/net/wireless/ti/wlcore/main.c | 8 ++
; that I posted earlier today as otherwise
you will get bogus errors.
Regards,
Tony
Tony Lindgren (2):
wlcore: Make sure PM calls are paired
wlcore: Add support runtime PM
drivers/net/wireless/ti/wl18xx/debugfs.c| 26 +-
drivers/net/wireless/ti/wlcore/debugfs.c| 79 ++--
drivers/
wl12xx_sdio_power_off(), then the MMC subsystem will idle the bus
when suitable.
Otherwise wlcore can sometimes get confused and may report bogus
errors and WLAN connection can fail.
Fixes: 60f36637bbbd ("wlcore: sdio: allow pm to handle sdio power")
Signed-off-by: Tony Lindgren
---
drivers/net/w
t;
> Signed-off-by: Eyal Reizer
> Cc: sta...@vger.kernel.org
Stable cc dropped, see Documentation/process/stable-kernel-rules.rst.
Looks good to me:
Acked-by: Tony Lindgren
ying on wilink6/7 Use mac internal mac address
> instead of a random one
> v6->v7: use random mac in case internal mac is zero
Great, works for me! Thanks for fixing this issue properly:
Tested-by: Tony Lindgren
* Reizer, Eyal [170810 07:24]:
> > >
> >
> > Sure, just want to make sure we are not trying to add work around just for
> > A couple of faulty devices.
> >
> > > > I have verified using a couple of com6 modules with an am335x-evm and
> > > they had mac addresses read ok.
> > >
> > > Sounds like
* Reizer, Eyal [170809 10:40]:
> Hi Tony,
>
> Sorry for top posting (mobile...)
> I have verified with system design and the data sheet that every wilink 6/7
> chip has a mac address in fuse so probably the board you have (pretty old,
> right?) has this mac address in fuse. Maybe it was from ve
* Tony Lindgren [170809 10:26]:
> * Reizer, Eyal [170809 00:55]:
> > --- a/drivers/net/wireless/ti/wlcore/main.c
> > +++ b/drivers/net/wireless/ti/wlcore/main.c
> > @@ -6040,6 +6040,21 @@ static int wl1271_register_hw(struct wl1271 *wl)
> > nic_a
* Reizer, Eyal [170809 00:55]:
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -6040,6 +6040,21 @@ static int wl1271_register_hw(struct wl1271 *wl)
> nic_addr = wl->fuse_nic_addr + 1;
> }
>
> + if (oui_addr == 0xdeadbe && n
* Reizer, Eyal [170809 00:26]:
> Managed to test with a wilink6 module and in fact reading hardware mac
> Address from fuse is working ok for wilink6/7 as well.
> submitting v6 using this mac address instead of a random one when the
> bogus (deadbeef...) mac address is read from default nvs file.
* Reizer, Eyal [170807 00:47]:
> Hi Tony,
> >
> > * Reizer, Eyal [170807 00:32]:
> > > The following commits:
> > > c815fde wlcore: spi: Populate config firmware data
> > > d776fc8 wlcore: sdio: Populate config firmware data
> > >
> > > Populated the nvs entry for wilink6 and wilink7 only while
* Reizer, Eyal [170807 00:32]:
> The following commits:
> c815fde wlcore: spi: Populate config firmware data
> d776fc8 wlcore: sdio: Populate config firmware data
>
> Populated the nvs entry for wilink6 and wilink7 only while it is
> still needed for wilink8 as well.
> This broke user space backw
* Reizer, Eyal [170725 04:33]:
> > From: Tony Lindgren [mailto:t...@atomide.com]
> > Hmm so why would we ever even use this bogus nvs file? In addition to
> > warning,
> > I think we should just ignore the bogus nvs file completely.
> >
> While it looks bogus,
1 - 100 of 152 matches
Mail list logo
