linux-kernel - Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <742637f13bc97ecaadd1d264cd0ad4cc@agner.ch>
Date:	Fri, 09 Jan 2015 23:19:50 +0100
From:	Stefan Agner <stefan@...er.ch>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	jslaby@...e.cz, jingchang.lu@...escale.com, shawn.guo@...aro.org,
	linux-serial@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] serial: fsl_lpuart: fix various DMA related issues

On 2015-01-09 23:14, Greg KH wrote:
> On Fri, Dec 12, 2014 at 05:19:02PM +0100, Stefan Agner wrote:
>> On 2014-12-12 15:32, Greg KH wrote:
>> > On Fri, Dec 12, 2014 at 02:44:06PM +0100, Stefan Agner wrote:
>> >> Any thoughts on this patchset? Would have hopped that it makes it into
>> >> 3.19 as those are mostly fixes.
>> >
>> > "mostly"?
>> >
>>
>> Well, all of them fix a bug, but PATCH 2/4 does this by also moving DMA
>> allocation to probe. I would really have to split up that patch and make
>> two incremental steps (split-up of RX/TX DMA allocation to make each
>> single action revert-able and move to probe). But this would lead to
>> more changed lines in total. The patchset as is already somewhat tested
>> since we use it in our 3.18 BSP, whereas a new set would not be tested.
>>
>> One could also argument, it only affects fsl_lpuart (UART in rather not
>> very widespread SoC's Freescale Vybrid and LS1021a).
>>
>>
>> > I'll get to these after 3.19-rc1 is out, but it really looks like these
>> > will be for 3.20-rc1, unless you break them up into "bugfix only" type
>> > patches.
>>
>>
>> PATCH 1/4 fixes a bug which happens on a normal console rather often on
>> my setup. So if you decide that patchset is for 3.20-rc1, that one would
>> be nice to have in 3.19 as well...
> 
> Please redo this patchset then, makeing it obvious that some are fixes,
> and need to go for 3.19 and others are ok for 3.20.  As it is, the
> changelog entries do not look like anything here is for 3.19, sorry.
> 

Ok, will create a patchset with 1 and 3 for 3.19 (since this two really
lead to reproducible kernel traces), and the rest for 3.20. Do you
prefer to have the patches in a single patchset (with 3 moved to 2) or
should I create two patchsets?

--
Stefan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/