Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp694584ybh; Tue, 10 Mar 2020 06:36:38 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtmgluVwvPOQyDAcK6lF2gTcKLBi5UEo3HOoZTsGM9aeUpd1HW9hQOCmiKCRVDnACMSF5hx X-Received: by 2002:a9d:6411:: with SMTP id h17mr16971254otl.332.1583847398342; Tue, 10 Mar 2020 06:36:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583847398; cv=none; d=google.com; s=arc-20160816; b=b8HDIJHCWNq0n249WHQ/t3LZycmcwlAQ3wVd5gO3jYPgqipRrRHmCpHUNxE4h2VTks KbKWH3uXOA4FJS508bdV1kXriPLMNY+1Ao/z83wYai83owcM/sTBGlgyKtxdsPPOpgF0 /LsdDnnrlIsYjZQgok0qHCDwina3bwi5M+r+E7R5s49s4x+YXSdLeJixrAyPFLEA1xxD FjS/yStf8ygSwIXWx4Lt/g4AFD0r5DwZMvVbE5sW+DKm8XEsOTR3zsITraO9PbhTE+42 99rr4ejiveT+fJl+Br5a/OvxGo7adYocL+oWsp/0w30T7e/h8lUE3CaTdgN+7Afkk5qz B4ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=xNq8Sa2xPalR59cb094KVYhu/SQSKnKnMJceD7uiiis=; b=gXzEYyyvf9uBOe0KP+pvXwtgK6P3HMq1DBgW38pe23umZg8WTCkyEu063p/NQJZ0Ef Xr0Ahj8FZCmV2apk8Yk2ESsiD6gRRM6FqOep3LJ3XtYmAFn6olXk/jcFB1L1c+Uqf4En vg/4/fZ+tMiAx6IXZfBWQSvTp7jvjw6HCCZvAjXMHSWxjU3nQ5lg++76OlXVDQ9S/u7l VE3ISdxgZl5zukyGub1ijVLuO2GQcaPYo0JkvJ1hp5/jos5mqf/wot/4MN1lSl/OV3x3 kQ6rHcM0ShUcKWDfkjP03pnW3HqIE3ahis5dsGpotnCFfByd3QclqJzIBpAyEwJeWHEx t4lA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lOQ3rVcm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t19si5996119oif.250.2020.03.10.06.36.24; Tue, 10 Mar 2020 06:36:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=lOQ3rVcm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727639AbgCJMqC (ORCPT + 99 others); Tue, 10 Mar 2020 08:46:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:48910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727517AbgCJMqA (ORCPT ); Tue, 10 Mar 2020 08:46:00 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 44A972468F; Tue, 10 Mar 2020 12:45:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1583844359; bh=lmH1utyMKQlbkWRrt5YcFzcKcYbLr9xfF/JCSANbeOk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lOQ3rVcm8YBd7HnRMdve/R9Iq656KkRAGLGW0/KOXFQnGUMLYCfB418q9uZTi7avH EpCAtAPOIQR77YLVB6PClSiEo9N3QvVPXycX7CpQ6kS2lL7V+EQ28C6AHMD4N610rp d6uhH1eCRHPit16sQvCHHfOJ6K5kjjAm4j0LB66M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jack Pham , Felipe Balbi , Sasha Levin Subject: [PATCH 4.9 52/88] usb: gadget: composite: Support more than 500mA MaxPower Date: Tue, 10 Mar 2020 13:39:00 +0100 Message-Id: <20200310123619.052130198@linuxfoundation.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200310123606.543939933@linuxfoundation.org> References: <20200310123606.543939933@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jack Pham [ Upstream commit a2035411fa1d1206cea7d5dfe833e78481844a76 ] USB 3.x SuperSpeed peripherals can draw up to 900mA of VBUS power when in configured state. However, if a configuration wanting to take advantage of this is added with MaxPower greater than 500 (currently possible if using a ConfigFS gadget) the composite driver fails to accommodate this for a couple reasons: - usb_gadget_vbus_draw() when called from set_config() and composite_resume() will be passed the MaxPower value without regard for the current connection speed, resulting in a violation for USB 2.0 since the max is 500mA. - the bMaxPower of the configuration descriptor would be incorrectly encoded, again if the connection speed is only at USB 2.0 or below, likely wrapping around U8_MAX since the 2mA multiplier corresponds to a maximum of 510mA. Fix these by adding checks against the current gadget->speed when the c->MaxPower value is used (set_config() and composite_resume()) and appropriately limit based on whether it is currently at a low-/full-/high- or super-speed connection. Because 900 is not divisible by 8, with the round-up division currently used in encode_bMaxPower() a MaxPower of 900mA will result in an encoded value of 0x71. When a host stack (including Linux and Windows) enumerates this on a single port root hub, it reads this value back and decodes (multiplies by 8) to get 904mA which is strictly greater than 900mA that is typically budgeted for that port, causing it to reject the configuration. Instead, we should be using the round-down behavior of normal integral division so that 900 / 8 -> 0x70 or 896mA to stay within range. And we might as well change it for the high/full/low case as well for consistency. N.B. USB 3.2 Gen N x 2 allows for up to 1500mA but there doesn't seem to be any any peripheral controller supported by Linux that does two lane operation, so for now keeping the clamp at 900 should be fine. Signed-off-by: Jack Pham Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin --- drivers/usb/gadget/composite.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index 4d7df2f6caf5b..3a0452ff1a565 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -438,9 +438,13 @@ static u8 encode_bMaxPower(enum usb_device_speed speed, if (!val) return 0; if (speed < USB_SPEED_SUPER) - return DIV_ROUND_UP(val, 2); + return min(val, 500U) / 2; else - return DIV_ROUND_UP(val, 8); + /* + * USB 3.x supports up to 900mA, but since 900 isn't divisible + * by 8 the integral division will effectively cap to 896mA. + */ + return min(val, 900U) / 8; } static int config_buf(struct usb_configuration *config, @@ -833,6 +837,10 @@ static int set_config(struct usb_composite_dev *cdev, /* when we return, be sure our power usage is valid */ power = c->MaxPower ? c->MaxPower : CONFIG_USB_GADGET_VBUS_DRAW; + if (gadget->speed < USB_SPEED_SUPER) + power = min(power, 500U); + else + power = min(power, 900U); done: usb_gadget_vbus_draw(gadget, power); if (result >= 0 && cdev->delayed_status) @@ -2272,7 +2280,7 @@ void composite_resume(struct usb_gadget *gadget) { struct usb_composite_dev *cdev = get_gadget_data(gadget); struct usb_function *f; - u16 maxpower; + unsigned maxpower; /* REVISIT: should we have config level * suspend/resume callbacks? @@ -2286,10 +2294,14 @@ void composite_resume(struct usb_gadget *gadget) f->resume(f); } - maxpower = cdev->config->MaxPower; + maxpower = cdev->config->MaxPower ? + cdev->config->MaxPower : CONFIG_USB_GADGET_VBUS_DRAW; + if (gadget->speed < USB_SPEED_SUPER) + maxpower = min(maxpower, 500U); + else + maxpower = min(maxpower, 900U); - usb_gadget_vbus_draw(gadget, maxpower ? - maxpower : CONFIG_USB_GADGET_VBUS_DRAW); + usb_gadget_vbus_draw(gadget, maxpower); } cdev->suspended = 0; -- 2.20.1