linux-kernel - Re: [PATCH v3 3/3] PCI: apple: Fix #PERST polarity

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: <87fsrmc4e6.wl-maz@kernel.org>
Date:   Wed, 24 Nov 2021 09:02:57 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Luca Ceresoli <luca@...aceresoli.net>
Cc:     linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-pci@...r.kernel.org,
        Pali Rohár <pali@...nel.org>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Mark Kettenis <mark.kettenis@...all.nl>,
        kernel-team@...roid.com
Subject: Re: [PATCH v3 3/3] PCI: apple: Fix #PERST polarity

On Tue, 23 Nov 2021 21:36:11 +0000,
Luca Ceresoli <luca@...aceresoli.net> wrote:
> 
> Hi Mark,
> 
> On 23/11/21 19:06, Marc Zyngier wrote:
> > Now that #PERST is properly defined as active-low in the device tree,
> > fix the driver to correctly drive the line indemendently of the
> > implied polarity.
> > 
> > Fixes: 1e33888fbe44 ("PCI: apple: Add initial hardware bring-up")
> > Suggested-by: Pali Rohár <pali@...nel.org>
> > Signed-off-by: Marc Zyngier <maz@...nel.org>
> 
> Thanks for quickly addressing this!
> 
> Do we need a transition path for backward compatibility with old DTs
> already around? Something like this [0]. You said [1] the DT actually
> used is not even the one in the kernel, thus how do we guarantee DT and
> driver switch to the new polarity all at once?

No. As it turns out, neither u-boot nor OpenBSD (the only two other
payloads that can boot on M1) are upstreamed yet. So we're still in
that stage where we don't need to maintain backward compatibility. If
we don't get this patches merged by the end of this cycle, we will
have to revisit this though.

> 
> [0] https://lkml.org/lkml/2021/6/24/1049
> [1] https://lkml.org/lkml/2021/11/23/455
> 
> > ---
> >  drivers/pci/controller/pcie-apple.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
> > index 957960a733c4..03bc56f39be5 100644
> > --- a/drivers/pci/controller/pcie-apple.c
> > +++ b/drivers/pci/controller/pcie-apple.c
> > @@ -540,7 +540,7 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie,
> >  	rmw_set(PORT_APPCLK_EN, port->base + PORT_APPCLK);
> >  
> >  	/* Engage #PERST before setting up the clock */
> >
> > -	gpiod_set_value(reset, 0);
> > +	gpiod_set_value(reset, 1);
> >  
> >  	ret = apple_pcie_setup_refclk(pcie, port);
> >  	if (ret < 0)
> > @@ -551,7 +551,7 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie,
> >  
> >  	/* Deassert #PERST */
> >  	rmw_set(PORT_PERST_OFF, port->base + PORT_PERST);
> > -	gpiod_set_value(reset, 1);
> > +	gpiod_set_value(reset, 0);
> 
> Minor note: if it were me I would coalesce patches 1 and 3 together,
> otherwise we are insisting on a wrong implementation (patch 1) to later
> fix it all (this patch).

The first patch is a clear bug fix that has a direct HW impact. The
second patch is only sugar coating with zero material impact
(absolutely nothing changes in the way the HW is driven). Squashing
these two patches would be absolutely the wrong thing to do.

	M.

-- 
Without deviation from the norm, progress is not possible.