[U-Boot] [PATCH v3 0/1] dm: usb: Copy over usb_device values from usb_scan_device() to final usb_device

[Simon Glass]

Hi Hans,

On 4 May 2015 at 13:12, Hans de Goede <hdegoede at redhat.com> wrote:
> Hi,
>
> On 04-05-15 19:22, Simon Glass wrote:
>>
>> Hi Hans,
>>
>> On 4 May 2015 at 11:19, Hans de Goede <hdegoede at redhat.com> wrote:
>>>
>>> Hi Simon,
>>>
>>> Here is v3 of my patch to fix the maxpacketsize0 not being set issue I
>>> found and related issues.
>>>
>>> I've added a big fat comment to explain that the usb_device pointer is a
>>> hack and should not be used outside of usb-uclass.c as requested.
>>>
>>> I hope this version is to your liking and you can ack it.
>>>
>>> Assuming that you do ack it, then my entire dm-usb fixes + ehci set is
>>> all acked, and the question becomes how to take uit upstream, I can take
>>> the entire set upstream through the sunxi tree, or you can take it
>>> upstream through the dm tree. Let me know which way you prefer to move
>>> forward with this.
>>
>>
>> I should probably take it through DM. I'll do a pull request once the
>> x86 pull request goes in.
>
>
> Ack.
>
>> But I'm still not sure how it is safe to pass a pointer to a local
>> stack variable out through another function. Can you please explain
>> that?
>
>
> A function 'a' can safely pass a pointer to an on stack variable to
> a function 'b' which it calls, since it is the caller of function 'b',
> and as long as code from 'b' is execution we are still within the
> lifetime of function 'a' (function 'a' will only end after b has
> returned) and as long as execution is within the lifetime of function
> 'a' any on stack variables of function 'a' are valid.
>
> AFAICT usb_child_pre_probe() gets called from the device_probe()
> call inside usb_scan_device() so using a pointer to an on stack
> variable of usb_scan_device() is valid since we are still executing
> within the lifetime of usb_scan_device().
>
> Hope this helps to follow my reasoning.
>

Ah I see. Gosh that is evil. The comment helps.

Acked-by: Simon Glass <sjg at chromium.org>

Regards,
Simon