On 8/1/22 14:29, Daniil Lunev wrote:
Please change "can not / can be enabled" into "is not supported by the
host controller / is supported by the host controller".
That would be incorrect. The "caps" variable semantics is a bit weird
in the sense that it is used at times to convey "active"
capabilities, not just supported one. For example, for the
writebooster capability to be present in caps, first controller
driver should indicate it is ready to support it, then the part that
is attached to the host controller has to indicate support in the
device descriptor, then WB has to be configured and its lifetime
should not be exhausted. If any of those parameters are not
satisfied, the capability will be removed from the set despite
generally being supported. I am not sure how to properly word it, but
just saying "controller supports it" would be counter-factual
(especially since the controller doesn't really knows anything about
writebooster per-se, it is part's functionality). What would be
suggested wording in that case?
Given the above I think we can keep the current wording. This also makes
me wonder why the UFSHCD_CAP_WB_EN flag occurs in the hba->caps member
variable. That member variable is used to track controller capabilities.
My understanding is that the WriteBooster functionality is a UFS device
feature and also that no host controller support is required to control
the WriteBooster feature.
Thanks,
Bart.
