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
