netdev - Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d4cfbbae-9cd0-4767-8c80-ec09d1dbaf9c@lunn.ch>
Date: Tue, 25 Jul 2023 20:57:57 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Quan, Evan" <Evan.Quan@....com>
Cc: "Limonciello, Mario" <Mario.Limonciello@....com>,
	"rafael@...nel.org" <rafael@...nel.org>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"Deucher, Alexander" <Alexander.Deucher@....com>,
	"Koenig, Christian" <Christian.Koenig@....com>,
	"Pan, Xinhui" <Xinhui.Pan@....com>,
	"airlied@...il.com" <airlied@...il.com>,
	"daniel@...ll.ch" <daniel@...ll.ch>,
	"johannes@...solutions.net" <johannes@...solutions.net>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"mdaenzer@...hat.com" <mdaenzer@...hat.com>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"tzimmermann@...e.de" <tzimmermann@...e.de>,
	"hdegoede@...hat.com" <hdegoede@...hat.com>,
	"jingyuwang_vip@....com" <jingyuwang_vip@....com>,
	"Lazar, Lijo" <Lijo.Lazar@....com>,
	"jim.cromie@...il.com" <jim.cromie@...il.com>,
	"bellosilicio@...il.com" <bellosilicio@...il.com>,
	"andrealmeid@...lia.com" <andrealmeid@...lia.com>,
	"trix@...hat.com" <trix@...hat.com>,
	"jsg@....id.au" <jsg@....id.au>, "arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

> > >> @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct
> > ieee80211_hw *hw)
> > >>    debugfs_hw_add(local);
> > >>    rate_control_add_debugfs(local);
> > >>
> > >> +  ieee80211_check_wbrf_support(local);
> > >> +
> > >>    rtnl_lock();
> > >>    wiphy_lock(hw->wiphy);
> > >>
> > >
> > >> +void ieee80211_check_wbrf_support(struct ieee80211_local *local) {
> > >> +  struct wiphy *wiphy = local->hw.wiphy;
> > >> +  struct device *dev;
> > >> +
> > >> +  if (!wiphy)
> > >> +          return;
> > >> +
> > >> +  dev = wiphy->dev.parent;
> > >> +  if (!dev)
> > >> +          return;
> > >> +
> > >> +  local->wbrf_supported = wbrf_supported_producer(dev);
> > >> +  dev_dbg(dev, "WBRF is %s supported\n",
> > >> +          local->wbrf_supported ? "" : "not"); }
> > >
> > > This seems wrong. wbrf_supported_producer() is about "Should this
> > > device report the frequencies it is using?" The answer to that depends
> > > on a combination of: Are there consumers registered with the core, and
> > > is the policy set so WBRF should take actions. > The problem here is,
> > > you have no idea of the probe order. It could be this device probes
> > > before others, so wbrf_supported_producer() reports false, but a few
> > > second later would report true, once other devices have probed.
> > >
> > > It should be an inexpensive call into the core, so can be made every
> > > time the channel changes. All the core needs to do is check if the
> > > list of consumers is empty, and if not, check a Boolean policy value.
> > >
> > >       Andrew
> >
> > No, it's not a combination of whether consumers are registered with the core.
> > If a consumer probes later it needs to know the current in use frequencies too.
> >
> > The reason is because of this sequence of events:
> > 1) Producer probes.
> > 2) Producer selects a frequency.
> > 3) Consumer probes.
> > 4) Producer stays at same frequency.
> >
> > If the producer doesn't notify the frequency because a consumer isn't yet
> > loaded then the consumer won't be able to get the current frequency.
> Yes, exactly.

So now we are back to, what is the point of wbrf_supported_producer()?

I'm talking general case here, not your ACPI implementation. All i'm
really interested in is the generic API, which is what an Intel CPU,
combined with a Radieon GPU and a Qualcomm WiFi device will use. Or an
AMD CPU combined with an nvidia GPU and a Mediatek Wifi, etc. The wbrf
core should support an combination of produces and consumers in a
generic way.

If you assume devices can probe in any order, and come and go, it
seems like the producers need to always report what frequencies they
are using. Otherwise when a noise generator pops into existence, as
you say, it has no idea what frequencies the producers are using.

The exception is when policy says there is no need to actually do
anything. If we can assume the policy is fixed, then
wbrf_supported_producer() could just report the policy which the wbrf
core should know about.

    Andrew