linux-kernel - Re: [PATCH 2/7] [RFC] Common power driver for Linux gadgets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200704130325.13813.david-b@pacbell.net>
Date:	Fri, 13 Apr 2007 03:25:13 -0700
From:	David Brownell <david-b@...bell.net>
To:	cbou@...l.ru
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/7] [RFC] Common power driver for Linux gadgets

On Friday 13 April 2007 2:52 am, Anton Vorontsov wrote:
> > > But I got the point, and yes I can't explain why it works correctly.
> > 
> > It probably doesn't work correctly.  But it's not broken enough to
> > fail badly.
> 
> Can that comment be an explanation?
> 
> --- drivers/usb/gadget/pxa2xx_udc.c:
> static const struct usb_gadget_ops pxa2xx_udc_ops = {
>         .get_frame      = pxa2xx_udc_get_frame,
>         .wakeup         = pxa2xx_udc_wakeup,
>         .vbus_session   = pxa2xx_udc_vbus_session,
>         .pullup         = pxa2xx_udc_pullup,
> 
>         // .vbus_draw ... boards may consume current from VBUS, up to
>         // 100-500mA based on config.  the 500uA suspend ceiling means
>         // that exclusively vbus-powered PXA designs violate USB specs.

That's basically a "plug in implementation here".  Nobody's yet done
that on a platform that _uses_ the VBUS power.


> };
> 
> 
> Comparing to omap_udc.
> 
> --- drivers/usb/gadget/omap_udc.c
> static int omap_vbus_draw(struct usb_gadget *gadget, unsigned mA)
> {
>         struct omap_udc *udc;
> 
>         udc = container_of(gadget, struct omap_udc, gadget);
>         if (udc->transceiver)
>                 return otg_set_power(udc->transceiver, mA);

Where the transceiver would then delegate to something else,
like the tps65010 driver.


>         return -EOPNOTSUPP;
> }
> [...]
> static struct usb_gadget_ops omap_gadget_ops = {
>         .get_frame              = omap_get_frame,
>         .wakeup                 = omap_wakeup,
>         .set_selfpowered        = omap_set_selfpowered,
>         .vbus_session           = omap_vbus_session,
>         .vbus_draw              = omap_vbus_draw,

... which has most certainly been on platforms which are hooked
up to draw power from VBUS.


>         .pullup                 = omap_pullup,
> };
> 
> 
> 
> Regarding API. If you all you want is to know how much power you need to
> ask from VBUS, we can extend external power interface... thus suppliers
> could ask their power consumption requirements in mA/uA, and these
> requests will be forwarded to power supply driver, and power driver will
> forward that request to USB transceiver (via platform hook).

I don't folow what you're saying.  The control flow *MUST* be that
the USB stack provides the only indication of how much power may
be drawn through the VBUS supply.  Nothing else in the system has
the knowledge of what's legal, and when.

If you want to talk about a "supplier", the way to put it might
then be that the USB stack is saying "here's N mA power for you";
it's supplying the power, not the other way around.

There's no "ask" involved, since the host controls "N".  So the
host supplies, the USB gadget stack interprets that, and some
power component must obeys.  That includes rules like reducing
VBUS draw to ~500 uA when the host suspends the USB link.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/