Message ID | 20211221235852.323752-1-david.e.box@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | driver_core: Auxiliary drvdata helper cleanup | expand |
On Tue, Dec 21, 2021 at 03:58:48PM -0800, David E. Box wrote: > Depends on "driver core: auxiliary bus: Add driver data helpers" patch [1]. > Applies the helpers to all auxiliary device drivers using > dev_(get/set)_drvdata. Drivers were found using the following search: > > grep -lr "struct auxiliary_device" $(grep -lr "drvdata" .) > > Changes were build tested using the following configs: > > vdpa/mlx5: CONFIG_MLX5_VDPA_NET > net/mlx53: CONFIG_MLX5_CORE_EN > soundwire/intel: CONFIG_SOUNDWIRE_INTEL > RDAM/irdma: CONFIG_INFINIBAND_IRDMA > CONFIG_MLX5_INFINIBAND > > [1] https://www.spinics.net/lists/platform-driver-x86/msg29940.html I have to say I don't really find this to be a big readability improvement. Also, what use is 'to_auxiliary_dev()' ? I didn't see any users added.. Jason
On Tue, 2021-12-21 at 20:09 -0400, Jason Gunthorpe wrote: > On Tue, Dec 21, 2021 at 03:58:48PM -0800, David E. Box wrote: > > Depends on "driver core: auxiliary bus: Add driver data helpers" patch [1]. > > Applies the helpers to all auxiliary device drivers using > > dev_(get/set)_drvdata. Drivers were found using the following search: > > > > grep -lr "struct auxiliary_device" $(grep -lr "drvdata" .) > > > > Changes were build tested using the following configs: > > > > vdpa/mlx5: CONFIG_MLX5_VDPA_NET > > net/mlx53: CONFIG_MLX5_CORE_EN > > soundwire/intel: CONFIG_SOUNDWIRE_INTEL > > RDAM/irdma: CONFIG_INFINIBAND_IRDMA > > CONFIG_MLX5_INFINIBAND > > > > [1] https://www.spinics.net/lists/platform-driver-x86/msg29940.html > > I have to say I don't really find this to be a big readability > improvement. I should have referenced the thread [1] discussing the benefit of this change since the question was asked and answered already. The idea is that drivers shouldn't have to touch the device API directly if they are already using a higher level core API (auxiliary bus) that can do that on its behalf. One benefit of this scheme is that it limits the number of places where changes need to be made if the device core were to change. [1] https://lore.kernel.org/all/YbBwOb6JvWkT3JWI@kroah.com/ > > Also, what use is 'to_auxiliary_dev()' ? I didn't see any users added.. This was not added by that patch. Thanks David > > Jason
On 2021-12-22 12:58 AM, David E. Box wrote: > Depends on "driver core: auxiliary bus: Add driver data helpers" patch [1]. > Applies the helpers to all auxiliary device drivers using > dev_(get/set)_drvdata. Drivers were found using the following search: > > grep -lr "struct auxiliary_device" $(grep -lr "drvdata" .) > > Changes were build tested using the following configs: > > vdpa/mlx5: CONFIG_MLX5_VDPA_NET > net/mlx53: CONFIG_MLX5_CORE_EN > soundwire/intel: CONFIG_SOUNDWIRE_INTEL > RDAM/irdma: CONFIG_INFINIBAND_IRDMA > CONFIG_MLX5_INFINIBAND > > [1] https://www.spinics.net/lists/platform-driver-x86/msg29940.html > > David E. Box (4): > RDMA/irdma: Use auxiliary_device driver data helpers > soundwire: intel: Use auxiliary_device driver data helpers > net/mlx5e: Use auxiliary_device driver data helpers > vdpa/mlx5: Use auxiliary_device driver data helpers > > drivers/infiniband/hw/irdma/main.c | 4 ++-- > drivers/infiniband/hw/mlx5/main.c | 8 ++++---- > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 8 ++++---- > drivers/soundwire/intel.c | 8 ++++---- > drivers/soundwire/intel_init.c | 2 +- > drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++-- > 6 files changed, 17 insertions(+), 17 deletions(-) Changes look good, I did post one question regarding possible occurrence of dev_get_drvdata() not being accounted for in patch: [PATCH 1/4] RDMA/irdma: Use auxiliary_device driver data helpers However, it does look like a blocker so: Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> For the record, I did scan the following files (users of struct auxiliary_device) from drivers/ directory for the missing occurrences and found only a single one (as mentioned earlier): drivers/net/ethernet/mellanox/mlx5/core/dev.c drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.c drivers/net/ethernet/mellanox/mlx5/core/sf/dev/driver.c drivers/net/ethernet/mellanox/mlx5/core/sf/dev/dev.h drivers/net/ethernet/mellanox/mlx5/core/en_rep.c drivers/net/ethernet/mellanox/mlx5/core/en_main.c drivers/net/ethernet/intel/i40e/i40e_client.c drivers/net/ethernet/intel/ice/ice.h drivers/net/ethernet/intel/ice/ice_idc.c drivers/infiniband/hw/irdma/main.c drivers/infiniband/hw/irdma/i40iw_if.c drivers/infiniband/hw/mlx5/main.c drivers/infiniband/hw/mlx5/ib_rep.c drivers/vdpa/mlx5/net/mlx5_vnet.c drivers/gpu/drm/bridge/ti-sn65dsi86.c drivers/soundwire/intel_init.c drivers/soundwire/intel.c Regards, Czarek
On Tue, Dec 21, 2021 at 04:48:17PM -0800, David E. Box wrote: > On Tue, 2021-12-21 at 20:09 -0400, Jason Gunthorpe wrote: > > On Tue, Dec 21, 2021 at 03:58:48PM -0800, David E. Box wrote: > > > Depends on "driver core: auxiliary bus: Add driver data helpers" patch [1]. > > > Applies the helpers to all auxiliary device drivers using > > > dev_(get/set)_drvdata. Drivers were found using the following search: > > > > > > grep -lr "struct auxiliary_device" $(grep -lr "drvdata" .) > > > > > > Changes were build tested using the following configs: > > > > > > vdpa/mlx5: CONFIG_MLX5_VDPA_NET > > > net/mlx53: CONFIG_MLX5_CORE_EN > > > soundwire/intel: CONFIG_SOUNDWIRE_INTEL > > > RDAM/irdma: CONFIG_INFINIBAND_IRDMA > > > CONFIG_MLX5_INFINIBAND > > > > > > [1] https://www.spinics.net/lists/platform-driver-x86/msg29940.html > > > > I have to say I don't really find this to be a big readability > > improvement. > > I should have referenced the thread [1] discussing the benefit of this change > since the question was asked and answered already. The idea is that drivers > shouldn't have to touch the device API directly if they are already using a > higher level core API (auxiliary bus) that can do that on its behalf. Driver writers should rarely use the auxilary device type directly, the should always immediately container_of it to their proper derived type. > > Also, what use is 'to_auxiliary_dev()' ? I didn't see any users added.. > > This was not added by that patch. It was added by the referenced patch, and seems totally pointless cut and paste, again because nothing should be using the auxiliary_device type for anything more than container_of'ing to their own type. We've been ripping out bus specific APIs in favour of generic ones (see the work on the DMA API for instance) so this whole concept seems regressive, particularly when applied to auxiliary bus which does not have an API of its own. Jason