Re: [PATCH v8 2/7] scsi: libsas: Define NCQ Priority sysfs attributes for SATA devices

[Damien Le Moal]

On 3/26/24 18:53, Geert Uytterhoeven wrote:
> Hi Igor,
> 
> On Thu, Mar 7, 2024 at 10:55 PM Igor Pylypiv <ipylypiv@xxxxxxxxxx> wrote:
>> Libata sysfs attributes cannot be used for libsas managed SATA devices
>> because the ata_port location is different for libsas.
>>
>> Defined sysfs attributes (visible for SATA devices only):
>> - /sys/block/sda/device/ncq_prio_enable
>> - /sys/block/sda/device/ncq_prio_supported
>>
>> The newly defined attributes will pass the correct ata_port to libata
>> helper functions.
>>
>> Reviewed-by: John Garry <john.g.garry@xxxxxxxxxx>
>> Reviewed-by: Damien Le Moal <dlemoal@xxxxxxxxxx>
>> Reviewed-by: Jason Yan <yanaijie@xxxxxxxxxx>
>> Signed-off-by: Igor Pylypiv <ipylypiv@xxxxxxxxxx>
> 
> Thanks for your patch, which is now commit b4d3ddd2df7531e3 ("scsi:
> libsas: Define NCQ Priority sysfs attributes for SATA devices")
> in scsi-mkp/for-next
> 
>> --- a/drivers/scsi/libsas/sas_ata.c
>> +++ b/drivers/scsi/libsas/sas_ata.c
> 
>> +
>> +DEVICE_ATTR(ncq_prio_supported, S_IRUGO, sas_ncq_prio_supported_show, NULL);
>> +
> 
> [...]
> 
>> +
>> +DEVICE_ATTR(ncq_prio_enable, S_IRUGO | S_IWUSR,
>> +           sas_ncq_prio_enable_show, sas_ncq_prio_enable_store);
>> +
> 
> When both CONFIG_SCSI_SAS_ATA and CONFIG_SATA_HOST are enabled:
> 
> aarch64-linux-gnu-ld: drivers/ata/libata-sata.o:(.data+0x110):
> multiple definition of `dev_attr_ncq_prio_supported';
> drivers/scsi/libsas/sas_ata.o:(.data+0x260): first defined here
> aarch64-linux-gnu-ld: drivers/ata/libata-sata.o:(.data+0xd8): multiple
> definition of `dev_attr_ncq_prio_enable';
> drivers/scsi/libsas/sas_ata.o:(.data+0x228): first defined here
> 
> Making both new DEVICE_ATTR() declarations static doesn't work,
> as <linux/libata.h> contains a forward declaration for the existing global
> dev_attr_ncq_prio_supported in libata:
> 
> In file included from include/linux/async.h:14,
>                  from drivers/scsi/libsas/sas_ata.c:12:
> include/linux/device.h:156:33: error: static declaration of
> ‘dev_attr_ncq_prio_supported’ follows non-static declaration
>   156 |         struct device_attribute dev_attr_##_name =
> __ATTR(_name, _mode, _show, _store)
>       |                                 ^~~~~~~~~
> drivers/scsi/libsas/sas_ata.c:984:8: note: in expansion of macro ‘DEVICE_ATTR’
>   984 | static DEVICE_ATTR(ncq_prio_supported, S_IRUGO,
> sas_ncq_prio_supported_show,
>       |        ^~~~~~~~~~~
> In file included from include/scsi/sas_ata.h:13,
>                  from drivers/scsi/libsas/sas_ata.c:15:
> include/linux/libata.h:508:32: note: previous declaration of
> ‘dev_attr_ncq_prio_supported’ with type ‘struct device_attribute’
>   508 | extern struct device_attribute dev_attr_ncq_prio_supported;
>       |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from include/linux/async.h:14,
>                  from drivers/scsi/libsas/sas_ata.c:12:
> include/linux/device.h:156:33: error: static declaration of
> ‘dev_attr_ncq_prio_enable’ follows non-static declaration
>   156 |         struct device_attribute dev_attr_##_name =
> __ATTR(_name, _mode, _show, _store)
>       |                                 ^~~~~~~~~
> drivers/scsi/libsas/sas_ata.c:1023:8: note: in expansion of macro ‘DEVICE_ATTR’
>  1023 | static DEVICE_ATTR(ncq_prio_enable, S_IRUGO | S_IWUSR,
>       |        ^~~~~~~~~~~
> In file included from include/scsi/sas_ata.h:13,
>                  from drivers/scsi/libsas/sas_ata.c:15:
> include/linux/libata.h:509:32: note: previous declaration of
> ‘dev_attr_ncq_prio_enable’ with type ‘struct device_attribute’
>   509 | extern struct device_attribute dev_attr_ncq_prio_enable;
>       |                                ^~~~~~~~~~~~~~~~~~~~~~~~
> 
> Perhaps the new attributes can be renamed?
> Alternatively, the DEVICE_ATTR() can be open-coded, so the actual
> device_attribute structures are named differently.

I think we need to do that because I do not want the attribute name to change in
sysfs as that creates hell for the user to control a feature that is identical
beside the different transport (which the user should not care about).
I will send something asap.

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

-- 
Damien Le Moal
Western Digital Research