Re: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET

[Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1739 bytes --]

On 02/05/2013 10:43 AM, Roger Quadros wrote:
> On 02/05/2013 11:09 AM, Felipe Balbi wrote:
>> On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
>>>>> diff --git a/include/linux/usb/nop-usb-xceiv.h b/include/linux/usb/nop-usb-xceiv.h
>>>>> index 3265b61..148d351 100644
>>>>> --- a/include/linux/usb/nop-usb-xceiv.h
>>>>> +++ b/include/linux/usb/nop-usb-xceiv.h
>>>>> @@ -6,6 +6,10 @@
>>>>>   struct nop_usb_xceiv_platform_data {
>>>>>       enum usb_phy_type type;
>>>>>       unsigned long clk_rate;
>>>>> +
>>>>> +    /* if set fails with -EPROBE_DEFER if can't get regulator */
>>>>> +    unsigned int needs_vcc:1;
>>>>> +    unsigned int needs_reset:1;
>>>>
>>>> how about u8 here?
>>>
>>> Not sure. Bitfields are usually defined as unsigned int.
>>
>> IIRC the benefit is that compiler can try to optimize those flags. I
>> mean, if you have 32 1-bit flags, compiler will combine those in a
>> single u32. Someone correct me if I'm wrong.
>>
> 
> Yes you are right. Kishon was asking me to use u8 instead of unsigned int, which
> I don't think is necessary. AFAIK, it is a norm to use unsigned int when defining
> a bitfield. Compilers are known to behave funny with bitfields. I don't mind
> using bool for each.

In the current version (rogerq/v3.8-usbhost17-dt) of this patch you've
put both needs_* into the private data struct and the pdata, but it's
only used inside the probe function.

regards,
Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss