linux-kernel - Re: [PATCH] mmc: tegra: fix SDR50 tuning override

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]

Date:   Tue, 7 Jan 2020 13:57:00 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        linux-mmc@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Thierry Reding <treding@...dia.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Lucas Stach <dev@...xeye.de>, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc: tegra: fix SDR50 tuning override

On Tue, Jan 07, 2020 at 10:53:59AM +0100, Michał Mirosław wrote:
> On Tue, Jan 07, 2020 at 10:37:15AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Jan 06, 2020 at 02:37:03PM +0100, Thierry Reding wrote:
> > > On Mon, Jan 06, 2020 at 01:27:45PM +0100, Greg Kroah-Hartman wrote:
> > > > On Mon, Jan 06, 2020 at 01:07:18PM +0100, Thierry Reding wrote:
> > > > > On Thu, Jan 02, 2020 at 11:30:50AM +0100, Michał Mirosław wrote:
> > > > > > Commit 7ad2ed1dfcbe inadvertently mixed up a quirk flag's name and
> > > > > > broke SDR50 tuning override. Use correct NVQUIRK_ name.
> > > > > > 
> > > > > > Fixes: 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes")
> > > > > > Depends-on: 4f6aa3264af4 ("mmc: tegra: Only advertise UHS modes if IO regulator is present")
> > > > > > Signed-off-by: Michał Mirosław <mirq-linux@...e.qmqm.pl>
> > > > > > ---
> > > > > >  drivers/mmc/host/sdhci-tegra.c | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > Oh my... good catch!
> > > > > 
> > > > > Reviewed-by: Thierry Reding <treding@...dia.com>
> > > > > 
> > > > > I also ran this through our internal test system and all tests pass, so
> > > > > also:
> > > > > 
> > > > > Tested-by: Thierry Reding <treding@...dia.com>
> > > > > 
> > > > > I'm not sure if that "Depends-on:" tag is anything that's recognized
> > > > > anywhere. It might be better to turn that into an additional "Fixes:"
> > > > > line. Adding Greg to see if he has a standard way of dealing with this
> > > > > kind of dependency.
> > > > > 
> > > > > Greg, what's your preferred way to handle these situations? I think the
> > > > > intention here was to describe that the original error was introduced by
> > > > > commit 7ad2ed1dfcbe ("mmc: tegra: enable UHS-I modes"), but then commit
> > > > > 4f6aa3264af4 ("mmc: tegra: Only advertise UHS modes if IO regulator is
> > > > > present") moved that code around, so this patch here will only be back-
> > > > > portable until the latter commit, but should be backported until the
> > > > > former.
> > > > 
> > > > The stable kernel rules document says how to handle this, but the
> > > > "depends on" commit id in the comment to the right of the stable@k.o cc:
> > > > line in the changelog area.
> > > 
> > > That only mentions "static" prerequisites needed by the patch, but what
> > > if the prerequisites change depending on version?
> > > 
> > > Could I do something like this:
> > > 
> > > 	Cc: <stable@...r.kernel.org> # 4.4.x: abcdef: ...
> > > 	Cc: <stable@...r.kernel.org> # 4.9.x: bcdefa: ...
> > > 	Cc: <stable@...r.kernel.org>
> > 
> > Yes.
> > 
> > > Would that mean that the patch is selected for all stable releases
> > > (because of the last line with no version prerequisite) but when applied
> > > for stable-4.4 the abcdef patch gets pulled in and for stable-4.9 the
> > > bcdefa dependency is applied before the patch?
> > 
> > Yes.
> > 
> > > I suppose this is perhaps a bit of an exotic case, but it might be good
> > > to document it specifically because it might be fairly rare. I can draft
> > > a change if you think this is useful to add.
> > 
> > I thought this was already in there, as others have done it in the past.
> > 
> > It's a _very_ exotic case, I wouldn't worry about it, just document it
> > like this, and if I have problems applying the patches to stable I'll be
> > sure to let you know and you can always tell me then.  That's usually
> > the easiest thing to do anyway :)
> 
> I understood the wording in stable-kernel-rules.rst as meaning that
> comments on Cc: lines make mentioned commit pulled in (cherry-picked).
> In this case I think this is ok, but in case the pulled-in patch changes
> something else (the dependency is only because of touching nearby code),
> how would I specify this and avoid the hint to include the other patch?

I really do not understand what you are asking for here.

Worst case, just say:
	cc: stable... # 4.4.x

and if you know that fails to apply or build, then just wait for my
email saying something failed and then respond with the needed commit
ids or backported patches.

It's not rocket science, and this isn't all that automated, I _can_
handle free-form text :)

thanks,

greg k-h