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
| ||
|
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