On 11/27/2012 03:28 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Nov 27, 2012 at 02:10:50PM +0200, Roger Quadros wrote:
>>> in fact, I would convert this construct into a switch which would look
>>> like:
>>>
>>> reg &= ~(OMAP4_P1_MODE_MASK << i * 2);
>>>
>>> switch (port_mode[i]) {
>>> case OMAP4_P1_MODE_TLL:
>>> reg |= OMAP4_P1_MODE_TLL << i * 2;
>>> break;
>>> case OMAP_P1_MODE_HSIC:
>>> reg |= OMAP4_P1_MODE_HSIC << i * 2;
>>> break;
>>> }
>>>
>>
>> Just realized that is_ohci_port() takes care of 10 cases, so I'll leave
>> it the way it was with if statement.
>
> fair enough.
>
>>> Also, it looks like the whoel for loop with port mode settings could be
>>> re-factored to a separate function to aid readability.
>>>
>>
>> it seems that the purpose of omap_usbhs_init() is to initialize
>> HOSTCONFIG so I see no point in adding another function for it. I can
>> clean it up for better readability though.
>
> when functions get too big, it starts to become a little difficult to
> see bugs. Re-factoring parts of a bigger function, into smaller
> functions helps with that as long as the new functions are
> self-contained and logical. At the end of the day, GCC will inline the
> new smaller functions anyway.
>
OK. I'll split the initialization of different revisions into different
functions.
regards,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
