Hi, 

On Mon, 2014-02-10 at 12:29 -0800, Courtney Cavin wrote: 

On Mon, Feb 10, 2014 at 08:41:44PM +0100, Ivan T. Ivanov wrote:

quoted

Hi,

On Mon, 2014-02-10 at 11:47 -0600, Andy Gross wrote:

quoted

On Mon, Feb 10, 2014 at 06:55:02PM +0200, Ivan T. Ivanov wrote:

[....]

quoted

quoted

quoted

quoted

Bail here?

I don't know. What will be the consequences if controller continue to
operate on its default rate?

It is unclear.  But if you can't set the rate that is configured or if there is
a misconfiguration, it's probably better to exit the probe and catch it here.

My preference is to delay clock speed change till first
SPI transfer. And use wherever transfer itself mandate.

That works.  My only concern is that it might be nice to catch a configuration
problem early rather than wait for the SPI transfer to fail continuously.

If developer is skilled enough to know which version controller is,
(s)he will be able to put the right frequency constrain here :-)

A developer doesn't have to have much skill at all to copy-paste DT
configurations around and muck with numbers....  I agree with Andy here,
early validation is a good idea here, at the very least, some sanity
checks.

Actually, thinking more on this. Supplying SPI controller with, 
let say 50MHz, which is what success of clk_set_rate() means, doesn't
necessarily guaranteer that controller will be able to do transfers
properly, right? Setting frequency at this point didn't bring any
benefit. 

Regards,
Ivan

-Courtney

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html