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

Stoppa, Igor igor.stoppa at intel.com
Wed Dec 18 10:30:28 GMT 2013


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.

 > From: Stoppa, Igor [mailto:igor.stoppa at intel.com]
> > Sent: Monday, December 16, 2013 5:31 PM
>

[snip]

> > that's good - the only constraint here is that the id must be
> > consistent with both:
> >
> > 1) what is assigned to the device in the factory, if available (but
> > in commercial devices, it will be available)
> >
> >
> > 2) what is reported by the device when in other modes
> > but this is really a requirement for the other modes, provided that
> > 1) is satisfied.
>
> 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.

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

[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?

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.

-- 
cheers, igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131218/c306b266/attachment-0001.html>


More information about the Dev mailing list