Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
Fixes: 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") Cc: stable@vger.kernel.org Reported-by: Alex Levin levinale@chromium.org Signed-off-by: Michal Stanek mst@semihalf.com --- drivers/gpio/gpiolib-acpi.c | 102 ++++++++++++++++++++- drivers/pinctrl/intel/pinctrl-cherryview.c | 63 ++++++++++--- 2 files changed, 150 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c index 31fee5e918b7..b5358facf3fb 100644 --- a/drivers/gpio/gpiolib-acpi.c +++ b/drivers/gpio/gpiolib-acpi.c @@ -23,6 +23,7 @@
#define QUIRK_NO_EDGE_EVENTS_ON_BOOT 0x01l #define QUIRK_NO_WAKEUP 0x02l +#define QUIRK_NEED_ACPI_GPIO_TRANSLATION 0x04l
static int run_edge_events_on_boot = -1; module_param(run_edge_events_on_boot, int, 0444); @@ -34,6 +35,11 @@ module_param(honor_wakeup, int, 0444); MODULE_PARM_DESC(honor_wakeup, "Honor the ACPI wake-capable flag: 0=no, 1=yes, -1=auto");
+static int need_acpi_gpio_translation = -1; +module_param(need_acpi_gpio_translation, int, 0444); +MODULE_PARM_DESC(need_acpi_gpio_translation, + "Do custom ACPI GPIO number translation: 0=no, 1=yes, -1=auto"); + /** * struct acpi_gpio_event - ACPI GPIO event handler data * @@ -98,6 +104,62 @@ static int acpi_gpiochip_find(struct gpio_chip *gc, void *data) return ACPI_HANDLE(gc->parent) == data; }
+#ifdef CONFIG_PINCTRL +/** + * acpi_gpiochip_pin_to_gpio_offset() - translates ACPI GPIO to Linux GPIO + * @gdev: GPIO device + * @pin: ACPI GPIO pin number from GpioIo/GpioInt resource + * + * Function takes ACPI GpioIo/GpioInt pin number as a parameter and + * translates it to a corresponding offset suitable to be passed to a + * GPIO controller driver. + * + * Typically the returned offset is same as @pin, but if the GPIO + * controller uses pin controller and the mapping is not contiguous the + * offset might be different. + */ +static int acpi_gpiochip_pin_to_gpio_offset(struct gpio_device *gdev, int pin) +{ + struct gpio_pin_range *pin_range; + + /* Only do translation on selected platforms */ + if (!need_acpi_gpio_translation) + return pin; + + /* If there are no ranges in this chip, use 1:1 mapping */ + if (list_empty(&gdev->pin_ranges)) + return pin; + + list_for_each_entry(pin_range, &gdev->pin_ranges, node) { + const struct pinctrl_gpio_range *range = &pin_range->range; + int i; + + if (range->pins) { + for (i = 0; i < range->npins; i++) { + if (range->pins[i] == pin) + return range->base + i - gdev->base; + } + } else { + if (pin >= range->pin_base && + pin < range->pin_base + range->npins) { + unsigned int gpio_base; + + gpio_base = range->base - gdev->base; + return gpio_base + pin - range->pin_base; + } + } + } + + return -EINVAL; +} +#else +static inline int acpi_gpiochip_pin_to_gpio_offset(struct gpio_device *gdev, + int pin) +{ + return pin; +} +#endif + /** * acpi_get_gpiod() - Translate ACPI GPIO pin to GPIO descriptor usable with GPIO API * @path: ACPI GPIO controller full path name, (e.g. "\_SB.GPO1") @@ -113,6 +175,7 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int pin) struct gpio_chip *chip; acpi_handle handle; acpi_status status; + int offset;
status = acpi_get_handle(NULL, path, &handle); if (ACPI_FAILURE(status)) @@ -122,7 +185,11 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int pin) if (!chip) return ERR_PTR(-EPROBE_DEFER);
- return gpiochip_get_desc(chip, pin); + offset = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin); + if (offset < 0) + return ERR_PTR(offset); + + return gpiochip_get_desc(chip, offset); }
static irqreturn_t acpi_gpio_irq_handler(int irq, void *data) @@ -236,6 +303,10 @@ static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares, if (!handler) return AE_OK;
+ pin = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin); + if (pin < 0) + return AE_BAD_PARAMETER; + desc = gpiochip_request_own_desc(chip, pin, "ACPI:Event", GPIO_ACTIVE_HIGH, GPIOD_IN); if (IS_ERR(desc)) { @@ -958,6 +1029,12 @@ acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address, struct gpio_desc *desc; bool found;
+ pin = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin); + if (pin < 0) { + status = AE_BAD_PARAMETER; + goto out; + } + mutex_lock(&achip->conn_lock);
found = false; @@ -1086,7 +1163,11 @@ acpi_gpiochip_parse_own_gpio(struct acpi_gpio_chip *achip, if (ret < 0) return ERR_PTR(ret);
- desc = gpiochip_get_desc(chip, gpios[0]); + ret = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, gpios[0]); + if (ret < 0) + return ERR_PTR(ret); + + desc = gpiochip_get_desc(chip, ret); if (IS_ERR(desc)) return desc;
@@ -1360,6 +1441,17 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] = { }, .driver_data = (void *)QUIRK_NO_WAKEUP, }, + { + /* + * Some Braswell based Google Chromebooks need custom ACPI GPIO + * number translation due to hardcoded GPIO numbers in firmware. + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"), + DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"), + }, + .driver_data = (void *)QUIRK_NEED_ACPI_GPIO_TRANSLATION, + }, {} /* Terminating entry */ };
@@ -1385,6 +1477,12 @@ static int acpi_gpio_setup_params(void) else honor_wakeup = 1; } + if (need_acpi_gpio_translation < 0) { + if (quirks & QUIRK_NEED_ACPI_GPIO_TRANSLATION) + need_acpi_gpio_translation = 1; + else + need_acpi_gpio_translation = 0; + }
return 0; } diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c index 4c74fdde576d..dd190ac6b11c 100644 --- a/drivers/pinctrl/intel/pinctrl-cherryview.c +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c @@ -119,6 +119,7 @@ struct chv_gpio_pinrange { * @nfunctions: Number of functions * @gpio_ranges: An array of GPIO ranges in this community * @ngpio_ranges: Number of GPIO ranges + * @ngpios: Total number of GPIOs in this community * @nirqs: Total number of IRQs this community can generate * @acpi_space_id: An address space ID for ACPI OpRegion handler */ @@ -132,6 +133,7 @@ struct chv_community { size_t nfunctions; const struct chv_gpio_pinrange *gpio_ranges; size_t ngpio_ranges; + size_t ngpios; size_t nirqs; acpi_adr_space_type acpi_space_id; }; @@ -380,6 +382,7 @@ static const struct chv_community southwest_community = { .nfunctions = ARRAY_SIZE(southwest_functions), .gpio_ranges = southwest_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(southwest_gpio_ranges), + .ngpios = ARRAY_SIZE(southwest_pins), /* * Southwest community can generate GPIO interrupts only for the * first 8 interrupts. The upper half (8-15) can only be used to @@ -469,6 +472,7 @@ static const struct chv_community north_community = { .npins = ARRAY_SIZE(north_pins), .gpio_ranges = north_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(north_gpio_ranges), + .ngpios = ARRAY_SIZE(north_pins), /* * North community can generate GPIO interrupts only for the first * 8 interrupts. The upper half (8-15) can only be used to trigger @@ -517,6 +521,7 @@ static const struct chv_community east_community = { .npins = ARRAY_SIZE(east_pins), .gpio_ranges = east_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(east_gpio_ranges), + .ngpios = ARRAY_SIZE(east_pins), .nirqs = 16, .acpi_space_id = 0x93, }; @@ -643,6 +648,7 @@ static const struct chv_community southeast_community = { .nfunctions = ARRAY_SIZE(southeast_functions), .gpio_ranges = southeast_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(southeast_gpio_ranges), + .ngpios = ARRAY_SIZE(southeast_pins), .nirqs = 16, .acpi_space_id = 0x94, }; @@ -1236,14 +1242,39 @@ static struct pinctrl_desc chv_pinctrl_desc = { .owner = THIS_MODULE, };
+static const struct dmi_system_id need_acpi_gpio_translation[] = { + { + /* + * Some Braswell based Google Chromebooks need custom ACPI GPIO + * number translation due to hardcoded GPIO numbers in firmware. + */ + .ident = "Intel_Strago based Chromebooks (All models)", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"), + DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"), + }, + }, +}; + +static unsigned int chv_gpio_offset_to_pin(struct chv_pinctrl *pctrl, + unsigned int offset) +{ + /* Mapping is not 1:1 on some platforms */ + if (dmi_check_system(need_acpi_gpio_translation)) + return pctrl->community->pins[offset].number; + else + return offset; +} + static int chv_gpio_get(struct gpio_chip *chip, unsigned int offset) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; u32 ctrl0, cfg;
raw_spin_lock_irqsave(&chv_lock, flags); - ctrl0 = readl(chv_padreg(pctrl, offset, CHV_PADCTRL0)); + ctrl0 = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0)); raw_spin_unlock_irqrestore(&chv_lock, flags);
cfg = ctrl0 & CHV_PADCTRL0_GPIOCFG_MASK; @@ -1257,13 +1288,14 @@ static int chv_gpio_get(struct gpio_chip *chip, unsigned int offset) static void chv_gpio_set(struct gpio_chip *chip, unsigned int offset, int value) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; void __iomem *reg; u32 ctrl0;
raw_spin_lock_irqsave(&chv_lock, flags);
- reg = chv_padreg(pctrl, offset, CHV_PADCTRL0); + reg = chv_padreg(pctrl, pin, CHV_PADCTRL0); ctrl0 = readl(reg);
if (value) @@ -1279,11 +1311,12 @@ static void chv_gpio_set(struct gpio_chip *chip, unsigned int offset, int value) static int chv_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); u32 ctrl0, direction; unsigned long flags;
raw_spin_lock_irqsave(&chv_lock, flags); - ctrl0 = readl(chv_padreg(pctrl, offset, CHV_PADCTRL0)); + ctrl0 = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0)); raw_spin_unlock_irqrestore(&chv_lock, flags);
direction = ctrl0 & CHV_PADCTRL0_GPIOCFG_MASK; @@ -1322,7 +1355,7 @@ static void chv_gpio_irq_ack(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc); - int pin = irqd_to_hwirq(d); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d)); u32 intr_line;
raw_spin_lock(&chv_lock); @@ -1339,7 +1372,7 @@ static void chv_gpio_irq_mask_unmask(struct irq_data *d, bool mask) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc); - int pin = irqd_to_hwirq(d); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d)); u32 value, intr_line; unsigned long flags;
@@ -1384,7 +1417,8 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d) if (irqd_get_trigger_type(d) == IRQ_TYPE_NONE) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc); - unsigned int pin = irqd_to_hwirq(d); + unsigned int offset = irqd_to_hwirq(d); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); irq_flow_handler_t handler; unsigned long flags; u32 intsel, value; @@ -1402,7 +1436,7 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d)
if (!pctrl->intr_lines[intsel]) { irq_set_handler_locked(d, handler); - pctrl->intr_lines[intsel] = pin; + pctrl->intr_lines[intsel] = offset; } raw_spin_unlock_irqrestore(&chv_lock, flags); } @@ -1415,7 +1449,8 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc); - unsigned int pin = irqd_to_hwirq(d); + unsigned int offset = irqd_to_hwirq(d); + unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; u32 value;
@@ -1461,7 +1496,7 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type) value &= CHV_PADCTRL0_INTSEL_MASK; value >>= CHV_PADCTRL0_INTSEL_SHIFT;
- pctrl->intr_lines[value] = pin; + pctrl->intr_lines[value] = offset;
if (type & IRQ_TYPE_EDGE_BOTH) irq_set_handler_locked(d, handle_edge_irq); @@ -1591,17 +1626,19 @@ static int chv_gpio_add_pin_ranges(struct gpio_chip *chip) struct chv_pinctrl *pctrl = gpiochip_get_data(chip); const struct chv_community *community = pctrl->community; const struct chv_gpio_pinrange *range; - int ret, i; + int ret, i, offset;
- for (i = 0; i < community->ngpio_ranges; i++) { + for (i = 0, offset = 0; i < community->ngpio_ranges; i++) { range = &community->gpio_ranges[i]; ret = gpiochip_add_pin_range(chip, dev_name(pctrl->dev), - range->base, range->base, + offset, range->base, range->npins); if (ret) { dev_err(pctrl->dev, "failed to add GPIO pin range\n"); return ret; } + + offset += range->npins; }
return 0; @@ -1617,7 +1654,7 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
*chip = chv_gpio_chip;
- chip->ngpio = community->pins[community->npins - 1].number + 1; + chip->ngpio = community->ngpios; chip->label = dev_name(pctrl->dev); chip->add_pin_ranges = chv_gpio_add_pin_ranges; chip->parent = pctrl->dev;
On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
Hi,
Can you elaborate this? I was under the impression that all the different Strago systems have been already worked around by patches from Dmitry (Cc'd).
What GPIO(s) we are talking about and how does it show up to the user?
Fixes: 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") Cc: stable@vger.kernel.org Reported-by: Alex Levin levinale@chromium.org Signed-off-by: Michal Stanek mst@semihalf.com
drivers/gpio/gpiolib-acpi.c | 102 ++++++++++++++++++++- drivers/pinctrl/intel/pinctrl-cherryview.c | 63 ++++++++++--- 2 files changed, 150 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c index 31fee5e918b7..b5358facf3fb 100644 --- a/drivers/gpio/gpiolib-acpi.c +++ b/drivers/gpio/gpiolib-acpi.c @@ -23,6 +23,7 @@ #define QUIRK_NO_EDGE_EVENTS_ON_BOOT 0x01l #define QUIRK_NO_WAKEUP 0x02l +#define QUIRK_NEED_ACPI_GPIO_TRANSLATION 0x04l static int run_edge_events_on_boot = -1; module_param(run_edge_events_on_boot, int, 0444); @@ -34,6 +35,11 @@ module_param(honor_wakeup, int, 0444); MODULE_PARM_DESC(honor_wakeup, "Honor the ACPI wake-capable flag: 0=no, 1=yes, -1=auto"); +static int need_acpi_gpio_translation = -1; +module_param(need_acpi_gpio_translation, int, 0444); +MODULE_PARM_DESC(need_acpi_gpio_translation,
"Do custom ACPI GPIO number translation: 0=no, 1=yes, -1=auto");/**
- struct acpi_gpio_event - ACPI GPIO event handler data
@@ -98,6 +104,62 @@ static int acpi_gpiochip_find(struct gpio_chip *gc, void *data) return ACPI_HANDLE(gc->parent) == data; } +#ifdef CONFIG_PINCTRL +/**
- acpi_gpiochip_pin_to_gpio_offset() - translates ACPI GPIO to Linux GPIO
- @gdev: GPIO device
- @pin: ACPI GPIO pin number from GpioIo/GpioInt resource
- Function takes ACPI GpioIo/GpioInt pin number as a parameter and
- translates it to a corresponding offset suitable to be passed to a
- GPIO controller driver.
- Typically the returned offset is same as @pin, but if the GPIO
- controller uses pin controller and the mapping is not contiguous the
- offset might be different.
- */
+static int acpi_gpiochip_pin_to_gpio_offset(struct gpio_device *gdev, int pin) +{
- struct gpio_pin_range *pin_range;
- /* Only do translation on selected platforms */
- if (!need_acpi_gpio_translation)
return pin;- /* If there are no ranges in this chip, use 1:1 mapping */
- if (list_empty(&gdev->pin_ranges))
return pin;- list_for_each_entry(pin_range, &gdev->pin_ranges, node) {
const struct pinctrl_gpio_range *range = &pin_range->range;int i;if (range->pins) {for (i = 0; i < range->npins; i++) {if (range->pins[i] == pin)return range->base + i - gdev->base;}} else {if (pin >= range->pin_base &&pin < range->pin_base + range->npins) {unsigned int gpio_base;gpio_base = range->base - gdev->base;return gpio_base + pin - range->pin_base;}}- }
- return -EINVAL;
+} +#else +static inline int acpi_gpiochip_pin_to_gpio_offset(struct gpio_device *gdev,
int pin)+{
- return pin;
+} +#endif
/**
- acpi_get_gpiod() - Translate ACPI GPIO pin to GPIO descriptor usable with GPIO API
- @path: ACPI GPIO controller full path name, (e.g. "\_SB.GPO1")
@@ -113,6 +175,7 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int pin) struct gpio_chip *chip; acpi_handle handle; acpi_status status;
- int offset;
status = acpi_get_handle(NULL, path, &handle); if (ACPI_FAILURE(status)) @@ -122,7 +185,11 @@ static struct gpio_desc *acpi_get_gpiod(char *path, int pin) if (!chip) return ERR_PTR(-EPROBE_DEFER);
- return gpiochip_get_desc(chip, pin);
- offset = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin);
- if (offset < 0)
return ERR_PTR(offset);- return gpiochip_get_desc(chip, offset);
} static irqreturn_t acpi_gpio_irq_handler(int irq, void *data) @@ -236,6 +303,10 @@ static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares, if (!handler) return AE_OK;
- pin = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin);
- if (pin < 0)
return AE_BAD_PARAMETER;- desc = gpiochip_request_own_desc(chip, pin, "ACPI:Event", GPIO_ACTIVE_HIGH, GPIOD_IN); if (IS_ERR(desc)) {
@@ -958,6 +1029,12 @@ acpi_gpio_adr_space_handler(u32 function, acpi_physical_address address, struct gpio_desc *desc; bool found;
pin = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, pin);if (pin < 0) {status = AE_BAD_PARAMETER;goto out;}- mutex_lock(&achip->conn_lock);
found = false; @@ -1086,7 +1163,11 @@ acpi_gpiochip_parse_own_gpio(struct acpi_gpio_chip *achip, if (ret < 0) return ERR_PTR(ret);
- desc = gpiochip_get_desc(chip, gpios[0]);
- ret = acpi_gpiochip_pin_to_gpio_offset(chip->gpiodev, gpios[0]);
- if (ret < 0)
return ERR_PTR(ret);- desc = gpiochip_get_desc(chip, ret); if (IS_ERR(desc)) return desc;
@@ -1360,6 +1441,17 @@ static const struct dmi_system_id gpiolib_acpi_quirks[] = { }, .driver_data = (void *)QUIRK_NO_WAKEUP, },
- {
/** Some Braswell based Google Chromebooks need custom ACPI GPIO* number translation due to hardcoded GPIO numbers in firmware.*/.matches = {DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"),},
AFAIK this now applies pretty much all Strago systems so at least this one should explicitly match only the affected firmware versions.
.driver_data = (void *)QUIRK_NEED_ACPI_GPIO_TRANSLATION,- }, {} /* Terminating entry */
}; @@ -1385,6 +1477,12 @@ static int acpi_gpio_setup_params(void) else honor_wakeup = 1; }
- if (need_acpi_gpio_translation < 0) {
if (quirks & QUIRK_NEED_ACPI_GPIO_TRANSLATION)need_acpi_gpio_translation = 1;elseneed_acpi_gpio_translation = 0;- }
return 0; } diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c index 4c74fdde576d..dd190ac6b11c 100644 --- a/drivers/pinctrl/intel/pinctrl-cherryview.c +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c @@ -119,6 +119,7 @@ struct chv_gpio_pinrange {
- @nfunctions: Number of functions
- @gpio_ranges: An array of GPIO ranges in this community
- @ngpio_ranges: Number of GPIO ranges
*/
- @ngpios: Total number of GPIOs in this community
- @nirqs: Total number of IRQs this community can generate
- @acpi_space_id: An address space ID for ACPI OpRegion handler
@@ -132,6 +133,7 @@ struct chv_community { size_t nfunctions; const struct chv_gpio_pinrange *gpio_ranges; size_t ngpio_ranges;
- size_t ngpios; size_t nirqs; acpi_adr_space_type acpi_space_id;
}; @@ -380,6 +382,7 @@ static const struct chv_community southwest_community = { .nfunctions = ARRAY_SIZE(southwest_functions), .gpio_ranges = southwest_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(southwest_gpio_ranges),
- .ngpios = ARRAY_SIZE(southwest_pins), /*
- Southwest community can generate GPIO interrupts only for the
- first 8 interrupts. The upper half (8-15) can only be used to
@@ -469,6 +472,7 @@ static const struct chv_community north_community = { .npins = ARRAY_SIZE(north_pins), .gpio_ranges = north_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(north_gpio_ranges),
- .ngpios = ARRAY_SIZE(north_pins), /*
- North community can generate GPIO interrupts only for the first
- 8 interrupts. The upper half (8-15) can only be used to trigger
@@ -517,6 +521,7 @@ static const struct chv_community east_community = { .npins = ARRAY_SIZE(east_pins), .gpio_ranges = east_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(east_gpio_ranges),
- .ngpios = ARRAY_SIZE(east_pins), .nirqs = 16, .acpi_space_id = 0x93,
}; @@ -643,6 +648,7 @@ static const struct chv_community southeast_community = { .nfunctions = ARRAY_SIZE(southeast_functions), .gpio_ranges = southeast_gpio_ranges, .ngpio_ranges = ARRAY_SIZE(southeast_gpio_ranges),
- .ngpios = ARRAY_SIZE(southeast_pins), .nirqs = 16, .acpi_space_id = 0x94,
}; @@ -1236,14 +1242,39 @@ static struct pinctrl_desc chv_pinctrl_desc = { .owner = THIS_MODULE, }; +static const struct dmi_system_id need_acpi_gpio_translation[] = {
- {
/** Some Braswell based Google Chromebooks need custom ACPI GPIO* number translation due to hardcoded GPIO numbers in firmware.*/.ident = "Intel_Strago based Chromebooks (All models)",.matches = {DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"),
Same comment here. Are you saying all Stragos are broken in the current mainline?
},- },
+};
+static unsigned int chv_gpio_offset_to_pin(struct chv_pinctrl *pctrl,
unsigned int offset)+{
- /* Mapping is not 1:1 on some platforms */
- if (dmi_check_system(need_acpi_gpio_translation))
return pctrl->community->pins[offset].number;- else
return offset;+}
static int chv_gpio_get(struct gpio_chip *chip, unsigned int offset) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; u32 ctrl0, cfg;
raw_spin_lock_irqsave(&chv_lock, flags);
- ctrl0 = readl(chv_padreg(pctrl, offset, CHV_PADCTRL0));
- ctrl0 = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0)); raw_spin_unlock_irqrestore(&chv_lock, flags);
cfg = ctrl0 & CHV_PADCTRL0_GPIOCFG_MASK; @@ -1257,13 +1288,14 @@ static int chv_gpio_get(struct gpio_chip *chip, unsigned int offset) static void chv_gpio_set(struct gpio_chip *chip, unsigned int offset, int value) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; void __iomem *reg; u32 ctrl0;
raw_spin_lock_irqsave(&chv_lock, flags);
- reg = chv_padreg(pctrl, offset, CHV_PADCTRL0);
- reg = chv_padreg(pctrl, pin, CHV_PADCTRL0); ctrl0 = readl(reg);
if (value) @@ -1279,11 +1311,12 @@ static void chv_gpio_set(struct gpio_chip *chip, unsigned int offset, int value) static int chv_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) { struct chv_pinctrl *pctrl = gpiochip_get_data(chip);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); u32 ctrl0, direction; unsigned long flags;
raw_spin_lock_irqsave(&chv_lock, flags);
- ctrl0 = readl(chv_padreg(pctrl, offset, CHV_PADCTRL0));
- ctrl0 = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0)); raw_spin_unlock_irqrestore(&chv_lock, flags);
direction = ctrl0 & CHV_PADCTRL0_GPIOCFG_MASK; @@ -1322,7 +1355,7 @@ static void chv_gpio_irq_ack(struct irq_data *d) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
- int pin = irqd_to_hwirq(d);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d)); u32 intr_line;
raw_spin_lock(&chv_lock); @@ -1339,7 +1372,7 @@ static void chv_gpio_irq_mask_unmask(struct irq_data *d, bool mask) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
- int pin = irqd_to_hwirq(d);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, irqd_to_hwirq(d)); u32 value, intr_line; unsigned long flags;
@@ -1384,7 +1417,8 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d) if (irqd_get_trigger_type(d) == IRQ_TYPE_NONE) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
unsigned int pin = irqd_to_hwirq(d);
unsigned int offset = irqd_to_hwirq(d);unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset);@@ -1402,7 +1436,7 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d) if (!pctrl->intr_lines[intsel]) { irq_set_handler_locked(d, handler);
pctrl->intr_lines[intsel] = pin;
pctrl->intr_lines[intsel] = offset;@@ -1415,7 +1449,8 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type) { struct gpio_chip *gc = irq_data_get_irq_chip_data(d); struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
- unsigned int pin = irqd_to_hwirq(d);
- unsigned int offset = irqd_to_hwirq(d);
- unsigned int pin = chv_gpio_offset_to_pin(pctrl, offset); unsigned long flags; u32 value;
@@ -1461,7 +1496,7 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type) value &= CHV_PADCTRL0_INTSEL_MASK; value >>= CHV_PADCTRL0_INTSEL_SHIFT;
- pctrl->intr_lines[value] = pin;
- pctrl->intr_lines[value] = offset;
if (type & IRQ_TYPE_EDGE_BOTH) irq_set_handler_locked(d, handle_edge_irq); @@ -1591,17 +1626,19 @@ static int chv_gpio_add_pin_ranges(struct gpio_chip *chip) struct chv_pinctrl *pctrl = gpiochip_get_data(chip); const struct chv_community *community = pctrl->community; const struct chv_gpio_pinrange *range;
- int ret, i;
- int ret, i, offset;
- for (i = 0; i < community->ngpio_ranges; i++) {
- for (i = 0, offset = 0; i < community->ngpio_ranges; i++) { range = &community->gpio_ranges[i]; ret = gpiochip_add_pin_range(chip, dev_name(pctrl->dev),
range->base, range->base,
offset, range->base, range->npins);offset += range->npins;return 0; @@ -1617,7 +1654,7 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq) *chip = chv_gpio_chip;
- chip->ngpio = community->pins[community->npins - 1].number + 1;
- chip->ngpio = community->ngpios; chip->label = dev_name(pctrl->dev); chip->add_pin_ranges = chv_gpio_add_pin_ranges; chip->parent = pctrl->dev;
-- 2.17.1
On Thu, Feb 6, 2020 at 9:31 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
Hi,
Can you elaborate this? I was under the impression that all the different Strago systems have been already worked around by patches from Dmitry (Cc'd).
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
/** Some Braswell based Google Chromebooks need custom ACPI GPIO* number translation due to hardcoded GPIO numbers in firmware.*/.ident = "Intel_Strago based Chromebooks (All models)",.matches = {DMI_MATCH(DMI_SYS_VENDOR, "GOOGLE"),DMI_MATCH(DMI_PRODUCT_FAMILY, "Intel_Strago"),Same comment here. Are you saying all Stragos are broken in the current mainline?
Yes, I believe all Braswell based Chromebooks are affected. Yes, I believe all Braswell based Chromebooks are affected.
On Thu, Feb 06, 2020 at 11:26:54PM +0100, Michał Stanek wrote:
On Thu, Feb 6, 2020 at 9:31 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
Hi,
Can you elaborate this? I was under the impression that all the different Strago systems have been already worked around by patches from Dmitry (Cc'd).
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO numbering (which can change and is fragile anyway)?
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO numbering (which can change and is fragile anyway)?
I believe so, yes.
On Sat, Feb 08, 2020 at 07:43:24PM +0100, Michał Stanek wrote:
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
Can you share the ACPI tables and point me to the GPIO that is using Linux number?
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO numbering (which can change and is fragile anyway)?
I believe so, yes.
This is something that should be fixed in userspace. Using global Linux GPIO or IRQ numbers is fragile and source of issues like this. There are correct ways of using GPIOs from userspace: in case of sysfs, you can find the base of the chip and then user relative numbering against it or switch to use libgpiod that does the same but uses the newer char device. Both cases the GPIO number are relative against the GPIO chip so they work even if global Linux GPIO numbering changes.
On Mon, Feb 10, 2020 at 11:14 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
On Sat, Feb 08, 2020 at 07:43:24PM +0100, Michał Stanek wrote:
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
Can you share the ACPI tables and point me to the GPIO that is using Linux number?
I think this is the one: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/%...
On Kefka the sysfs GPIO number for wpsw_cur was gpio392 before the translation change occurred in Linux.
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO numbering (which can change and is fragile anyway)?
I believe so, yes.
This is something that should be fixed in userspace. Using global Linux GPIO or IRQ numbers is fragile and source of issues like this. There are correct ways of using GPIOs from userspace: in case of sysfs, you can find the base of the chip and then user relative numbering against it or switch to use libgpiod that does the same but uses the newer char device. Both cases the GPIO number are relative against the GPIO chip so they work even if global Linux GPIO numbering changes.
I analyzed crossystem source code and it looks like it is doing exactly what you're saying without any hardcoded assumptions. It gets the absolute offset of the GPIO pin from sysfs using its ACPI identifier, then it subtracts the base offset of the GPIO bank from it and the result is added to the bank's gpiochip%d number as it shows up in sysfs. The result is what is used to export and read the state of the pin.
With the newer kernel the gpiochip%d number is different so crossystem ends up reading the wrong pin.
On Tue, Mar 10, 2020 at 03:12:00PM +0100, Michał Stanek wrote:
On Mon, Feb 10, 2020 at 11:14 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
On Sat, Feb 08, 2020 at 07:43:24PM +0100, Michał Stanek wrote:
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
Can you share the ACPI tables and point me to the GPIO that is using Linux number?
I think this is the one: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/%...
On Kefka the sysfs GPIO number for wpsw_cur was gpio392 before the translation change occurred in Linux.
But that table does not seem to have any GPIO numbers in it.
What GPIO(s) we are talking about and how does it show up to the user?
As an example, the issue manifests itself when you run 'crossystem wpsw_cur'. On my Kefka it incorrectly reports the value as 1 instead of 0 when the write protect screw is removed.
Is it poking GPIOs directly through sysfs relying the Linux GPIO numbering (which can change and is fragile anyway)?
I believe so, yes.
This is something that should be fixed in userspace. Using global Linux GPIO or IRQ numbers is fragile and source of issues like this. There are correct ways of using GPIOs from userspace: in case of sysfs, you can find the base of the chip and then user relative numbering against it or switch to use libgpiod that does the same but uses the newer char device. Both cases the GPIO number are relative against the GPIO chip so they work even if global Linux GPIO numbering changes.
I analyzed crossystem source code and it looks like it is doing exactly what you're saying without any hardcoded assumptions. It gets the absolute offset of the GPIO pin from sysfs using its ACPI identifier, then it subtracts the base offset of the GPIO bank from it and the result is added to the bank's gpiochip%d number as it shows up in sysfs. The result is what is used to export and read the state of the pin.
With the newer kernel the gpiochip%d number is different so crossystem ends up reading the wrong pin.
Hmm, so gpiochipX is also not considered a stable number. It is based on ARCH_NR_GPIOS which may change. So if the userspace is relaying certain GPIO chip is always gpichip200 for example then it is wrong.
On Tue, Mar 10, 2020 at 3:49 PM Mika Westerberg mika.westerberg@linux.intel.com wrote:
With the newer kernel the gpiochip%d number is different so crossystem ends up reading the wrong pin.
Hmm, so gpiochipX is also not considered a stable number. It is based on ARCH_NR_GPIOS which may change. So if the userspace is relaying certain GPIO chip is always gpichip200 for example then it is wrong.
Yes it has always been clear that sysfs is what one shall use for establishing the topology of the hardware, so /sys/bus/gpiochip etc.
For example on my laptop: $ pwd /sys/bus/gpio/devices $ ls -al total 0 drwxr-xr-x. 2 root root 0 25 mar 23.49 . drwxr-xr-x. 4 root root 0 25 mar 23.49 .. lrwxrwxrwx. 1 root root 0 25 mar 23.49 gpiochip0 -> ../../../devices/pci0000:00/INT344B:00/gpiochip0
Here we see that this gpiochip is on this PCI card and so on.
Linus
Hi Mika,
I'm following along with attempts to "fix" our user space to paper over this issue, and I think some of this conversation missed the mark. (Sorry for jumping in late.)
On Tue, Mar 10, 2020 at 04:49:13PM +0200, Mika Westerberg wrote:
On Tue, Mar 10, 2020 at 03:12:00PM +0100, Michał Stanek wrote:
On Mon, Feb 10, 2020 at 11:14 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
On Sat, Feb 08, 2020 at 07:43:24PM +0100, Michał Stanek wrote:
Hi Mika,
The previous patches from Dmitry handled IRQ numbering, here we have a similar issue with GPIO to pin translation - hardcoded values in FW which do not agree with the (non-consecutive) numbering in newer kernels.
Hmm, so instead of passing GpioIo/GpioInt resources to devices the firmware uses some hard-coded Linux GPIO numbering scheme? Would you able to share the exact firmware description where this happens?
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
Can you share the ACPI tables and point me to the GPIO that is using Linux number?
I think this is the one: https://chromium-review.googlesource.com/c/chromiumos/third_party/coreboot/%...
On Kefka the sysfs GPIO number for wpsw_cur was gpio392 before the translation change occurred in Linux.
But that table does not seem to have any GPIO numbers in it.
Actually, it's encoding pin numbers, not GPIO numbers. The 0x10016 (or now, 0x10013) is encoding a bank offset (0x10000) and pin number (0x16 or 0x13). The actual pin numbers is 0x16, I believe, but someone decided to subtract 3, because the Linux numbering used to be contiguous, skipping over the hole between 11 and 15.
So no, nobody was hard-coding gpiochip numbers -- we were hard-coding the contiguous pin number (relative to the bank). Now that commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") made those non-contiguous, we're kinda screwed -- we have to guess (based on the kernel version number) whether pin numbers (within a single bank!) are contiguous or not.
This is something that should be fixed in userspace. Using global Linux GPIO or IRQ numbers is fragile and source of issues like this.
To be clear, we're not hard-coding global <anything> numbers in user space.
in case of sysfs, you can find the base of the chip
We're doing that.
and then user relative numbering against it or switch
^^ This is the problem. The *bank-relative* numbers changed.
Both cases the GPIO number are relative against the GPIO chip so they work even if global Linux GPIO numbering changes.
I analyzed crossystem source code and it looks like it is doing exactly what you're saying without any hardcoded assumptions.
^^ Exactly.
With the newer kernel the gpiochip%d number is different so crossystem ends up reading the wrong pin.
Hmm, so gpiochipX is also not considered a stable number. It is based on ARCH_NR_GPIOS which may change. So if the userspace is relaying certain GPIO chip is always gpichip200 for example then it is wrong.
If you just read the last sentence from Michal, you get the wrong picture. There's no hard-coding of gpiochipX numbers going on. We only had the pin offsets "hardcoded" (in ACPI), and the kernel driver unilaterally changed from a contiguous mapping to a non-contiguous mapping.
How do you recommend determining (both pre- and post-commit-03c4749dd6c7ff94) whether pin 22 is at offset 22, vs. offset 19?
Brian
On Thu, Apr 16, 2020 at 07:06:41PM -0700, Brian Norris wrote:
If you just read the last sentence from Michal, you get the wrong picture. There's no hard-coding of gpiochipX numbers going on. We only had the pin offsets "hardcoded" (in ACPI), and the kernel driver unilaterally changed from a contiguous mapping to a non-contiguous mapping.
OK, I now understand the issue. My apologies that I was not able to figure that out from the previous explanation.
So indeed if relative GPIO numbering inside the gpiochip was changed then it is kernel regression and needs to be dealt with.
How do you recommend determining (both pre- and post-commit-03c4749dd6c7ff94) whether pin 22 is at offset 22, vs. offset 19?
I wonder if we can add back the previous GPIO base like this?
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c index 4c74fdde576d..f53de56bb763 100644 --- a/drivers/pinctrl/intel/pinctrl-cherryview.c +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c @@ -1591,17 +1591,18 @@ static int chv_gpio_add_pin_ranges(struct gpio_chip *chip) struct chv_pinctrl *pctrl = gpiochip_get_data(chip); const struct chv_community *community = pctrl->community; const struct chv_gpio_pinrange *range; - int ret, i; + int ret, i, offset;
- for (i = 0; i < community->ngpio_ranges; i++) { + for (i = 0, offset = 0; i < community->ngpio_ranges; i++) { range = &community->gpio_ranges[i]; - ret = gpiochip_add_pin_range(chip, dev_name(pctrl->dev), - range->base, range->base, - range->npins); + ret = gpiochip_add_pin_range(chip, dev_name(pctrl->dev), offset, + range->base, range->npins); if (ret) { dev_err(pctrl->dev, "failed to add GPIO pin range\n"); return ret; } + + offset += range->npins; }
return 0;
- Michal (bouncing)
On Fri, Apr 17, 2020 at 2:05 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
I wonder if we can add back the previous GPIO base like this?
Thanks for the patch! At first glance, it looks like the right kind of thing. Unfortunately, it doesn't appear to work quite right for me. I'm out of time for today to look any further, but I (or perhaps someone else on this email) will try to follow up next week sometime.
Cheers, Brian
On Fri, Apr 17, 2020 at 05:55:44PM -0700, Brian Norris wrote:
- Michal (bouncing)
On Fri, Apr 17, 2020 at 2:05 AM Mika Westerberg mika.westerberg@linux.intel.com wrote:
I wonder if we can add back the previous GPIO base like this?
Thanks for the patch! At first glance, it looks like the right kind of thing. Unfortunately, it doesn't appear to work quite right for me. I'm out of time for today to look any further, but I (or perhaps someone else on this email) will try to follow up next week sometime.
Just in case you are going to do something about this, take into consideration that Cherryview driver got several cleanups in the past, it may require to rework this on top of the made changes.
P.S. Currently they are in my branch, but within couple of days it will be in Linux Next if nothing prevents it.
On Sat, Feb 8, 2020 at 7:43 PM Michał Stanek mst@semihalf.com wrote:
Actually it is a GPIO offset in ACPI tables for Braswell that was hardcoded in the old firmware to match the previous (consecutive) Linux GPIO numbering.
That's bad practice by the firmware authors. (Sad face)
We have enough problem saving ourselves from our own legacy ABIs without someone handling out more guns to shoot oneself in the foot with. :(
I'm also speaking on behalf of Microsoft and others in this I think. In the past we would find Windowsisms in the BIOSes and get really annoyed that we had to work around them. Now there are Linuxisms in the BIOS, that's not any better.
Yours, Linus Walleij
On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
And on top what Mika asked already, is it a real problem to update firmware?
On Thu, Feb 6, 2020 at 1:45 AM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Wed, Feb 05, 2020 at 08:48:04PM +0100, Michal Stanek wrote:
Dropping custom Linux GPIO translation caused some Intel_Strago based Chromebooks with old firmware to detect GPIOs incorrectly. Add quirk which restores some code removed by commit 03c4749dd6c7ff94 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation").
And on top what Mika asked already, is it a real problem to update firmware?
Even if we qualify new firmware (which is an involved process) how do you communicate to users that are not running Chrome OS that they need to update firmware? So no, we have to work around issues in existing firmware even if there is newer one that might address the issue.
Thanks.
-- Dmitry
linux-stable-mirror@lists.linaro.org
-
Andy Shevchenko -
Brian Norris -
Dmitry Torokhov -
Linus Walleij -
Michal Stanek -
Michał Stanek
-
Mika Westerberg