Hi,
On 11-03-19 06:33, Chunfeng Yun wrote:
Hi,
On Fri, 2019-03-08 at 13:07 +0100, Hans de Goede wrote:
Hi,Yes, it would be, PMIC is in charger of detecting the status of ID pin
On 08-03-19 07:13, Chunfeng Yun wrote:
Add id-gpios, vbus-gpios, vbus-supply and pinctrl properties for
usb-b-connector
Signed-off-by: Chunfeng Yun <chunfeng.yun@xxxxxxxxxxxx>
---
ÂÂ .../devicetree/bindings/connector/usb-connector.txtÂÂÂ | 10 ++++++++++
ÂÂ 1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt b/Documentation/devicetree/bindings/connector/usb-connector.txt
index a9a2f2fc44f2..7a07b0f4f973 100644
--- a/Documentation/devicetree/bindings/connector/usb-connector.txt
+++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
@@ -17,6 +17,16 @@ Optional properties:
ÂÂ - self-powered: Set this property if the usb device that has its own power
ÂÂÂÂ source.
+Optional properties for usb-b-connector:
+- id-gpios: gpio for USB ID pin.
What about boards where the ID pin is *not* connected to a GPIO,
but e.g. to a special pin on the PMIC which can also detect
an ACA adapter ? Currently this case is handled by extcon
drivers, but we have no way to set e.g. vbus-supply for the
connector. Maybe in this case the usb-connector node should
be a child of the PMIC node ?
Ok, then I think this should be documented too.
And in many cases there also is a mux to switch the datalinesI'm not sure, the mux seems not belong to this connector,
between the host and device(gadget) controllers, how should
that be described in this model? See the new usb-role-switch
code under drivers/usb/roles
In some cases the mux is controlled through a gpio, so we
may want to add a "mux-gpios" here in which case we also
need to define what 0/1 means.
and may need another driver to register usb-role-switch,
similar to:
[v2,2/2] usb: typec: add typec switch via GPIO control
https://patchwork.kernel.org/patch/10834327/
Right the mux/role-switch will need a driver, but the "owner"
of the usb_connector, e.g. the PMIC or the owner of the
id GPIO pin needs to know which device is the role-switch so
that it can set the role correctly based on the id-pin.
Your binding already contains Vbus info, allowing the owner
of the usb_connector to enable/disable Vbus based on the id-pin,
but the owner will also be responsible for setting the role-switch.
Note we cannot simply assume there will be only one role-switch,
we really need some link from the usb_connector to the role-switch
(or if it is a GPIO driven role-switch simply a role-switch-gpios
member in the usb_connector).