[PATCH 04/11] ARM: OMAP2+: usb_host_fs: add custom reset for usb_host_fs (fsusb)

[Tony Lindgren]

* Paul Walmsley <paul at pwsan.com> [120607 15:09]:
> On Thu, 7 Jun 2012, Tony Lindgren wrote:
> 
> > Until we have something generic in place to deal with stuff like unused driver
> > reset and idle, how about we set up the driver specific reset parts as inline
> > functions in the driver header?
> 
> You're referring to the driver integration header files in 
> arch/arm/plat-omap/include/ and arch/arm/mach-omap2/, right?  That would 
> avoid the need for "sideways" includes from drivers/.
> 
> > That way the hwmod code can include those functions using the driver register
> > defines. Something like:
> > 
> > static inline int xyz_driver_reset(void __iomem *base, int flags)
> > {
> > 	...
> > }
> > 
> > Then instead of having a separate platform init file for each driver,
> > we could just have a list of reset functions:
> > 
> > static int hwmod_xyz_driver_reset(void __iomem *base, int flags)
> 
> This should probably be passed a struct omap_hwmod * instead of base so 
> it can call the existing hwmod bus related reset functions like 
> omap_hwmod_softreset().  Or were you thinking about open-coding those into 
> this reset function?

Oh OK yeah makes sense as that's hwmod internal function. Then the driver
specific part should use just void __iomem *base and use readl/writel and
live under include/linux/platform_data/omap-usb.h.

> Just as an aside, this function will probably need to be marked 
> __maybe_unused, so the compiler doesn't warn when other files include this 
> header, but don't call the function.

Yeah probably.
 
> > {
> > 	int res;
> > 
> > 	/* do bus related reset here */
> > 	...
> >
> > 	/* call the driver reset */
> > 	res = xyz_driver_reset(base, flags)
> > 
> > 
> > 	/* do more bus related reset here */
> > 	...
> > }
> 
> That's fine with me.  It doesn't matter to me where that code lives as 
> long as it makes technical sense.

OK good. That way we can separate the driver specific part from the bus
code. And the driver maintainers can review the driver specific part of the
idle/reset function. And maybe at some point we'll have device_reset and
device_idle functions and some generic framework in place for it..
 
> I'm hoping that in the near future that we can get rid of these 
> hwmod_xyz_driver_reset() functions.  Instead it should be possible to have 
> the hwmod reset code call functions like xyz_driver_reset_pre_wait() and 
> xyz_driver_reset_post_ocpreset() via optional function pointers at 
> different points in the reset process.  That should allow us to remove the 
> omap_hwmod function calls from the I2C, MSDI, etc. reset functions, and 
> also remove some needlessly duplicated code.

Sounds good to me. Also sounds like that does not need changes to the
driver specific xyz_driver_reset functions.

Regards,

Tony