Hello.
Kevin Hilman wrote:
Hi Sergei,
[...]
void __iomem *da8xx_syscfg0_base;
void __iomem *da8xx_syscfg1_base;
+EXPORT_SYMBOL_GPL(da8xx_syscfg0_base);
Would it be an overkill to pass as a resource and ioremap in
usb_hcd_da8xx_probe() instead?
Passing a resource is certainly an overkill.
Do you really want me to pass the single CFGCHIP2 register as a
resource?! Since the rest of the system config. registers don't belong
to USB...
Yes.
Oh horror... can't the patch be accepted as a short-term fix at least?
Not by me, sorry.
This kind of "short-term fix" tends to last a really long time, so is
better prevented early.
It's too late to prevent it -- I've already used the
da8xx_syscfg0_base in the OHCI glue. :-)
Also, I don't see the OHCI driver that uses this variable in mainline
or in linux-next.
Look ar drivers/usb/host/ohci-da8xx.c, it's used via
DA8XX_SYSCFG0_VIRT() macro.
More specifically I'd rather see this address/region passed in a more
normal way: use a resource, a platform_data callback etc. Passing
Platform data callback won't do -- there is no board specifics here.
Well, considering that CFGCHIP2 is shared between MUSB and OHCI,
passing it as a resource is out of question for me. So, platfrom data
callback has to be considered.
Disagree.
I would much rather see this as a resource than as a global variable.
But it's already a global variable!
Yes, and that will hopefully be remedied that can be fixed after
Cyril's ioremap rework.
How Cyril's ioremap() work can help here? You will still need to
ioremap() system config. register range...
Yes, but the base address varible will no longer need to be global
since those DA8XX_SYSCFGx_VIRT() macros can disappear.
Kevin
Ah, you're going tio kill the macros... OHCI glue should stop using
them before that can happen.
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
