All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jack Pham <jackp@codeaurora.org>
To: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org
Subject: Re: [PATCH 2/2] usb: gadget: composite: Support more than 500mA MaxPower
Date: Tue, 29 Oct 2019 19:11:03 -0700	[thread overview]
Message-ID: <20191030021103.GA12661@jackp-linux.qualcomm.com> (raw)
In-Reply-To: <87wocnhkzk.fsf@gmail.com>

Hi Felipe,

On Tue, Oct 29, 2019 at 01:03:27PM +0200, Felipe Balbi wrote:
> 
> Hi,
> 
> jackp@codeaurora.org writes:
> > On 2019-10-23 00:49, Felipe Balbi wrote:
> >> Hi,
> >> 
> >> Jack Pham <jackp@codeaurora.org> writes:
> >>> 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 UINT8_MAX since
> >>>    the 2mA multiplier corresponds to a maximum of 610mA.
> >>> 
> >>> Fix these by adding checks against the current gadget->speed
> >>> when the c->MaxPower value is used and appropriately limit
> >>> based on whether it is currently at a low-/full-/high- or super-
> >>> speed connection.
> >>> 
> >>> Incidentally, 900 is not divisble by 8, so even for super-speed
> >>> the bMaxPower neds to be capped at 896mA, otherwise due to the
> >>                 ^^^^
> >>                 needs
> >> 
> >> Why do you need to cap it? DIV_ROUND_UP() should still work.
> >
> > The round up causes 900 on the input side to be greater than 900 when 
> > doing the
> > reverse, i.e. multiplication by 8.
> >
> > Alternatively we could just do a normal integer division here 
> > (effectively
> > round down).
> 
> (...)
> 
> >> DIV_ROUND_UP(896, 8) = 112
> >> DIV_ROUND_UP(900, 8) = 113
> >> 
> >> Why value do you want here?
>    ^^^
>    I mean which, sorry
> 
> > Right, but now on the host it will do the reverse calculation, i.e.
> > 113*8 == 904mA.  For a root port this would be greater than it's
> > maximum power budget of 900mA and would result in not selecting the
> > config.
> 
> That's a very good explanation of the problem, thank you. It seems like
> a round down would be safer here in all cases.

Ok, so do you mean something like:

	if (speed < USB_SPEED_SUPER)
-		return DIV_ROUND_UP(val, 2);
+		return DIV_ROUND_UP(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, we need to round down.
+		 */
+		return min(val, 900U) / 8;

Or by "all cases" did you also mean high/full/low speeds too where the
divisor is 2mA (in the first part of the if/else)? Otherwise it looks a
little inconsistent using two modes of division here. Technically the
calculation would then be changed for any odd values less than 500mA but
we're only talking about a difference of 2mA here...

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2019-10-30  2:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-23  6:57 [PATCH 1/2] usb: gadget: composite: Fix bMaxPower for SuperSpeedPlus Jack Pham
2019-10-23  6:57 ` [PATCH 2/2] usb: gadget: composite: Support more than 500mA MaxPower Jack Pham
2019-10-23  7:02   ` Jack Pham
2019-10-23  7:49   ` Felipe Balbi
2019-10-23  8:31     ` jackp
2019-10-29 11:03       ` Felipe Balbi
2019-10-30  2:11         ` Jack Pham [this message]
2019-10-30 11:39           ` Felipe Balbi
2019-10-26  1:04 ` [PATCH v2 " Jack Pham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191030021103.GA12661@jackp-linux.qualcomm.com \
    --to=jackp@codeaurora.org \
    --cc=balbi@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.