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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 CEFABC433B4 for ; Tue, 6 Apr 2021 14:43:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9E79661262 for ; Tue, 6 Apr 2021 14:43:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345273AbhDFOnO (ORCPT ); Tue, 6 Apr 2021 10:43:14 -0400 Received: from vps.xff.cz ([195.181.215.36]:47206 "EHLO vps.xff.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345263AbhDFOnO (ORCPT ); Tue, 6 Apr 2021 10:43:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megous.com; s=mail; t=1617720185; bh=yfn/2Ls2uZcier/kQtma6DwvPfmcADTWwB6MXMslfV8=; h=Date:From:To:Cc:Subject:X-My-GPG-KeyId:References:From; b=mVp0tVUUyb64KaQajTBwe8gR/Fkxq1TKrg5TXyaXPVxRpMInsYEeoS/orGGE7utkh Zz4WmqjDNDzSv2XGqzRTZbf0ohqSKODpJwhsd7xhYeHY/q6JPu5Cv4gGgfL2nfrUbJ FwmQDMj6wTQMPLrA9YVmfb0Jc6oWA99Rp8eNLryI= Date: Tue, 6 Apr 2021 16:43:04 +0200 From: =?utf-8?Q?Ond=C5=99ej?= Jirman To: Dafna Hirschfeld Cc: Laurent Pinchart , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, a.hajda@samsung.com, narmstrong@baylibre.com, jonas@kwiboo.se, jernej.skrabec@siol.net, airlied@linux.ie, daniel@ffwll.ch, chunkuang.hu@kernel.org, p.zabel@pengutronix.de, enric.balletbo@collabora.com, drinkcat@chromium.org, hsinyi@chromium.org, kernel@collabora.com, dafna3@gmail.com, robh+dt@kernel.org Subject: Re: [PATCH v5 1/2] dt-bindings: usb: add analogix,anx7688.yaml Message-ID: <20210406144304.u2flatne2bxn5t3g@core> X-My-GPG-KeyId: EBFBDDE11FB918D44D1F56C1F9F0A873BE9777ED References: <20210305124351.15079-1-dafna.hirschfeld@collabora.com> <20210305124351.15079-2-dafna.hirschfeld@collabora.com> <35f505ee-d939-4b42-490b-321b961bdec3@collabora.com> <20210305172437.meu45ol7d4c3w2lr@core.my.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, Mar 31, 2021 at 07:16:40PM +0200, Dafna Hirschfeld wrote: > Hi, > > On 05.03.21 18:24, Ondřej Jirman wrote: > > Hello Dafna, > > [...] > > > > > + vconn-en1-gpios: > > > > > + description: Controls the VCONN switch on the CC1 pin. > > > > > + maxItems: 1 > > > > > + > > > > > + vconn-en2-gpios: > > > > > + description: Controls the VCONN switch on the CC2 pin. > > > > > + maxItems: 1 > > > > VCONN is a voltage regulator that can be enabled either on CC1 or CC2 > > pin, or disabled completely. This control is *partially* performed in reference > > design directly by the OCM. OCM only decides which CC pin to switch > > the VCONN regulator to, and informs the SoC when the base VCONN regulator > > for the switches needs to be enabled. > > > > So vconn-en1/2 gpios are irrelevant to the driver, but the driver needs > > to control VCONN power supply somehow and defer control over it to the OCM. > > > > I don't know how to express it in the bindings. Maybe a vconn-supply here > > on the anx7688 node? > > > > It may also be part of the usb-connector binding, but this is really when it > > comes to anx7688 a parent regulator for the switches, and switches are not > > controlled by this driver, just their parent regulator is. > > > > Any ideas? > > Looking at the diagram in the schematics, I see that both vbus-supply and vconn-supply > come directly from the PMIC so similarly to the vbus-supply, the vconn-supply > can be part of the usb-connector. Then a driver can access the vconn-supply from the remote usb > connector. Is there a problem with that? No problem with that. usb-c-connector binding would just have to be extended. I just don't see any need for these `vconn-en*-gpios`, because the control is performed directly by the OCM firmware via GPIOs in the ANX7688 chip, outside of the control of the Linux driver, and the driver doesn't even care about the status of these pins. And if it will ever care, the status can be read via I2C from the ANX7688 chip directly. kind regards, o. > Thanks a lot for the review, I am not very familiar with usb and type-c, so your review helps a lot. > I will send v6 soon. > > Thanks, > Dafna