On Mon, Apr 23, 2018 at 02:49:30PM +0100, Peter Maydell wrote: > On 23 April 2018 at 14:41, Dave Martin <Dave.Martin@xxxxxxx> wrote: > > This is an update to a previous RFC v2 [1], to fix a problem observed by > > the qemu community that causes serial input to hang when booting a > > simulated system with data already queued in the UART FIFO [2]. > > > > After discussion, I decided that the approach in [1] was over- > > engineered: it tries to preserve a guarantee that people shouldn't be > > relying on anyway, namely that data sent to the UART prior to kernel > > boot will be received by the kernel; or more generally that data > > received by the UART while the pl011 driver is not opened will be > > received (either intact or at all) by the driver. > > > > If anyone can please test the following and let me know the results, > > that would be much appreciated! > > > > a) Check that you can still reproduce the bug on mainline without this > > patch. > > > > b) Check whether this patch fixes the problem. > > Thanks. I'm cc'ing Ciro and Drew, who are the two people I > recall reporting this issue to me. > Link to the patch for their benefit: > http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573120.html > Hi Dave, v3 does not resolve the issue for me. v2 does, and, fwiw, v3 applied on top of v2 (i.e. applying both), still works. If you choose to go with v2, then you can add my tested-by. Thanks, drew -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
