[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DM6PR04MB657562B04C1394FF8FC1D9A3FCEC2@DM6PR04MB6575.namprd04.prod.outlook.com>
Date: Wed, 15 May 2024 04:56:39 +0000
From: Avri Altman <Avri.Altman@....com>
To: Bart Van Assche <bvanassche@....org>, "Martin K . Petersen"
<martin.petersen@...cle.com>
CC: Bean Huo <beanhuo@...ron.com>, Peter Wang <peter.wang@...iatek.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] scsi: ufs: Allow RTT negotiation
> 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.
Powered by blists - more mailing lists