Re: [PATCH 2/3] ARM: OMAP2+: Add support to parse optional clk info from DT

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Wed, Aug 14, 2013 at 02:49:04PM +0100, Mark Rutland wrote:
> [Adding Mike Turquette and dt maintainers]
> 
> On Wed, Aug 14, 2013 at 02:39:44PM +0100, Nishanth Menon wrote:
> > yes. the idea being, we now have a meaning to the clock name - there are 
> > two types of clocks here.. functional and optional, we *might* have 
> > facility to add interface clock(we dont know interface clock handling 
> > yet, but something in the future).. we might increase the support for 
> > number of functional clocks.. it might help to keep the format such that 
> > it is a "bit extendable".
> 
> I completely disagree. The only things that should appear in clock-names
> are the names of the clock inputs that appear in the manual for the
> device. The driver should know which ones are optional, as that's a
> fixed property of the IP and the way the driver uses it.
> 
> You should not be embedding additional semantics in name properties.

Agreed.  I've been on at people about this for years, and every time they
go off and do something else, it ultimately ends up coming back to bite
them.  Clock names _are_ the clock input names as far as device drivers
are concerned, and nothing else.

If there are optional clocks, then the driver should be doing as Mark
says - the driver should try to get them, and if it fails to get them
then they're quite simply not provided by the platform.  If there are
optional clocks which the device driver does not know about (or even
need to know about) then that too should not be a problem - the driver
just doesn't have to touch them.

If they're optional, but required for the device to function, then the
driver should get them and control them as necessary.