When the port does not support USB PD, prevent transition to PD
only states when power supply property is written. In this case,
TCPM transitions to SNK_NEGOTIATE_CAPABILITIES
which should not be the case given that the port is not pd_capable.
[ 84.308251] state change SNK_READY -> SNK_NEGOTIATE_CAPABILITIES [rev3 NONE_AMS]
[ 84.308335] Setting usb_comm capable false
[ 84.323367] set_auto_vbus_discharge_threshold mode:3 pps_active:n vbus:5000 ret:0
[ 84.323376] state change SNK_NEGOTIATE_CAPABILITIES -> SNK_WAIT_CAPABILITIES [rev3 NONE_AMS]
Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com>
---
drivers/usb/typec/tcpm/tcpm.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index ea5a917c51b1..904c7b4ce2f0 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -6320,6 +6320,13 @@ static int tcpm_psy_set_prop(struct power_supply *psy,
struct tcpm_port *port = power_supply_get_drvdata(psy);
int ret;
+ /*
+ * All the properties below are related to USB PD. The check needs to be
+ * property specific when a non-pd related property is added.
+ */
+ if (!port->pd_supported)
+ return -EOPNOTSUPP;
+
switch (psp) {
case POWER_SUPPLY_PROP_ONLINE:
ret = tcpm_psy_set_online(port, val);
--
2.37.1.595.g718a3a8f04-goog
From: Jakub Kicinski <kuba(a)kernel.org>
Date: Mon, 15 Aug 2022 18:45:12 -0700
> On Mon, 15 Aug 2022 20:51:29 +0000 Kuniyuki Iwashima wrote:
> > From: Wei Wang <weiwan(a)google.com>
> >
> > commit 4d8f24eeedc58d5f87b650ddda73c16e8ba56559 upstream.
> >
> > This reverts commit 4a41f453bedfd5e9cd040bad509d9da49feb3e2c.
> >
> > This to-be-reverted commit was meant to apply a stricter rule for the
> > stack to enter pingpong mode. However, the condition used to check for
> > interactive session "before(tp->lsndtime, icsk->icsk_ack.lrcvtime)" is
> > jiffy based and might be too coarse, which delays the stack entering
> > pingpong mode.
> > We revert this patch so that we no longer use the above condition to
> > determine interactive session, and also reduce pingpong threshold to 1.
> >
> > Fixes: 4a41f453bedf ("tcp: change pingpong threshold to 3")
> > Reported-by: LemmyHuang <hlm3280(a)163.com>
> > Suggested-by: Neal Cardwell <ncardwell(a)google.com>
> > Signed-off-by: Wei Wang <weiwan(a)google.com>
> > Acked-by: Neal Cardwell <ncardwell(a)google.com>
> > Reviewed-by: Eric Dumazet <edumazet(a)google.com>
> > Link: https://lore.kernel.org/r/20220721204404.388396-1-weiwan@google.com
> > Signed-off-by: Jakub Kicinski <kuba(a)kernel.org>
>
> Should we wait for the resolution in the original thread first?
>
> https://lore.kernel.org/all/ca408271-8730-eb2b-f12e-3f66df2e643a@kernel.org/
Oh, I missed that thread being active.
I'll keep eyes on it.
Thank you!
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From aa7aeee169480e98cf41d83c01290a37e569be6d Mon Sep 17 00:00:00 2001
From: Tyler Hicks <tyhicks(a)linux.microsoft.com>
Date: Sun, 10 Jul 2022 09:14:02 -0500
Subject: [PATCH] net/9p: Initialize the iounit field during fid creation
Ensure that the fid's iounit field is set to zero when a new fid is
created. Certain 9P operations, such as OPEN and CREATE, allow the
server to reply with an iounit size which the client code assigns to the
p9_fid struct shortly after the fid is created by p9_fid_create(). On
the other hand, an XATTRWALK operation doesn't allow for the server to
specify an iounit value. The iounit field of the newly allocated p9_fid
struct remained uninitialized in that case. Depending on allocation
patterns, the iounit value could have been something reasonable that was
carried over from previously freed fids or, in the worst case, could
have been arbitrary values from non-fid related usages of the memory
location.
The bug was detected in the Windows Subsystem for Linux 2 (WSL2) kernel
after the uninitialized iounit field resulted in the typical sequence of
two getxattr(2) syscalls, one to get the size of an xattr and another
after allocating a sufficiently sized buffer to fit the xattr value, to
hit an unexpected ERANGE error in the second call to getxattr(2). An
uninitialized iounit field would sometimes force rsize to be smaller
than the xattr value size in p9_client_read_once() and the 9P server in
WSL refused to chunk up the READ on the attr_fid and, instead, returned
ERANGE to the client. The virtfs server in QEMU seems happy to chunk up
the READ and this problem goes undetected there.
Link: https://lkml.kernel.org/r/20220710141402.803295-1-tyhicks@linux.microsoft.c…
Fixes: ebf46264a004 ("fs/9p: Add support user. xattr")
Cc: stable(a)vger.kernel.org
Signed-off-by: Tyler Hicks <tyhicks(a)linux.microsoft.com>
Reviewed-by: Christian Schoenebeck <linux_oss(a)crudebyte.com>
Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org>
diff --git a/net/9p/client.c b/net/9p/client.c
index 89c5aeb00076..3c145a64dc2b 100644
--- a/net/9p/client.c
+++ b/net/9p/client.c
@@ -887,16 +887,13 @@ static struct p9_fid *p9_fid_create(struct p9_client *clnt)
struct p9_fid *fid;
p9_debug(P9_DEBUG_FID, "clnt %p\n", clnt);
- fid = kmalloc(sizeof(*fid), GFP_KERNEL);
+ fid = kzalloc(sizeof(*fid), GFP_KERNEL);
if (!fid)
return NULL;
- memset(&fid->qid, 0, sizeof(fid->qid));
fid->mode = -1;
fid->uid = current_fsuid();
fid->clnt = clnt;
- fid->rdir = NULL;
- fid->fid = 0;
refcount_set(&fid->count, 1);
idr_preload(GFP_KERNEL);