lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181217153140.6d51b9f3@xps13>
Date:   Mon, 17 Dec 2018 15:31:40 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Cc:     Gregory Clement <gregory.clement@...tlin.com>,
        Jason Cooper <jason@...edaemon.net>,
        Andrew Lunn <andrew@...n.ch>,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        linux-pci@...r.kernel.org, <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Antoine Tenart <antoine.tenart@...tlin.com>,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Nadav Haklai <nadavh@...vell.com>
Subject: Re: [PATCH v2 10/12] ARM64: dts: marvell: armada-3720-espressobin:
 declare PCIe reset GPIO

Hi Thomas,

Thomas Petazzoni <thomas.petazzoni@...tlin.com> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ