[Dev] usb-manager: set correct usb gadget attributes

Krzysztof Opasiak k.opasiak at samsung.com
Wed Dec 18 14:47:54 GMT 2013

(-) Tomasz Swierczek - involved in other part of this discussion


> Hello,
> On 18 December 2013 11:58, Krzysztof Opasiak
> <k.opasiak at samsung.com> wrote:
> 	+ Tomasz Swierczek
> 	Dear Security team,
> 	could you support us in discussion about the topic from the
> bottom of
> 	message?
> I'll drop that from this branch of the thread and let security
> expert continue
> in a separate branch.
> 	But why would you like to use the ID for flashing?
> 	In my opinion USB topology is better to discover which USB
> device we are
> 	talking to. Let's assume that you have 3 different targets.
> You would
> 	like to flash them all but each with different image. It's
> better to
> 	know which cable is ttyACM1, ttyACM2 etc. than know the 3
> long id's of
> 	each device. The topology could be constant. You can have
> some stickers
> 	on USB connectors and connect "connector 1" to target XYZ and
> then you
> 	are sure that you are flashing this particular device. If you
> would like
> 	to do that same with ID's you should compare the longs
> targets ID's
> 	instead of simply connecting the device to correct connector.
> I am working on a fully unattended solution, which also relies on
> Jenkins.
> Hence it's really not a problem to compare very long strings, as
> long as they
> are consistent across device modes (Tizen mode vs native flashing
> mode).
> And I have means to ensure consistency between SW image and target
> device.

Different target devices could have different product ids, so you will
know what device you are talking to. That same target devices could be
distinguished using USB topology. Such information is provided via SysFS
in /sys/bus/usb/devices.

> It would really be a problem if I had to involve myself in the
> automated mechanism,
> just to look at the stickers =)

But there is a moment when you physically connect the devices to a host
with Jenkins so I hope that you know what are you doing and which
connector you plug in to which device;)

> [snip]
> 	Such electrical switch is not necessary. In Tizen reference
> Kernel we
> 	have ConfigFS and we will use it for gadget composition.
> There is a
> 	"file" called UDC. So doing simply:
> 	$ echo "" > UDC
> 	Disables gadget and
> 	$ echo "udc-name" > UDC
> 	Enables gadget. Those commands are enough to do support your
> scenario.
> 	For host it's similar to physical detachment of device.
> Afaik the battery charging is (should be) fully HW driven, because
> when the
> battery is really flat, it cannot rely on the OS to drive its
> charging.
> I thought that there is no warranty that disabling gadget mode will
> really
> affect the charging circuitry: isn't it implementation specific?

Charging is not a part of usb gadget subsystem. Changing is a lower
layer. But we could prepare simple patch for kernel which will allow to
control extcon via the SysFS. Then the circuit is totally detached.
Better solution it is to implement disconnection on a host side. Some of
the hubs offers a possibility to disable usb ports one by one. This will
guarantee that you can disable or enable usb device when you would like
to do so.

> I want to ensure that the built in coulomb counter will be
> measuring the
> depletion of the charge stored in the battery.
> Using an externally controlled device seems safer and more
> resilient toward
> supporting a multitude of different target devices, because it
> simulates a
> user action that will always be supported.

You need only a hub which support an operation described above.


Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

More information about the Dev mailing list