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 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] 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: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

On Tue, 2018-03-27 at 15:13 +0200, Andrea Parri wrote: > > > > So unless it's very performance sensitive, I'd rather have things like > > spin_is_locked be conservative by default and provide simpler ordering > > semantics. > > Well, it might not be "very performance sensitive" but allow me to

Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

On Tue, 2018-03-27 at 15:13 +0200, Andrea Parri wrote: > > > > So unless it's very performance sensitive, I'd rather have things like > > spin_is_locked be conservative by default and provide simpler ordering > > semantics. > > Well, it might not be "very performance sensitive" but allow me to

Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

On Tue, 2018-03-27 at 12:25 +0200, Andrea Parri wrote: > > I would rather wait until it is properly documented. Debugging that IPC > > problem took a *LOT* of time and energy, I wouldn't want these issues > > to come and bite us again. > > I understand. And I'm grateful for this debugging as well

Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

On Tue, 2018-03-27 at 12:25 +0200, Andrea Parri wrote: > > I would rather wait until it is properly documented. Debugging that IPC > > problem took a *LOT* of time and energy, I wouldn't want these issues > > to come and bite us again. > > I understand. And I'm grateful for this debugging as well

Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

rather wait until it is properly documented. Debugging that IPC problem took a *LOT* of time and energy, I wouldn't want these issues to come and bite us again. > [1] https://marc.info/?l=linux-kernel=151981440005264=2 > > Signed-off-by: Andrea Parri <andrea.pa...@amarulasolution

Re: [PATCH for-4.17 2/2] powerpc: Remove smp_mb() from arch_spin_is_locked()

rather wait until it is properly documented. Debugging that IPC problem took a *LOT* of time and energy, I wouldn't want these issues to come and bite us again. > [1] https://marc.info/?l=linux-kernel=151981440005264=2 > > Signed-off-by: Andrea Parri > Cc: Benjamin Herrenschmidt >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, 2018-03-02 at 10:25 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: > > > > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > > We use only 52 in practice but yes. > > > > > > > That's 6

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, 2018-03-02 at 10:25 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: > > > > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > > We use only 52 in practice but yes. > > > > > > > That's 6

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: (Switching back to my non-IBM address ...) > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: (Switching back to my non-IBM address ...) > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: > > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap for the entire space it will take 16TB

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 16:19 -0700, Logan Gunthorpe wrote: > > On 01/03/18 04:00 PM, Benjamin Herrenschmidt wrote: > > We use only 52 in practice but yes. > > > > > That's 64PB. If you use need > > > a sparse vmemmap for the entire space it will take 16TB

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:57 -0700, Logan Gunthorpe wrote: > > On 01/03/18 02:45 PM, Logan Gunthorpe wrote: > > It handles it fine for many situations. But when you try to map > > something that is at the end of the physical address space then the > > spares-vmemmap needs virtual address space

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:57 -0700, Logan Gunthorpe wrote: > > On 01/03/18 02:45 PM, Logan Gunthorpe wrote: > > It handles it fine for many situations. But when you try to map > > something that is at the end of the physical address space then the > > spares-vmemmap needs virtual address space

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote: > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt <b...@au1.ibm.com> > wrote: > > > > Could be that x86 has the smarts to do the right thing, still trying to > > untangle the code :-) > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:31 -0800, Linus Torvalds wrote: > On Thu, Mar 1, 2018 at 2:06 PM, Benjamin Herrenschmidt > wrote: > > > > Could be that x86 has the smarts to do the right thing, still trying to > > untangle the code :-) > > Afaik, x86 will n

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 13:53 -0700, Jason Gunthorpe wrote: > On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote: > > Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM > > on ppc64 (maybe via an arch hook as it might depend on the processor >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 13:53 -0700, Jason Gunthorpe wrote: > On Fri, Mar 02, 2018 at 07:40:15AM +1100, Benjamin Herrenschmidt wrote: > > Also we need to be able to hard block MEMREMAP_WB mappings of non-RAM > > on ppc64 (maybe via an arch hook as it might depend on the processor >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > > > The devm_memremap_pages() infrastructure allows placing the memmap in > "System-RAM" even if the hotplugged range is in PCI space. So, even if > it is an issue on some configurations, it's just a simple adjustment > to where the memmap

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > > > The devm_memremap_pages() infrastructure allows placing the memmap in > "System-RAM" even if the hotplugged range is in PCI space. So, even if > it is an issue on some configurations, it's just a simple adjustment > to where the memmap

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, 2018-03-02 at 07:34 +1100, Benjamin Herrenschmidt wrote: > > But what happens with that PCI memory ? Is it effectively turned into > nromal memory (ie, usable for normal allocations, potentially used to > populate user pages etc...) or is it kept aside ? (What I mean is

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Fri, 2018-03-02 at 07:34 +1100, Benjamin Herrenschmidt wrote: > > But what happens with that PCI memory ? Is it effectively turned into > nromal memory (ie, usable for normal allocations, potentially used to > populate user pages etc...) or is it kept aside ? (What I mean is

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > On Wed, Feb 28, 2018 at 7:56 PM, Benjamin Herrenschmidt > <b...@au1.ibm.com> wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:21 -0800, Dan Williams wrote: > On Wed, Feb 28, 2018 at 7:56 PM, Benjamin Herrenschmidt > wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 18:09 +, Stephen Bates wrote: > > > So Oliver (CC) was having issues getting any of that to work for us. > > > > > > The problem is that acccording to him (I didn't double check the latest > > > patches) you effectively hotplug the PCIe memory into the system when > > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 18:09 +, Stephen Bates wrote: > > > So Oliver (CC) was having issues getting any of that to work for us. > > > > > > The problem is that acccording to him (I didn't double check the latest > > > patches) you effectively hotplug the PCIe memory into the system when > > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:04 -0700, Logan Gunthorpe wrote: > > On 28/02/18 08:56 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > The problem is that acccording to him (I didn't double check the latest > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 11:04 -0700, Logan Gunthorpe wrote: > > On 28/02/18 08:56 PM, Benjamin Herrenschmidt wrote: > > On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > > > The problem is that acccording to him (I didn't double check the latest > >

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > Hi Everyone, So Oliver (CC) was having issues getting any of that to work for us. The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > Hi Everyone, So Oliver (CC) was having issues getting any of that to work for us. The problem is that acccording to him (I didn't double check the latest patches) you effectively hotplug the PCIe memory into the system when creating

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > Hi Everyone, > > > So Oliver (CC) was having issues getting any of that to work for us. > > The problem is that acccording to him (I didn't

Re: [PATCH v2 00/10] Copy Offload in NVMe Fabrics with P2P PCI Memory

On Thu, 2018-03-01 at 14:54 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2018-02-28 at 16:39 -0700, Logan Gunthorpe wrote: > > Hi Everyone, > > > So Oliver (CC) was having issues getting any of that to work for us. > > The problem is that acccording to him (I didn't

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: [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 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 13:42 +0800, Ryder Lee wrote: > Thanks for explanation. > > So I guess the better way to achieve my aim - one IRQ per slot that is > connected to all INTx and get propagated through the bridges (and for > those root ports own interrupts (PME ..)} is to add interrupt-map >

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 13:42 +0800, Ryder Lee wrote: > Thanks for explanation. > > So I guess the better way to achieve my aim - one IRQ per slot that is > connected to all INTx and get propagated through the bridges (and for > those root ports own interrupts (PME ..)} is to add interrupt-map >

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote: > On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > > > > > I think the code should look at the bridge address <0x0800 ...> we lis

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 12:31 +0800, Ryder Lee wrote: > On Tue, 2018-02-06 at 15:05 +1100, Benjamin Herrenschmidt wrote: > > On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > > > > > I think the code should look at the bridge address <0x0800 ...> we lis

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > I think the code should look at the bridge address <0x0800 ...> we list > in bindings for resolving interrupts in this case, but it seems like it > use the 'pdev->defvn << 8' which is not really we want and will lead to > mismatch. > >

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Tue, 2018-02-06 at 10:38 +0800, Ryder Lee wrote: > > I think the code should look at the bridge address <0x0800 ...> we list > in bindings for resolving interrupts in this case, but it seems like it > use the 'pdev->defvn << 8' which is not really we want and will lead to > mismatch. > >

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Fri, 2018-02-02 at 17:32 +0800, Ryder Lee wrote: > On Wed, 2018-01-31 at 10:02 -0600, Rob Herring wrote: > > On Wed, Jan 31, 2018 at 1:41 AM, Ryder Lee wrote: > > > A root complex usually consist of a host bridge and multiple P2P bridges, > > > and someone may express

Re: [PATCH 1/2] of_pci_irq: add a check to fallback to standard device tree parsing

On Fri, 2018-02-02 at 17:32 +0800, Ryder Lee wrote: > On Wed, 2018-01-31 at 10:02 -0600, Rob Herring wrote: > > On Wed, Jan 31, 2018 at 1:41 AM, Ryder Lee wrote: > > > A root complex usually consist of a host bridge and multiple P2P bridges, > > > and someone may express that in the form of a

[PATCH] clk: aspeed: Handle inverse polarity of USB port 1 clock gate

The USB port 1 clock gate control has an inversed polarity from all the other clock gates in the chip. This makes the aspeed_clk_{enable,disable} functions honor the flag CLK_GATE_SET_TO_DISABLE and set that flag appropriately so it's set for all clocks except USB port 1. Signed-off-by: Benjamin

[PATCH] clk: aspeed: Handle inverse polarity of USB port 1 clock gate

The USB port 1 clock gate control has an inversed polarity from all the other clock gates in the chip. This makes the aspeed_clk_{enable,disable} functions honor the flag CLK_GATE_SET_TO_DISABLE and set that flag appropriately so it's set for all clocks except USB port 1. Signed-off-by: Benjamin

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 10:59 +0100, Greg KH wrote: > And, if you use it in a device, it's still totally unsupported and > insecure. Seriously, does no one actually pay attention to the patches > I merge in the stable trees anymore? Yeah not sure why we aren't picking an LTC here, it could be that

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 10:59 +0100, Greg KH wrote: > And, if you use it in a device, it's still totally unsupported and > insecure. Seriously, does no one actually pay attention to the patches > I merge in the stable trees anymore? Yeah not sure why we aren't picking an LTC here, it could be that

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 09:41 +0100, Greg KH wrote: > On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote: > > On Wed, Jan 10, 2018 at 11:30 PM, Greg KH > > wrote: > > > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: > > > > Thanks for your

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 09:41 +0100, Greg KH wrote: > On Thu, Jan 11, 2018 at 12:28:48AM -0800, Joel Stanley wrote: > > On Wed, Jan 10, 2018 at 11:30 PM, Greg KH > > wrote: > > > On Wed, Jan 10, 2018 at 01:46:34PM -0800, Jae Hyun Yoo wrote: > > > > Thanks for your pointing it out and I totally

Re: [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers

On Tue, 2018-01-09 at 14:31 -0800, Jae Hyun Yoo wrote: > +struct peci_rd_ia_msr_msg { > + unsigned char target; > + unsigned char thread_id; > + unsigned short address; > + unsigned long value; > +}; Those types are representing messages on the wire ? In that case those

Re: [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers

On Tue, 2018-01-09 at 14:31 -0800, Jae Hyun Yoo wrote: > +struct peci_rd_ia_msr_msg { > + unsigned char target; > + unsigned char thread_id; > + unsigned short address; > + unsigned long value; > +}; Those types are representing messages on the wire ? In that case those

Re: [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers

On Wed, 2018-01-10 at 11:18 +0100, Greg KH wrote: > On Tue, Jan 09, 2018 at 02:31:23PM -0800, Jae Hyun Yoo wrote: > > This commit adds driver implementation for Aspeed PECI. Also adds > > generic peci.h and peci_ioctl.h files to provide compatibility > > to peci drivers that can be implemented

Re: [PATCH linux dev-4.10 3/6] drivers/misc: Add driver for Aspeed PECI and generic PECI headers

On Wed, 2018-01-10 at 11:18 +0100, Greg KH wrote: > On Tue, Jan 09, 2018 at 02:31:23PM -0800, Jae Hyun Yoo wrote: > > This commit adds driver implementation for Aspeed PECI. Also adds > > generic peci.h and peci_ioctl.h files to provide compatibility > > to peci drivers that can be implemented

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 08:30 +0100, Greg KH wrote: > 4.13? Why that kernel? It too is obsolete and insecure and > unsupported. Haha, it's n-1. come on :-) > What keeps you all from just always tracking the latest tree from Linus? > What is in your tree that is not upstream that requires you to

Re: [PATCH linux dev-4.10 0/6] Add support PECI and PECI hwmon drivers

On Thu, 2018-01-11 at 08:30 +0100, Greg KH wrote: > 4.13? Why that kernel? It too is obsolete and insecure and > unsupported. Haha, it's n-1. come on :-) > What keeps you all from just always tracking the latest tree from Linus? > What is in your tree that is not upstream that requires you to

Re: [PATCH v7 3/5] clk: aspeed: Add platform driver and register PLLs

Stanley <j...@jms.id.au> Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > -- > v6: > - Add Andrew's reviewed-by > v5: > - Remove eclk configuration. We do not have enough information to > correctly implement the mux and divisor, so it will have to be >

Re: [PATCH v7 3/5] clk: aspeed: Add platform driver and register PLLs

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > This registers a platform driver to set up all of the non-core clocks. > > The clocks that have configurable rates are now registered. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley Reviewed-by: Benj

Re: [PATCH v7 4/5] clk: aspeed: Register gated clocks

ex for the reset. > > Reviewed-by: Andrew Jeffery <and...@aj.id.au> > Signed-off-by: Joel Stanley <j...@jms.id.au> Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > v7: > - Use mdelay instead of msleep and remove the todo. Stephen points

Re: [PATCH v7 4/5] clk: aspeed: Register gated clocks

ex for the reset. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley Reviewed-by: Benjamin Herrenschmidt > --- > v7: > - Use mdelay instead of msleep and remove the todo. Stephen points out: > > No you can't sleep here. It needs to delay because this is inside &

Re: [PATCH v7 5/5] clk: aspeed: Add reset controller

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > There are some resets that are not associated with gates. These are > represented by a reset controller. > > Reviewed-by: Andrew Jeffery <and...@aj.id.au> > Signed-off-by: Joel Stanley <j...@jms.id.au> Reviewed

Re: [PATCH v7 5/5] clk: aspeed: Add reset controller

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > There are some resets that are not associated with gates. These are > represented by a reset controller. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley Reviewed-by: Benjamin Herrenschmidt > --- > v

Re: [PATCH v7 2/5] clk: aspeed: Register core clocks

-off-by: Joel Stanley <j...@jms.id.au> Reviewed-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > --- > v5: > - Add Andrew's Reviewed-by > v4: > - Add defines to document the BIT() macros > v3: > - Fix ast2400 ahb calculation > - Remove incorrect 'th

Re: [PATCH v7 2/5] clk: aspeed: Register core clocks

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > This registers the core clocks; those which are required to calculate > the rate of the timer peripheral so the system can load a clocksource > driver. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley Rev

Re: [PATCH v7 1/5] clk: Add clock driver for ASPEED BMC SoCs

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > This adds the stub of a driver for the ASPEED SoCs. The clocks are > defined and the static registration is set up. > > Reviewed-by: Andrew Jeffery <and...@aj.id.au> > Signed-off-by: Joel Stanley <j...@jms.id.au

Re: [PATCH v7 1/5] clk: Add clock driver for ASPEED BMC SoCs

On Fri, 2017-12-22 at 13:15 +1030, Joel Stanley wrote: > This adds the stub of a driver for the ASPEED SoCs. The clocks are > defined and the static registration is set up. > > Reviewed-by: Andrew Jeffery > Signed-off-by: Joel Stanley Reviewed-by: Benjamin Herrenschm

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Sat, 2017-12-30 at 09:03 +1100, Benjamin Herrenschmidt wrote: > On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote: > > > I noticed we do have a few i2c based clock drivers... how are they ever > > > supposed to work ? i2c bus controllers are allowed to sleep and the

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Sat, 2017-12-30 at 09:03 +1100, Benjamin Herrenschmidt wrote: > On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote: > > > I noticed we do have a few i2c based clock drivers... how are they ever > > > supposed to work ? i2c bus controllers are allowed to sleep and the

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote: > > I noticed we do have a few i2c based clock drivers... how are they ever > > supposed to work ? i2c bus controllers are allowed to sleep and the i2c > > core takes mutexes... > > We have clk_prepare()/clk_unprepare() for sleeping suckage.

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Tue, 2017-12-26 at 17:32 -0800, Stephen Boyd wrote: > > I noticed we do have a few i2c based clock drivers... how are they ever > > supposed to work ? i2c bus controllers are allowed to sleep and the i2c > > core takes mutexes... > > We have clk_prepare()/clk_unprepare() for sleeping suckage.

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Thu, 2017-12-21 at 15:39 -0800, Stephen Boyd wrote: > On 11/28, Joel Stanley wrote: > > diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c > > index 839243691b26..b5dc3e298693 100644 > > --- a/drivers/clk/clk-aspeed.c > > +++ b/drivers/clk/clk-aspeed.c > > @@ -202,6 +202,107 @@

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Thu, 2017-12-21 at 15:39 -0800, Stephen Boyd wrote: > On 11/28, Joel Stanley wrote: > > diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c > > index 839243691b26..b5dc3e298693 100644 > > --- a/drivers/clk/clk-aspeed.c > > +++ b/drivers/clk/clk-aspeed.c > > @@ -202,6 +202,107 @@

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Fri, 2017-12-22 at 13:36 +1100, Benjamin Herrenschmidt wrote: > > > No you can't sleep here. It needs to delay because this is inside > > spinlock_irqsave. > > Additionally you really don't want to delay for 10ms with interrupts > off :-( > > Sadly, it looks

Re: [PATCH v6 4/5] clk: aspeed: Register gated clocks

On Fri, 2017-12-22 at 13:36 +1100, Benjamin Herrenschmidt wrote: > > > No you can't sleep here. It needs to delay because this is inside > > spinlock_irqsave. > > Additionally you really don't want to delay for 10ms with interrupts > off :-( > > Sadly, it looks

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 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 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 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 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 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: [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 Acked-by: Benjamin Herrenschmidt

Re: [PATCH 1/4] 44x/fsp2: add fsp2 headers

On Mon, 2017-11-27 at 15:58 +1100, Alistair Popple wrote: > Hi Ivan, > > Does it make sense to have these in a seperate include file? From what I could > see these defines were only used in fsp2.c so you could just put them directly > in there. Or at least have an fsp2.h next to fsp2.c rather

Re: [PATCH 1/4] 44x/fsp2: add fsp2 headers

On Mon, 2017-11-27 at 15:58 +1100, Alistair Popple wrote: > Hi Ivan, > > Does it make sense to have these in a seperate include file? From what I could > see these defines were only used in fsp2.c so you could just put them directly > in there. Or at least have an fsp2.h next to fsp2.c rather

Re: [PATCH] powerpc/xive: store server for masked interrupt in kvmppc_xive_set_xive()

On Thu, 2017-11-23 at 10:06 +0100, Laurent Vivier wrote: > This is needed to map kvmppc_xive_set_xive() behavior > to kvmppc_xics_set_xive(). > > As we store the server, kvmppc_xive_get_xive() can return > the good value and we can also allow kvmppc_xive_int_on(). > > Signed-off-by: Laurent

Re: [PATCH] powerpc/xive: store server for masked interrupt in kvmppc_xive_set_xive()

On Thu, 2017-11-23 at 10:06 +0100, Laurent Vivier wrote: > This is needed to map kvmppc_xive_set_xive() behavior > to kvmppc_xics_set_xive(). > > As we store the server, kvmppc_xive_get_xive() can return > the good value and we can also allow kvmppc_xive_int_on(). > > Signed-off-by: Laurent

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Tue, 2017-11-21 at 19:28 +0200, Meelis Roos wrote: > For wider powerpc audience: this warning-like INFO bit is present > independently of theis patch. Is it dangerous for some configuration? > > INFO: Uncompressed kernel (size 0x5d6c54) overlaps the address of the > wrapper(0x40) > INFO:

Re: [PATCH v2] powerpc: fix boot on BOOK3S_32 with CONFIG_STRICT_KERNEL_RWX

On Tue, 2017-11-21 at 19:28 +0200, Meelis Roos wrote: > For wider powerpc audience: this warning-like INFO bit is present > independently of theis patch. Is it dangerous for some configuration? > > INFO: Uncompressed kernel (size 0x5d6c54) overlaps the address of the > wrapper(0x40) > INFO:

Re: [RFC PATCH v2] Fix: x86: Add missing core serializing instruction on migration

On Mon, 2017-11-13 at 10:26 +1100, Benjamin Herrenschmidt wrote: > On Sat, 2017-11-11 at 10:03 -0500, Mathieu Desnoyers wrote: > > x86 has a missing core serializing instruction in migration scenarios. > > > > Given that x86-32 can return to user-space with sysexit, and x86-6

Re: [RFC PATCH v2] Fix: x86: Add missing core serializing instruction on migration

On Mon, 2017-11-13 at 10:26 +1100, Benjamin Herrenschmidt wrote: > On Sat, 2017-11-11 at 10:03 -0500, Mathieu Desnoyers wrote: > > x86 has a missing core serializing instruction in migration scenarios. > > > > Given that x86-32 can return to user-space with sysexit, and x86-6

Re: [RFC PATCH v2] Fix: x86: Add missing core serializing instruction on migration

m.com> > CC: Boqun Feng <boqun.f...@gmail.com> > CC: Andrew Hunter <a...@google.com> > CC: Maged Michael <maged.mich...@gmail.com> > CC: Avi Kivity <a...@scylladb.com> > CC: Benjamin Herrenschmidt <b...@kernel.crashing.org> > CC: Paul Mackerras &

Re: [RFC PATCH v2] Fix: x86: Add missing core serializing instruction on migration

) static inline > need to define ARCH_HAS_SYNC_CORE_BEFORE_USERMODE. > > Signed-off-by: Mathieu Desnoyers > CC: Peter Zijlstra > CC: Andy Lutomirski > CC: Paul E. McKenney > CC: Boqun Feng > CC: Andrew Hunter > CC: Maged Michael > CC: Avi Kivity > CC: Benjamin H

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

On Mon, 2017-10-30 at 15:24 +0100, Wolfram Sang wrote: > checkpatch --strict says: > > CHECK: braces {} should be used on all arms of this statement And checkpatch should die a horrible death, so what ? :-) Sorry, I can't help but trolling here when checkpatch enforce obviously disgusting and

Re: [PATCH v3] i2c: aspeed: Deassert reset in probe

On Mon, 2017-10-30 at 15:24 +0100, Wolfram Sang wrote: > checkpatch --strict says: > > CHECK: braces {} should be used on all arms of this statement And checkpatch should die a horrible death, so what ? :-) Sorry, I can't help but trolling here when checkpatch enforce obviously disgusting and

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On Fri, 2017-10-13 at 19:37 +1100, Michael Ellerman wrote: > > We recently had a situation in which i40e driver couldn't start, > > even after a full power cycle, due to a bug in its FW triggered > > by a DCB condition in switch (thanks Mauro for narrowing this). > > This patch enabled us to

Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

On Fri, 2017-10-13 at 19:37 +1100, Michael Ellerman wrote: > > We recently had a situation in which i40e driver couldn't start, > > even after a full power cycle, due to a bug in its FW triggered > > by a DCB condition in switch (thanks Mauro for narrowing this). > > This patch enabled us to

Re: [PATCH v2] net: ftgmac100: Request clock and set speed

On Thu, 2017-10-12 at 11:32 +0800, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. This patch > configures a 100MHz clock if the system has a direct-attached > PHY, or 25MHz if the system is

Re: [PATCH v2] net: ftgmac100: Request clock and set speed

On Thu, 2017-10-12 at 11:32 +0800, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. This patch > configures a 100MHz clock if the system has a direct-attached > PHY, or 25MHz if the system is

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