linux-kernel - Re: [PATCH V2] usb: typec: Add sysfs node to show connector orientation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191024120346.GC15396@kuha.fi.intel.com>
Date:   Thu, 24 Oct 2019 15:06:28 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Puma Hsu <pumahsu@...gle.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        Kyle Tso <kyletso@...gle.com>,
        Albert Wang <albertccwang@...gle.com>,
        Chien Kun Niu <rickyniu@...gle.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] usb: typec: Add sysfs node to show connector
 orientation

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