lkml.org 
[lkml]   [2023]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v8 3/4] fpga: dfl: add basic support for DFHv1


On Mon, 2 Jan 2023, Andy Shevchenko wrote:

> On Mon, Jan 02, 2023 at 07:27:06PM +0200, Andy Shevchenko wrote:
>> On Mon, Jan 02, 2023 at 08:54:48AM -0800, matthew.gerlach@linux.intel.com wrote:
>>> On Thu, 29 Dec 2022, Andy Shevchenko wrote:
>>>> On Thu, Dec 29, 2022 at 08:18:03AM -0800, Tom Rix wrote:
>>>>> On 12/28/22 10:16 AM, matthew.gerlach@linux.intel.com wrote:
>
> ...
>
>>>>>> + u64 params[];
>>>>> u64 *params
>>
>>>> This will break the overflow.h macros, no?
>>>> Besides that it will break the code for sure as it's not an equivalent.
>>
>>> I don't understand how this will break the overflow.h macros. The definition
>>> of struct dfl_feature_info and all of its uses are in a single file, dfl.c.
>>
>> Hint: __must_be_array()
>>
>> As I said, the proposed change is not acceptable since it's not an equivalent.
>
> Ah, you meant that there is no use of macros from overflow in the dfl.c?
> IIRC we discussed that some of the code may make use of them, or am I
> mistaken?

There currently is one usage of struct_size() from overflow.h in dfl.c,
and my patch adds another usage of struct_size(). struct dfl_feature_info
ends with a trailing array of u64.

I think the confusion is with struct dfl_feature and/or struct struct
dfl_device. Those structs don't end with a trailing array, and those
structs are not used with macros from overview.h.

Thanks for the feedback,
Matthew Gerlach

>
> --
> With Best Regards,
> Andy Shevchenko
>
>
>

\
 
 \ /
  Last update: 2023-03-26 23:25    [W:0.127 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site