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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 12 Apr 2007 23:06:46 -0700
From:	David Brownell <david-b@...bell.net>
To:	Anton Vorontsov <cbou@...l.ru>
Cc:	Linux Kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/7] [RFC] Common power driver for Linux gadgets

> This driver used to stop code/logic duplication through different
> machines we porting at handhelds.org. pda_power register machs' power
> supplies, and will take care about notifying batteries about power
> changes through external power interface.

It gets USB power management wrong though.  Have a look at two I2C drivers
in drivers/i2c/chips:  tps65010.c (which would talk to this API) and then
isp1301_omap.c (which would talk to the tps65010 driver).  The tps65010
chip accepts the same two power sources you're addressing here, as part
of its battery charging responsibilities. [1]

Key points:

 - The API needs to say *how much power* can be drawn.  Common values
   are 8 mA (OTG peripherals before configuration), 100 mA (non-OTG ones
   before configuration), 500 mA (high power configurations) ... but the
   exact value depends on what's listed in the configuration descriptor
   for the chosen configuration, any value 0..500 mA (increments of two)
   could be appropriate.

 - Sensing VBUS power is not the same thing as being allowed to consume
   it.  Again, USB OTG devices are different:  OTG hosts **SUPPLY** the
   current, so you really don't want to be telling the OTG transceiver to
   fire up its charge pump (say, 3.0V VBAT converted to 5V VBUS) while at
   the same time telling the battery manager to use that battery-derived
   VBUS current to recharge its battery!  Not only would that waste power,
   but it also deprives the peripheral of the power it needs to draw.

In general, no component other than the USB peripheral (or host) controller
driver has any business trying to control how VBUS power is used.  It's
likely to get it wrong ... as shown by this patch.  ;)

And that's exactly why the USB gadget API has had calls to manage the USB
power consumption since mid-2004.  And I wonder why H5000 code evidently
doesn't implement those calls.

- Dave

[1] You may find http://www.linux-usb.org/gadget/h2-otg.html useful too.
    It gives a high level map of the complicated OTG case, including
    those drivers, and points out how simpler peripheral-only systems
    could behave with the same drivers.  However it does turn out to
    be useful if USB peripheral drivers have a "transciever" notion
    that can receive "VBUS present" interrupts, letting the peripheral
    controller driver power down almost *everything* to save power,
    and that otg_transceiver interface does that job.
 
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ