[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4b2d5e30-1962-40f4-8c36-bfc35eba503c@lunn.ch>
Date: Sat, 1 Jul 2023 02:51:22 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Evan Quan <evan.quan@....com>
Cc: rafael@...nel.org, lenb@...nel.org, Alexander.Deucher@....com,
Christian.Koenig@....com, Xinhui.Pan@....com, airlied@...il.com,
daniel@...ll.ch, johannes@...solutions.net, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
Mario.Limonciello@....com, mdaenzer@...hat.com,
maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de,
hdegoede@...hat.com, jingyuwang_vip@....com, Lijo.Lazar@....com,
jim.cromie@...il.com, bellosilicio@...il.com,
andrealmeid@...lia.com, trix@...hat.com, jsg@....id.au,
arnd@...db.de, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
dri-devel@...ts.freedesktop.org, linux-wireless@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism
introduced by AMD
> + 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
Powered by blists - more mailing lists