linux-kernel - Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec

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]

Date:   Tue, 13 Jun 2017 19:22:25 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Jeffy Chen <jeffy.chen@...k-chips.com>,
        linux-kernel@...r.kernel.org, dianders@...omium.org,
        heiko@...ech.de, devicetree@...r.kernel.org,
        linux-rockchip@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        Will Deacon <will.deacon@....com>,
        Mark Rutland <mark.rutland@....com>,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH v2 4/4] arm64: dts: rockchip: use cs-gpios for cros_ec_spi

On Tue, Jun 13, 2017 at 10:50:44AM -0700, Brian Norris wrote:
> On Tue, Jun 13, 2017 at 01:25:43PM +0800, Jeffy Chen wrote:
> > The cros_ec requires CS line to be active after last message. But the CS
> > would be toggled when powering off/on rockchip spi, which breaks ec xfer.
> > Use GPIO CS to prevent that.

> I suppose this change is fine. (At least, I don't have a good reason not
> to do this.)

> But I still wonder whether this is something that the SPI core can be
> expected to handle. drivers/mfd/cros_ec_spi.c already sets the
> appropriate trans->cs_change bits, to ensure CS remains active in
> between certain messages (all under spi_bus_lock()). But you're
> suggesting that your bus controller may deassert CS if you runtime
> suspend the device (e.g., in between messages).

> So, is your controller just peculiar? Or should the SPI core avoid
> autosuspending the bus controller when it's been instructed to keep CS
> active? Any thoughts Mark?

This sounds like the controller being unusual - though frankly the
ChromeOS chip select usage is also odd so it's fairly rare for something
like this to come up.  I'd not expect a runtime suspend to loose the pin
state, though possibly through use of pinctrl rather than the
controller.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)