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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E4DA7EB64DA for ; Tue, 4 Jul 2023 13:08:00 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 251BE10E164; Tue, 4 Jul 2023 13:08:00 +0000 (UTC) Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by gabe.freedesktop.org (Postfix) with ESMTPS id F17A410E164; Tue, 4 Jul 2023 13:07:57 +0000 (UTC) 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" 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: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "jingyuwang_vip@163.com" , "bellosilicio@gmail.com" , "rafael@kernel.org" , "trix@redhat.com" , "Lazar, Lijo" , "dri-devel@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , "mdaenzer@redhat.com" , "Limonciello, Mario" , "amd-gfx@lists.freedesktop.org" , "linux-acpi@vger.kernel.org" , "kuba@kernel.org" , "pabeni@redhat.com" , "lenb@kernel.org" , "andrealmeid@igalia.com" , "arnd@arndb.de" , "hdegoede@redhat.com" , "netdev@vger.kernel.org" , "Pan, Xinhui" , "linux-wireless@vger.kernel.org" , "edumazet@google.com" , "Koenig, Christian" , "tzimmermann@suse.de" , "Deucher, Alexander" , "johannes@sipsolutions.net" , "davem@davemloft.net" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > > 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