Thu, May 09, 2024 at 01:24:45AM +0000, Hongxing Zhu kirjoitti: > > -----Original Message----- > > From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > Sent: 2024年5月6日 22:21 ... > > - imx6_pcie->gpio_active_high = of_property_read_bool(node, > > - "reset-gpio-active-high"); > > - if (gpio_is_valid(imx6_pcie->reset_gpio)) { > > - ret = devm_gpio_request_one(dev, imx6_pcie->reset_gpio, > > - imx6_pcie->gpio_active_high ? > > - GPIOF_OUT_INIT_HIGH : > > - GPIOF_OUT_INIT_LOW, > > - "PCIe reset"); > > - if (ret) { > > - dev_err(dev, "unable to get reset gpio\n"); > > - return ret; > > - } > > - } else if (imx6_pcie->reset_gpio == -EPROBE_DEFER) { > > - return imx6_pcie->reset_gpio; > > - } > Please correct me if my understand is wrong. > The "reset-gpio-active-high" property is added for some buggy board designs. > On these buggy boards, the reset gpio is active high. This is my understanding too. > In the other words, the PERST# is active and remote endpoint device would > be in reset stat when this gpio is high on these buggy boards. Yes. > I'm afraid that the PCIe would be broken on these boards, If these codes > are removed totally, No. Linus W. explained in the previous version review round how it's supposed to work. > and toggle the reset GPIO pin like below. > ... > gpio_set_value_cansleep(imx6_pcie->reset_gpio, 0); > msleep(100); > gpio_set_value_cansleep(imx6_pcie->reset_gpio, 1); > ... It's not the code that this patch adds. I'm not sure if I understand starting from here what you mean. > By the way, this reset GPIO pin should be high at end in > imx6_pcie_deassert_core_reset() if the imx6_pcie->gpio_active_high is zero. This seems a terminology mixup. You probably meant "inactive". And this is exactly the case with this patch. If you start thinking in terms of "active"/"inactive" you will see that there is no contradiction and no behaviour change. The quirk itself is located in gpiolib-of.c.. -- With Best Regards, Andy Shevchenko