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  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]
Date:   Thu, 03 Dec 2020 16:10:39 -0800
From:   Stephen Boyd <swboyd@...omium.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Alexandru M Stan <amstan@...omium.org>,
        Mark Brown <broonie@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Akash Asthana <akashast@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Benson Leung <bleung@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>
Subject: Re: [PATCH] spi: spi-geni-qcom: Use the new method of gpio CS control

Quoting Doug Anderson (2020-12-03 12:06:10)
> On Wed, Dec 2, 2020 at 4:47 PM Stephen Boyd <swboyd@...omium.org> wrote:
> >
> > And that is wrong. With even more investigation and Doug's eagle eyes it
> > seems that the cros-ec driver is overriding the spi::mode to clear out
> > the SPI_CS_HIGH bit that the spi core sets in there when using the gpio
> > descriptors. I'll send a patch for cros-ec-spi shortly.
> 
> So do we need any coordinating here, are we OK w/ trogdor devices
> being broken for a short period of time?
> 
> I think the device tree changes switching to use GPIO for chip select
> is already queued in linux-next.  That means if we land this patch
> before the fix to cros_ec [1] then we'll end up in a broken state.
> Would we be able to do some quick landing to get the cros-ec fix into
> v5.10 and then target the SPI patch for 5.11?

I don't think it really matters if the two patches meet up in linux-next
or cros-ec is fast tracked, but it would be bad if this patch was merged
without the cros-ec one. One option would be to apply the cros-ec fix to
the spi tree along with this patch (or vice versa) so that a bisection
hole isn't created. Or this patch can wait for a while until cros-ec is
fixed. I'm not the maintainer here so it's really up to Mark and
Enric/Benson.

> 
> [1] https://lore.kernel.org/r/20201203011649.1405292-2-swboyd@chromium.org/

Powered by blists - more mailing lists