Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp4115932pxb; Tue, 7 Sep 2021 15:25:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwqO4MfJaTqv4HCZHI5aYlIbgZIku9S8xXwDGXCOtv+BMUr4O0UbBekQsrMrnhARt4eSPyd X-Received: by 2002:a02:cc59:: with SMTP id i25mr533517jaq.125.1631053558154; Tue, 07 Sep 2021 15:25:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631053558; cv=none; d=google.com; s=arc-20160816; b=eHzb2Eysj5ejoz4C0bVPdxkhBXpzBKpXDYHFguYpoSRaPxU96wCmOLXWJka0tScVSR 9aDjcdzuDMRXWrCm9VjZhU1GMflyGOF8oHEeBdhHBE1vngjSegt4sRDd637g5UmPmgHk Ece27b60VtbHetxyJAirukYcKOVXz4ZdfgzM2BYKtE8DSyTM1+oNLeNu40YIhPKGv65n aSHL1FEK0r7aAXFx3NxFxkoWQ9rtbjSTcqRZRTv0EtD7R6oGNaNrevPt9qOcM3kuWe51 pk+OtvMEbv14aQ4yaf/z+ZC2LA6xU2T/k3yohkIkV8SExs8F7tmdXr7gAGdZOqd3NqGP lV+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=4hHHNGQ0/c7grA1NVwCheQIrG1pechrzo95jBO8E7AQ=; b=JeZ6gjfSg3yjBT1Q+Y/0c0VO9B2jYWt10fRKFt9UhjfKjgPl1+1RnFByKPMy+vvwx2 AJxpkJKdaIaP88zYZl9Xp3hws7gX/70t5g5e/1DKGOT/mjJsmAHUAo5d3P4IR0dlpze+ gjeNFfDKaYt+qS2OP+Hha8hOzo9t3TPOMya8homCYUze610lJAtOXaLWX5lkGGKZ8USx 375UMQt1pJWblvZElVnibGSA4ghS9XU6coNY+yAAo/rmoAZoyc6lFVPQRht2vLg5wdHy JkUUZscPzQK5y9F75lQklQBY1yOaEaWzj1dHuvWqo9Hy5LIcNoc0nYB7wK+le/BmOpNf FNrA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AKZ2P6Wl; 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=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h30si354134ila.1.2021.09.07.15.25.46; Tue, 07 Sep 2021 15:25:58 -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=@chromium.org header.s=google header.b=AKZ2P6Wl; 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=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238914AbhIGVh2 (ORCPT + 99 others); Tue, 7 Sep 2021 17:37:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229875AbhIGVh2 (ORCPT ); Tue, 7 Sep 2021 17:37:28 -0400 Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 688E6C061575 for ; Tue, 7 Sep 2021 14:36:21 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id d11so95627qtw.3 for ; Tue, 07 Sep 2021 14:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4hHHNGQ0/c7grA1NVwCheQIrG1pechrzo95jBO8E7AQ=; b=AKZ2P6Wl/6ltmXc31yGRxxU9WhQSvfbxpWyMH+icfJn8YJp8gC3gWm1RRoUWIPks3L 11ZrJLEKD70D6kx8vG3YvmAFi79X6Jz1k5+0YfKzorgKUed8Ikjk3brIKvCUiQFBq/Q4 dhpboaWll2+31bUgTQ2oVPxe+LZApI/X8xmFg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4hHHNGQ0/c7grA1NVwCheQIrG1pechrzo95jBO8E7AQ=; b=MnhpZmt3rZ6Uv915wNDjTd3Ygda/+23pILTuNxo1iQY/ayZ/GtfjJzRUm7sTYTaWpw tabs8265RCguHfDZDIZqzH2zt/xzH+7VjMGS8dmqHBLHwUKH/wrAf/nFrflIGL5Z9qfs tkAFKt0FMf+sBrgJ5NZO2rT+Zo+xAbsZOfGVjZuFaA3ECjrDPYPwcpTUS+eBjZ4NKPce BqfVI7g35VfvpFPkBe3Hzwrit46Lqlr86FWbNey1dswu26ZX3r4wdSGs6tvLu+bgjxII vuB/LvFAk5AiJEvX5UVxCMxau6H41+EtDCMeil2dAf6XJHg6KUH4fciNoSlYQMaa8Rx4 L7zA== X-Gm-Message-State: AOAM5312qOir2UwMspxxiV4EZbcbhdzAtQDyeh6Iru+P/IDH7JsnNO8R 73Xi17Z15t3dYiw99Q9Bli9KXt3Q/feqf3CWNfBYUvIQktw= X-Received: by 2002:ac8:4b43:: with SMTP id e3mr551768qts.312.1631050580551; Tue, 07 Sep 2021 14:36:20 -0700 (PDT) MIME-Version: 1.0 References: <20210902213500.3795948-1-pmalani@chromium.org> <20210902213500.3795948-2-pmalani@chromium.org> <20210903064701.GA3515@jackp-linux.qualcomm.com> <20210903180507.GB3515@jackp-linux.qualcomm.com> In-Reply-To: <20210903180507.GB3515@jackp-linux.qualcomm.com> From: Prashant Malani Date: Tue, 7 Sep 2021 14:36:09 -0700 Message-ID: Subject: Re: [RFC PATCH 1/3] usb: pd: Increase max PDO objects to 13 To: Jack Pham Cc: Linux Kernel Mailing List , "open list:USB NETWORKING DRIVERS" , "open list:POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS" , Benson Leung , Heikki Krogerus , Badhri Jagan Sridharan , Greg Kroah-Hartman , Sebastian Reichel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jack, Thanks for taking a look at the patch. On Fri, Sep 3, 2021 at 11:05 AM Jack Pham wrote: > > On Thu, Sep 02, 2021 at 11:47:01PM -0700, Jack Pham wrote: > > Hi Prashant, > > > > On Thu, Sep 02, 2021 at 02:34:58PM -0700, Prashant Malani wrote: > > > Increase the max number of PDO objects to 13, to accommodate the extra > > > PDOs added as a part of EPR (Extended Power Range) operation introduced > > > in the USB PD Spec Rev 3.1, v 1.0. See Figure 6-54 for details. > > > > > > Signed-off-by: Prashant Malani > > > --- > > > include/linux/usb/pd.h | 8 +++++++- > > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h > > > index 96b7ff66f074..7e8bdca1ce6e 100644 > > > --- a/include/linux/usb/pd.h > > > +++ b/include/linux/usb/pd.h > > > @@ -201,7 +201,13 @@ struct pd_message { > > > } __packed; > > > > > > /* PDO: Power Data Object */ > > > -#define PDO_MAX_OBJECTS 7 > > > + > > > +/* > > > + * The EPR (Extended Power Range) structure is a superset of the SPR (Standard Power Range) > > > + * capabilities structure, so set the max number of PDOs to 13 instead of 7. On SPR-only systems, > > > + * objects 8 through 13 will just be empty. > > > + */ > > > +#define PDO_MAX_OBJECTS 13 > > > > Hmm this might break the recent change I made to UCSI in commit > > 1f4642b72be7 ("usb: typec: ucsi: Retrieve all the PDOs instead of just > > the first 4"). > > > > 520 static void ucsi_get_src_pdos(struct ucsi_connector *con, int is_partner) > > 521 { > > 522 int ret; > > 523 > > 524 /* UCSI max payload means only getting at most 4 PDOs at a time */ > > 525 ret = ucsi_get_pdos(con, 1, con->src_pdos, 0, UCSI_MAX_PDOS); > > 526 if (ret < 0) > > 527 return; > > 528 > > 529 con->num_pdos = ret / sizeof(u32); /* number of bytes to 32-bit PDOs */ > > 530 if (con->num_pdos < UCSI_MAX_PDOS) > > 531 return; > > 532 > > 533 /* get the remaining PDOs, if any */ > > 534 ret = ucsi_get_pdos(con, 1, con->src_pdos, UCSI_MAX_PDOS, > > 535 PDO_MAX_OBJECTS - UCSI_MAX_PDOS); > > ^^^^^^^^^^^^^^^ > > This routine calls the UCSI GET_PDOS command for up to 4 PDOs at a time > > since that's the most the return payload can carry. Currently this > > assumes that we'd only need to request the PPM at most twice to retrieve > > all the PDOs for up to a maximum of 7 (first request for 4 then again if > > needed for the remaining 3). I'm not sure if any existing UCSI FW would > > be updatable to support more than 7 PDOs in the future, much less > > support EPR. In fact, current UCSI 1.2 spec [1] Table 4-34 mentions PDO > > Sorry, forgot the footnote with the link to the spec: > [1] https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/usb-type-c-ucsi-spec.pdf > > > offset valid values are 0-7 and anything else "shall not be used", so I > > don't know how UCSI will eventually cope with EPR without a spec update. > > > > So if this macro changes to 13 then this call would result in a call to > > the UCSI GET_PDOS command passing num_pdos == 13-4 = 9 which would > > probably result in an error from the PPM FW. So we might need to retain > > the maximum value of 7 PDOs at least for UCSI here. Maybe that means > > this UCSI driver needs to carry its own definition of > > UCSI_MAX_TOTAL_PDOS=7 instead of using PDO_MAX_OBJECTS? Thanks for pointing this out. We can perhaps just add another macro for EPR_PDO_MAX_OBJECTS, and leave the current macro as is for now. Best regards,