Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp9601432rwd; Wed, 21 Jun 2023 09:20:39 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4aLSCcuMRpb1pW53L7XMhNwJQPL9MP1HSShFSwas1JNXrCyo6eWz/9YR+ElHs/JMDinE5L X-Received: by 2002:a05:6a20:12c4:b0:122:fce4:db09 with SMTP id v4-20020a056a2012c400b00122fce4db09mr3541546pzg.7.1687364438733; Wed, 21 Jun 2023 09:20:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687364438; cv=none; d=google.com; s=arc-20160816; b=Ji4u3ao0aER6/oGK29prWxxRzzHZ+rMkenRyyNUXY/c0LnU2Xmh/Do/BAbdpQE+5vr jSVfQfVhb3HA7STlFvql8uuXh5vCpbrMSV+CtauTD0kMNCE5dtP7zbaGQw4jigbq4qW6 LDNegnHHK3uZKU4gOxrO+IYb8tGR/5obyjDIH/n5Jjfsf+oqdte0K66xf6/5UvsNdVDl KscuWMOWt37B6L1tEJ2JYA9Irn45fp1JoufLBHNDhk7QMFOn7Vj6LJru8sEk+mnts/Xi mADu88h/ee8m/cPC8LO2AyAptJOKFhOH1XAoO8p+uxtwy7XDJkMvQaBSUlFs3MpREQMd raKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ik7rJHaj1qzSs2X3MBG7iKEMNpHmxnSx/M+1Kzp2joY=; b=i5AEdQ9B5Y+ffqBB9/8bgq0qF6S9O4s7/LOB8O4Tlly1fdmYJr3QUx6F5JL6ZCDsjp J5Wi7z9wPGZppn4RBEgLJ5Al+k9nhf9U1ft7fXzkqiphe0lHARks+4NF2pFv9xOBoe58 2d2ipz1dYEbGLxcJffVuocr37FjtINTImvWU6oR2adZlB7hc4aWqKw2fHlVeE76MmAaK delsxr2Kh18f7OmDy/99XzXoKEdFWJVOClV08Yxftv8jruIJNiyVVWnFRagNm1QLpAdb /kIUmCO/Qjm8DZAT3sOCRVKgxdualFJ8kwkl6qqLdnj3RVsQsw75isngaJOL9QMAjc80 zquA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=otdvDzqf; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a6566c5000000b00550e8b1ebc1si4597845pgw.339.2023.06.21.09.20.31; Wed, 21 Jun 2023 09:20:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=otdvDzqf; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231760AbjFUQPU (ORCPT + 59 others); Wed, 21 Jun 2023 12:15:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232190AbjFUQOx (ORCPT ); Wed, 21 Jun 2023 12:14:53 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D40C186; Wed, 21 Jun 2023 09:14:52 -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=ik7rJHaj1qzSs2X3MBG7iKEMNpHmxnSx/M+1Kzp2joY=; b=otdvDzqfkar6RS4pYFoDbzEzpq JiN4CSjoBZNtghkEbKsI1RX5gmvM6tiW/Dr566PB7PEyCctqx8zFajPymPf5MymYszlRGwSq3Tc3g GxqLybgBqao4pj6kJIszUNHKhsoeVIC/m4p07vccvLnZp/FBUW1D6/54RdI4ADtXNYW8=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1qC0T5-00HA64-GG; Wed, 21 Jun 2023 18:14:03 +0200 Date: Wed, 21 Jun 2023 18:14:03 +0200 From: Andrew Lunn To: Johannes Berg Cc: Evan Quan , rafael@kernel.org, lenb@kernel.org, alexander.deucher@amd.com, christian.koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, mario.limonciello@amd.com, mdaenzer@redhat.com, maarten.lankhorst@linux.intel.com, tzimmermann@suse.de, hdegoede@redhat.com, jingyuwang_vip@163.com, lijo.lazar@amd.com, 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 V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations Message-ID: References: <20230621054603.1262299-1-evan.quan@amd.com> <20230621054603.1262299-2-evan.quan@amd.com> <3a7c8ffa-de43-4795-ae76-5cd9b00c52b5@lunn.ch> <216f3c5aa1299100a0009ddf4e95b019855a32be.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <216f3c5aa1299100a0009ddf4e95b019855a32be.camel@sipsolutions.net> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org > > Do only ACPI based systems have: > > > > interference of relatively high-powered harmonics of the (G-)DDR > > memory clocks with local radio module frequency bands used by > > Wifi 6/6e/7." > > > > Could Device Tree based systems not experience this problem? > > They could, of course, but they'd need some other driver to change > _something_ in the system? I don't even know what this is doing > precisely under the hood in the ACPI BIOS If you don't know what it is actually doing, it suggests the API is not very well defined. Is there even enough details that ARM64 ACPI BIOS could implement this? > > > +/** > > > + * APIs needed by drivers/subsystems for contributing frequencies: > > > + * During probe, check `wbrf_supported_producer` to see if WBRF is supported. > > > + * If adding frequencies, then call `wbrf_add_exclusion` with the > > > + * start and end points specified for the frequency ranges added. > > > + * If removing frequencies, then call `wbrf_remove_exclusion` with > > > + * start and end points specified for the frequency ranges added. > > > + */ > > > +bool wbrf_supported_producer(struct acpi_device *adev); > > > +int wbrf_add_exclusion(struct acpi_device *adev, > > > + struct wbrf_ranges_in *in); > > > +int wbrf_remove_exclusion(struct acpi_device *adev, > > > + struct wbrf_ranges_in *in); > > > > Could struct device be used here, to make the API agnostic to where > > the information is coming from? That would then allow somebody in the > > future to implement a device tree based information provider. > > That does make sense, and it wouldn't even be that much harder if we > assume in a given platform there's only one provider That seems like a very reasonable assumption. It is theoretically possible to build an ACPI + DT hybrid, but i've never seen it actually done. If an ARM64 ACPI BIOS could implement this, then i would guess the low level bits would be solved, i guess jumping into the EL1 firmware. Putting DT on top instead should not be too hard. Andrew