linux-kernel - Re: [PATCH] serial: tegra: Map the iir register to default defines

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: <20170331132137.GA23510@kroah.com>
Date:   Fri, 31 Mar 2017 15:21:37 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Olliver Schinagl <oliver@...inagl.nl>
Cc:     Jon Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Jiri Slaby <jslaby@...e.com>,
        Stephen Warren <swarren@...dotorg.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Alexandre Courbot <gnurou@...il.com>,
        linux-serial@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: tegra: Map the iir register to default defines

On Thu, Mar 30, 2017 at 05:37:41PM +0200, Olliver Schinagl wrote:
> Hey Jon,
> 
> On March 30, 2017 3:42:19 PM CEST, Jon Hunter <jonathanh@...dia.com> wrote:
> >
> >On 29/03/17 19:48, Olliver Schinagl wrote:
> >> The tegra serial IP seems to be following the common layout and the
> >> interrupt ID's match up nicely. Replace the magic values to match the
> >> common serial_reg defines, with the addition of the Tegra unique End
> >of
> >> Data interrupt.
> >> 
> >> Signed-off-by: Olliver Schinagl <oliver@...inagl.nl>
> >> ---
> >> Note I do not own any tegra hardware and just noticed it while
> >working on my
> >> somewhat related previous patch,
> >> "serial: Do not treat the IIR register as a bitfield"
> >> 
> >> As such, this patch can only be applied after the aforementioned
> >patch or the
> >> iir variable will not have its mask applied yet.
> >
> >Nit-pick. If this is the case, then this should really be part of a
> >patch series so it is obvious to everyone that this should only be
> >applied after the other patch.
> Yes, and it was, but I did not want to have the really big list of names in this much smaller group.

Ok, this is a mess, don't send me patches that need to be applied in a
specific order, yet are not obviously linked together in a single
series.

How do you expect a maintainer to handle this type of stuff?  You need
to make it _OBVIOUS_ as to what I need to do here, otherwise I will get
it wrong.

I'm going to drop all of your patches from my queue and wait for a
resend with the correct order, and ones that work properly, you can do
better than this :)

thanks,

greg k-h