Hi Rob, On 9/15/20 8:15 AM, Rob Herring wrote: > On Fri, Sep 04, 2020 at 11:23:21PM +0200, Heiko Stübner wrote: >> Hi Jagan, >> >> Am Freitag, 4. September 2020, 21:18:27 CEST schrieb Jagan Teki: >>> USB Type-C protocol supports various modes of operations >>> includes PD, USB3, and Altmode. If the platform design >>> supports a Type-C connector then configuring these modes >>> can be done via enumeration. >>> >>> However, there are some platforms that design these modes >>> of operations as separate protocol connectors like design >>> Display Port from on-chip USB3 controller. So accessing >>> Type-C Altmode Display Port via onboard Display Port >>> connector instead of a Type-C connector. >>> >>> These kinds of platforms require an explicit extcon driver >>> in order to handle Power Delivery and Port Detection. >>> >>> This series support this Type-C Virtual PD and enable the >>> same in ROCK Pi 4C SBC. >>> >>> Any inputs? >> >> I tend to disagree on the design via an extcon. > > I don't accept new extcon bindings or users of it either. It's a > poorly thought out collection of Linux driver properties. Use the usb > connector binding. I agree the prior binding format of extcon with 'extcon' property name is not proper. So, I'll try to bind new style. But, I have a question. Do you have the objection of the use of extcon like 'users of it either' of your comment? > >> >> That the Rockchip rk3399 currently carries that extcon thingy is unfortunate >> and only works for ChromeOS devices based on the rk3399. >> >> The kernel now has a real type-c framework so we should not extend this >> extcon hack any further, because that will make it even harder to roll back >> later. Also simply because other Rockchip boards currently can't really make >> use of type-c due to this, as they use the fsusb302 phys directly connected. >> >> ChromeOS actually spend some time to make the cros-ec pd part of the type-c >> framework if I remember correctly, so a viable battle plan would be to: >> >> (1) move the Rockchip type-c phy driver to actually be part of the type-c >> framework, with the extcon being a deprecated fallback for old DTs. >> (2) implement your gpio-altmode as part of the type-c framework >> (which may even already exist) >> >> >> In short, please don't extend the rk3399 type-c extcon hack. >> >> Thanks >> Heiko >> >> >> >> > > -- Best Regards, Chanwoo Choi Samsung Electronics
