Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote: > > > DRM drivers don't strike me as suitable for small/slow cores with dumb > > framebuffers or simple 2D only accel, such as the one found in the ASpeed > > BMCs. > > Then the DRM framework should be improved to be suitable. Dave ? :-)

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Thu, 2016-12-08 at 10:01 +0200, Tomi Valkeinen wrote: > > > DRM drivers don't strike me as suitable for small/slow cores with dumb > > framebuffers or simple 2D only accel, such as the one found in the ASpeed > > BMCs. > > Then the DRM framework should be improved to be suitable. Dave ? :-)

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

[PATCH] scsi/ipr: Fix runaway IRQs when falling back from MSI to LSI

Signed-off-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> --- drivers/scsi/ipr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c index 5324741..5dd3194 100644 --- a/drivers/scsi/ipr.c +++ b/drivers/scsi/ipr.c @@ -10213,6 +10213,7 @@ static i

[PATCH] scsi/ipr: Fix runaway IRQs when falling back from MSI to LSI

Signed-off-by: Benjamin Herrenschmidt --- drivers/scsi/ipr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c index 5324741..5dd3194 100644 --- a/drivers/scsi/ipr.c +++ b/drivers/scsi/ipr.c @@ -10213,6 +10213,7 @@ static int ipr_probe_ioa(struct pci

Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced

On Thu, 2016-11-10 at 11:22 +, Mark Rutland wrote: > On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind > > firmware calls ;-) We use that infrastructure to plumb in the LPC bus. > > Just to check, do you hook that in your inb/outb/etc? Yes. > Generally, it would seem

Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced

On Thu, 2016-11-10 at 11:22 +, Mark Rutland wrote: > On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind > > firmware calls ;-) We use that infrastructure to plumb in the LPC bus. > > Just to check, do you hook that in your inb/outb/etc? Yes. > Generally, it would seem

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote: > The big change would be to handle !MMIO translations, for which we'd > need a runtime registry of ISA bus instance to find the relevant > accessor ops and instance-specific data. Yes. We do something a bit like that on ppc, we find the PCI

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Wed, 2016-11-09 at 11:20 +, Mark Rutland wrote: > The big change would be to handle !MMIO translations, for which we'd > need a runtime registry of ISA bus instance to find the relevant > accessor ops and instance-specific data. Yes. We do something a bit like that on ppc, we find the PCI

Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced

On Tue, 2016-11-08 at 12:03 +, Mark Rutland wrote: > On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote: > > > > For arm64, there is no I/O space as other architectural platforms, such as > > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs, > > such as

Re: [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced

On Tue, 2016-11-08 at 12:03 +, Mark Rutland wrote: > On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote: > > > > For arm64, there is no I/O space as other architectural platforms, such as > > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs, > > such as

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Tue, 2016-11-08 at 11:49 +, Mark Rutland wrote: > > My understanding of ISA (which may be flawed) is that it's not part of > the PCI host bridge, but rather on x86 it happens to share the IO space > with PCI. Sort-of. On some systems it actually goes through PCI and there's a PCI->ISA

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

On Tue, 2016-11-08 at 11:49 +, Mark Rutland wrote: > > My understanding of ISA (which may be flawed) is that it's not part of > the PCI host bridge, but rather on x86 it happens to share the IO space > with PCI. Sort-of. On some systems it actually goes through PCI and there's a PCI->ISA

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote: > > Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to > commit 05fd007e4629 > Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne > l.org/msg1253391.html > Stat: 2016-10-22

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote: > > Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to > commit 05fd007e4629 > Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne > l.org/msg1253391.html > Stat: 2016-10-22

Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code

On Thu, 2016-10-06 at 20:32 +0530, Aneesh Kumar K.V wrote: > Laurent Dufour writes: > (Off-list) Did that bug make it to RHEL/CentOS/SLES ? We also need to poke Ubuntu to get the fix ASAP. > > This commit fixes a stack corruption in the pseries specific code > >

Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code

On Thu, 2016-10-06 at 20:32 +0530, Aneesh Kumar K.V wrote: > Laurent Dufour writes: > (Off-list) Did that bug make it to RHEL/CentOS/SLES ? We also need to poke Ubuntu to get the fix ASAP. > > This commit fixes a stack corruption in the pseries specific code > > dealing > > with the huge

Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code

On Thu, 2016-10-06 at 15:33 +0200, Laurent Dufour wrote: > This commit fixes a stack corruption in the pseries specific code > dealing > with the huge pages. Wow, nice catch ! > In __pSeries_lpar_hugepage_invalidate() the buffer used to pass > arguments > to the hypervisor is not large enough.

Re: [PATCH] powerpc/pseries: Fix stack corruption in htpe code

On Thu, 2016-10-06 at 15:33 +0200, Laurent Dufour wrote: > This commit fixes a stack corruption in the pseries specific code > dealing > with the huge pages. Wow, nice catch ! > In __pSeries_lpar_hugepage_invalidate() the buffer used to pass > arguments > to the hypervisor is not large enough.

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote: > Right, so I think Zhichang can make the necessary generic changes to  > 8250 OF driver to support IO port as well as MMIO-based. > > However an LPC-based earlycon driver is still required. > > A note on hip07-based D05 (for those unaware):

Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06

On Tue, 2016-10-04 at 13:02 +0100, John Garry wrote: > Right, so I think Zhichang can make the necessary generic changes to  > 8250 OF driver to support IO port as well as MMIO-based. > > However an LPC-based earlycon driver is still required. > > A note on hip07-based D05 (for those unaware):

Re: [PATCH 0/2] powerpc: stack protector (-fstack-protector) support

On Fri, 2016-09-30 at 18:38 +0200, Christophe LEROY wrote: > I don't have any ppc64 target, I only have mpc8xx and mpc83xx which > both  > are ppc32 That's what qemu is for :-) Cheers, Ben.

Re: [PATCH 0/2] powerpc: stack protector (-fstack-protector) support

On Fri, 2016-09-30 at 18:38 +0200, Christophe LEROY wrote: > I don't have any ppc64 target, I only have mpc8xx and mpc83xx which > both  > are ppc32 That's what qemu is for :-) Cheers, Ben.

Re: [PATCH v3 5/5] mm: enable CONFIG_MOVABLE_NODE on powerpc

On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote: > To create a movable node, we need to hotplug all of its memory into > ZONE_MOVABLE. > > Note that to do this, auto_online_blocks should be off. Since the memory > will first be added to the default zone, we must explicitly use >

Re: [PATCH v3 5/5] mm: enable CONFIG_MOVABLE_NODE on powerpc

On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote: > To create a movable node, we need to hotplug all of its memory into > ZONE_MOVABLE. > > Note that to do this, auto_online_blocks should be off. Since the memory > will first be added to the default zone, we must explicitly use >

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote: > At boot, the movable_node option sets bottom-up memblock allocation. > > This reduces the chance that, in the window before movable memory has > been identified, an allocation for the kernel might come from a movable > node. By going

Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

On Sun, 2016-09-25 at 13:36 -0500, Reza Arbab wrote: > At boot, the movable_node option sets bottom-up memblock allocation. > > This reduces the chance that, in the window before movable memory has > been identified, an allocation for the kernel might come from a movable > node. By going

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Wed, 2016-09-21 at 18:48 +0930, Joel Stanley wrote: > > What line is it out of the PHY ? The PHY IRQ ? If yes then it's meant > > to be telling you to go look at the PHY registers for a link status > > change, but only works if the PHY has also been configured > > appropriately... > > Yep, PHY

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Wed, 2016-09-21 at 18:48 +0930, Joel Stanley wrote: > > What line is it out of the PHY ? The PHY IRQ ? If yes then it's meant > > to be telling you to go look at the PHY registers for a link status > > change, but only works if the PHY has also been configured > > appropriately... > > Yep, PHY

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Wed, 2016-09-21 at 11:32 +0930, Joel Stanley wrote: > I had a look at the eval board schematic and it appears that the line > has pull down resistors on it, explaining why the IRQ fires when it's > configured to active low. Other machines re-use the pin pin as a GPIO. > So yes, I will change

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Wed, 2016-09-21 at 11:32 +0930, Joel Stanley wrote: > I had a look at the eval board schematic and it appears that the line > has pull down resistors on it, explaining why the IRQ fires when it's > configured to active low. Other machines re-use the pin pin as a GPIO. > So yes, I will change

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Tue, 2016-09-20 at 16:00 +0930, Joel Stanley wrote: > On Aspeed SoC with a direct PHY connection (non-NSCI), we receive > continual PHYSTS interrupts: > >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] =

Re: [PATCH net-next 6/7] net/faraday: Fix phy link irq on Aspeed G5 SoCs

On Tue, 2016-09-20 at 16:00 +0930, Joel Stanley wrote: > On Aspeed SoC with a direct PHY connection (non-NSCI), we receive > continual PHYSTS interrupts: > >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] = 0x200: PHYSTS_CHG >  [   20.28] ftgmac100 1e66.ethernet eth0: [ISR] =

Re: [PATCH v3 4/7] palmetto: Request relevant mux functions in devicetree

On Tue, 2016-09-13 at 22:11 +0930, Joel Stanley wrote: > It's not clear that all systems use these pins in that way. I will > not > include this one for now. Well, it has VGA so the VGA hsync, vsync and DDC should be there at least... Ben.

Re: [PATCH v3 4/7] palmetto: Request relevant mux functions in devicetree

On Tue, 2016-09-13 at 22:11 +0930, Joel Stanley wrote: > It's not clear that all systems use these pins in that way. I will > not > include this one for now. Well, it has VGA so the VGA hsync, vsync and DDC should be there at least... Ben.

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 10:24 +0200, Mike Galbraith wrote: > > > Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > > >  > > > > Signed-off-by: Balbir Singh <bsinghar...@gmail.com> > > > > --- > > ... no Cc: @stable?  Sou

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 10:24 +0200, Mike Galbraith wrote: > > > Acked-by: Benjamin Herrenschmidt > > >  > > > > Signed-off-by: Balbir Singh > > > > --- > > ... no Cc: @stable?  Sounds plenty nasty enough to be worthy. Right, we should ha

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 13:16 +1000, Balbir Singh wrote:  .../... > > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Nicholas Piggin <npig...@gmail.com> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> > Signed-off-by: Balbir Singh <bsinghar...@gmail.

Re: [RESEND][v2][PATCH] Fix a race between try_to_wake_up() and a woken up task

On Mon, 2016-09-05 at 13:16 +1000, Balbir Singh wrote:  .../... > > Cc: Peter Zijlstra > Cc: Nicholas Piggin Acked-by: Benjamin Herrenschmidt > Signed-off-by: Balbir Singh > --- >  kernel/sched/core.c | 11 +++ >  1 file changed, 11 insertions(+) > >

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 15:31 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:28:18AM +1000, Benjamin Herrenschmidt > wrote: > > > > > On powerpc we have a sync deep in _switch to achieve that. > > OK, for giggles, could you (or Balbir) check what happens

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 15:31 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:28:18AM +1000, Benjamin Herrenschmidt > wrote: > > > > > On powerpc we have a sync deep in _switch to achieve that. > > OK, for giggles, could you (or Balbir) check what happens

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:18 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:28:18AM +1000, Benjamin Herrenschmidt > wrote: > > > > It's always been a requirement that if you actually context switch > > a > > full mb() is implied ... > > > > &

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:20 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:25:01AM +1000, Benjamin Herrenschmidt wrote: > > > > On Tue, 2016-08-30 at 15:04 +0200, Oleg Nesterov wrote: > > > > > > > > > Confused... how this connects to UNLO

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:18 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:28:18AM +1000, Benjamin Herrenschmidt > wrote: > > > > It's always been a requirement that if you actually context switch > > a > > full mb() is implied ... > > > > &

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:20 +0200, Peter Zijlstra wrote: > On Wed, Aug 31, 2016 at 07:25:01AM +1000, Benjamin Herrenschmidt wrote: > > > > On Tue, 2016-08-30 at 15:04 +0200, Oleg Nesterov wrote: > > > > > > > > > Confused... how this connects to UNLO

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:28 +0200, Peter Zijlstra wrote: > > What hardware do you see this on, is it shiny new Power8 chips which > have never before seen deep queues or something. Or is it 'regular' > old Power7 like stuff? Power8 which isn't *that* new these days... Cheers, Ben.

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Wed, 2016-08-31 at 09:28 +0200, Peter Zijlstra wrote: > > What hardware do you see this on, is it shiny new Power8 chips which > have never before seen deep queues or something. Or is it 'regular' > old Power7 like stuff? Power8 which isn't *that* new these days... Cheers, Ben.

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Tue, 2016-08-30 at 20:34 +0200, Peter Zijlstra wrote: > > I'm not actually sure it does. There is the comment from 8643cda549ca4 > which explain the program order guarantees. > > But I'm not sure who or what would simply a full smp_mb() when you call > schedule() -- I mean, its true on x86,

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Tue, 2016-08-30 at 20:34 +0200, Peter Zijlstra wrote: > > I'm not actually sure it does. There is the comment from 8643cda549ca4 > which explain the program order guarantees. > > But I'm not sure who or what would simply a full smp_mb() when you call > schedule() -- I mean, its true on x86,

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Tue, 2016-08-30 at 15:04 +0200, Oleg Nesterov wrote: > > Confused... how this connects to UNLOCK+LOCK on rq->lock? A LOAD can > leak into the critical section. > > But context switch should imply mb() we can rely on? Between setting of ->on_rq and returning to the task so it can change its

Re: [RFC][PATCH] Fix a race between rwsem and the scheduler

On Tue, 2016-08-30 at 15:04 +0200, Oleg Nesterov wrote: > > Confused... how this connects to UNLOCK+LOCK on rq->lock? A LOAD can > leak into the critical section. > > But context switch should imply mb() we can rely on? Between setting of ->on_rq and returning to the task so it can change its

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag

On Mon, 2016-08-29 at 12:15 -0700, Linus Torvalds wrote: > On Sun, Aug 28, 2016 at 9:44 PM, Benjamin Herrenschmidt > > <b...@kernel.crashing.org> wrote: > > > > > > This is my first signed-tag and use of 2fa so I hope I got it all right... > > I tr

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag

On Mon, 2016-08-29 at 12:15 -0700, Linus Torvalds wrote: > On Sun, Aug 28, 2016 at 9:44 PM, Benjamin Herrenschmidt > > wrote: > > > > > > This is my first signed-tag and use of 2fa so I hope I got it all right... > > I tried to use the same fo

[GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag

Hi Linus ! So my appologies for being a lousy replacement maintainer while Michael is on vacation ... this was meant to be sent early last week, but I has a change pending on one of the fixes and other things made me forget all about. Ugh. This is my first signed-tag and use of 2fa so I hope I

[GIT PULL] Please pull powerpc/linux.git powerpc-4.8-4 tag

Hi Linus ! So my appologies for being a lousy replacement maintainer while Michael is on vacation ... this was meant to be sent early last week, but I has a change pending on one of the fixes and other things made me forget all about. Ugh. This is my first signed-tag and use of 2fa so I hope I

Re: [PATCH v2] powerpc: move hmi.c to arch/powerpc/kvm/

On Thu, 2016-08-18 at 10:53 +0200, Paolo Bonzini wrote: > > On 11/08/2016 15:07, Paolo Bonzini wrote: > > > > hmi.c functions are unused unless sibling_subcore_state is nonzero, > > and > > that in turn happens only if KVM is in use.  So move the code to > > arch/powerpc/kvm/, putting it under

Re: [PATCH v2] powerpc: move hmi.c to arch/powerpc/kvm/

On Thu, 2016-08-18 at 10:53 +0200, Paolo Bonzini wrote: > > On 11/08/2016 15:07, Paolo Bonzini wrote: > > > > hmi.c functions are unused unless sibling_subcore_state is nonzero, > > and > > that in turn happens only if KVM is in use.  So move the code to > > arch/powerpc/kvm/, putting it under

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Mon, 2016-08-15 at 23:16 +, Rustad, Mark D wrote: > > Bugs in existing guests is an interesting case, but I have been focused on   > getting acceptable behavior from a properly functioning guest, in the face   > of hardware issues that can only be resolved in a single place. > > I agree

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Mon, 2016-08-15 at 23:16 +, Rustad, Mark D wrote: > > Bugs in existing guests is an interesting case, but I have been focused on   > getting acceptable behavior from a properly functioning guest, in the face   > of hardware issues that can only be resolved in a single place. > > I agree

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-16 at 08:23 +1000, Benjamin Herrenschmidt wrote: > > I don't think desktop users appreciate hangs any more than anyone else, and  > >   > > that is one of the symptoms that can arise here without the vfio   > > coordination. > > And can happen wit

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-16 at 08:23 +1000, Benjamin Herrenschmidt wrote: > > I don't think desktop users appreciate hangs any more than anyone else, and  > >   > > that is one of the symptoms that can arise here without the vfio   > > coordination. > > And can happen wit

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Mon, 2016-08-15 at 17:59 +, Rustad, Mark D wrote: > > Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > > > > > We may want some kind of "strict" vs. "relaxed" model here to > > differenciate the desktop user wanting to give a

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Mon, 2016-08-15 at 17:59 +, Rustad, Mark D wrote: > > Benjamin Herrenschmidt wrote: > > > > > We may want some kind of "strict" vs. "relaxed" model here to > > differenciate the desktop user wanting to give a function to his/her >

Re: [PATCH 02/12] pinctrl: Add core pinctrl support for Aspeed SoCs

On Fri, 2016-08-12 at 15:18 +0200, Linus Walleij wrote: > I would probably prefer that option (introduce another field) > but you should make the overall decision, it's no strong opinion > from my side. > > > Would it be acceptable to document that requirement? It might make it a bit less nasty

Re: [PATCH 02/12] pinctrl: Add core pinctrl support for Aspeed SoCs

On Fri, 2016-08-12 at 15:18 +0200, Linus Walleij wrote: > I would probably prefer that option (introduce another field) > but you should make the overall decision, it's no strong opinion > from my side. > > > Would it be acceptable to document that requirement? It might make it a bit less nasty

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Thu, 2016-08-11 at 14:17 -0600, Alex Williamson wrote: > > vfio isn't playing nanny here for the fun of it, part of the reason we > have vpd access functions is because folks have discovered that vpd > registers between PCI functions on multi-function devices may be > shared.  So pounding on

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Thu, 2016-08-11 at 14:17 -0600, Alex Williamson wrote: > > vfio isn't playing nanny here for the fun of it, part of the reason we > have vpd access functions is because folks have discovered that vpd > registers between PCI functions on multi-function devices may be > shared.  So pounding on

Re: spin_lock implicit/explicit memory barrier

On Wed, 2016-08-10 at 15:23 -0700, Davidlohr Bueso wrote: > On Wed, 10 Aug 2016, Paul E. McKenney wrote: > > > > > On Wed, Aug 10, 2016 at 08:21:22PM +0200, Manfred Spraul wrote: >   4) > > > spin_unlock_wait() and spin_unlock() pair >

Re: spin_lock implicit/explicit memory barrier

On Wed, 2016-08-10 at 15:23 -0700, Davidlohr Bueso wrote: > On Wed, 10 Aug 2016, Paul E. McKenney wrote: > > > > > On Wed, Aug 10, 2016 at 08:21:22PM +0200, Manfred Spraul wrote: >   4) > > > spin_unlock_wait() and spin_unlock() pair >

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Wed, 2016-08-10 at 08:47 -0700, Alexander Duyck wrote: > > The problem is if we don't do this it becomes possible for a guest to > essentially cripple a device on the host by just accessing VPD > regions that aren't actually viable on many devices.  And ? We already can cripple the device in

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Wed, 2016-08-10 at 08:47 -0700, Alexander Duyck wrote: > > The problem is if we don't do this it becomes possible for a guest to > essentially cripple a device on the host by just accessing VPD > regions that aren't actually viable on many devices.  And ? We already can cripple the device in

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-09 at 11:12 -0700, Alexander Duyck wrote: > > The PCI spec is what essentially assumes that there is only one block. > If I am not mistaken in the case of this device the second block here > actually contains device configuration data, not actual VPD data.  The > issue here is

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

On Tue, 2016-08-09 at 11:12 -0700, Alexander Duyck wrote: > > The PCI spec is what essentially assumes that there is only one block. > If I am not mistaken in the case of this device the second block here > actually contains device configuration data, not actual VPD data.  The > issue here is

Re: spin_lock implicit/explicit memory barrier

On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > Hi Benjamin, Hi Michael, > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to  > arch_spin_is_locked()"): > > For the ipc/sem code, I would like to replace the spin_is_locked() with  > a smp_load_acquire(), see: > >

Re: spin_lock implicit/explicit memory barrier

On Tue, 2016-08-09 at 20:52 +0200, Manfred Spraul wrote: > Hi Benjamin, Hi Michael, > > regarding commit 51d7d5205d33 ("powerpc: Add smp_mb() to  > arch_spin_is_locked()"): > > For the ipc/sem code, I would like to replace the spin_is_locked() with  > a smp_load_acquire(), see: > >

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

> On Tue, 2016-08-09 at 22:54 +1000, Alexey Kardashevskiy wrote: > The cxgb3 driver is reading the second bit starting from 0xc00 but since > the size is wrongly detected as 0x7c, VFIO blocks access beyond it and the > guest driver fails to probe. > > I also cannot find a clause in the PCI 3.0

Re: [PATCHv2 3/4] pci: Determine actual VPD size on first access

> On Tue, 2016-08-09 at 22:54 +1000, Alexey Kardashevskiy wrote: > The cxgb3 driver is reading the second bit starting from 0xc00 but since > the size is wrongly detected as 0x7c, VFIO blocks access beyond it and the > guest driver fails to probe. > > I also cannot find a clause in the PCI 3.0

Re: kexec: device shutdown vs. remove

On Sun, 2016-07-24 at 16:36 -0500, Eric W. Biederman wrote: > > A lot of drivers we care about are modular. But maybe the right > > approach is to do something like remove() if it exist and > shutdown() if > > it doesn't ? Or a new callback for kexec ? quiesce() ? > > Perhaps remove if shutdown

Re: kexec: device shutdown vs. remove

On Sun, 2016-07-24 at 16:36 -0500, Eric W. Biederman wrote: > > A lot of drivers we care about are modular. But maybe the right > > approach is to do something like remove() if it exist and > shutdown() if > > it doesn't ? Or a new callback for kexec ? quiesce() ? > > Perhaps remove if shutdown

Re: kexec: device shutdown vs. remove

On Sun, 2016-07-24 at 00:24 -0500, Eric W. Biederman wrote: > If you are willing to do the work to merge shutdown into remove and > simplify the drivers, perform the testing and the other state I am in > favor of the change.  I think we have had enough time to see if have two > methods was

Re: kexec: device shutdown vs. remove

On Sun, 2016-07-24 at 00:24 -0500, Eric W. Biederman wrote: > If you are willing to do the work to merge shutdown into remove and > simplify the drivers, perform the testing and the other state I am in > favor of the change.  I think we have had enough time to see if have two > methods was

Re: kexec: device shutdown vs. remove

On Sat, 2016-07-23 at 22:18 -0700, Guenter Roeck wrote: > I suspect that using (or depending on) the remove function may not be feasible > anymore after the recent effort by Paul Gortmaker to make drivers explicitly > non-modular if they are only configurable as boolean. In many cases, this >

Re: kexec: device shutdown vs. remove

On Sat, 2016-07-23 at 22:18 -0700, Guenter Roeck wrote: > I suspect that using (or depending on) the remove function may not be feasible > anymore after the recent effort by Paul Gortmaker to make drivers explicitly > non-modular if they are only configurable as boolean. In many cases, this >

kexec: device shutdown vs. remove

Hi ! This is somewhat of a recurring issue, some of my previous attempts on lkml, I suspect, were just drowned in the noise. Eric, we had a quick discussion about this a while back but I don't think we reached a conclusion. A bit of context: On OpenPOWER machines, we have a Linux based

kexec: device shutdown vs. remove

Hi ! This is somewhat of a recurring issue, some of my previous attempts on lkml, I suspect, were just drowned in the noise. Eric, we had a quick discussion about this a while back but I don't think we reached a conclusion. A bit of context: On OpenPOWER machines, we have a Linux based

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, 2016-07-07 at 23:21 +1000, Benjamin Herrenschmidt wrote: >  > I think the right fix is that if a restore_sigcontext() has the MSR > bits set, > it should set the corresponding used_* flag. Something like this: (totally untested) diff --git a/arch/powerpc/kernel/signal

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, 2016-07-07 at 23:21 +1000, Benjamin Herrenschmidt wrote: >  > I think the right fix is that if a restore_sigcontext() has the MSR > bits set, > it should set the corresponding used_* flag. Something like this: (totally untested) diff --git a/arch/powerpc/kernel/signal

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, 2016-07-07 at 15:12 +0200, Laurent Dufour wrote: > > Basically, CRIU checkpoints the process register's state through the > ptrace API, and it restores it through a signal frame at restart time. > This is quite odd but that the way it works on all the CRIU's supported > architectures. >

Re: [v4] powerpc: Export thread_struct.used_vr/used_vsr to user space

On Thu, 2016-07-07 at 15:12 +0200, Laurent Dufour wrote: > > Basically, CRIU checkpoints the process register's state through the > ptrace API, and it restores it through a signal frame at restart time. > This is quite odd but that the way it works on all the CRIU's supported > architectures. >

Re: [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum

On Fri, 2016-07-01 at 10:46 -0700, Dave Hansen wrote: > The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights > Landing) has an erratum where a processor thread setting the Accessed > or Dirty bits may not do so atomically against its checks for the > Present bit.  This may cause a

Re: [PATCH 0/4] [RFC][v4] Workaround for Xeon Phi PTE A/D bits erratum

On Fri, 2016-07-01 at 10:46 -0700, Dave Hansen wrote: > The Intel(R) Xeon Phi(TM) Processor x200 Family (codename: Knights > Landing) has an erratum where a processor thread setting the Accessed > or Dirty bits may not do so atomically against its checks for the > Present bit.  This may cause a

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

On Tue, 2016-06-28 at 08:06 +0100, David Binderman wrote: > > I don't know the code, but given that insn is unsigned long and so > can go > past 32 bits, using a cast to unsigned int might throw away the > possibly important > upper bits. our instructions are only ever 32-bits. That xmon code is

Re: arch/powerpc/xmon/dis-asm.h: 2 * wrong specifiers ?

On Tue, 2016-06-28 at 08:06 +0100, David Binderman wrote: > > I don't know the code, but given that insn is unsigned long and so > can go > past 32 bits, using a cast to unsigned int might throw away the > possibly important > upper bits. our instructions are only ever 32-bits. That xmon code is

Re: [PATCH v6 07/11] powerpc/powernv: set power_save func after the idle states are initialized

am R. Shenoy <e...@linux.vnet.ibm.com> > Signed-off-by: Shreyas B. Prabhu <shre...@linux.vnet.ibm.com> Acked-by: Benjamin Herrenschmidt <b...@kernel.crashing.org> Please merge that one as-is now, no need to wait for the rest, as otherwise pwoer9 crashes at boot. It doesn't need to wait

Re: [PATCH v6 07/11] powerpc/powernv: set power_save func after the idle states are initialized

y > Signed-off-by: Shreyas B. Prabhu Acked-by: Benjamin Herrenschmidt Please merge that one as-is now, no need to wait for the rest, as otherwise pwoer9 crashes at boot. It doesn't need to wait for the rest of the series. Cheers, Ben. > --- > - No changes since v1 > >  arch/po

Re: [off-list] a path toward killing thread_info

On Fri, 2016-06-17 at 16:10 -0700, H. Peter Anvin wrote: >  > Yes. > > I did a half-finished patchset to do this once, in that I defined > accessor functions which used container_of instead of pointers on > architectures where this merge was enabled. How do you get to "current" in that case ? A

Re: [off-list] a path toward killing thread_info

On Fri, 2016-06-17 at 16:10 -0700, H. Peter Anvin wrote: >  > Yes. > > I did a half-finished patchset to do this once, in that I defined > accessor functions which used container_of instead of pointers on > architectures where this merge was enabled. How do you get to "current" in that case ? A

Re: [PATCH] tracing: Expose CPU physical addresses (resource values) for PCI devices

On Fri, 2016-06-17 at 17:59 -0400, Steven Rostedt wrote: > Sorry for the late reply, this patch got pushed down in my INBOX. > > Could I get someone from PPC to review this patch, just to be safe? The patch makes sense, I can try getting somebody onto porting mmiotrace one of these days.

Re: [PATCH] tracing: Expose CPU physical addresses (resource values) for PCI devices

On Fri, 2016-06-17 at 17:59 -0400, Steven Rostedt wrote: > Sorry for the late reply, this patch got pushed down in my INBOX. > > Could I get someone from PPC to review this patch, just to be safe? The patch makes sense, I can try getting somebody onto porting mmiotrace one of these days.

<    6   7   8   9   10   11   12   13   14   15   >