Messages in this thread | | | Date | Mon, 1 Aug 2022 14:42:57 -0700 | Subject | Re: [PATCH v4] ufs: core: print UFSHCD capabilities in controller's sysfs node | From | Bart Van Assche <> |
| |
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.
| |