Re: [PATCH 00/24] ARM: OMAP2+: Adapt to ehci-omap changes for 3.10

[Roger Quadros]

On 03/12/2013 06:40 PM, Tony Lindgren wrote:
> * Roger Quadros <rogerq@xxxxxx> [130312 04:47]:
>> Hi Tony,
>>
>> These patches provide the SoC side code required to support
>> the changes in the OMAP USB Host drivers done in [1], [2] & [3].
> ... 
> 
>>  arch/arm/mach-omap2/board-3430sdp.c                |   97 +++++++++++++++-
>>  arch/arm/mach-omap2/board-3630sdp.c                |  100 +++++++++++++++-
>>  arch/arm/mach-omap2/board-am3517crane.c            |   95 +++++++++++++--
>>  arch/arm/mach-omap2/board-am3517evm.c              |   66 ++++++++++-
>>  arch/arm/mach-omap2/board-cm-t35.c                 |   95 ++++++++++++++-
>>  arch/arm/mach-omap2/board-cm-t3517.c               |   97 +++++++++++++++-
>>  arch/arm/mach-omap2/board-devkit8000.c             |   20 ++--
>>  arch/arm/mach-omap2/board-generic.c                |   67 +++++++++++
>>  arch/arm/mach-omap2/board-igep0020.c               |  112 ++++++++++++++++---
>>  arch/arm/mach-omap2/board-omap3beagle.c            |   93 +++++++++++++--
>>  arch/arm/mach-omap2/board-omap3evm.c               |   62 ++++++++--
>>  arch/arm/mach-omap2/board-omap3pandora.c           |   52 +++++++--
>>  arch/arm/mach-omap2/board-omap3stalker.c           |   52 +++++++-
>>  arch/arm/mach-omap2/board-omap3touchbook.c         |   62 +++++++++-
>>  arch/arm/mach-omap2/board-omap4panda.c             |  122 ++++++++++++++------
>>  arch/arm/mach-omap2/board-overo.c                  |   54 ++++++++-
>>  arch/arm/mach-omap2/board-zoom.c                   |   56 ++++++++-
> 
> Can't you have some mach-omap2/ehci-common.c that takes care
> of the initializiation to avoid this much addition to the
> board-*.c files? You may be able to have just a common function
> to do it and pass few parameters?

Since we moved reset and power handling for the USB PHYs from omap-echi
driver into the USB PHY driver we need to define the regulator data
for RESET and Power line of each PHY. So most of the code added is just
regulator data for the PHY rather than omap-ehci.

Instead of a common function, I can implement some macros that make it
easier to define the regulators for the PHY in the board files.
Does this sound OK?

Personally I don't like such macros because it hides the implementation
and is difficult to read/debug.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/