Hi Thomas, Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxx> wrote on Thu, 13 Dec 2018 15:36:19 +0100: > Hello, > > On Thu, 13 Dec 2018 15:33:06 +0100, Miquel Raynal wrote: > > > I will re-send a series without this patch. I think it does not hurt to > > keep the previous patch adding the pinmux setting in the > > Armada-37xx.dtsi file even without using it, so I will drop only this > > patch. > > I tend to disagree here (but perhaps you'll have other arguments to > convince me otherwise): the GPIO used for PCIe reset is a completely > board-specific thing. You can chose whatever GPIO you want, and each > board can be different. Therefore, there is no reason to have such a > pinmux configuration at the SoC level (.dtsi), it should be within the > particular board that uses that pinmux configuration. > > This is a rule that we have applied to mvebu platforms in general, and > which I believe is fairly common in many DTs. Actually this is a pin that may be driven directly by the PCI IP and is not board-specific (note that the patch is wrong as the functions should be "pcie" instead of "gpio"). What is board specific is if this pin is actually wired to the endpoint PCIe card or not. Anyway, as seen by Gregory, the pinctrl driver must be fixed as when selecting the "pcie1" group, the driver was poking another area making the EspressoBin switch unstable. With a quick fix on my side I realized the reset was not behaving at all as expected. As it is not actually needed for suspend/resume operation (at least on my setup) I will drop the 'reset pin' related patches in the next iteration of the series. Thanks, Miquèl
