From: Rob Herring <robh@kernel.org>
To: "Heiko Stübner" <heiko@sntech.de>,
"Jagan Teki" <jagan@amarulasolutions.com>
Cc: devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
Tom Cubie <tom@radxa.com>,
linux-kernel@vger.kernel.org,
Chanwoo Choi <cw00.choi@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
linux-amarula@amarulasolutions.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/3] extcon: Add Type-C Virtual PD
Date: Mon, 14 Sep 2020 17:15:33 -0600 [thread overview]
Message-ID: <20200914231533.GA429337@bogus> (raw)
In-Reply-To: <6955091.ERBjKZ0CLf@diego>
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
>
>
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: "Heiko Stübner" <heiko@sntech.de>,
"Jagan Teki" <jagan@amarulasolutions.com>
Cc: devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
Tom Cubie <tom@radxa.com>,
linux-kernel@vger.kernel.org,
Chanwoo Choi <cw00.choi@samsung.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
linux-amarula@amarulasolutions.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 0/3] extcon: Add Type-C Virtual PD
Date: Mon, 14 Sep 2020 17:15:33 -0600 [thread overview]
Message-ID: <20200914231533.GA429337@bogus> (raw)
In-Reply-To: <6955091.ERBjKZ0CLf@diego>
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
>
>
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: "Heiko Stübner" <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
Date: Mon, 14 Sep 2020 17:15:33 -0600 [thread overview]
Message-ID: <20200914231533.GA429337@bogus> (raw)
In-Reply-To: <6955091.ERBjKZ0CLf@diego>
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
>
>
>
>
next prev parent reply other threads:[~2020-09-14 23:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 19:18 [PATCH 0/3] extcon: Add Type-C Virtual PD Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` [PATCH 1/3] dt-bindings: extcon: Document Type-C Virtual PD driver Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` [PATCH 2/3] extcon: Add " Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` [PATCH 3/3] arm64: dts: rk3399-rock-pi-4c: Enable Display Port Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 19:18 ` Jagan Teki
2020-09-04 21:23 ` [PATCH 0/3] extcon: Add Type-C Virtual PD Heiko Stübner
2020-09-04 21:23 ` Heiko Stübner
2020-09-04 21:23 ` Heiko Stübner
2020-09-09 13:56 ` Jagan Teki
2020-09-09 13:56 ` Jagan Teki
2020-09-09 13:56 ` Jagan Teki
2020-09-14 23:15 ` Rob Herring [this message]
2020-09-14 23:15 ` Rob Herring
2020-09-14 23:15 ` Rob Herring
2020-09-15 1:17 ` Chanwoo Choi
2020-09-15 1:17 ` Chanwoo Choi
2020-09-15 1:17 ` Chanwoo Choi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200914231533.GA429337@bogus \
--to=robh@kernel.org \
--cc=cw00.choi@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jagan@amarulasolutions.com \
--cc=linux-amarula@amarulasolutions.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=myungjoo.ham@samsung.com \
--cc=tom@radxa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.