Allows userspace to check if Clock Scaling and Write Booster are
supported.
Signed-off-by: Daniil Lunev <[email protected]>
---
Changes in v5:
* Correct wording for clock scaling.
* Correct wording for the commit message.
Changes in v4:
* Dropped crypto node per Eric Biggers mentioning it can be queried from
disk's queue node
Changes in v3:
* Expose each capability individually.
* Update documentation to represent new scheme.
Changes in v2:
* Add documentation entry for the new sysfs node.
Documentation/ABI/testing/sysfs-driver-ufs | 26 ++++++++++++++++++
drivers/ufs/core/ufs-sysfs.c | 31 ++++++++++++++++++++++
2 files changed, 57 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs
index 6b248abb1bd71..1750a9b84ce0f 100644
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@@ -1591,6 +1591,32 @@ Description: This entry shows the status of HPB.
The file is read only.
+What: /sys/bus/platform/drivers/ufshcd/*/capabilities/clock_scaling
+What: /sys/bus/platform/devices/*.ufs/capabilities/clock_scaling
+Date: July 2022
+Contact: Daniil Lunev <[email protected]>
+Description: Indicates status of clock scaling.
+
+ == ============================
+ 0 Clock scaling is not supported.
+ 1 Clock scaling is supported.
+ == ============================
+
+ The file is read only.
+
+What: /sys/bus/platform/drivers/ufshcd/*/capabilities/write_booster
+What: /sys/bus/platform/devices/*.ufs/capabilities/write_booster
+Date: July 2022
+Contact: Daniil Lunev <[email protected]>
+Description: Indicates status of Write Booster.
+
+ == ============================
+ 0 Write Booster can not be enabled.
+ 1 Write Booster can be enabled.
+ == ============================
+
+ The file is read only.
+
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
Date: February 2021
Contact: Avri Altman <[email protected]>
diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
index 0a088b47d5570..5c53349337dd8 100644
--- a/drivers/ufs/core/ufs-sysfs.c
+++ b/drivers/ufs/core/ufs-sysfs.c
@@ -279,6 +279,36 @@ static const struct attribute_group ufs_sysfs_default_group = {
.attrs = ufs_sysfs_ufshcd_attrs,
};
+static ssize_t clock_scaling_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+
+ return sysfs_emit(buf, "%d\n", ufshcd_is_clkscaling_supported(hba));
+}
+
+static ssize_t write_booster_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct ufs_hba *hba = dev_get_drvdata(dev);
+
+ return sysfs_emit(buf, "%d\n", ufshcd_is_wb_allowed(hba));
+}
+
+static DEVICE_ATTR_RO(clock_scaling);
+static DEVICE_ATTR_RO(write_booster);
+
+static struct attribute *ufs_sysfs_capabilities_attrs[] = {
+ &dev_attr_clock_scaling.attr,
+ &dev_attr_write_booster.attr,
+ NULL
+};
+
+static const struct attribute_group ufs_sysfs_capabilities_group = {
+ .name = "capabilities",
+ .attrs = ufs_sysfs_capabilities_attrs,
+};
+
static ssize_t monitor_enable_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1134,6 +1164,7 @@ static const struct attribute_group ufs_sysfs_attributes_group = {
static const struct attribute_group *ufs_sysfs_groups[] = {
&ufs_sysfs_default_group,
+ &ufs_sysfs_capabilities_group,
&ufs_sysfs_monitor_group,
&ufs_sysfs_device_descriptor_group,
&ufs_sysfs_interconnect_descriptor_group,
--
2.31.0
On 8/1/22 17:37, Daniil Lunev wrote:
> +What: /sys/bus/platform/drivers/ufshcd/*/capabilities/write_booster
> +What: /sys/bus/platform/devices/*.ufs/capabilities/write_booster
> +Date: July 2022
> +Contact: Daniil Lunev <[email protected]>
> +Description: Indicates status of Write Booster.
> +
> + == ============================
> + 0 Write Booster can not be enabled.
> + 1 Write Booster can be enabled.
> + == ============================
> +
> + The file is read only.
Is the "capabilities" directory a directory with capabilities of the
host, with capabilities of the UFS device or perhaps with capabilities
of both?
Thanks,
Bart.
> Is the "capabilities" directory a directory with capabilities of the
> host, with capabilities of the UFS device or perhaps with capabilities
> of both?
I would say effective capabilities of the controller-device pair, from the
semantic that hba->caps field presents. Do you want me to mention it
anywhere?
Thanks,
Daniil
On 8/1/22 20:20, Daniil Lunev wrote:
>> Is the "capabilities" directory a directory with capabilities of the
>> host, with capabilities of the UFS device or perhaps with capabilities
>> of both?
>
> I would say effective capabilities of the controller-device pair, from the
> semantic that hba->caps field presents. Do you want me to mention it
> anywhere?
Calling this the effective capabilities of the controller-device pair
sounds good to me. But please do not refer to hba->caps. I'd like to
rework hba->caps such that it only includes controller capabilities and
no information related to the WriteBooster. Additionally, several UFS
device capabilities that may be exported in the future are not
represented in hba->caps.
Thanks,
Bart.
> Calling this the effective capabilities of the controller-device pair
> sounds good to me. But please do not refer to hba->caps. I'd like to
> rework hba->caps such that it only includes controller capabilities and
> no information related to the WriteBooster. Additionally, several UFS
> device capabilities that may be exported in the future are not
> represented in hba->caps.
So can you clarify where specifically do you want me to mention that?
Should I name the directory "effective_capabilities" or the commit
message?
Thanks,
--Daniil
On 8/1/22 21:12, Daniil Lunev wrote:
>> Calling this the effective capabilities of the controller-device pair
>> sounds good to me. But please do not refer to hba->caps. I'd like to
>> rework hba->caps such that it only includes controller capabilities and
>> no information related to the WriteBooster. Additionally, several UFS
>> device capabilities that may be exported in the future are not
>> represented in hba->caps.
>
> So can you clarify where specifically do you want me to mention that?
> Should I name the directory "effective_capabilities" or the commit
> message?
I'm fine with the name "capabilities" since "effective_capabilities" is
a bit long.
How about adding the above explanation in the source code close to the
definition of the capabilities group since it is more likely that it
will be noticed there by software developers compared to Documentation/ABI/?
Thanks,
Bart.