Hi Andy
On 01/11/2021 10:29, Andy Shevchenko wrote:
> On Mon, Nov 1, 2021 at 2:12 AM Daniel Scally <djrscally@xxxxxxxxx> wrote:
>> The ov8865 driver as written expects a 24MHz input clock, but the sensor
>> is sometimes found on x86 platforms with a 19.2MHz input clock supplied.
>> Add a set of PLL configurations to the driver to support that rate too.
>> As ACPI doesn't auto-configure the clock rate, check for a clock-frequency
>> during probe and set that rate if one is found.
> ...
>
>> + /*
>> + * We could have either a 24MHz or 19.2MHz clock rate. Check for a
>> + * clock-frequency property and if found, set that rate. This should
>> + * cover the ACPI case. If the system uses devicetree then the
>> + * configured rate should already be set, so we'll have to check it.
>> + */
>> + ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
>> + &rate);
>> + if (!ret) {
>> + ret = clk_set_rate(sensor->extclk, rate);
>> + if (ret) {
>> + dev_err(dev, "failed to set clock rate\n");
>> + return ret;
>> + }
> dev_err_probe()
> 7065f92255bb ("driver core: Clarify that dev_err_probe() is OK even
> w/out -EPROBE_DEFER")
That cuts down on boilerplate usefully, thank you!
>
>> + }
> ...
>
>> + for (i = 0; i < ARRAY_SIZE(supported_extclk_rates); i++) {
>> + if (sensor->extclk_rate == supported_extclk_rates[i])
>> + break;
>> + }
>> +
>> + if (i == ARRAY_SIZE(supported_extclk_rates)) {
>> + dev_err(dev, "clock rate %lu Hz is unsupported\n",
>> + sensor->extclk_rate);
>> ret = -EINVAL;
>> goto error_endpoint;
>> }
> find_closest() ?
>
Not sure about this one though; the values might not match exactly, but
if someone makes a device with this sensor supplying a totally different
clock than 19.2MHz or 24MHz, it ought to fail here rather than attempt
to continue I think
