On Wed, Feb 21, 2018 at 8:20 PM, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > On 20 February 2018 at 19:39, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: >> On Tue, Feb 20, 2018 at 8:04 PM, Ard Biesheuvel >> <ard.biesheuvel@xxxxxxxxxx> wrote: >>> On 20 February 2018 at 14:02, Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: >>>>> + 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. >> >>> 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
