linux-kernel - Re: [PATCH] mfd: cros_ec: Use proper protocol transfer function

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: <20161128221320.GA55972@google.com>
Date:   Mon, 28 Nov 2016 14:13:21 -0800
From:   Brian Norris <briannorris@...omium.org>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Olof Johansson <olof@...om.net>,
        Benson Leung <bleung@...omium.org>,
        linux-kernel@...r.kernel.org,
        Doug Anderson <dianders@...omium.org>,
        Brian Norris <computersforpeace@...il.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        Shawn Nematbakhsh <shawnn@...omium.org>,
        Gwendal Grignou <gwendal@...omium.org>,
        Enric Balletbo <enric.balletbo@...labora.co.uk>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>
Subject: Re: [PATCH] mfd: cros_ec: Use proper protocol transfer function

Hi Lee,

On Wed, Nov 23, 2016 at 08:37:49AM +0000, Lee Jones wrote:
> On Tue, 22 Nov 2016, Brian Norris wrote:
> > On Wed, Aug 10, 2016 at 01:45:12PM -0700, Brian Norris wrote:
> > > From: Shawn Nematbakhsh <shawnn@...omium.org>
> > > 
> > > pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
> > > one instance of these functions correct, but not the second, fall-back
> > > case. We use the fall-back only when the first command returns an
> > > IN_PROGRESS status, which is only used on some EC firmwares where we
> > > don't want to constantly poll the bus, but instead back off and
> > > sleep/retry for a little while.
> > > 
> > > Fixes: 2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
> 
> You need to Cc stable with a note saying which kernel version it
> fixes.  Grep the `git log`s for stable.*#.

I understand how the stable process works. This was intentional. Fixes
!= stable. It's easy to tag what commit it's supposed to fix. It's less
easy to backport and verify that it's a useful for all affected kernels.

(If somebody else determines it should be backported -- e.g., Benson or
Olof -- then I won't stop them, of course.)

Side note: isn't 'Fixes' a more accurate way of describing which version
it applies to than just putting the kernel version with a '#' comment?
That helps anyone who might have backported the buggy commit -- e.g., as
part of the stable process.

> > > Signed-off-by: Shawn Nematbakhsh <shawnn@...omium.org>
> > > Signed-off-by: Brian Norris <briannorris@...omium.org>
> > > ---
> > > MAINTAINERS tells me this goes through Olof, but many things have gone through
> > > Lee.
> > 
> > I believe this was supposed to go through Olof. Olof, are you out there?
> 
> Yes, I concur.
> 
> There maybe some confusion since the $SUBJECT line is
> misleading/incorrect.

Thanks. I'll resend with a 'platform/chrome:' prefix, and make sure it
shows up in Benson's inbox too. I think I didn't look deeply enough into
history -- the last few commits touching drivers/platform/chrome/ had an
'mfd' tag, but they also happened to touch mfd-prefixed files too.

Brian

> > Or Benson? I see this:
> > 
> > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1273587.html
> > [PATCH] platform/chrome : Add myself as Maintainer
> > 
> > but it's not merged anywhere AFAICT.
> > 
> > I can resend if that helps.
> > 
> > Brian
[...]