All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: "Jérôme Pouiller" <jerome.pouiller@silabs.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	driverdevel <devel@driverdev.osuosl.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"David S . Miller" <davem@davemloft.net>,
	DTML <devicetree@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Pali Rohár" <pali@kernel.org>
Subject: Re: [PATCH v5 08/24] wfx: add bus_sdio.c
Date: Mon, 12 Apr 2021 10:22:47 +0200	[thread overview]
Message-ID: <CAPDyKFrgrSAz-B7wqNNPKk3kB8UqhGs=+bZ8RRhmqh8HuvhcEQ@mail.gmail.com> (raw)
In-Reply-To: <87pmz6mhim.fsf@codeaurora.org>

On Wed, 7 Apr 2021 at 14:00, Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> >> If I follow what has been done in other drivers I would write something
> >> like:
> >>
> >>   static int wfx_sdio_suspend(struct device *dev)
> >>   {
> >>           struct sdio_func *func = dev_to_sdio_func(dev);
> >>           struct wfx_sdio_priv *bus = sdio_get_drvdata(func);
> >>
> >>           config_reg_write_bits(bus->core, CFG_IRQ_ENABLE_DATA, 0);
> >>           // Necessary to keep device firmware in RAM
> >>           return sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
> >
> > This will tell the mmc/sdio core to keep the SDIO card powered on
> > during system suspend. Thus, it doesn't need to re-initialize it at
> > system resume - and the firmware should not need to be re-programmed.
> >
> > On the other hand, if you don't plan to support system wakeups, it
> > would probably be better to power off the card, to avoid wasting
> > energy while the system is suspended. I assume that means you need to
> > re-program the firmware as well. Normally, it's these kinds of things
> > that need to be managed from a ->resume() callback.
>
> Many mac80211 drivers do so that the device is powered off during
> interface down (ifconfig wlan0 down), and as mac80211 does interface
> down automatically during suspend, suspend then works without extra
> handlers.

That sounds simple. :-)

Would you mind elaborating on what is actually being powered off at
interface down - and thus also I am curious what happens at a typical
interface up?

Even if we don't want to use system wakeups (wake-on-lan), the SDIO
core and the SDIO func driver still need to somewhat agree on how to
manage the power for the card during system suspend, I think.

For example, for a non-removable SDIO card, the SDIO/MMC core may
decide to power off the card in system suspend. Then it needs to
restore power to the card and re-initialize it at system resume, of
course. This doesn't mean that the actual corresponding struct device
for it, gets removed/re-added, thus the SDIO func driver isn't being
re-probed after the system has resumed. Although, since the SDIO card
was re-initialized, it's likely that the FW may need to be
re-programmed after the system has been resumed.

Are you saying that re-programming the FW is always happening at
interface up, when there are none system suspend/resume callbacks
assigned for the SDIO func driver?

Kind regards
Uffe

WARNING: multiple messages have this Message-ID
From: Ulf Hansson <ulf.hansson@linaro.org>
To: Kalle Valo <kvalo@codeaurora.org>
Cc: driverdevel <devel@driverdev.osuosl.org>,
	DTML <devicetree@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"Pali Rohár" <pali@kernel.org>,
	"David S . Miller" <davem@davemloft.net>
Subject: Re: [PATCH v5 08/24] wfx: add bus_sdio.c
Date: Mon, 12 Apr 2021 10:22:47 +0200	[thread overview]
Message-ID: <CAPDyKFrgrSAz-B7wqNNPKk3kB8UqhGs=+bZ8RRhmqh8HuvhcEQ@mail.gmail.com> (raw)
In-Reply-To: <87pmz6mhim.fsf@codeaurora.org>

On Wed, 7 Apr 2021 at 14:00, Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Ulf Hansson <ulf.hansson@linaro.org> writes:
>
> >> If I follow what has been done in other drivers I would write something
> >> like:
> >>
> >>   static int wfx_sdio_suspend(struct device *dev)
> >>   {
> >>           struct sdio_func *func = dev_to_sdio_func(dev);
> >>           struct wfx_sdio_priv *bus = sdio_get_drvdata(func);
> >>
> >>           config_reg_write_bits(bus->core, CFG_IRQ_ENABLE_DATA, 0);
> >>           // Necessary to keep device firmware in RAM
> >>           return sdio_set_host_pm_flags(func, MMC_PM_KEEP_POWER);
> >
> > This will tell the mmc/sdio core to keep the SDIO card powered on
> > during system suspend. Thus, it doesn't need to re-initialize it at
> > system resume - and the firmware should not need to be re-programmed.
> >
> > On the other hand, if you don't plan to support system wakeups, it
> > would probably be better to power off the card, to avoid wasting
> > energy while the system is suspended. I assume that means you need to
> > re-program the firmware as well. Normally, it's these kinds of things
> > that need to be managed from a ->resume() callback.
>
> Many mac80211 drivers do so that the device is powered off during
> interface down (ifconfig wlan0 down), and as mac80211 does interface
> down automatically during suspend, suspend then works without extra
> handlers.

That sounds simple. :-)

Would you mind elaborating on what is actually being powered off at
interface down - and thus also I am curious what happens at a typical
interface up?

Even if we don't want to use system wakeups (wake-on-lan), the SDIO
core and the SDIO func driver still need to somewhat agree on how to
manage the power for the card during system suspend, I think.

For example, for a non-removable SDIO card, the SDIO/MMC core may
decide to power off the card in system suspend. Then it needs to
restore power to the card and re-initialize it at system resume, of
course. This doesn't mean that the actual corresponding struct device
for it, gets removed/re-added, thus the SDIO func driver isn't being
re-probed after the system has resumed. Although, since the SDIO card
was re-initialized, it's likely that the FW may need to be
re-programmed after the system has been resumed.

Are you saying that re-programming the FW is always happening at
interface up, when there are none system suspend/resume callbacks
assigned for the SDIO func driver?

Kind regards
Uffe
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

  reply	other threads:[~2021-04-12  8:23 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 13:24 [PATCH v5 00/24] wfx: get out from the staging area Jerome Pouiller
2021-03-15 13:24 ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 01/24] mmc: sdio: add SDIO IDs for Silabs WF200 chip Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 02/24] dt-bindings: introduce silabs,wfx.yaml Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-23 22:42   ` Rob Herring
2021-03-23 22:42     ` Rob Herring
2021-03-15 13:24 ` [PATCH v5 03/24] wfx: add Makefile/Kconfig Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 15:11   ` Leon Romanovsky
2021-03-15 15:11     ` Leon Romanovsky
2021-03-15 16:21     ` Jérôme Pouiller
2021-03-15 16:21       ` Jérôme Pouiller
2021-03-17  4:25       ` Leon Romanovsky
2021-03-17  4:25         ` Leon Romanovsky
2021-03-15 13:24 ` [PATCH v5 04/24] wfx: add wfx.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 05/24] wfx: add main.c/main.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 06/24] wfx: add bus.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 07/24] wfx: add bus_spi.c Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 08/24] wfx: add bus_sdio.c Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-22 12:20   ` Ulf Hansson
2021-03-22 12:20     ` Ulf Hansson
2021-03-22 17:14     ` Jérôme Pouiller
2021-03-22 17:14       ` Jérôme Pouiller
2021-03-23 14:11       ` Ulf Hansson
2021-03-23 14:11         ` Ulf Hansson
2021-03-23 17:53         ` Jérôme Pouiller
2021-03-23 17:53           ` Jérôme Pouiller
2021-03-23 19:12           ` Ulf Hansson
2021-03-23 19:12             ` Ulf Hansson
2021-04-07 12:00             ` Kalle Valo
2021-04-07 12:00               ` Kalle Valo
2021-04-12  8:22               ` Ulf Hansson [this message]
2021-04-12  8:22                 ` Ulf Hansson
2021-10-01 12:31                 ` Kalle Valo
2021-11-08 17:27                   ` Ulf Hansson
2021-03-15 13:24 ` [PATCH v5 09/24] wfx: add hwio.c/hwio.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 10/24] wfx: add fwio.c/fwio.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 11/24] wfx: add bh.c/bh.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 12/24] wfx: add hif_api_*.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 13/24] wfx: add hif_tx*.c/hif_tx*.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 14/24] wfx: add key.c/key.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 15/24] wfx: add hif_rx.c/hif_rx.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 16/24] wfx: add data_rx.c/data_rx.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 17/24] wfx: add queue.c/queue.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 18/24] wfx: add data_tx.c/data_tx.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 19/24] wfx: add sta.c/sta.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 20/24] wfx: add scan.c/scan.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 21/24] wfx: add debug.c/debug.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:24 ` [PATCH v5 22/24] wfx: add traces.h Jerome Pouiller
2021-03-15 13:24   ` Jerome Pouiller
2021-03-15 13:25 ` [PATCH v5 23/24] wfx: remove from the staging area Jerome Pouiller
2021-03-15 13:25   ` Jerome Pouiller
2021-03-15 13:25 ` [PATCH v5 24/24] wfx: get out " Jerome Pouiller
2021-03-15 13:25   ` Jerome Pouiller
2021-03-15 21:09   ` kernel test robot
2021-03-15 21:09     ` kernel test robot
2021-03-15 21:09     ` kernel test robot
2021-03-15 21:09   ` [PATCH] wfx: fix irqf_oneshot.cocci warnings kernel test robot
2021-03-15 21:09     ` kernel test robot
2021-03-15 21:09     ` kernel test robot
2021-03-16  7:53     ` Jérôme Pouiller
2021-03-16  7:53       ` Jérôme Pouiller
2021-03-16  7:53       ` Jérôme Pouiller
2021-03-16  8:03       ` [kbuild-all] " Li, Philip
2021-03-16  8:03         ` Li, Philip
2021-03-16  8:03         ` [kbuild-all] " Li, Philip

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPDyKFrgrSAz-B7wqNNPKk3kB8UqhGs=+bZ8RRhmqh8HuvhcEQ@mail.gmail.com' \
    --to=ulf.hansson@linaro.org \
    --cc=davem@davemloft.net \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jerome.pouiller@silabs.com \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pali@kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.