On Friday 21 February 2014 16:18:54 Jonas Gorski wrote: > On Fri, Feb 21, 2014 at 3:59 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Friday 21 February 2014 15:48:04 Jonas Gorski wrote: > >> > >> There already is a (non-OF) user for this driver that exports a > >> "periph" clock, which is where the name comes from. It currently does > >> all clock lookups purely based on the clock name, not the device name > >> itself. Of course we can just make it get a different named clock when > >> of_node is present; that should satisfy both. > > > > I think you are referring to arch/mips/bcm63xx/clk.c, but that doesn't > > actually use clkdev at all and instead expects device drivers to know > > the name of *output* of the clock controllers. You can't use that > > name in the binding for a device, which needs to know the name of > > the *input* from the clock consumer point of view. > > That's why I was suggesting making the driver do a lookup on the input > name in case of probing through OF (having an of_node), and using > the "legacy" output name else. That way the binding is not limited to > the output name of bcm63xx/mips anymore. Ok, fair enough. > > An easy solution would be to register a clkdev lookup table in > > the above clock driver. > > Requiring bcm63xx/mips to implement clkdev would be IMHO an > unnecessary burden just so bcm63xx/arm using OF can reuse this driver. > Letting bcm63xx use a clkdev lookup table (or rather tables, as each > chip is different) is good mid or long term goal, but it should not > block other users. Ah, that's probably right. I was assuming you'd only need to add a single function call to register a table, but I see now that using clkdev would impact the entire clk implementation on bcm63xx. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
