Attention is currently required from: Tim Wawrzynczak, Nick Vaccaro. Kyösti Mälkki has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/59011 )
Change subject: mb/google,intel: Split chromeos.c files ......................................................................
Patch Set 6:
(3 comments)
File src/mainboard/google/dedede/chromeos.c:
https://review.coreboot.org/c/coreboot/+/59011/comment/7a16667d_4c7aaf73 PS6, Line 15: {GPIO_EC_IN_RW, ACTIVE_HIGH, gpio_get(GPIO_EC_IN_RW), "EC in RW"}, What is the relevance of passing a GPIO pin number and polarity here? Is the payload able (and platform dependent) to read the current GPIO state?
For EC_IN_RW, isn't this flag in vboot2 context too? Or is the entire lb_gpio struct obsolete and was only ever used with depthcharge?
File src/mainboard/google/eve/chromeos.c:
https://review.coreboot.org/c/coreboot/+/59011/comment/0d256aaf_d57f1fed PS6, Line 26: CROS_GPIO_WP_AH(GPIO_PCH_WP, CROS_GPIO_DEVICE_NAME), I understand this fills CRHW.GPIO sysfs subtree with chromeos_acpi driver. Is there some specification what one expects to see there?
Does a virtual GPIO need a name or polarity? How does user-space determine the state of it with no GPIO associated?
CROS_GPIO_DEVICE_NAME does not expand to ACPI device object name. Can userspace do anything with a GPIO pin number like GPIO_PCH_WP?
File src/mainboard/google/parrot/chromeos.c:
https://review.coreboot.org/c/coreboot/+/59011/comment/ad460c08_f622ebec PS6, Line 25: {101, ACTIVE_LOW, (gen_pmcon_1 >> 9) & 1, "power"}, GPIO pin 101? Should these non-GPIO pins be -1 for virtual?
-
Kyösti Mälkki (Code Review)