Tim Wawrzynczak has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/45091 )
Change subject: drivers/intel/mipi_camera: Add compatible field for NVM ......................................................................
Patch Set 3:
Patch Set 1:
Patch Set 1:
Patch Set 1:
I'm not sure what to make of the "unused" claim. Here's a counter-example: https://review.coreboot.org/c/coreboot/+/31168/1/src/mainboard/google/poppy/...
I'm not clear on whether the scheme for NVM has changed.
"Unused" may not be the correct word. From what I understand looking at the driver code (drivers/misc/eeprom/at24.c), the schemes may be used interchangeably. i.e., HID with INT3499 or a HID with PRP0001 and compatibility with "atmel,24c08"
It does appear as though both are equivalent, though it also looks like almost any of the properties that are set/defaulted based on the ID can be overridden by settings values for ACPI properties "size", "address-width", "read-only", "num-addresses", "no-read-rollover". The main exception seems to be there's no way to set flags for AT24_FLAG_SERIAL, AT24_FLAG_MAC, or AT24_FLAG_IRUGO, though I'm guessing these aren't usually relevant for camera use.
It seems like there's 3 possible schemes: 1) INT3499 with explicit ACPI properties, 2) PRP0001 with a specific compatible string, and 3) scheme #2 plus explicit ACPI properties. To me scheme #3 seems to be a bit redundant and invite inconsistencies with conflicting information, so I'd favor one of the other two schemes. Scheme #1 helps keep consistent with older boards and relies less on whether a OS driver is using appropriate values for a given compat string (it also avoids the need to look up a suitable compat string or deal with a situation where none of the available compat strings matches the characteristics of a new chip).
To me, I see 1 vs. 2 as just about binding the device to a driver, and if the driver has support for OF already, but not ACPI, it's much simpler to just stick with PRP0001/_DSD until we can get a driver upstreamed.
Anyway, my long-term motivation would be to see Intel's drivers for Linux and Windows converge on a single ACPI scheme, so I'm concerned to see there's now additional schemes going on on the Linux side for advertising NVM and hope there can be at least some kind of consistency/re-convergence on how the NVM is advertised.
I have zero familiarity with the way Windows consumes ACPI, is there some info available on how it looks there?