Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp23085388rwd; Fri, 30 Jun 2023 18:01:17 -0700 (PDT) X-Google-Smtp-Source: APBJJlFihSIvmQfcmBeu1FeIveAbskkdWqFV+yR1qLbkjamC+Mijv/0Rx3pJzbxDogpcfdyVNUjs X-Received: by 2002:a92:d403:0:b0:345:d2fe:da92 with SMTP id q3-20020a92d403000000b00345d2feda92mr4118469ilm.10.1688173277396; Fri, 30 Jun 2023 18:01:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688173277; cv=none; d=google.com; s=arc-20160816; b=EWoHkTNSZzQo3kQcqfVlHIHXtpVezu06LN0y5Gg+6hFA1vwvP0YYf+yZb3UPqJWoO5 fvT/nlUlhx9+8r9aWUG+fxxOF+/XOZRg0aBI/1fiUtcWsb0Voy2pFzbpFguLQauH83BF ObO6HMjJTa1mFImI/JRGldnRXuWPmzpM5pLBvTNpMie5LwTDUN8P6879oy1KuvN1kKIw UyzITmvEhH7qjQnRFL2YclVK/Nq6S0qSZfybJGeBb5CK9rg/otS2UUj2KGiZJSTtCgr6 sLyBJGVnOuRIjqC9zyozGtRm6oBlz1eG5KWTP6Vitc8iP4Y4YoPPsH4dcBULfjOaF5/r cveg== 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=q5d9fk0Kq4PVVfrVMmslbF5d31U7oc6/SS2DxBc28Hc=; fh=D6nYKxI5p4Smxpa6kt74yrzpYFjczuTbkMJFqTiguQY=; b=VBzyFZbSeT9Vcu1lFlWhO5KFz/GLyHPHHIDPwaqpfp2A7gy/a7EdApI8HxXqam8YXw YcihCl+57eilwMzZ+JjJwuDTXv5j7xhOJ+ijT74xvTTwsSfU0wo+QIi7htE+TE+Mr3E3 7HiVrlpAxJkCeBawfqENgau5LhJU1yIxyFMzqCKMFANxlJ/JnQGJxCzS9wT5K5QEBhyJ pMDQinjgp2JeMx5t+NhhxaaAdUHCx99ybXS1la6zuyH3DMsq1HSqkdk64iVu8UslGx/6 Ukgv3Ei8vo737SlHkFJrbIgPDQD6UwdAnLz+zw8JFbwsB9MwRN+B5c/nize9jP75lWaK kcXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=vs8MTtvS; 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 k3-20020a170902c40300b001b665d8d63asi14991109plk.356.2023.06.30.18.01.04; Fri, 30 Jun 2023 18:01:17 -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=vs8MTtvS; 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 S229547AbjGAAvt (ORCPT + 60 others); Fri, 30 Jun 2023 20:51:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbjGAAvs (ORCPT ); Fri, 30 Jun 2023 20:51:48 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A799D1BD4; Fri, 30 Jun 2023 17:51:47 -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=q5d9fk0Kq4PVVfrVMmslbF5d31U7oc6/SS2DxBc28Hc=; b=vs8MTtvSbbgjYrbJogrzb1pxKW JK+3fztnoVP53vLCXM0f7H6wjh4BpPRl3jsGz6wJhz7u2qPekaJMCnkf1U7Sfv33U2UCDK/9LE3wh HdIAvAfxZ2goU2mx+r47OvElcUZKdaYBNRqpXI070OqEfM85L31oqAhbxqcWH7y0fOUQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1qFOpe-000LRM-Vz; Sat, 01 Jul 2023 02:51:22 +0200 Date: Sat, 1 Jul 2023 02:51:22 +0200 From: Andrew Lunn To: Evan Quan Cc: rafael@kernel.org, lenb@kernel.org, Alexander.Deucher@amd.com, Christian.Koenig@amd.com, Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch, johannes@sipsolutions.net, 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 V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD Message-ID: <4b2d5e30-1962-40f4-8c36-bfc35eba503c@lunn.ch> References: <20230630103240.1557100-1-evan.quan@amd.com> <20230630103240.1557100-3-evan.quan@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230630103240.1557100-3-evan.quan@amd.com> 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 > + argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1), GFP_KERNEL); > + if (!argv4) > + return -ENOMEM; > + > + argv4[arg_idx].package.type = ACPI_TYPE_PACKAGE; > + argv4[arg_idx].package.count = 2 + 2 * num_of_ranges; > + argv4[arg_idx++].package.elements = &argv4[1]; > + argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER; > + argv4[arg_idx++].integer.value = num_of_ranges; > + argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER; > + argv4[arg_idx++].integer.value = action; There is a lot of magic numbers in that kzalloc. It is being used as an array, kcalloc() would be a good start to make it more readable. Can some #define's be used to explain what the other numbers mean? > + /* > + * Bit 0 indicates whether there's support for any functions other than > + * function 0. > + */ Please make use of the BIT macro to give the different bits informative names. > + if ((mask & 0x1) && (mask & funcs) == funcs) > + return true; > + > + return false; > +} > + > +int acpi_amd_wbrf_retrieve_exclusions(struct device *dev, > + struct wbrf_ranges_out *out) > +{ > + struct acpi_device *adev = ACPI_COMPANION(dev); > + union acpi_object *obj; > + > + if (!adev) > + return -ENODEV; > + > + obj = acpi_evaluate_wbrf(adev->handle, > + WBRF_REVISION, > + WBRF_RETRIEVE); > + if (!obj) > + return -EINVAL; > + > + WARN(obj->buffer.length != sizeof(*out), > + "Unexpected buffer length"); > + memcpy(out, obj->buffer.pointer, obj->buffer.length); You WARN, and then overwrite whatever i passed the end of out? Please at least use min(obj->buffer.length, sizeof(*out)), but better still: if (obj->buffer.length != sizeof(*out)) { dev_err(dev, "BIOS FUBAR, ignoring wrong sized WBRT information"); return -EINVAL; } > +#if defined(CONFIG_WBRF_GENERIC) > static struct exclusion_range_pool wbrf_pool; > > static int _wbrf_add_exclusion_ranges(struct wbrf_ranges_in *in) > @@ -89,6 +92,7 @@ static int _wbrf_retrieve_exclusion_ranges(struct wbrf_ranges_out *out) > > return 0; > } > +#endif I was expecting you would keep these tables, and then call into the BIOS as well. Having this table in debugfs seems like a useful thing to have for debugging the BIOS. > +#ifdef CONFIG_WBRF_AMD_ACPI > +#else > +static inline bool > +acpi_amd_wbrf_supported_consumer(struct device *dev) { return false; } > +static inline bool > +acpi_amd_wbrf_supported_producer(struct device *dev) {return false; } > +static inline int > +acpi_amd_wbrf_remove_exclusion(struct device *dev, > + struct wbrf_ranges_in *in) { return -ENODEV; } > +static inline int > +acpi_amd_wbrf_add_exclusion(struct device *dev, > + struct wbrf_ranges_in *in) { return -ENODEV; } > +static inline int > +acpi_amd_wbrf_retrieve_exclusions(struct device *dev, > + struct wbrf_ranges_out *out) { return -ENODEV; } Do you actually need these stub versions? Andrew