linux-kernel - Re: [PATCH] mfd: cros ec: spi: Fix "in progress" error signaling

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] [day] [month] [year] [list]

Message-ID: <CAHNYxRz9tBv_AEQ6DiyxuN2hR_2ACiNr0Afx_tj-uepwBYXp+w@mail.gmail.com>
Date:   Thu, 29 Mar 2018 15:08:27 -0700
From:   Alexandru M Stan <amstan@...omium.org>
To:     Enric Balletbo Serra <eballetbo@...il.com>
Cc:     Lee Jones <lee.jones@...aro.org>,
        Shawn Nematbakhsh <shawnn@...omium.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        jonathanh@...dia.com, Brian Norris <briannorris@...omium.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        Doug Anderson <dianders@...omium.org>
Subject: Re: [PATCH] mfd: cros ec: spi: Fix "in progress" error signaling

On Tue, Mar 27, 2018 at 3:49 AM, Enric Balletbo Serra
<eballetbo@...il.com> wrote:
> I think that accessing to the ec console should give the same result, right?

Yep, even better.

>
> In such case here is:
>
> Veyron Minnie ( ASUS Chromebook Flip C100PA )
> -------------------------------------------------------------------
> Chip:    stm stm32f07x
> Board:   0
> RO:      minnie_v1.1.2697-faafaa5
> RW:      minnie_v1.1.2712-242f6bd
> Build: minnie_v1.1.2712-242f6bd 2016-11-03 00:34:41 @build196-m2
>
> Veyron Jaq (  Haier Mighty MP )
> --------------------------------------------------------------------
> Chip:    stm stm32f07x
> Board:   0
> RO:      mighty_v1.1.2680-6727e1d
> RW:      mighty_v1.1.2712-242f6bd
> Build: mighty_v1.1.2680-6727e1d 2015-03-24 01:12:48 @build290-m2

Looks like your mighty is running the RO firmware, whereas your minnie
runs RW. Is it possible you have the 0x200 bit in the gbb flags set on
mighty? That would prevent the RO->RW transition, and give you an
older firmware.

6727e1d..242f6bd is quite the change. I see some spi changes too,
though i believe it's mostly at power state transitions
(suspend/resume). Other changes include battery settings (yeah.. you
should really avoid running that RO if you can avoid it) and a ton of
accelerometer stuff for minnie.

If it's not the gbb flags, and we can't figure it out why you're stuck
in RO, you can also use "sysjump RW" to force the RW copy on mighty.
See if there's any behavior changes in what you care about.

>
> We're running the RW firmware and I just discovered that our jaq is a
> mighty (but I guess it's the same?)

They're essentially the same, but they're running slightly different
firmware. In practice the only difference is that mighty's firmware
reads an extra gpio for the battery presence.

Feel free to diff the board/{jaq,mighty} ec folders for yourself for
more details/assurances.

>
> Thanks,
>   Enric

All in all I'm not sure that the version differences are enough to
explain the spi errors you see in the kernel.

My bet is back to the accelerometer stuff:
Are you running chromeos ui on this device (is there a chromeos-chrome
process constantly polling the accelerometer, so asking the cros-ec
driver for transfers)?
Another thing to make sure accelerometer is disabled is to run
"accelrate 0 0" on the minnie EC.
If none of that accelerometer stuff is enabled, minnie should
essentially act like a mighty/jaq.