All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
To: Pkshih <pkshih@realtek.com>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"tony0620emma@gmail.com" <tony0620emma@gmail.com>,
	"kvalo@codeaurora.org" <kvalo@codeaurora.org>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Neo Jou <neojou@gmail.com>,
	Jernej Skrabec <jernej.skrabec@gmail.com>
Subject: Re: [PATCH RFC v1 2/7] rtw88: Use rtw_iterate_vifs where the iterator reads or writes registers
Date: Sun, 25 Jul 2021 23:31:26 +0200	[thread overview]
Message-ID: <CAFBinCCqVpqC+CaJqTjhCj6-4rFcttQ-cFjOPwtKFbXbnop3XA@mail.gmail.com> (raw)
In-Reply-To: <2170471a1c144adb882d06e08f3c9d1a@realtek.com>

Hello Ping-Ke,

On Mon, Jul 19, 2021 at 7:47 AM Pkshih <pkshih@realtek.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Martin Blumenstingl [mailto:martin.blumenstingl@googlemail.com]
> > Sent: Sunday, July 18, 2021 4:41 AM
> > To: linux-wireless@vger.kernel.org
> > Cc: tony0620emma@gmail.com; kvalo@codeaurora.org; johannes@sipsolutions.net; netdev@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Neo Jou; Jernej Skrabec; Martin Blumenstingl
> > Subject: [PATCH RFC v1 2/7] rtw88: Use rtw_iterate_vifs where the iterator reads or writes registers
> >
> > Upcoming SDIO support may sleep in the read/write handlers. Switch
> > all users of rtw_iterate_vifs_atomic() which are either reading or
> > writing a register to rtw_iterate_vifs().
> >
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> > ---
> >  drivers/net/wireless/realtek/rtw88/main.c | 6 +++---
> >  drivers/net/wireless/realtek/rtw88/ps.c   | 2 +-
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
> > index c6364837e83b..207161a8f5bd 100644
> > --- a/drivers/net/wireless/realtek/rtw88/main.c
> > +++ b/drivers/net/wireless/realtek/rtw88/main.c
> > @@ -229,8 +229,8 @@ static void rtw_watch_dog_work(struct work_struct *work)
> >       rtw_phy_dynamic_mechanism(rtwdev);
> >
> >       data.rtwdev = rtwdev;
> > -     /* use atomic version to avoid taking local->iflist_mtx mutex */
> > -     rtw_iterate_vifs_atomic(rtwdev, rtw_vif_watch_dog_iter, &data);
> > +
> > +     rtw_iterate_vifs(rtwdev, rtw_vif_watch_dog_iter, &data);
>
> You revert the fix of [1].
Thanks for bringing this to my attention!

> I think we can move out rtw_chip_cfg_csi_rate() from rtw_dynamic_csi_rate(), and
> add/set a field cfg_csi_rate to itera data. Then, we do rtw_chip_cfg_csi_rate()
> outside iterate function. Therefore, we can keep the atomic version of iterate_vifs.
just to make sure that I understand this correctly:
rtw_iterate_vifs_atomic can be the iterator as it was before
inside the iterator func I use something like:
    iter_data->cfg_csi_rate = rtwvif->bfee.role == RTW_BFEE_SU ||
rtwvif->bfee.role == RTW_BFEE_MU || iter_data->cfg_csi_rate;
(the last iter_data->cfg_csi_rate may read a bit strange, but I think
it's needed because there can be multiple interfaces and if any of
them has cfg_csi_rate true then we need to remember that)
then move the rtw_chip_cfg_csi_rate outside the iterator function,
taking iter_data->cfg_csi_rate to decide whether it needs to be called


Best regards,
Martin

  reply	other threads:[~2021-07-25 21:32 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-17 20:40 [PATCH RFC v1 0/7] rtw88: prepare locking for SDIO support Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 1/7] mac80211: Add stations iterator where the iterator function may sleep Martin Blumenstingl
2021-07-19  5:46   ` Pkshih
2021-07-19  6:30   ` Johannes Berg
2021-07-17 20:40 ` [PATCH RFC v1 2/7] rtw88: Use rtw_iterate_vifs where the iterator reads or writes registers Martin Blumenstingl
2021-07-19  5:47   ` Pkshih
2021-07-25 21:31     ` Martin Blumenstingl [this message]
2021-07-26  7:22       ` Pkshih
2021-07-17 20:40 ` [PATCH RFC v1 3/7] rtw88: Use rtw_iterate_stas " Martin Blumenstingl
2021-07-19  6:36   ` Johannes Berg
2021-07-25 21:51     ` Martin Blumenstingl
2021-07-26  7:22       ` Pkshih
2021-08-09 20:00         ` Johannes Berg
2021-07-17 20:40 ` [PATCH RFC v1 4/7] rtw88: Replace usage of rtw_iterate_keys_rcu() with rtw_iterate_keys() Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 5/7] rtw88: Configure the registers from rtw_bf_assoc() outside the RCU lock Martin Blumenstingl
2021-07-19  5:47   ` Pkshih
2021-07-25 21:36     ` Martin Blumenstingl
2021-07-26  7:22       ` Pkshih
2021-07-17 20:40 ` [PATCH RFC v1 6/7] rtw88: hci: Convert rf_lock from a spinlock to a mutex Martin Blumenstingl
2021-07-17 20:40 ` [PATCH RFC v1 7/7] rtw88: fw: Convert h2c.lock " Martin Blumenstingl
2021-07-19  5:52 ` [PATCH RFC v1 0/7] rtw88: prepare locking for SDIO support Pkshih

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=CAFBinCCqVpqC+CaJqTjhCj6-4rFcttQ-cFjOPwtKFbXbnop3XA@mail.gmail.com \
    --to=martin.blumenstingl@googlemail.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=neojou@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=pkshih@realtek.com \
    --cc=tony0620emma@gmail.com \
    /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.