Sergei Shtylyov <[email protected]> writes: > 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. Also, I don't see the OHCI driver that uses this variable in mainline or in linux-next. >> 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. > >> data from platform code to drivers in a global variables is simply not >> acceptable. >> > > Why? Can you elaborate?.. Because there are existing, established methods for platform/board code to communicate data to drivers. >>>> 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 _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
