On Tue, Dec 01, 2020 at 08:55:48PM +0200, Laurent Pinchart wrote:
> On Tue, Dec 01, 2020 at 08:54:17PM +0200, Andy Shevchenko wrote:
> > On Tue, Dec 01, 2020 at 08:30:03AM +0000, Dan Scally wrote:
> > > On 30/11/2020 20:07, Andy Shevchenko wrote:
...
> > > >> +static struct int3472_sensor_regulator_map int3472_sensor_regulator_maps[] = {
> > > >> + { "GNDF140809R", 2, miix_510_ov2680 },
> > > >> + { "YHCU", 2, surface_go2_ov5693 },
> > > >> + { "MSHW0070", 2, surface_book_ov5693 },
> > > >> +};
> > > >
> > > > Hmm... Usual way is to use DMI for that. I'm not sure above will not give us
> > > > false positive matches.
> > >
> > > I considered DMI too, no problem to switch to that if it's a better choice.
> >
> > I prefer DMI as it's a standard way to describe platform quirks in x86 world.
>
> Do you think the Windows driver would use DMI ?
Linux is using DMI for quirks.
> That seems quite
> unlikely to me, given how they would have to release a new driver binary
> for every machine. I'm pretty sure that a different mechanism is used to
> identify camera integration, and I think it would make sense to follow
> the same approach. That would allow us to avoid large tables of DMI
> identifiers that would need to be constently updated, potentially making
> user experience better.
All Surface family can be matched in a way as Apple machines [1].
[1]: https://lkml.org/lkml/2020/4/15/1198
--
With Best Regards,
Andy Shevchenko
