From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB3F5CA9EA0 for ; Fri, 18 Oct 2019 20:21:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A18A22082C for ; Fri, 18 Oct 2019 20:21:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="JYwPIRM+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437762AbfJRUVf (ORCPT ); Fri, 18 Oct 2019 16:21:35 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:37295 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726545AbfJRUVe (ORCPT ); Fri, 18 Oct 2019 16:21:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571430093; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XSbdbj+wXGSv6Xtgci7agv/N2COPVch8KltnfFcM01A=; b=JYwPIRM+Z0p9qsVvDoLUQT0xLnYUTfTqRa353fgvp3neLBRvphmIo7YpY5JMA+w6K0j9jE GOBcQ3nhxbx5IhEPYzi9V/0kx1rIqhknas/k/omndDZsA4+HUCmV/6rRM12bTRdNWK3SfC +NlE5wJfFPvqTMfXjo19Yd2m86H7+Bk= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-138-ieCTBD3XOvizW_cHsuZanQ-1; Fri, 18 Oct 2019 16:21:31 -0400 Received: by mail-wr1-f72.google.com with SMTP id p8so3204511wrj.8 for ; Fri, 18 Oct 2019 13:21:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6u6vJO+zIbtOKQSr5a8/ZaiKiRenOVbT3zCNikSDSSg=; b=WxXvYDQL4KRGYDB9VuMWzuuYcZ6UaKbCOBQaVXUoMToY7xW9gd4opXAc1/j3MTXhpW p6fz91kXVtV2y7oOCJ5KmW8viN2vO8PeI8N7LN07NKx5HiHqUmHnMl2XODxjAXzOjXcA +lp3aSo01msjcEB6sN973/0yPAUYVL4Zo4Vc+Y7tu+73m0AqHzhcvC9Q3xqKOGhFdxgz ko9IcNAIt0sPYShhxfhXNs4/KtjP1cEFNfKri4hH0Ytk64UobK+X6K6zezpDfY6RQShi e67NM7/GNHg/YktWp3PZe7BHyEzdGdT5oHh4heWjKvUJq2KXqqigFBa4DkXO8u2DUAJo +ZwQ== X-Gm-Message-State: APjAAAWqMP1Ks8U8VaRG5KJSWwcckvUtF8/zpdRDhQHFLctgSQyfP4rq Fx9IPW7NWIxBJ/NIgjFAROaIY4/LAl3qQ+Be24frTaIYq05i8bifxiivP6sRq4JHKavC2Ep/50Z AKaYyuiT+yWiNgRrV1mfJdA== X-Received: by 2002:a05:600c:490:: with SMTP id d16mr9074962wme.131.1571430090125; Fri, 18 Oct 2019 13:21:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqyCCcieYMEnaT1Hycj8RUPMk9oRpKyXHixT+kFXUt3/2glO8P/PUCAbl0452Azbls+mfm+5Sw== X-Received: by 2002:a05:600c:490:: with SMTP id d16mr9074940wme.131.1571430089848; Fri, 18 Oct 2019 13:21:29 -0700 (PDT) Received: from shalem.localdomain (2001-1c00-0c14-2800-ec23-a060-24d5-2453.cable.dynamic.v6.ziggo.nl. [2001:1c00:c14:2800:ec23:a060:24d5:2453]) by smtp.gmail.com with ESMTPSA id t13sm7910568wra.70.2019.10.18.13.21.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Oct 2019 13:21:29 -0700 (PDT) Subject: Re: [RFC][PATCH 2/3] usb: roles: Add usb role switch notifier. To: John Stultz Cc: lkml , Yu Chen , Greg Kroah-Hartman , Rob Herring , Mark Rutland , Heikki Krogerus , Suzuki K Poulose , Chunfeng Yun , Felipe Balbi , Andy Shevchenko , Jun Li , Valentin Schneider , Linux USB List , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" References: <20191002231617.3670-1-john.stultz@linaro.org> <20191002231617.3670-3-john.stultz@linaro.org> <2e369349-41f6-bd15-2829-fa886f209b39@redhat.com> <648e2943-42f5-e07d-5bb4-f6fd8b38b726@redhat.com> <7877d69b-b17c-d4a4-9806-3dca98fc9e26@redhat.com> <7ea7824f-abc2-4cf6-720a-3668b6286781@redhat.com> From: Hans de Goede Message-ID: Date: Fri, 18 Oct 2019 22:21:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-MC-Unique: ieCTBD3XOvizW_cHsuZanQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi, On 18-10-2019 22:12, John Stultz wrote: > On Fri, Oct 18, 2019 at 12:59 PM Hans de Goede wrot= e: >> On 18-10-2019 21:53, John Stultz wrote: >>> On Fri, Oct 18, 2019 at 12:30 PM Hans de Goede wr= ote: >>>> Looking at drivers/usb/typec/tcpm/tcpci.c: tcpci_set_vconn I see that >>>> there is a data struct with vendor specific callbacks and that the >>>> drivers/usb/typec/tcpm/tcpci_rt1711h.c implements that. >>>> >>>> So you may want something similar here. But things are tricky here, >>>> because when nothing is connected you want to provide Vbus for >>>> the USB-A ports, which means that if someone then connects a >>>> USB-A to C cable to connect the board to a PC (switching the port >>>> to device mode) there will be a time when both sides are supplying >>>> 5V if I remember the schedule correctly. >>> >>> Ok. Thanks for the pointer, I'll take a look at that to see if I can >>> get it to work. >>> >>>> I think that the original hack might not be that bad, the whole hw >>>> design seems so, erm, broken, that you probably cannot do proper >>>> roleswapping anyways. So just tying Vbus to host mode might be >>>> fine, the question then becomes again how can some other piece >>>> of code listen to the role-switch events... >>> >>> So, at least in the current approach (see the v3 series), I've >>> basically set the hub driver as an role-switch intermediary, sitting >>> between the calls from the tcpm to the dwc3 driver. It actually works >>> better then the earlier notifier method (which had some issues with >>> reliably establishing the initial state on boot). Does that approach >>> work for you? >> >> That sounds like it might be a nice solution. But I have not seen the >> code, I think I was not Cc-ed on v3. Do you have a patchwork or >> lore.kernel.org link for me? >=20 > Oh! I think I had you on CC, maybe it got caught in your spam folder? More likely I just deleted mail to aggressively, sorry. > My apologies either way! The thread is here: > https://lore.kernel.org/lkml/20191016033340.1288-1-john.stultz@linaro.= org/ >=20 > And the hub/role-switch-intermediary driver is here: > https://lore.kernel.org/lkml/20191016033340.1288-12-john.stultz@linaro= .org/ Hm, this looks very nice actually, much much better then the notifier stuff= ! As for your: "NOTE: It was noted that controlling the TYPEC_VBUS_POWER_OFF and TYPEC_VBUS_POWER_ON values here is not reccomended. I'm looking for a way to remove that bit from the logic here, but wanted to still get feedback on this approach." Comment in the commit message, normally a type-c port would turn external V= bus off until a sink is connected, IIRC the same Vbus is also used for the Tupe= A ports on the hub, so that would mean those are unusable when nothing is connected= to the TypeC port, which is not what you want. So I think that given the special case / hack-ish hw you have, that just se= tting Vbus based on the role is ok(ish). Regards, Hans