linux-kernel - Re: [PATCH 0/3] extcon: Add Type-C Virtual PD

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200914231533.GA429337@bogus>
Date:   Mon, 14 Sep 2020 17:15:33 -0600
From:   Rob Herring <robh@...nel.org>
To:     Heiko Stübner <heiko@...ech.de>,
        Jagan Teki <jagan@...rulasolutions.com>
Cc:     MyungJoo Ham <myungjoo.ham@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Tom Cubie <tom@...xa.com>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-amarula@...rulasolutions.com
Subject: Re: [PATCH 0/3] extcon: Add Type-C Virtual PD

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