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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
