Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp738349pxb; Fri, 3 Sep 2021 12:17:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhXYTi0+NR+J6vxyyk2zf8qkILZIVq04Z+qWsWzZn9Zoz0cMcc3x7i3qa3v+MegtmdmfY2 X-Received: by 2002:a6b:8f4e:: with SMTP id r75mr406160iod.172.1630696645235; Fri, 03 Sep 2021 12:17:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630696645; cv=none; d=google.com; s=arc-20160816; b=G8wlkvSYCh7nAK2g7hPG4dYlGJGr4ow0Bh4LHU3esA2v582r0RH2CrDE/Xfr3TsC6R JJ26YFsPD5dcXx5lIQdVC3LJHh75PXq2Bmbehbd1ihPW2qhMXEB7Px/xF3SWGNFCxls+ Li0teMpBrT9p9NhH4n4rupWoARpTJxtZh4Ks5OsyOgViSdSfxrzphyxHEuvu6jqI1kIL cK9xAR7ZstijS0q2eRJ2qDNxCzr5LG+jLpneQRkVOaUmXs+iAajm5XbQ7rg0SmRCKzj3 L4azqLdVjSUeVFEBP07qAw+fQuM/LMI33W208bG3RGjE6xeR7++OZUou/nLzNDv6EhQ4 cCIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dmarc-filter:sender:dkim-signature; bh=aGdZtz9MTWWljqht2uCxkXmCJ8HbWsZNCst2R0IK2Cc=; b=j4ZMtG4R4Ewya1tu4IkWgl74PWrZ3qzmnriZj1GjewiMuDxy58iVyYn2mK84g+aNQm wpZ5RLObj1mdvJxbEXrfvj2Q0zvyJvniIicRP9HF4WR2EGYG29+zizDAxhhRW0FK4uHs s8UXDByx9Gzrs9LErHwoBXkWWSCXERMEwQpRmLwjbCR23pclZfE09Xd1ulWIyhuC38P/ ENkyfq4UjwdbF8w00RFhahfLvzAwHuvHvE0/h7FSNAZK9AovbeccrTQmsyEsi41qDluY NLIN8IRv1jnjNidH7Bn9RHc7rMWgK8iO9/A0NgSNVsgkLusPN4xbBCjLn6c55guA7k1e /DuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mg.codeaurora.org header.s=smtp header.b="ey1x015/"; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i126si228837iof.61.2021.09.03.12.17.14; Fri, 03 Sep 2021 12:17:25 -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=@mg.codeaurora.org header.s=smtp header.b="ey1x015/"; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350361AbhICSGW (ORCPT + 99 others); Fri, 3 Sep 2021 14:06:22 -0400 Received: from m43-7.mailgun.net ([69.72.43.7]:48376 "EHLO m43-7.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350160AbhICSGT (ORCPT ); Fri, 3 Sep 2021 14:06:19 -0400 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1630692319; h=In-Reply-To: Content-Type: MIME-Version: References: Message-ID: Subject: Cc: To: From: Date: Sender; bh=aGdZtz9MTWWljqht2uCxkXmCJ8HbWsZNCst2R0IK2Cc=; b=ey1x015/xyRip/B2GN1ZXP01GyQrYwPokWuFjndD/y3PjB+rFWopRX2i0z00kYWxxHuN7TXv EC2FHy8q4rvFeZQHrNQI2GuS45WSO2xsbE/8bqFCqxe7lwxQD+O3Id99RedPubohDcAMm2se peTsLZx+OvGmi+lXXkCWdStIUnY= X-Mailgun-Sending-Ip: 69.72.43.7 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n03.prod.us-west-2.postgun.com with SMTP id 613263d940d2129ac14742e7 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Fri, 03 Sep 2021 18:05:13 GMT Sender: jackp=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id 06533C4360C; Fri, 3 Sep 2021 18:05:12 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-caf-mail-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=ALL_TRUSTED,BAYES_00,SPF_FAIL, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from jackp-linux.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jackp) by smtp.codeaurora.org (Postfix) with ESMTPSA id 42D33C4338F; Fri, 3 Sep 2021 18:05:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org 42D33C4338F Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: aws-us-west-2-caf-mail-1.web.codeaurora.org; spf=fail smtp.mailfrom=codeaurora.org Date: Fri, 3 Sep 2021 11:05:07 -0700 From: Jack Pham To: Prashant Malani Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, linux-pm@vger.kernel.org, bleung@chromium.org, heikki.krogerus@linux.intel.com, badhri@google.com, Greg Kroah-Hartman , Sebastian Reichel Subject: Re: [RFC PATCH 1/3] usb: pd: Increase max PDO objects to 13 Message-ID: <20210903180507.GB3515@jackp-linux.qualcomm.com> References: <20210902213500.3795948-1-pmalani@chromium.org> <20210902213500.3795948-2-pmalani@chromium.org> <20210903064701.GA3515@jackp-linux.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210903064701.GA3515@jackp-linux.qualcomm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > > Jack -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project