On Wed, Feb 21, 2018 at 8:20 PM, Ard Biesheuvel
[off-list ref] wrote:

On 20 February 2018 at 19:39, Andy Shevchenko [off-list ref] wrote:

quoted

On Tue, Feb 20, 2018 at 8:04 PM, Ard Biesheuvel
[off-list ref] wrote:

quoted

On 20 February 2018 at 14:02, Andy Shevchenko [off-list ref] wrote:

quoted

quoted

quoted

quoted

+               ret = device_property_read_u32(&pdev->dev,
+                                              "socionext,pclk-rate",
+                                              &i2c->clkrate);

I suppose for ACPI we just register a fixed rate clock and use it in
the driver in the same way as in OF case.
I guess at some point we even can provide a generic clock provider for
ACPI based on rate property.

quoted

Is there a question here? Do you want me to change anything?

Is it opener for discussion. At least in the drivers we have done for
x86 we do the way I described.

See, for example, drivers/mfd/intel-lpss.c

OK, I see what you mean now. But for this driver, creating a fixed
rate clock with no controls whatsoever, only to interrogate it for its
rate (which we retrieved from the ACPI device node in the first place)
seems rather pointless to me. Am I missing something here?

Somehow you are right. That's why I'm thinking that we need to provide
a generic clock provider for such cases.
It's really not a driver business to know the details of resource provider.

-- 
With Best Regards,
Andy Shevchenko