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