Messages in this thread | | | Date | Tue, 1 Dec 2020 17:06:30 +0200 | From | Andy Shevchenko <> | Subject | Re: [PATCH 13/18] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows |
| |
On Mon, Nov 30, 2020 at 10:35:51PM +0200, Sakari Ailus wrote: > On Mon, Nov 30, 2020 at 01:31:24PM +0000, Daniel Scally wrote:
...
> > +/* > > + * Extend this array with ACPI Hardware ID's of devices known to be working. > > + * Do not add a HID for a sensor that is not actually supported. > > + */ > > +static const char * const cio2_supported_devices[] = { > > + "INT33BE", > > + "OVTI2680", > > I guess we don't have the known-good frequencies for the CSI-2 bus in > firmware? > > One option would be to put there what the drivers currently use. This > assumes the support for these devices is, well, somewhat opportunistic but > I guess there's no way around that right now at least. > > As the systems are laptops, they're likely somewhat less prone to EMI > issues to begin with than mobile phones anyway.
ACPI has only XTAL clock frequency (dunno if it's the same as CSI-2 bus clock). Currently it may be one out of 19.2 MHz, 24 MHz (with a remark that all sensors must use same value as PMIC can't produce several clocks).
> > +};
...
> > + strcpy(sensor->prop_names.clock_frequency, "clock-frequency"); > > + strcpy(sensor->prop_names.rotation, "rotation"); > > + strcpy(sensor->prop_names.bus_type, "bus-type"); > > + strcpy(sensor->prop_names.data_lanes, "data-lanes"); > > + strcpy(sensor->prop_names.remote_endpoint, "remote-endpoint"); > > Please use the actual field size instead with strncpy / strscpy.
Perhaps Laurent's proposal is better?
-- With Best Regards, Andy Shevchenko
| |