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

Tomasz Swierczek t.swierczek at samsung.com
Wed Dec 18 10:50:36 GMT 2013


Too late, already answered. J

 

Tomasz

 

From: Stoppa, Igor [mailto:igor.stoppa at intel.com] 
Sent: 18 grudnia 2013 11:30
To: Krzysztof Opasiak
Cc: Tomasz Swierczek; Yang Chengwei; Taeyoung Kim; Krogerus, Heikki;
dev at lists.tizen.org; Brad T Peters
Subject: Re: [Dev] usb-manager: set correct usb gadget attributes

 

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/6559140c/attachment-0001.html>


More information about the Dev mailing list