Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On 11/12/15 23:26, Jiri Kosina wrote: On Fri, 11 Dec 2015, Russell King - ARM Linux wrote: I'm personally happy with the existing code, and I've been wondering why there's this effort to apply further cleanups - to me, the changelogs don't seem to make that much sense, unless we want to start

RE: [RFC PATCH 3/3] vfio-pci: Allow to mmap MSI-X table if EEH is supported

From: Alex Williamson > Sent: 17 December 2015 21:07 ... > > Is this all related to the statements in the PCI(e) spec that the > > MSI-X table and Pending bit array should in their own BARs? > > (ISTR it even suggests a BAR each.) > > > > Since the MSI-X table exists in device memory/registers

Re: [RFC PATCH 2/3] vfio-pci: Allow to mmap sub-page MMIO BARs if all MMIO BARs are page aligned

On 2015/12/18 5:46, Alex Williamson wrote: On Thu, 2015-12-17 at 18:26 +0800, yongji xie wrote: On 2015/12/17 4:04, Alex Williamson wrote: On Fri, 2015-12-11 at 16:53 +0800, Yongji Xie wrote: Current vfio-pci implementation disallows to mmap sub-page(size < PAGE_SIZE) MMIO BARs because

[PATCH] powerpc/powernv: Only delay opal_rtc_read() retry when necessary

Only delay opal_rtc_read() when busy and are going to retry. This has the advantage of possibly saving a massive 10ms off booting! Kudos to Stewart for noticing. Signed-off-by: Michael Neuling diff --git a/arch/powerpc/platforms/powernv/opal-rtc.c

Re: [PATCH] powerpc: Enable UBSAN support

On Tue, 2015-12-15 at 14:46 +1100, Daniel Axtens wrote: > This hooks up UBSAN support for PowerPC. > > So far it's found some interesting cases where we don't properly sanitise > input to shifts, including one in our futex handling. It's also found an > out of bounds read in an array. Nothing

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote: > I'm not entirely sure that this is an improvement. What I do these days is delete everything in vprintk_emit() and simply call early_printk(). Kill the useless kmsg buffer crap and locking, just pound bytes to the UART registers

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Fri, Dec 18, 2015 at 12:29:02PM +0100, Peter Zijlstra wrote: > On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote: > > I'm not entirely sure that this is an improvement. > > What I do these days is delete everything in vprintk_emit() and simply > call early_printk(). On that,

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Fri 2015-12-18 10:18:08, Daniel Thompson wrote: > On 11/12/15 23:26, Jiri Kosina wrote: > >On Fri, 11 Dec 2015, Russell King - ARM Linux wrote: > > > >>I'm personally happy with the existing code, and I've been wondering why > >>there's this effort to apply further cleanups - to me, the

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On 18/12/15 14:52, Petr Mladek wrote: On Fri 2015-12-18 10:18:08, Daniel Thompson wrote: On 11/12/15 23:26, Jiri Kosina wrote: On Fri, 11 Dec 2015, Russell King - ARM Linux wrote: I'm personally happy with the existing code, and I've been wondering why there's this effort to apply further

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Thu 2015-12-17 14:38:58, Andrew Morton wrote: > On Tue, 15 Dec 2015 15:26:21 +0100 Petr Mladek wrote: > > > > OK, thanks. So "not needed at present, might be needed in the future, > > > useful for out-of-tree debug code"? > > > > It is possible that I got it a wrong way on

Re: [PATCH powerpc/next v6 0/4] atomics: powerpc: Implement relaxed/acquire/release variants

I've left this series testing overnight on a power7 box and so far so good, nothing has broken. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 4/4] printk/nmi: Increase the size of NMI buffer and make it configurable

On Fri, 18 Dec 2015 13:11:41 +0100 Peter Zijlstra wrote: > On Fri, Dec 18, 2015 at 12:29:02PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote: > > > I'm not entirely sure that this is an improvement. > > > > What I do these

Re: [PATCH V3] cpufreq: qoriq: Register cooling device based on device tree

On Tuesday 15 December 2015 00:58:26 Rafael J. Wysocki wrote: > On Thursday, November 26, 2015 05:21:11 PM Jia Hongtao wrote: > > Register the qoriq cpufreq driver as a cooling device, based on the > > thermal device tree framework. When temperature crosses the passive trip > > point cpufreq is