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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c398870-08ea-e0ec-5fd4-101255e2b727@skidata.com>
Date:   Tue, 20 Feb 2018 13:14:31 +0100
From:   Richard Leitner <richard.leitner@...data.com>
To:     Felipe Balbi <felipe.balbi@...ux.intel.com>,
        Richard Leitner <dev@...l1n.net>, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
CC:     <gregkh@...uxfoundation.org>, <stern@...land.harvard.edu>,
        <linux@...ck-us.net>, <mathias.nyman@...ux.intel.com>,
        <johan@...nel.org>, <ekorenevsky@...il.com>, <peter.chen@....com>,
        <drake@...lessm.com>, <joe@...ches.com>
Subject: Re: [PATCH v2] usb: core: introduce per-port over-current counters

On 02/20/2018 12:55 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Richard Leitner <dev@...l1n.net> writes:
>> From: Richard Leitner <richard.leitner@...data.com>
>>
>> For some userspace applications information on the number of
>> over-current conditions at specific USB hub ports is relevant.
>>
>> In our case we have a series of USB hardware (using the cp210x driver)
>> which communicates using a proprietary protocol. These devices sometimes
>> trigger an over-current situation on some hubs. In case of such an
>> over-current situation the USB devices offer an interface for reducing
>> the max used power. As these conditions are quite rare and imply
>> performance reductions of the device we don't want to reduce the max
>> power always.
>>
>> Therefore give user-space applications the possibility to react
>> adequately by introducing an over_current_counter in the usb port struct
>> which is exported via sysfs.
> 
> why don't you just provide more than one configuration with several
> bMaxPower fields? Then host OS should choose correct configuration based
> on power budget.

Thank you for that suggestion!
Generally speaking that would be possible. Nonetheless we
	a) don't have the possibility to change the firmware or the USB 
		configuration of the device.
	b) in those corner-cases (where the over-current situation occurs)
		the device consumes more than 500mA (which couldn't be 
		configured in bMaxPower AFAIK?). Nonetheless most
		hubs don't detect the over-current (AFAIK) due to
		electrical tolerances of their components. Our problem are
		the hubs which trigger the over-current situation (which
		is fine from a USB perspective).

I know it's probably not a very nice solution, so if anybody has a better
proposal please let me know :-)

Thanks!

regards;Richard.L

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ