writel(value, padcfg0);
 }
 
+static int __intel_gpio_get_gpio_mode(u32 value)
+{
+       return (value & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT;
+}
+
 static int intel_gpio_get_gpio_mode(void __iomem *padcfg0)
 {
-       return (readl(padcfg0) & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT;
+       return __intel_gpio_get_gpio_mode(readl(padcfg0));
 }
 
 static void intel_gpio_set_gpio_mode(void __iomem *padcfg0)
 static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl, unsigned int pin)
 {
        const struct pin_desc *pd = pin_desc_get(pctrl->pctldev, pin);
+       u32 value;
 
        if (!pd || !intel_pad_usable(pctrl, pin))
                return false;
            gpiochip_line_is_irq(&pctrl->chip, intel_pin_to_gpio(pctrl, pin)))
                return true;
 
+       /*
+        * The firmware on some systems may configure GPIO pins to be
+        * an interrupt source in so called "direct IRQ" mode. In such
+        * cases the GPIO controller driver has no idea if those pins
+        * are being used or not. At the same time, there is a known bug
+        * in the firmwares that don't restore the pin settings correctly
+        * after suspend, i.e. by an unknown reason the Rx value becomes
+        * inverted.
+        *
+        * Hence, let's save and restore the pins that are configured
+        * as GPIOs in the input mode with GPIROUTIOXAPIC bit set.
+        *
+        * See https://bugzilla.kernel.org/show_bug.cgi?id=214749.
+        */
+       value = readl(intel_get_padcfg(pctrl, pin, PADCFG0));
+       if ((value & PADCFG0_GPIROUTIOXAPIC) && (value & PADCFG0_GPIOTXDIS) &&
+           (__intel_gpio_get_gpio_mode(value) == PADCFG0_PMODE_GPIO))
+               return true;
+
        return false;
 }