lkml.org 
[lkml]   [2023]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD
Date
[AMD Official Use Only - General]

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Saturday, July 1, 2023 8:51 AM
> To: Quan, Evan <Evan.Quan@amd.com>
> Cc: rafael@kernel.org; lenb@kernel.org; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>; Pan, Xinhui <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; Limonciello, Mario <Mario.Limonciello@amd.com>;
> mdaenzer@redhat.com; maarten.lankhorst@linux.intel.com;
> tzimmermann@suse.de; hdegoede@redhat.com; jingyuwang_vip@163.com;
> Lazar, Lijo <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
>
> > + 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?
Sure, will update accordingly.
>
> > + /*
> > + * 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.
Sure.
>
> > + 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;
> }
OK. Sounds reasonable. Will update as suggested.
>
> > +#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.
I'm not sure. Since these interfaces what we designed now kind of serve as a library.
When and where the debugfs should be created will be quite tricky.
>
> > +#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?
Yes, these can be dropped. Let me update accordingly.

Evan
>
> Andrew

\
 
 \ /
  Last update: 2023-07-04 05:25    [W:0.078 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site