Received: by 2002:a05:6a10:6d25:0:0:0:0 with SMTP id gq37csp2045284pxb; Mon, 13 Sep 2021 10:43:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlLIv1dpICLH8ckmOB9RYccg2Sa6qq3KR/IcY3Tg/fI+mrZ72rC5qXIbJ/ZEUogykoBIwI X-Received: by 2002:a50:ee8b:: with SMTP id f11mr14473718edr.112.1631554993855; Mon, 13 Sep 2021 10:43:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631554993; cv=none; d=google.com; s=arc-20160816; b=qTlm34dXPuX6+ug5vc5R2SKkhvL1B9IFZ7GfZejOsuzsR8GN7VN6vsxH+R9h++jkSO 951/gXuoJm4+zH/WLZlgR/mqK7ueRs4flVKavcSk4nhVuqBSOGfsFaUFrFXyGlqIr4Rd Q3bFs3xuQGbcpy6qWgFnbmvmMe2JOc5mC/DLPEok1aX+bPwdTI+H04fZri8wv9ZXWxHF RgYHimHKzrR+oi5CiD2uCGPtktijqhKoP7/2gIjnyN3brXGQvax9l2HxPY3bneF8V8Xx /EzAcjmMUmNgZeLBPn33k6KWceG1NuwGnH9OnU3YnHzzu4XLVOZkrB2UEF3iHmDqnkW4 x03A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=3HEy5QOgGPe7wcN+0QN1kQCAYQBdydFgWiZKsBhUq28=; b=XrfiWZipp7QYKLpZ8tS2j7VN1+B77Y/6mXFyRvtKUWV6F+gTUM05iLK/LI7ilO4Gqi zIZFyKspJvGmRO70jmkCCcSIFcwHA3rOym/vFS49DlXRZTkF/S2r5w7z32c6fFLS8nz5 WeZQQmSHadI/V9Bq9VTBrIkL6SjoOHjn1o826e3NWlkhS/R3phU9VwhecDt569VithcE Ff+380hwG4YOEfnhMXLDSNY4QdGA9x8iP1g+OMC9J7kMDnYeFKXVEYTfwsevfcIJv1Yf l4SuUKUXSvARcjaqLyRLoE8GI/2HqnBux1dGx/xTE+fPnYXABZ/UY09Qn2n3pwqGmhlH hwsA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=CGOa3+4G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i5si7728979ejd.224.2021.09.13.10.42.49; Mon, 13 Sep 2021 10:43:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=CGOa3+4G; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243832AbhIMRmc (ORCPT + 99 others); Mon, 13 Sep 2021 13:42:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245731AbhIMRmV (ORCPT ); Mon, 13 Sep 2021 13:42:21 -0400 Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40993C06178A for ; Mon, 13 Sep 2021 10:40:16 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id g14so9559501pfm.1 for ; Mon, 13 Sep 2021 10:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=3HEy5QOgGPe7wcN+0QN1kQCAYQBdydFgWiZKsBhUq28=; b=CGOa3+4GGEptXc5PuDypeXAJI1wCrXyFgv1bZ7SzsR2e0wRoJ+lRY43NE5RFGIONdU P2uH+Aoqmj5+JsSEcVIHiFpbMrN8dKJI9TwDjXsP8avbRxg0Lte9Yh3JzGGqZpWh/Vo5 SiZyjWUC4YUkKqDwN6hcH+axujIJpevQ0800RHChLornVsanxXmQYz2qiyOEFxwp20Ip dqkfgcitS22ja77/SLdJRimQnrQBAhNYTqALRVgxqQA6CWVd8NDt69OYMjDXc8xWdNZI ScyKGl06XeZHUDAErsIDgN/8hYTejuzv9Dv6kTMwfFvQgM5Pi1mXIhbjRN5/5Z2euwJE Sq/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=3HEy5QOgGPe7wcN+0QN1kQCAYQBdydFgWiZKsBhUq28=; b=pHhtCJ1i6WIG0LWd9eQJPZRtvnl1VfMneiC9HrkAhSt/qiLS4X8OgJ7nsdGZ0lyzQU bEA8H6Q4zS9BIYDIcHNPvSf+73yRnkq7jDLjUUMYu+VhJ62M7+igg6RE4DG9Z5JLqqNb ltRwwGKecQQA22ZEpRFqQPoU5CKjpc4N2Ox1ZI4ok9euUdrGy/DAiVDED83zCJv/Ic/l hhQ+vdDXJtXYBdN38ACC/6RLZsU03+KpvQhaTAbumJAheC9OYJ8kCy+6UF+LpsUXJ3TI EW2CsaNC45FDv1fM5hzEyn3FWMpjgPKyi0ENqC+83nWq9glZSeici+8W62Om9H1PIUro 5v/g== X-Gm-Message-State: AOAM533KITses5WDjLaEhlHPhrwDRDx1T33XRkp3DbUr+WGOxmFefiM+ QQLHafMrsR68/l9mxItkCIF0Nw== X-Received: by 2002:a62:16c8:0:b0:43d:d6b8:f38 with SMTP id 191-20020a6216c8000000b0043dd6b80f38mr643872pfw.9.1631554815226; Mon, 13 Sep 2021 10:40:15 -0700 (PDT) Received: from google.com ([2620:15c:202:201:7b92:14a1:4f7c:6560]) by smtp.gmail.com with ESMTPSA id z131sm7936638pfc.159.2021.09.13.10.40.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Sep 2021 10:40:14 -0700 (PDT) Date: Mon, 13 Sep 2021 10:40:08 -0700 From: Benson Leung To: Heikki Krogerus Cc: Prashant Malani , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, bleung@chromium.org, badhri@google.com, Greg Kroah-Hartman , Sebastian Reichel , Adam Thomson , Guenter Roeck Subject: Re: [RFC PATCH 2/3] power: supply: Add support for PDOs props Message-ID: References: <20210902213500.3795948-1-pmalani@chromium.org> <20210902213500.3795948-3-pmalani@chromium.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SbCgKMEoeM84Kils" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --SbCgKMEoeM84Kils Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Heikki, On Mon, Sep 13, 2021 at 04:30:08PM +0300, Heikki Krogerus wrote: > My plan is to register a separate power supply for each PDO. So for > every source PDO and every sink PDO a port has in its capabilities, > you'll have a separate power supply registered, and the same for the > partner when it's connected. With every connection there should always > be one active (online) source psy and active sink psy (if the port is > source, one of the port's source psys will be active and the partner > will have the active sink psy, or vise versa - depending on the role). >=20 > Each PDO represents a "Power Supply" so to me that approach just > makes the most sense. It will require a bit of work in kernel, however > in user space it should mean that we only have a single new attribute > file for the power supplies named "pdo" that returns a single PDO. There's a few downsides to this approach (one psy for each pdo). The PDOs returned by Source Capabilities and Sink Capabilities do not just contain possible Voltage, Current, and Power combinations, but they also co= ntain additional information in the form of properties. In the Fixed Supply PDO, the following bits convey information about the su= pply or sink (See USB PD Spec R3.1 V1.0 Table 6-9): * B29 - Dual-Role Power * B28 - USB Suspend Supported * B27 - Unconstrained Power * B26 - USB Communications Capable * B25 - Dual-Role Data * B24 - Unchunked Extended Messages Supported * B23 - EPR Mode Capable These bits exist in every single 32-bit Fixed Supply PDO, however,=20 Section 6.4.1.2.2 requires that they be appropriately set in the vSafe5V Fi= xed PDO (which is required for all sources and sinks), and set to 0 in all other PDOs in the caps. > Since all USB Providers support vSafe5V, the required vSafe5V Fixed Supply > Power Data Object is also used to convey additional information that is > returned in bits 29 through 25. All other Fixed Supply Power Data Objects > Shall set bits 29=E2=80=A622 to zero. So, splitting out a particular port partner or port's PDOs into individual power supplies runs the risk of the information above not properly being attributed to the actual power supply. For example, if you're connected to a 18W power supply that has a vSafe5V P= DO, and a 9V Fixed PDO, and you're operating at 18W, the 9V Fixed PDO will be A= ctive but the inactive vSafe5V PDO has information in those higher order bits that remain relevant. Just something to keep in mind. >=20 > Let me know if you guys see any obvious problems with the idea. > Otherwise, that is how we really need to do this. That will make > things much more clear in user space. I have a feeling it will make > things easier in kernel as well in the long run. >=20 > Adding Adam and Guenter. It would be good if you guys could comment > the idea as well. I'm supportive of using a separate PSY to represent the different power rol= es of a particular port and port-partner, however. If you're connected to a US= B-C power bank, you should see two objects for that partner, one for when the power bank is in source role, and one when the power bank is in sink role. Even when you're in one role or the other, you should still be able to read information from the other role in order to make an informed decision wheth= er you want to power role swap. Thanks so much! Benson --=20 Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. bleung@google.com Chromium OS Project bleung@chromium.org --SbCgKMEoeM84Kils Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQCtZK6p/AktxXfkOlzbaomhzOwwgUCYT+M+AAKCRBzbaomhzOw woiuAP98EOxvnyM8s0sjMr4L7+xT/HIE8zBgWBc1Hc9K19iKDQD+KguqhT0F6CQW m/3+6GMzrNmx9TGeLNsp/9IcjhOZGw0= =sfGH -----END PGP SIGNATURE----- --SbCgKMEoeM84Kils--