[PATCH] powerpc/powernv/opal: Use standard interrupts property when available

inux switch to using the standard "interrupts" and "interrupt-names" properties instead when they are available, using standard of_irq helpers, which can carry all the desired type information. Newer versions of OPAL will generate those properties in addition to the legacy ones

Re: [PATCH] powerpc/64: irq_work avoid immediate interrupt when raised with hard irqs enabled

On Fri, 2018-04-06 at 00:31 +1000, Nicholas Piggin wrote: > irq_work_raise should not schedule the hardware decrementer interrupt > unless it is called from NMI context. Doing so often just results in an > immediate masked decrementer interrupt: > ><...>-55090d...4us : update_curr_rt

Re: [PATCH 5/6] powerpc/powernv: implement opal_put_chars_nonatomic

On Mon, 2018-04-09 at 16:23 +1000, Nicholas Piggin wrote: > On Mon, 09 Apr 2018 15:57:55 +1000 > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > On Mon, 2018-04-09 at 15:40 +1000, Nicholas Piggin wrote: > > > The RAW console does not need wri

Re: [PATCH v2 4/9] powerpc/powernv: OPAL console standardise OPAL_BUSY loops

On Mon, 2018-04-09 at 16:13 +1000, Nicholas Piggin wrote: > We can always make exceptions to the standard form, but in those > cases I would like to document it in the OPAL API and comment for > the Linux side. > > My thinking in this case is that it reduces time in firmware and > in particular

Re: [PATCH 6/6] drivers/tty/hvc: remove unexplained "just in case" spin delay

On Mon, 2018-04-09 at 15:40 +1000, Nicholas Piggin wrote: > This delay was in the very first OPAL console commit 6.5 years ago. > The firmware console has hardened sufficiently to remove it. > Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Signed-off-by: Nic

Re: [PATCH 5/6] powerpc/powernv: implement opal_put_chars_nonatomic

ave the caller to deal with it. I was hoping (but that isn't the case) that by nonatomic you actually meant calls that could be done in a non-atomic context, where we can do msleep instead of mdelay. That would be handy for the console coming from the hvc thread (the tty one). Cheers, Ben. > >

Re: [PATCH v2 4/9] powerpc/powernv: OPAL console standardise OPAL_BUSY loops

On Mon, 2018-04-09 at 15:24 +1000, Nicholas Piggin wrote: > Convert to using the standard delay poll/delay form. > > The console code: > > - Did not previously delay or sleep in its busy loop. > > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Signed

Re: [PATCH v2 3/9] powerpc/powernv: opal_put_chars partial write fix

y. total_len is always "bytes left to copy", so it should be > added to written bytes. > > This code may not be exercised any more if partial writes will not be > hit, but this is a small bugfix before a larger change. > Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashin

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Fri, 2018-04-06 at 00:16 -0700, Christoph Hellwig wrote: > On Fri, Apr 06, 2018 at 08:23:10AM +0530, Anshuman Khandual wrote: > > On 04/06/2018 02:48 AM, Benjamin Herrenschmidt wrote: > > > On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: > > > > &g

Re: [RESEND v2 3/4] doc/devicetree: Persistent memory region bindings

On Thu, 2018-04-05 at 19:25 -0700, Dan Williams wrote: > > > Please also include my niggly nit picky trivial annoying bike shed > > > color for the driver name to *not* use the "nd_region" suffix for a > > > driver registering "nvdimm_bus" objects. "of_pmem_range" or > > > "of_pmem_bus" or almost

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, 2018-04-05 at 21:34 +0300, Michael S. Tsirkin wrote: > > In this specific case, because that would make qemu expect an iommu, > > and there isn't one. > > > I think that you can set iommu_platform in qemu without an iommu. No I mean the platform has one but it's not desirable for it to

Re: [RFC] virtio: Use DMA MAP API for devices without an IOMMU

On Thu, 2018-04-05 at 17:54 +0300, Michael S. Tsirkin wrote: > On Thu, Apr 05, 2018 at 08:09:30PM +0530, Anshuman Khandual wrote: > > On 04/05/2018 04:26 PM, Anshuman Khandual wrote: > > > There are certian platforms which would like to use SWIOTLB based DMA API > > > for bouncing purpose without

Re: RFC on writel and writel_relaxed

On Thu, 2018-03-29 at 09:56 -0400, Sinan Kaya wrote: > On 3/28/2018 11:55 AM, David Miller wrote: > > From: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > Date: Thu, 29 Mar 2018 02:13:16 +1100 > > > > > Let's fix all archs, it's way easier than fixing

Re: RFC on writel and writel_relaxed

On Thu, 2018-03-29 at 02:23 +1000, Nicholas Piggin wrote: > On Wed, 28 Mar 2018 11:55:09 -0400 (EDT) > David Miller <da...@davemloft.net> wrote: > > > From: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > Date: Thu, 29 Mar 2018 02:13:16 +1100 > > >

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 07:41 -0400, ok...@codeaurora.org wrote: > Yes, we want to get there indeed. It is because of some arch not > implementing writel properly. Maintainers want to play safe. > > That is why I asked if IA64 and other well known archs follow the > strongly ordered rule at this

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 11:30 +, David Laight wrote: > From: Benjamin Herrenschmidt > > Sent: 28 March 2018 10:56 > > ... > > For example, let's say I have a device with a reset bit and the spec > > says the reset bit needs to be set for at least 1

Re: Aw: Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 12:13 +0200, Lino Sanfilippo wrote: > Hi, > > > > > > Yeah so that other trick I'm talking about is also used for timing > > accuracy. > > > > For example, let's say I have a device with a reset bit and the spec > > says the reset bit needs to be set for at least 10us. >

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 11:55 +0200, Arnd Bergmann wrote: > > powerpc and ARM can't quite make them synchronous I think, but at least > > they should have the same semantics as writel. > > One thing that ARM does IIRC is that it only guarantees to order writel() > within > one device, and the

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 10:09 +0100, Will Deacon wrote: > On Wed, Mar 28, 2018 at 09:00:01AM +, David Laight wrote: > > From: Will Deacon > > > Sent: 28 March 2018 09:54 > > > > ... > > > > > I don't think so. My reading of memory-barriers.txt says that writeX > > > > > might > > > > > expand

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 10:07 +0100, Will Deacon wrote: > > For arm/arm64 we guarantee ordering for (1) but not for (2) -- you'd need to > add an mb() to make it work. > > Do both of these work on power? Yes. There's even another quirk, see further down ;-) > If so, I guess I can make readl

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 09:53 +0100, Will Deacon wrote: > For arm/arm64 these end up behaving exactly the same as readX/writeX, but > I'm nervous about changing the documentation without understanding why it's > like it is currently. Maybe another ia64 thing?. I doubt it ... the Intel ancestry here

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 09:11 +0200, Arnd Bergmann wrote: > On Wed, Mar 28, 2018 at 8:56 AM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Wed, 2018-03-28 at 06:53 +, Linus Torvalds wrote: > > > On Tue, Mar 27, 2018, 20:43 Benja

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-28 at 06:53 +, Linus Torvalds wrote: > > > On Tue, Mar 27, 2018, 20:43 Benjamin Herrenschmidt <benh@kernel.crash > ing.org> wrote: > > > > > > Of course, you'd have to be pretty odd to want to start a DMA > > with a > >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 20:26 -1000, Linus Torvalds wrote: > On Tue, Mar 27, 2018 at 6:33 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > > > This is why, I want (with your agreement) to define clearly and once > > and for all, that

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 23:24 -0400, Sinan Kaya wrote: > On 3/27/2018 10:51 PM, Linus Torvalds wrote: > > > The discussion at hand is about > > > > > > dma_buffer->foo = 1;/* WB */ > > > writel(KICK, DMA_KICK_REGISTER);/* UC */ > > > > Yes. That

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 16:51 -1000, Linus Torvalds wrote: > On Tue, Mar 27, 2018 at 3:03 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > > > The discussion at hand is about > > > > dma_buffer->foo = 1;

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 16:10 +0100, Will Deacon wrote: > To clarify: are you saying that on x86 you need a wmb() prior to a writel > if you want that writel to be ordered after prior writes to memory? Is this > specific to WC memory or some other non-standard attribute? > > The only reason we have

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 14:39 -1000, Linus Torvalds wrote: > On Tue, Mar 27, 2018 at 11:33 AM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > > > Well, we need to clarify that once and for all, because as I wrote > > earlier, it was decreed b

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 14:54 -0700, Alexander Duyck wrote: > On Tue, Mar 27, 2018 at 2:35 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote: > > > combined buffers. > > > > > > Alex:

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 10:46 -0400, Sinan Kaya wrote: > combined buffers. > > Alex: > "Don't bother. I can tell you right now that for x86 you have to have a > wmb() before the writel(). No, this isn't the semantics of writel. You shouldn't need it unless something changed and we need to revisit

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 11:54 -0700, Alexander Duyck wrote: > As far as I know the code has been this way for a while, something > like 2002, when the barrier was already present in e1000. However > there it was calling out weakly ordered models "such as IA-64". Since > then pretty much all the

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 15:36 +0100, Will Deacon wrote: > > Can we say the same thing for iowrite32() and iowrite32be(). I also see > > wmb() > > in front of these. > > I don't think so. My reading of memory-barriers.txt says that writeX might > expand to outX, and outX is not ordered with respect

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 08:12 -0600, Jason Gunthorpe wrote: > > I have been converting wmb+writel to wmb+writel_relaxed. (About 30 patches) > > > > I will have to just remove the wmb and keep writel, then repost. > > Okay, but before you do that, can we get a statement how this works > for WC? >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 09:46 -0400, Sinan Kaya wrote: > On 3/27/2018 7:02 AM, Will Deacon wrote: > > - See Documentation/DMA-API.txt for more information on consistent > > memory. > > + can see it now has ownership. Note that, when using writel(), a prior > > + wmb() is not needed to

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 10:57 +0100, Will Deacon wrote: > > > > The interesting thing is that we do seem to have a whole LOT of these > > spurrious wmb before writel all over the tree, I suspect because of > > that incorrect recommendation in memory-barriers.txt. > > > > We should fix that. > >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 12:02 +0100, Will Deacon wrote: > can see it now has ownership. Note that, when using writel(), a prior > > wmb() is not needed to guarantee that the cache coherent memory writes > > have completed before writing to the cache incoherent MMIO region. > >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 11:44 +0200, Arnd Bergmann wrote: > > The interesting thing is that we do seem to have a whole LOT of these > > spurrious wmb before writel all over the tree, I suspect because of > > that incorrect recommendation in memory-barriers.txt. > > > > We should fix that. > >

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 10:42 +0100, Will Deacon wrote: > > > > This example adds a wmb() between two writes to a coherent DMA > > area, it is definitely required there. I'm pretty sure I've never seen > > any bug reports pointing to a missing wmb() between memory > > and MMIO write accesses, but

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 09:56 +0200, Arnd Bergmann wrote: > On Tue, Mar 27, 2018 at 12:27 AM, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Tue, Mar 27, 2018 at 09:01:57AM +1100, Benjamin Herrenschmidt wrote: > > > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: >

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 16:50 -0600, Jason Gunthorpe wrote: > On Tue, Mar 27, 2018 at 09:36:11AM +1100, Benjamin Herrenschmidt wrote: > > On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote: > > > > Otherwise almost all drivers out there are broken which I ve

Re: RFC on writel and writel_relaxed

On Tue, 2018-03-27 at 09:36 +1100, Benjamin Herrenschmidt wrote: > I don't kow, it used to be the case, at least that's what drove us to > define things the way we did. > > Maybe things changed, but if that's the case, nobody knows for sure, > and we probably want to get Linus PO

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 16:27 -0600, Jason Gunthorpe wrote: > > Otherwise almost all drivers out there are broken which I very much > > doubt :-) > > But.. Sinan is right, you look anywhere in the driver tree and you > find stuff like this: > > drivers/net/ethernet/intel/i40e/i40e_txrx.c > >

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 18:08 -0400, Sinan Kaya wrote: > On 3/26/2018 6:01 PM, Benjamin Herrenschmidt wrote: > > On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > > > On 3/26/2018 5:30 PM, Arnd Bergmann wrote: > > > > > But that was never a requirement of

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 17:46 -0400, Sinan Kaya wrote: > On 3/26/2018 5:30 PM, Arnd Bergmann wrote: > > > But that was never a requirement of writel(), > > > Documentation/memory-barriers.txt gives an explicit example demanding > > > the wmb() before writel() for ordering system memory against

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 23:30 +0200, Arnd Bergmann wrote: > Most of the drivers have a unwound loop with writeq() or something to > > do it. > > But isn't the writeq() barrier much more expensive than anything you'd > do in function calls? It is for us, and will break any write combining. > > >

Re: RFC on writel and writel_relaxed

On Mon, 2018-03-26 at 10:54 -0600, Jason Gunthorpe wrote: > On Mon, Mar 26, 2018 at 11:08:45AM +, David Laight wrote: > > > > This is a super performance critical operation for most drivers and > > > > directly impacts network performance. > > > > Perhaps there ought to be writel_nobarrier()

Re: [PATCH v2] powerpc/eeh: Fix race with driver un/bind

rforming the driver EEH callbacks and > associated code. This ensures either the callbacks are no longer > register, or if they are registered the driver will not be removed > from underneath us. > > This has been broken forever. The EEH call backs were first introduced > in 2

Re: DMA Mapping Error in ppc64

On Fri, 2018-03-23 at 07:41 -0500, Jared Bents wrote: > Thank you for the advice. Looks like I get to try to rewrite the ath9k and > ath10k drivers to use dma_alloc_coherent() instead of kmemdup() and > dev_alloc_skb() Euh no... dev_alloc_skb() is the right thing to do for receive packets for

Re: [PATCH] cxl: disable the lazy approach for irqs in POWERVM environment.

On Fri, 2018-03-23 at 17:17 +0100, christophe lombard wrote: > Le 23/03/2018 à 03:14, Benjamin Herrenschmidt a écrit : > > On Thu, 2018-03-22 at 17:37 +0100, Christophe Lombard wrote: > > > The cxl driver cannot disable the interrupt at the device level and has > > >

Re: RFC on writel and writel_relaxed

On Fri, 2018-03-23 at 10:35 -0600, Jason Gunthorpe wrote: > On Fri, Mar 23, 2018 at 12:52:02AM +1100, Benjamin Herrenschmidt wrote: > > > > > - Make writel_relaxed() be a simple store without barriers, and > > > > readl_relaxed() be "eieio, read, ei

Re: RFC on writel and writel_relaxed

On Fri, 2018-03-23 at 09:42 -0400, Sinan Kaya wrote: > On 3/22/2018 8:16 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2018-03-22 at 12:51 -0500, Sinan Kaya wrote: > > > On 3/22/2018 8:52 AM, Benjamin Herrenschmidt wrote: > > > > > > No, it's not sufficie

Re: [PATCH] powerpc/eeh: Fix race with driver un/bind

On Fri, 2018-03-23 at 16:44 +1100, Michael Neuling wrote: .../... > This fixes the problem in the same way the generic PCIe AER code (in > drivers/pci/pcie/aer/aerdrv_core.c) does. It makes the EEH code hold > the device_lock() before performing the driver EEH callbacks. This > ensures either

Re: [PATCH 3/3] powerpc/mm: Fixup tlbie vs store ordering issue on POWER9

On Fri, 2018-03-23 at 10:26 +0530, Aneesh Kumar K.V wrote: > +#define CPU_FTR_TLBIE_BUG LONG_ASM_CONST(0x2000) I did ask you to make this CPU_FTR_POWER9_TLBIE_BUG... Cheers, Ben

Re: [PATCH] cxl: disable the lazy approach for irqs in POWERVM environment.

On Thu, 2018-03-22 at 17:37 +0100, Christophe Lombard wrote: > The cxl driver cannot disable the interrupt at the device level and has > to use disable_irq[_nosync] instead. > To avoid the implementation of the lazy optimisation (the interrupt is > marked disabled, but the hardware is left

Re: RFC on writel and writel_relaxed

On Thu, 2018-03-22 at 12:51 -0500, Sinan Kaya wrote: > On 3/22/2018 8:52 AM, Benjamin Herrenschmidt wrote: > > > > No, it's not sufficient. > > > > Just to clarify ... barrier() is just a compiler barrier, it means the > > compiler will generate things in the o

Re: RFC on writel and writel_relaxed

On Thu, 2018-03-22 at 21:15 +1100, Oliver wrote: > On Thu, Mar 22, 2018 at 3:24 PM, Benjamin Herrenschmidt > <b...@kernel.crashing.org> wrote: > > On Wed, 2018-03-21 at 08:53 -0500, Sinan Kaya wrote: > > > writel_relaxed() needs to have ordering guarantees with

Re: RFC on writel and writel_relaxed

On Wed, 2018-03-21 at 08:53 -0500, Sinan Kaya wrote: > writel_relaxed() needs to have ordering guarantees with respect to the order > device observes writes. Correct. > x86 has compiler barrier inside the relaxed() API so that code does not > get reordered. ARM64 architecturally guarantees

Re: [PATCH] powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened

On Wed, 2018-03-21 at 13:16 +1000, Nicholas Piggin wrote: > Yes Carol is working on this with distros. Backporting should be > simple, so hoping to get this upstream soon to help the process. > We can take that as a Reviewed-by:? :) Ah yup. Cheers, Ben.

Re: [PATCH] powerpc/64s: Fix lost pending interrupt due to race causing lost update to irq_happened

and high IPI rate. The hang was > bisected down to enabling doorbell interrupts for IPIs. These provided > an interrupt type that could run at high rates in the do_IRQ path, > stressing the race. > > Fixes: 1d607bb3bd ("powerpc/irq: Add mechanism to force a replay of > inter

Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown

On Wed, 2018-03-14 at 17:58 +0100, Frederic Barrat wrote: > + if (irq == hw_irq) { > + cur &= 1 << 31; > + cur |= XIVE_BAD_IRQ; > + *(q->qpage + idx) = cpu_to_be32(cur); > +

Re: [RFC] powerpc/xive: Remove irq from queue when it is shutdown

On Wed, 2018-03-14 at 18:47 +0100, Cédric Le Goater wrote: > We could also loop on the ESB 'P' bit to wait for the irqs to be handled, > using : > > xive_esb_read(irq, XIVE_ESB_GET) > > which has no side effect. It looks simpler to me. Is that possible ? But you can race with something

Re: [PATCHv4 1/3] powerpc, cpu: partially unbind the mapping between cpu logical id and its seq in dt

On Mon, 2018-03-12 at 12:43 +0800, Pingfan Liu wrote: > For kexec -p, the boot cpu can be not the cpu0, this causes the problem > to alloc paca[]. In theory, there is no requirement to assign cpu's logical > id as its present seq by device tree. But we have something like >

Re: [RESEND][PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

On Thu, 2018-03-01 at 01:03 +0530, Akshay Adiga wrote: > commit 1e1601b38e6e ("powerpc/powernv/idle: Restore SPRs for deep idle > states via stop API.") uses stop-api provided by the firmware to restore > PSSCR. PSSCR restore is required for handling special wakeup. When special > wakeup is

Re: [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

On Thu, 2018-02-08 at 16:42 -0600, Bjorn Helgaas wrote: > On Fri, Feb 09, 2018 at 09:21:43AM +1100, Benjamin Herrenschmidt wrote: > > On Thu, 2018-02-08 at 15:39 -0600, Bjorn Helgaas wrote: > > > I don't understand how this fix works. We used to check the result of > > &g

Re: [PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

On Thu, 2018-02-08 at 15:39 -0600, Bjorn Helgaas wrote: > I don't understand how this fix works. We used to check the result of > of_irq_parse_and_map_pci() and entered the block if it was zero. > > Now you enter the block if it is zero or less than zero, but: > > static int

Re: Kernel 4.15 lost set_robust_list support on POWER 9

On Mon, 2018-02-05 at 19:14 -0200, Mauricio Faria de Oliveira wrote: > Nick, Michael, +Aneesh. > On 02/05/2018 10:48 AM, Florian Weimer wrote: > > 7041 set_robust_list(0x7fff93dc3980, 24) = -1 ENOSYS (Function not > > implemented) > > The regression was introduced by commit 371b8044

Re: Are those hacks still valid on powerpc kernel ?

On Wed, 2018-01-24 at 11:17 +0100, Christophe LEROY wrote: > Below comments are very old. > > Aren't new glibc and binutils now able to go without this ? > > Note that the code inside the #if 0 is wrong as we have no vma defined > in the function. > > Or does it just have no performance impact

Re: [PATCH 3/6] KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2

On Thu, 2018-01-18 at 12:27 +1100, Paul Mackerras wrote: > > You need to check that it's a Nimbus using the top nimble of the bottom > > 16 bits of PVR. For Cumulus, the fixes are either in 1.0 or 1.1 (to > > check). > > OK, how about this for the check: > > if

Re: [PATCH 3/6] KVM: PPC: Book3S HV: Allow HPT and radix on the same core for POWER9 v2.2

On Wed, 2018-01-17 at 20:51 +1100, Paul Mackerras wrote: > + > + /* > +* POWER9 chips before version 2.02 can't have some threads in > +* HPT mode and some in radix mode on the same core. > +*/ > + if (cpu_has_feature(CPU_FTR_ARCH_300)) { > +

[PATCH 2/2] powerpc/xive: Add interrupt flag to disable automatic EOI

This will be used by KVM in order to keep escalation interrupts in the non-EOI (masked) state after they fire. They will be re-enabled directly in HW by KVM when needed. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/xive.h | 3 +++ arch/p

[PATCH 1/2] powerpc/xive: Move definition of ESB bits

>From xive.h to xive-regs.h since it's a HW register definition and it can be used from assembly Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/xive-regs.h | 35 +++ arch/powerpc/include/asm/xive.h

[PATCH v4 5/6] powerpc/kvm/xive: Make xive_pushed a byte, not a word

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/kvm_host.h | 2 +- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/inclu

[PATCH v4 2/6] powerpc/kvm/xive: Enable use of the new "single escalation" feature

guests especially when those guests use multiple priorities. It will also enable a future change to control the masking of the escalation interrupts more precisely to avoid spurrious ones. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/opal-api.

[PATCH v4 6/6] powerpc/kvm/xive: Keep escalation interrupt masked unless ceded

in the host whenever a guest interrupt fires. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/kvm_host.h | 3 ++ arch/powerpc/kernel/asm-offsets.c | 3 ++ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 62 -

[PATCH v4 4/6] powerpc/kvm/xive: Check DR not IR to chose real vs virt mode MMIOs

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index 327f5e6a1e4d..506a1c

[PATCH v4 3/6] powerpc/kvm/xive: Don't use existing "prodded" flag for xive escalations

exception bitmap as to avoid expensive atomic ops. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/kvm_host.h | 1 + arch/powerpc/kernel/asm-offsets.c | 1 + arch/powerpc/kvm/book3s_hv.c| 2 +- arch/powerpc/kvm/book3s_hv_r

[PATCH v4 1/6] powerpc/kvm/xive: Add more debugfs queues info

Add details about enabled queues and escalation interrupts Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kvm/book3s_xive.c | 28 1 file changed, 28 insertions(+) diff --git a/arch/powerpc/kvm/book3s_xive.c b/arch/power

[PATCH 3/5] powerpc: Reduce log level of "OPAL detected !" message

This message isn't terribly useful. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/platforms/powernv/opal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c

[PATCH 4/5] powerpc: Remove useless EXC_COMMON_HV

ct, we only have one user of EXC_COMMON_HV and it's for an unknown interrupt case. All the other ones already using EXC_COMMON. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/include/asm/head-64.h | 7 +-- arch/powerpc/kernel/exceptions-64s.S

[PATCH 2/5] powerpc: Remove DEBUG define in 64-bit early setup code

This statement causes some not very useful messages to always be printed on the serial port at boot, even on quiet boots. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/setup_64.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/

[PATCH 1/5] powerpc/xive: Remove incorrect debug code

WORD2 if the TIMA isn't byte accessible and isn't that useful to know about, take out the pr_devel statement. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/sysdev/xive/common.c | 5 - 1 file changed, 5 deletions(-) diff --git a/arch/powerpc/sysde

[PATCH 5/5] powerpc: Use the TRAP macro whenever comparing a trap number

Trap numbers can have extra bits at the bottom that need to be filtered out. There are a few cases where we don't do that. It's possible that we got lucky but better safe than sorry. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/process.c | 2 +-

Re: [PATCH 00/26] KVM: PPC: Book3S PR: Transaction memory support on PR KVM

On Thu, 2018-01-11 at 11:56 -0200, Gustavo Romero wrote: > Hi Simon, > > On 01/11/2018 08:11 AM, wei.guo.si...@gmail.com wrote: > > From: Simon Guo > > > > In current days, many OS distributions have utilized transaction > > memory functionality. In PowerPC, HV KVM

[PATCH 1/3] powerpc: Don't preempt_disable() in show_cpuinfo()

This causes warnings from cpufreq mutex code. This is also rather unnecessary and ineffective. If we really want to prevent concurrent unplug, we could take the unplug read lock but I don't see this being critical. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/p

[PATCH 3/3] powerpc: Cosmetic cleanup of cpuinfo_op

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/setup-common.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index c1df4ba0094c..9f9524bdd3f1

[PATCH 2/3] powerpc: Make newline in cpuinfo unconditional

We used to not put the newline between the CPU part and the summary part on UP kernels. This is a rather pointless ifdef so take it out. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- arch/powerpc/kernel/setup-common.c | 4 +--- 1 file changed, 1 insertion(+), 3 del

Re: Sleep in preempt_disable on powernv with 'cat /proc/cpuinfo' on v4.15

On Mon, 2018-01-08 at 21:30 -0800, John Sperbeck wrote: > The pnv_get_proc_freq() function was recently changed to call > cpufreq_get(), instead of cpufreq_quick_get(), in order to fetch > a more up-to-date value for the CPU frequency: > >cd77b5ce208c153260ed7882d8910f2395bfaabd >

Re: [PATCH] powerpc/mm: restore SEGV_ACCERR for segv on mapped region

can confuse debug libraries that temporarily > change the protection of memory regions, and expect to use > SEGV_ACCERR as an indication to restore access to a region. > > This change restores the previous behavior. The following program > exhibits the issue: Good catch ! Acked-by

Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume

On Thu, 2017-12-28 at 17:22 -0600, Bjorn Helgaas wrote: > Both paths end up calling the pci_error_handlers.error_detected() > hook. > > Drivers are not supposed to care what arch they're running on. If the > driver supplies an .error_detected() entry point, it's up to the PCI > core and powerpc

Re: [PATCH] powerpc: Add aacraid and nvme to powernv_defconfig

On Sat, 2017-12-23 at 11:40 +1100, Alexey Kardashevskiy wrote: > On 20/12/17 13:14, Benjamin Herrenschmidt wrote: > > On Wed, 2017-12-20 at 12:59 +1100, Alexey Kardashevskiy wrote: > > > On 20/12/17 12:51, Benjamin Herrenschmidt wrote: > > > > These adapters can be fo

Re: [RFC] macio airport how standard pccard?

On Fri, 2017-12-22 at 16:18 +0100, René Rebe wrote: > Hi all, > > I have a nice 1.2 GHz G4 Cube on my desk, and if I could somehow get USB 2 > into it, it would be way more useful as a “thin client” ;-) > > I was looking at the macio airport kernel glue, but could not immediately > figure out

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Wed, 2017-12-20 at 09:50 -0800, Ram Pai wrote: > The argument against this patch is -- it should not be baked into > the ABI as yet, since we do not have clarity on what applications need. > > As it stands today the only way to figure out the information from > userspace is by probing the

Re: [PATCH] powerpc: Add aacraid and nvme to powernv_defconfig

On Wed, 2017-12-20 at 12:59 +1100, Alexey Kardashevskiy wrote: > On 20/12/17 12:51, Benjamin Herrenschmidt wrote: > > These adapters can be found in a number of our systems, so let's > > enable the corresponding drivers by default. > > > > Signed-off-by

[PATCH] powerpc: Add aacraid and nvme to powernv_defconfig

These adapters can be found in a number of our systems, so let's enable the corresponding drivers by default. Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- --- a/arch/powerpc/configs/powernv_defconfig2017-12-19 18:37:24.803470591 -0600 +++ b/arch/powerpc/c

Re: [PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

On Mon, 2017-12-18 at 14:28 -0800, Dave Hansen wrote: > > We do not have generic support for something like that on ppc. > > The kernel looks at the device tree to determine what hardware features > > are available. But does not have mechanism to tell the hardware to track > > which of its

Re: [PATCH v2 2/7] powerpc/kernel: Add uevents in EEH error/resume

On Mon, 2017-12-18 at 22:50 -0600, Bjorn Helgaas wrote: > [+cc Keith, Gabriele, Dongdong] > > On Mon, Dec 18, 2017 at 04:38:03PM -0600, Bryant G. Ly wrote: > > Devices can go offline when EEH is reported. This patch adds > > a change to the kernel object and lets udev know of error. > > When

Re: [PATCH 07/13] ocxl: Add AFU interrupt support

On Mon, 2017-12-18 at 16:21 +0100, Frederic Barrat wrote: > Add user APIs through ioctl to allocate, free, and be notified of an > AFU interrupt. > > For opencapi, an AFU can trigger an interrupt on the host by sending a > specific command targeting a 64-bit object handle. On POWER9, this is >

Re: [PATCH] KVM: PPC: Book3S HV: Fix pending_pri value in kvmppc_xive_get_icp()

he other side, kvmppc_xive_get_icp() doesn't set > neither the pending_pri value, nor the xisr value (set to 0) > (and kvmppc_xive_set_icp() ignores the pending_pri value) > > As xisr is 0, pending_pri must be set to 0xff. > > Signed-off-by: Laurent Vivier <lviv...@redhat.com> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org>

Re: [RFC PATCH 1/2] powerpc: Add a CPU feature bit for TM bug workarounds on POWER9 DD2.2

On Fri, 2017-12-08 at 17:09 +1100, Paul Mackerras wrote: > This adds a CPU feature bit which is set for POWER9 DD2.2 processors > which will be used to enable software emulation for some transactional > memory instructions, in order to work around hardware bugs. The worry here is backward

Re: [PATCH 2/4] powerpc/64: do not trace irqs-off at interrupt return to soft-disabled context

On Mon, 2017-12-04 at 16:09 +1100, Michael Ellerman wrote: > Nicholas Piggin writes: > > > When an interrupt is returning to a soft-disabled context (which can > > happen for non-maskable interrupts or synchronous interrupts), it goes > > through the motions of soft-disabling

<    1   2   3   4   5   6   7   8   9   10   >