lkml.org 
[lkml]   [2019]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 1/5] dt-bindings: connector: add optional properties for Type-B
    From
    Date
    Hi,

    On 12-03-19 04:18, Chunfeng Yun wrote:
    > Hi,
    > On Mon, 2019-03-11 at 09:06 +0100, Hans de Goede wrote:
    >> 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,
    >>>>
    >>>> 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@mediatek.com>
    >>>>> ---
    >>>>> .../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 ?
    >>> Yes, it would be, PMIC is in charger of detecting the status of ID pin
    >>
    >> Ok, then I think this should be documented too.
    >>
    >>>> And in many cases there also is a mux to switch the datalines
    >>>> 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.
    >>> I'm not sure, the mux seems not belong to this connector,
    >>> 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.
    > In this patch series, I make usb_connector driver enable/disable Vbus,
    > but not the parent(USB controller) of usb_connector which registers a
    > usb-role-switch, which way do you think it is better?

    IMHO there should not be a driver for the usb_connector child-node,
    only for the parent-device of that child-node.

    There are going to be too many specific setups surrounding PMICs to
    be able to do a single generic driver for the connector.

    Regards,

    Hans

    \
     
     \ /
      Last update: 2019-03-12 13:46    [W:2.438 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site