> On 5/14/24 15:07, Avri Altman wrote: > > Bart Van Assche wrote: > >> My understanding is that the above check won't work as intended if > >> ufshcd_rtt_set() does not modify the RTT value. Wouldn't it be better > >> to add a boolean in struct ufs_hba that indicates whether or not > >> ufshcd_rtt_set() has been called before? > > > > My intension was to not override RTT should it was written, e.g. from user > space. > > As this attribute is persistent. > > How can RTT be written from user space? There is no sysfs attribute for > configuring the RTT value. If the above refers to a mechanism that bypasses the > UFSHCI kernel driver: I don't think that we should preserve any configuration > changes applied this way. As an example, the SCSI core does not care about > configuration changes applied via the SG interface. Via ufs-utils - https://github.com/westerndigitalcorporation/ufs-utils You may remember - this is why we needed the ufs-bsg interface we added few years ago. Ufs-utils is the industry standard with respect of configuring and provisioning ufs devices, And currently is being used by the vast majority of ufs stake-holders: device manufacturers, platform manufacturers, mobile vendors, etc. > > Additionally, what does "persistent" mean in this context? See Table 14.27 JEDEC Standard No. 220F page 443 — Attributes access properties: Persistent (Write) - The attribute can be written multiple times, the value is kept after power cycle or any type of reset event. Thanks, Avri > > Thanks, > > Bart.
