Hi, On Thu, Oct 24, 2019 at 05:02:18PM +0800, Puma Hsu wrote: > Yes, generally this might be purely informational or be a dynamically > debuggable > mechanism for end user as I mentioned in previous discussion > thread(https://lkml.org/lkml/2019/10/22/198). > Could I know if it is not suitable that we expose a file for > informational usage? > > If everyone agreed above, about the definition of “unknown” and the condition > “don’t know the orientation”, what about adding additional return value? > 1. For original “unknown”, it is a generic unknown state which can > indicate no > matter connector is disconnected, cannot specify which cc side > is configured(such as Ra-Ra), > or even driver can not know the orientation. > 2. New additional value “unavailable”, it can be used to > specifically explicate that > driver can not know the orientation. > Take UCSI as example, it can use generic “unknown” or “unavailable” if > it wants. > But if it exposes “unavailable”, then application in user space can > know that this attribute is not useful. > > I summarize the proposal definition below: > - unknown (generic unknown. driver don’t or can’t know the polarity, > e.g. disconnected, both cc1 and cc2 are the same, ) > - normal (configured in cc1 side) > - reversed (configured in cc2 side) > - unavailable (not support the polarity detection) Now the attribute would be supplying two types of information: 1) Does the driver know the orientation 2) The current orientation Let's not do that! If you really need this, then just implement the ".is_visible" callback with it. You just need to add a flag to the struct typec_capability that tells does the driver know the orientation or not. Something like: unsigned int orientation_aware:1; We already "hide" the identity information if the underlying driver is unable to supply it. By making this attribute optional as well (by hiding it when it's not known), the style of exposing the information is kept the same throughout the class. thanks, -- heikki
