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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:	Tue, 28 Jun 2016 19:08:17 -0700
From:	Guenter Roeck <groeck@...gle.com>
To:	cw00.choi@...sung.com
Cc:	Chris Zhong <zyw@...k-chips.com>,
	Douglas Anderson <dianders@...omium.org>,
	Tomasz Figa <tfiga@...omium.org>,
	Heiko Stübner <heiko@...ech.de>,
	姚智情 <yzq@...k-chips.com>,
	Guenter Roeck <groeck@...omium.org>,
	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [v3 PATCH 1/5] extcon: Add Type-C and DP support

On Tue, Jun 28, 2016 at 6:40 PM, Chanwoo Choi <cwchoi00@...il.com> wrote:
> Hi Guenter,
>
> 2016년 6월 29일 수요일, Guenter Roeck<groeck@...gle.com>님이 작성한 메시지:
>>
>> On Tue, Jun 28, 2016 at 5:26 AM, Chanwoo Choi <cwchoi00@...il.com> wrote:
>> > Hi Chris,
>> >
>> > I agree to add the new EXTCON_DISP_DP connector.
>> > But, other new definition should be discussed.
>> > - EXTCON_DISP_DP_ALT
>> > - EXTCON_TYPEC_POLARITY
>> > - EXTCON_TYPEC_PIN_ASSIGN
>> >
>> > I think that TYPEC_POLARITY and TYPEC_PIN_ASSING are not appropriate
>> > as the new external connector definition. These are the property or
>> > attribute of
>> > USB connector with C-type.
>> >
>> > Also, EXTCON_DISP_DP_ALT is not a new type of connector.
>> > It is just one of the mode for DP connector.
>> >
>> > As I knew, DP alternative mode use the USB connector with C-type.
>> > So, DP alternative mode can be expressed on following:
>> >  = EXTCON_DISP_DP + EXTCON_USB + some property of USB c-type
>> >
>>
>> Problem is that extcon doesn't support exchanging cable properties
>> between cable providers (extcon drivers) and consumers, other than
>> cable states. In order to exchange properties such as polarity and pin
>> assignments, we would need a separate infrastructure. But then the
>> question would be why to use extcon in the first place.
>>
>> If you have a solution for that puzzle, please let us know.
>>
>
> You're right.
> Current extcon don't support the cable properties.
> The requirement about cables properties occur such as USB ID and VBUS pin.
> So, I'll support the cable properties in extcon framework and send the
> patches within this week.
>
> Maybe, the function definitions are following:
> (But, these may be changed on real patches)
> - extcon_set_cable_property(struct extcon_dev *edev, unsigned int id, enum
> extcon_property prop, unsigned in prop_val)
> - extcon_get_cable_property(struct extcon_dev *edev, unsigned int id, enum
> extcon_property prop)
>

Excellent idea. Couple of thoughts:

- We might need notifiers for property events. Not sure if the state
notifiers are sufficient (properties might change independently of
state). Or maybe state events could be used if a cable property (but
not the state) changes ?

- It might possibly make sense to make the prop argument opaque (such
as u32). Properties would still be defined in extcon (such as
EXTCON_PROP_TYPEC_POLARITY), but this would leave more room for cable
type specific properties. After all, the properties would be cable
type specific.

Thanks,
Guenter

Powered by blists - more mailing lists