mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Mario Limonciello <mario.limonciello@amd.com>
Cc: "Quan, Evan" <Evan.Quan@amd.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	"Pan, Xinhui" <Xinhui.Pan@amd.com>,
	"airlied@gmail.com" <airlied@gmail.com>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"johannes@sipsolutions.net" <johannes@sipsolutions.net>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"edumazet@google.com" <edumazet@google.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"pabeni@redhat.com" <pabeni@redhat.com>,
	"mdaenzer@redhat.com" <mdaenzer@redhat.com>,
	"maarten.lankhorst@linux.intel.com" 
	<maarten.lankhorst@linux.intel.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"hdegoede@redhat.com" <hdegoede@redhat.com>,
	"jingyuwang_vip@163.com" <jingyuwang_vip@163.com>,
	"Lazar, Lijo" <Lijo.Lazar@amd.com>,
	"jim.cromie@gmail.com" <jim.cromie@gmail.com>,
	"bellosilicio@gmail.com" <bellosilicio@gmail.com>,
	"andrealmeid@igalia.com" <andrealmeid@igalia.com>,
	"trix@redhat.com" <trix@redhat.com>,
	"jsg@jsg.id.au" <jsg@jsg.id.au>, "arnd@arndb.de" <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF
Date: Tue, 25 Jul 2023 22:09:49 +0200	[thread overview]
Message-ID: <5e92b45a-d99b-4a8a-9987-46c75a5fcb3c@lunn.ch> (raw)
In-Reply-To: <6aa9061b-1702-b8f2-9cb8-982895b9def4@amd.com>

> This comes back to the point that was mentioned by Johannes - you need to
> have deep design understanding of the hardware to know whether or not you
> will have producers that a consumer need to react to.

Yes, this is the policy is keep referring to. I would expect that
there is something somewhere in ACPI which says for this machine, the
policy is Yes/No.

It could well be that AMD based machine has a different ACPI extension
to indicate this policy to what Intel machine has. As far as i
understand it, you have not submitted this yet for formal approval,
this is all vendor specific, so Intel could do it completely
differently. Hence i would expect a generic API to tell the core what
the policy is, and your glue code can call into ACPI to find out that
information, and then tell the core.

> If all producers indicate their frequency and all consumers react to it you
> may have activated mitigations that are unnecessary. The hardware designer
> may have added extra shielding or done the layout such that they're not
> needed.

And the policy will indicate No, nothing needs to be done. The core
can then tell produces and consumes not to bother telling the core
anything.

> So I don't think we're ever going to be in a situation that the generic
> implementation should be turned on by default.  It's a "developer knob".

Wrong. You should have a generic core, which your AMD CPU DDR device
plugs into. The Intel CPU DDR device can plug into, the nvidea GPU can
plug into, your Radeon GPU can plug into, the intel ARC can plug into,
the generic WiFi core plugs into, etc.

> If needed these can then be enabled using the AMD ACPI interface, a DT one
> if one is developed or maybe even an allow-list of SMBIOS strings.

Notice i've not mentioned DT for a while. I just want a generic core,
which AMD, Intel, nvidea, Ampare, Graviton, Qualcomm, Marvell, ...,
etc can use. We should be solving this problem once, for everybody,
not adding a solution for just one vendor.

      Andrew

  reply	other threads:[~2023-07-25 20:10 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-19  9:00 [PATCH V7 0/9] Enable Wifi RFI interference mitigation feature support Evan Quan
2023-07-19  9:00 ` [PATCH V7 1/9] drivers core: Add support for Wifi band RF mitigations Evan Quan
2023-07-19  9:00 ` [PATCH V7 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD Evan Quan
2023-07-19  9:00 ` [PATCH V7 3/9] cfg80211: expose nl80211_chan_width_to_mhz for wide sharing Evan Quan
2023-07-19  9:00 ` [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF Evan Quan
2023-07-24  9:22   ` Andrew Lunn
2023-07-24 13:40     ` Limonciello, Mario
2023-07-25 10:38       ` Quan, Evan
2023-07-25 18:57         ` Andrew Lunn
2023-07-25 19:15           ` Mario Limonciello
2023-07-25 20:09             ` Andrew Lunn [this message]
2023-07-25 20:44               ` Mario Limonciello
2023-08-14  9:50               ` Quan, Evan
2023-08-14 14:31                 ` Andrew Lunn
2023-08-14 10:02               ` Johannes Berg
2023-07-19  9:00 ` [PATCH V7 5/9] drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature Evan Quan
2023-07-19  9:00 ` [PATCH V7 6/9] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature Evan Quan
2023-07-19  9:00 ` [PATCH V7 7/9] drm/amd/pm: add flood detection for wbrf events Evan Quan
2023-07-19  9:00 ` [PATCH V7 8/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0 Evan Quan
2023-07-19  9:00 ` [PATCH V7 9/9] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7 Evan Quan
2023-07-24  2:50 ` [PATCH V7 0/9] Enable Wifi RFI interference mitigation feature support Quan, Evan

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=5e92b45a-d99b-4a8a-9987-46c75a5fcb3c@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Evan.Quan@amd.com \
    --cc=Lijo.Lazar@amd.com \
    --cc=Xinhui.Pan@amd.com \
    --cc=airlied@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andrealmeid@igalia.com \
    --cc=arnd@arndb.de \
    --cc=bellosilicio@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=davem@davemloft.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edumazet@google.com \
    --cc=hdegoede@redhat.com \
    --cc=jim.cromie@gmail.com \
    --cc=jingyuwang_vip@163.com \
    --cc=johannes@sipsolutions.net \
    --cc=jsg@jsg.id.au \
    --cc=kuba@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mario.limonciello@amd.com \
    --cc=mdaenzer@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rafael@kernel.org \
    --cc=trix@redhat.com \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®