From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Puma Hsu <pumahsu@google.com>
Cc: Guenter Roeck <linux@roeck-us.net>,
Greg KH <gregkh@linuxfoundation.org>,
Badhri Jagan Sridharan <badhri@google.com>,
Kyle Tso <kyletso@google.com>,
Albert Wang <albertccwang@google.com>,
Chien Kun Niu <rickyniu@google.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V2] usb: typec: Add sysfs node to show connector orientation
Date: Thu, 24 Oct 2019 15:06:28 +0300 [thread overview]
Message-ID: <20191024120346.GC15396@kuha.fi.intel.com> (raw)
In-Reply-To: <CAGCq0LZGz04JCTEJXrBqs4ENybQih6zKWTacq9T9DKPNOQAfMw@mail.gmail.com>
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
next prev parent reply other threads:[~2019-10-24 12:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-22 8:59 [PATCH V2] usb: typec: Add sysfs node to show connector orientation Puma Hsu
2019-10-22 17:27 ` Greg KH
2019-10-23 3:26 ` Puma Hsu
2019-10-23 8:32 ` Heikki Krogerus
2019-10-23 13:44 ` Guenter Roeck
2019-10-23 13:53 ` Puma Hsu
2019-10-23 14:29 ` Heikki Krogerus
2019-10-23 15:01 ` Guenter Roeck
2019-10-23 15:57 ` Heikki Krogerus
2019-10-24 9:02 ` Puma Hsu
2019-10-24 12:06 ` Heikki Krogerus [this message]
2019-10-25 6:46 ` Puma Hsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191024120346.GC15396@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=albertccwang@google.com \
--cc=badhri@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=kyletso@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=pumahsu@google.com \
--cc=rickyniu@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox