From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65305EB64DA for ; Tue, 4 Jul 2023 13:08:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231159AbjGDNIK (ORCPT ); Tue, 4 Jul 2023 09:08:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229645AbjGDNIJ (ORCPT ); Tue, 4 Jul 2023 09:08:09 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C06711B4; Tue, 4 Jul 2023 06:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=p2IeYQpGstyHc2o1uZoj5LpWskpFkCurknri7FAU7Sc=; b=doFCJ3+M2ZbnwCnNdylf69dbn7 dEt8U5JRYhixIcAX4/NUmMkQDZ4Yv1Hh/NkwBjC5ObE9o8vEoAfQPYw7wCHQQI5Yuja91bxFm+NbL Blb/HMHvkbYn5Xo+/+e/pq8EDf7c9kn3U8xCg61HatQrAw8Kz3JHzRXB1XKbecqxHB30=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1qGfkR-000Ydd-1w; Tue, 04 Jul 2023 15:07:15 +0200 Date: Tue, 4 Jul 2023 15:07:15 +0200 From: Andrew Lunn To: "Quan, Evan" Cc: "rafael@kernel.org" , "lenb@kernel.org" , "Deucher, Alexander" , "Koenig, Christian" , "Pan, Xinhui" , "airlied@gmail.com" , "daniel@ffwll.ch" , "johannes@sipsolutions.net" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "Limonciello, Mario" , "mdaenzer@redhat.com" , "maarten.lankhorst@linux.intel.com" , "tzimmermann@suse.de" , "hdegoede@redhat.com" , "jingyuwang_vip@163.com" , "Lazar, Lijo" , "jim.cromie@gmail.com" , "bellosilicio@gmail.com" , "andrealmeid@igalia.com" , "trix@redhat.com" , "jsg@jsg.id.au" , "arnd@arndb.de" , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "amd-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "linux-wireless@vger.kernel.org" , "netdev@vger.kernel.org" Subject: Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations Message-ID: <18dfe989-2610-4234-ade2-ffbc2f233c19@lunn.ch> References: <20230630103240.1557100-1-evan.quan@amd.com> <20230630103240.1557100-2-evan.quan@amd.com> <7e7db6eb-4f46-407a-8d1f-16688554ad80@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org > > What is the purpose of this stage? Why would it not be supported for this > > device? > This is needed for wbrf support via ACPI mechanism. If BIOS(AML code) does not support the wbrf adding/removing for some device, > it should speak that out so that the device can be aware of that. How much overhead is this adding? How deep do you need to go to find the BIOS does not support it? And how often is this called? Where do we want to add complexity? In the generic API? Or maybe a little deeper in the ACPI specific code? Andrew