Received: by 2002:a05:6a10:eb17:0:0:0:0 with SMTP id hx23csp21761pxb; Tue, 7 Sep 2021 16:33:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxO1D4lCDOKoHuduWNFPLnCLGVOkT4Dnr7lit6q2dIR9mH/buA9gm3CaTNcmB4j6sMm7hJB X-Received: by 2002:a05:6402:5:: with SMTP id d5mr781103edu.359.1631057585848; Tue, 07 Sep 2021 16:33:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631057585; cv=none; d=google.com; s=arc-20160816; b=BJJoXyRGuqP8XWY3PBaGv5RuLXySNMHeHXMNpb2ZgscihLL75INI/hQhBLiFYd5sWR MjOC7MhVaKw2ugNUMfhd7S5KIa4h8KwfsztgR2J7+PPzCNSVn9TdImM/cSU4edMPxYpw Gy4Fbk8b4hIzsy7gXTp9h81O9XbzUG9YXXFlrYvP4dnq7c1CCftJAzkoOwjfu6YRtJj7 lOa2KcyIAG3P6pXLLwIxiIF2TZNXevxtSmBg9sFDCFh59Uvx8QllMPTWvl71MCqEJBNQ nth3CwBHpT4vuXuw5PSyI8sOtiaQS266W1GlR/XtlxOuPjltnLHi/HdzB+9562inizxt ejHA== 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=huc226miYakXtQslcOJ5OFd9dcBX+yoxXSmw1/JBDr8=; b=SFyTen/bCsDAImoJ6u5XxzBsbl7er0ZdHv6v6PWRWnPtDOpFnhmpxJ/kCTkyobtQT5 0WyJP1cZ2LJo0JbeKG8x6o5sK2UVsP8CUoQnIbvvLy/rdYmn8b2pIpWBR70gfoOdtveX 6C85SnOds9ByjLj8qs96RY3OKpj7UHi2vgSTTcUGv/evblVuZ18H9xOMqrMoirZJSiBY KRJjA26HN5vuX/1jlVq2OB22UeyUsTTK2baCBldfolVAsNN7ri/6PiPY6+rc872i2L3F DIi0pxpUEAh1SakQKBt/AN9zrpZk9BM7xiUq6hOGGaD81jVYjSdJbg3OCnhdsFocihY+ vUlg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=g4QFCzGn; 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 i5si470569eds.477.2021.09.07.16.32.36; Tue, 07 Sep 2021 16:33:05 -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=g4QFCzGn; 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 S1344607AbhIGXaJ (ORCPT + 99 others); Tue, 7 Sep 2021 19:30:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241594AbhIGXaI (ORCPT ); Tue, 7 Sep 2021 19:30:08 -0400 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F50CC061757 for ; Tue, 7 Sep 2021 16:29:02 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id w8so518600pgf.5 for ; Tue, 07 Sep 2021 16:29:02 -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=huc226miYakXtQslcOJ5OFd9dcBX+yoxXSmw1/JBDr8=; b=g4QFCzGnJKWqHaVTPchOeRfVnrN2KkPvCP/gI9KbDmC0V7x92NAtrU/9bnOsKqcJv5 DBNqQTLuzd/4bv0C4E9Cr28bZNRF0OYpTNgd00YAjWtfjS08ktJsotXMkcW2lnrzTV3q 4G9wdJuSLftnVsmdarmsmJ9zUwx4/Gl2ZEbOuhURkRV4CH4A6+fAdexIEeZM13Y4L/au oHk0yxTlw16XOXS/8BNP5gbkx2q3D2WbKCZ0luZtRrY/VRTBVXqM18Kl5cguzhBZvXwn O5a3FOt7R0X+6n/21N+uJfdPD5FIzWWv7NKrpYhbeiWlF0/1snB/CXtefy3SGQoG/JrQ MnTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=huc226miYakXtQslcOJ5OFd9dcBX+yoxXSmw1/JBDr8=; b=Scad2v+kP1lj+4FVC4sxeLNNUnPt7pwUJMPtJgjoz58bQWERRBMzTMEKCPo3mR/G0h ek+oK/7RsAQB2+n93p0U8cDvAL+1P/oFK+49RqKHUSrbeGTw8DnF49ZfRciIiPbjCr2Z dd6yYltoe9DtZ1Sr7xZPMa7moAA6zLp59rvLCVOUaCcVXoFy9AE7KRELDOC3UFFRVtIN TfMVdz5D8iqPleYU1/i8pYpCnDKBmjEKnTmAWHvCIztwWUB27m+eJ+bx9/s6fFvaaj1d YMlneOsviXm5PI3UU0lz9kBJdLZmUMzAIB/GyE3GX+gul0rmeZ3QN+8Xq1M+wKUZ6762 UeoQ== X-Gm-Message-State: AOAM530gr6qJc7lm0oMSIFXlRFT6XQ8L20a4I1zvuL7ZIxYldVpdyZiy HYz+pbKqWNRQb/ZAU1C8F3TWem3Ew7odpA== X-Received: by 2002:a63:f050:: with SMTP id s16mr772788pgj.258.1631057340982; Tue, 07 Sep 2021 16:29:00 -0700 (PDT) Received: from google.com ([2620:15c:202:201:8525:5337:1a6c:f8af]) by smtp.gmail.com with ESMTPSA id z9sm163607pfk.28.2021.09.07.16.28.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Sep 2021 16:28:59 -0700 (PDT) Date: Tue, 7 Sep 2021 16:28:53 -0700 From: Benson Leung To: Jack Pham Cc: Prashant Malani , 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: 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: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dU2rkRBfuzWCPsob" Content-Disposition: inline In-Reply-To: <20210903064701.GA3515@jackp-linux.qualcomm.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --dU2rkRBfuzWCPsob Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Jack, On Thu, Sep 02, 2021 at 11:47:01PM -0700, Jack Pham wrote: > Hi Prashant, >=20 > 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. > >=20 > > Signed-off-by: Prashant Malani > > --- > > include/linux/usb/pd.h | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > >=20 > > 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; > > =20 > > /* 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 >=20 > 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"). >=20 > 520 static void ucsi_get_src_pdos(struct ucsi_connector *con, int is_par= tner) > 521 { > 522 int ret; > 523 > 524 /* UCSI max payload means only getting at most 4 PDOs at a t= ime */ > 525 ret =3D ucsi_get_pdos(con, 1, con->src_pdos, 0, UCSI_MAX_PDO= S); > 526 if (ret < 0) > 527 return; > 528 > 529 con->num_pdos =3D ret / sizeof(u32); /* number of bytes to 3= 2-bit PDOs */ > 530 if (con->num_pdos < UCSI_MAX_PDOS) > 531 return; > 532 > 533 /* get the remaining PDOs, if any */ > 534 ret =3D 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 > 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. >=20 I've had a conversation with Dmitriy Berchanskiy at Intel (the UCSI WG Chai= r) about this, and it sounds like the UCSI spec is planned on being revved (post R2.0) in order to support the additional messages and expanded struct= ures of USB PD R3.1 around EPR. > So if this macro changes to 13 then this call would result in a call to > the UCSI GET_PDOS command passing num_pdos =3D=3D 13-4 =3D 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=3D7 instead of using PDO_MAX_OBJECTS? >=20 Prashant mentioned this as well, but maybe it makes sense to define a separ= ate EPR_PDO_MAX_OBJECTS to handle the EPR case, as there are completely separate underlying PD messages (EPR_Source_Capabilities) where we expect up to 13 objects, and the classic SPR Source and Sink capabilities will still have t= he 7 object limit. Thanks, Benson > Jack > --=20 > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > a Linux Foundation Collaborative Project --=20 Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. bleung@google.com Chromium OS Project bleung@chromium.org --dU2rkRBfuzWCPsob Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQQCtZK6p/AktxXfkOlzbaomhzOwwgUCYTf1tQAKCRBzbaomhzOw wlRvAPwPZTx65uU6EEUXq7sH6/pz2lo/Y6+g2Brgeyph8nhZuAD/U0LKYsc1cWoX y/jbqXCGXSm7zQBhJ3Xrs0fDV2B2Mw8= =gobX -----END PGP SIGNATURE----- --dU2rkRBfuzWCPsob--