netdev - Re: [RFC PATCH fwctl 3/5] pds_fwctl: initial driver framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6e023017-27ac-4182-8a87-313d2b34f5e4@amd.com>
Date: Thu, 20 Feb 2025 15:27:37 -0800
From: "Nelson, Shannon" <shannon.nelson@....com>
To: Leon Romanovsky <leon@...nel.org>
Cc: jgg@...dia.com, andrew.gospodarek@...adcom.com,
 aron.silverton@...cle.com, dan.j.williams@...el.com, daniel.vetter@...ll.ch,
 dave.jiang@...el.com, dsahern@...nel.org, gospo@...adcom.com,
 hch@...radead.org, itayavr@...dia.com, jiri@...dia.com,
 Jonathan.Cameron@...wei.com, kuba@...nel.org, lbloch@...dia.com,
 saeedm@...dia.com, linux-cxl@...r.kernel.org, linux-rdma@...r.kernel.org,
 netdev@...r.kernel.org, brett.creeley@....com
Subject: Re: [RFC PATCH fwctl 3/5] pds_fwctl: initial driver framework

On 2/19/2025 12:25 AM, Leon Romanovsky wrote:
> 
> On Tue, Feb 18, 2025 at 02:19:03PM -0800, Nelson, Shannon wrote:
>> On 2/18/2025 11:51 AM, Leon Romanovsky wrote:
>>>
>>> On Tue, Feb 11, 2025 at 03:48:52PM -0800, Shannon Nelson wrote:
>>>> Initial files for adding a new fwctl driver for the AMD/Pensando PDS
>>>> devices.  This sets up a simple auxiliary_bus driver that registers
>>>> with fwctl subsystem.  It expects that a pds_core device has set up
>>>> the auxiliary_device pds_core.fwctl
>>>>
>>>> Signed-off-by: Shannon Nelson <shannon.nelson@....com>
>>>> ---
>>>>    MAINTAINERS                    |   7 ++
>>>>    drivers/fwctl/Kconfig          |  10 ++
>>>>    drivers/fwctl/Makefile         |   1 +
>>>>    drivers/fwctl/pds/Makefile     |   4 +
>>>>    drivers/fwctl/pds/main.c       | 195 +++++++++++++++++++++++++++++++++
>>>>    include/linux/pds/pds_adminq.h |  77 +++++++++++++
>>>>    include/uapi/fwctl/fwctl.h     |   1 +
>>>>    include/uapi/fwctl/pds.h       |  27 +++++
>>>>    8 files changed, 322 insertions(+)
>>>>    create mode 100644 drivers/fwctl/pds/Makefile
>>>>    create mode 100644 drivers/fwctl/pds/main.c
>>>>    create mode 100644 include/uapi/fwctl/pds.h
>>>
>>> <...>
> 
> <...>
> 
>>>> +             return err;
>>>> +     }
>>>> +
>>>> +     cmd.fwctl_ident.opcode = PDS_FWCTL_CMD_IDENT;
>>>> +     cmd.fwctl_ident.version = 0;
>>>
>>> How will you manage this version field?
>>
>> Since there is only version 0 at this point, there is not much to manage.  I
>> wanted to explicitly show the setting to version 0, but maybe that can be
>> assumed by the basic struct init.
> 
> But the question is slightly different "How will you manage this version field?"

If we find we have to change the interface in a non-backward-compatable 
way, we'll increment the version number that we support, and watch for 
the version number supported by the firmware as reported in the ident 
struct data and interpret the data appropriately.  Similarly, if the 
firmware sees that the host driver is at a lower version number, it will 
handle data in the older format.

sln