Thu, Feb 01, 2024 at 05:42:33PM CET, david.e.box@xxxxxxxxxxxxxxx wrote: >Hi Jiro, > >Thanks for your comments. > >On Thu, 2024-02-01 at 10:26 +0100, Jiri Pirko wrote: >> Thu, Feb 01, 2024 at 02:07:43AM CET, david.e.box@xxxxxxxxxxxxxxx wrote: >> >> [...] >> >> >> > + - >> > + name: spdm-req >> > + type: binary >> > + - >> > + name: spdm-rsp >> > + type: binary >> >> I don't understand the need to use netlink for this. Basically what you >> do is you just use it to pass binary blobs to and from FW. >> Advantages, like well-defined attributes, notifications etc, for which >> it makes sense to use Netlink are not utilized at all. > >SPDM supports the setup of a secure channel between the responder and requestor >using TLS based encryption algorthms. While this is just a transport for those >blobs, netlink seemed an appropriate interface for this type of communication. >The binary blobs can instead be broken out into the SPDM protocol messages, >right out of the spec. But for our needs this would still just define the >protocol. The algorithms themselves are not handled by the driver. If that is a standard, break it from blob into well-defined attributes and push it out of your driver to some common code. > >> Also, I don't thing it is good idea to have hw-driver-specific genl >> family. I'm not aware of anything like that so far. Leave netlink >> for use of generic and abstracted APIs. > >Sounds like an implied rule. If so should it be documented somewhere? > >> >> Can't you just have a simple misc device for this? > >It wouldn't be too much work to convert it. > >David
