On Mon, Mar 03, 2025 at 05:53:58PM -0800, Jakub Kicinski wrote: > On Thu, 27 Feb 2025 20:26:28 -0400 Jason Gunthorpe wrote: > > v5: > > - Move hunks between patches to make more sense > > - Rename ucmd_buffer to fwctl_ucmd_buffer > > - Update comments and commit messages > > - Copyright to 2025 > > - Drop bxnt WIP patches > > - Allow a NULL ops->info > > - Decode more op codes for mlx5 and the sub-operation for > > MLX5_CMD_OP_ACCESS_REG/_USER > > Did you address my feedback? I asked for the mlx5 support to only be > enabled in RDMA is in use. Saeed who wrote the mlx5 parts of this > patchset clearly admitted on v4: I never agreed to that formulation. I suggested that perhaps runtime configurations where netdev is the only driver using the HW could be disabled (ie a netdev exclusion, not a rdma inclusion). However, there is not agreement on this from Saeed who is responsible for mlx5: https://lore.kernel.org/all/Z7z0ADkimCkhr7Xz@x130/ I also surveyed other stakeholders on a netdev-exclusion proposal and did not hear support. You need to convince people this is a good idea. However, I would agree fwctl should not accept any fwctl drivers for simple networking devices. However, "smart nics" and RDMA capable devices are in-scope. I could also probably agree to using kconfig to disable fwctl drivers on kernels that statically compile out rdma, vdpa, nvme and related, though I agree with Saeed that it seems to lack technical merit. > Greg, I've been asking for this interface to be scoped to when RDMA > (/CXL/storage) is in enabled on these NICs since pretty much the first > RFC. You only started asking for this more limited approach in v4. All your previous arguments were that fwctl should be entirely killed for any networking HW. Jason
