On Mon, Nov 13, 2017 at 03:10:48PM +0200, Andy Shevchenko wrote: > On Mon, 2017-11-13 at 13:55 +0200, Mika Westerberg wrote: > > On Fri, Nov 10, 2017 at 03:40:33PM +0200, Andy Shevchenko wrote: > > > Allow to relax IoRestriction for certain cases. > > > > > > One of the use case is incorrectly cooked ACPI table where interrupt > > > pin is > > > defined with GpioIo() macro with IoRestrictionOutputOnly. > > > > > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > > > I think you should include user of this quirk in the patch series as > > well. Otherwise it is pretty pointless to add random quirks without > > real issues they are supposed to solve ;-) > > Something like below? Yes, but I would also add comment on top of the added line explaining why this particular quirk is needed in this particular system. > --- a/drivers/extcon/extcon-intel-int3496.c > +++ b/drivers/extcon/extcon-intel-int3496.c > @@ -50,7 +50,7 @@ static const struct acpi_gpio_params vbus_gpios = { > INT3496_GPIO_VBUS_EN, 0, fal > static const struct acpi_gpio_params mux_gpios = { > INT3496_GPIO_USB_MUX, 0, false }; > > static const struct acpi_gpio_mapping acpi_int3496_default_gpios[] = { > - { "id-gpios", &id_gpios, 1 }, > + { "id-gpios", &id_gpios, 1, ACPI_GPIO_QUIRK_NO_IO_RESTRICTION }, > { "vbus-gpios", &vbus_gpios, 1 }, > { "mux-gpios", &mux_gpios, 1 }, > { }, > @@ -112,9 +112,6 @@ static int int3496_probe(struct platform_device > *pdev) > ret = PTR_ERR(data->gpio_usb_id); > dev_err(dev, "can't request USB ID GPIO: %d\n", ret); > return ret; > - } else if (gpiod_get_direction(data->gpio_usb_id) != > GPIOF_DIR_IN) { > - dev_warn(dev, FW_BUG "USB ID GPIO not in input mode, > fixing\n"); > - gpiod_direction_input(data->gpio_usb_id); > } > > > > > Anyway looks good to me, > > > > Reviewed-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > Thanks! > > -- > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html