Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 14 Sep 2020 17:15:33 -0600
From:   Rob Herring <robh@kernel.org>
To:     Heiko =?iso-8859-1?Q?St=FCbner?= <heiko@sntech.de>,
        Jagan Teki <jagan@amarulasolutions.com>
Cc:     MyungJoo Ham <myungjoo.ham@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>,
        Tom Cubie <tom@radxa.com>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-amarula@amarulasolutions.com
Subject: Re: [PATCH 0/3] extcon: Add Type-C Virtual PD
Message-ID: <20200914231533.GA429337@bogus>
References: <20200904191830.387296-1-jagan@amarulasolutions.com>
 <6955091.ERBjKZ0CLf@diego>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6955091.ERBjKZ0CLf@diego>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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