Re: [RFC PATCH 0/6] Change vendor prefix for Intersil Corporation

2014-09-07 Thread Jason Cooper
On Wed, Aug 20, 2014 at 08:16:43AM -0400, Jason Cooper wrote: Philipp, On Wed, Aug 20, 2014 at 10:42:58AM +0200, Philipp Zabel wrote: Hi, currently there is a wild mixture of isl, isil, and intersil compatibles in the kernel. I figure at this point it is still possible to change

Re: bit fields data tearing

2014-09-07 Thread Paul E. McKenney
On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote: On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote: Hi James, On 09/04/2014 10:11 PM, James Bottomley wrote: On Thu, 2014-09-04 at 17:17 -0700,

[PATCH 0/2 v5] powerpc/kvm: support to handle sw breakpoint

2014-09-07 Thread Madhavan Srinivasan
This patchset adds ppc64 server side support for software breakpoint and extends the use of illegal instruction as software breakpoint across ppc platform. Patch 1, adds kernel side support for software breakpoint. Design is that, by using an illegal instruction, we trap to hypervisor via

[PATCH 1/2 v5] powerpc/kvm: support to handle sw breakpoint

2014-09-07 Thread Madhavan Srinivasan
This patch adds kernel side support for software breakpoint. Design is that, by using an illegal instruction, we trap to hypervisor via Emulation Assistance interrupt, where we check for the illegal instruction and accordingly we return to Host or Guest. Patch also adds support for software

[PATCH 2/2 v5] powerpc/kvm: common sw breakpoint instr across ppc

2014-09-07 Thread Madhavan Srinivasan
This patch extends the use of illegal instruction as software breakpoint instruction across the ppc platform. Patch extends booke program interrupt code to support software breakpoint. Signed-off-by: Madhavan Srinivasan ma...@linux.vnet.ibm.com --- Patch is only compile tested. Will really help

Re: bit fields data tearing

2014-09-07 Thread James Bottomley
On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote: On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote: On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote: Hi James, On 09/04/2014 10:11 PM,

Re: [PATCH 0/2] PCI/MSI: Remove arch_msi_check_device()

2014-09-07 Thread Alexander Gordeev
On Fri, Sep 05, 2014 at 03:27:49PM -0600, Bjorn Helgaas wrote: I applied these (with Michael's ack on the first, and v2 of the second) to pci/msi for v3.18, thanks! Hi Bjorn, I resent a series with updates that fix kbuild robot errors. Hopefully, the rebase for pci/msi would not cause

Re: bit fields data tearing

2014-09-07 Thread Peter Hurley
On 09/07/2014 03:04 PM, James Bottomley wrote: On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote: On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote: On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:

Re: bit fields data tearing

2014-09-07 Thread Paul E. McKenney
On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote: On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote: On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote: On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote: On Thu, Sep 04, 2014 at 10:47:24PM

Re: bit fields data tearing

2014-09-07 Thread H. Peter Anvin
I'm confused why storing 0x0102 would be a problem. I think gcc does that even on other cpus. More atomicity can't hurt, can it? On September 7, 2014 4:00:19 PM PDT, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Sep 07, 2014 at 12:04:47PM -0700, James Bottomley wrote: On Sun,

Re: bit fields data tearing

2014-09-07 Thread Paul E. McKenney
On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote: I'm confused why storing 0x0102 would be a problem. I think gcc does that even on other cpus. More atomicity can't hurt, can it? I must defer to James for any additional details on why PARISC systems don't provide atomicity

Re: bit fields data tearing

2014-09-07 Thread H. Peter Anvin
How many PARISC systems do we have that actually do real work on Linux? On September 7, 2014 4:36:55 PM PDT, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Sep 07, 2014 at 04:17:30PM -0700, H. Peter Anvin wrote: I'm confused why storing 0x0102 would be a problem. I think gcc does

[PATCH v2 3/3] PCI/MSI: Remove arch_msi_check_device()

2014-09-07 Thread Alexander Gordeev
There are no archs that override arch_msi_check_device() hook. Remove it as it is completely redundant. If an arch would need to check MSI/MSI-X possibility for a device it should make it within arch_setup_msi_irqs() hook. Cc: Michael Ellerman m...@ellerman.id.au Cc:

[PATCH v2 1/3] PCI/MSI/PPC: Remove arch_msi_check_device()

2014-09-07 Thread Alexander Gordeev
Moving MSI checks from arch_msi_check_device() function to arch_setup_msi_irqs() function makes code more compact and allows removing unnecessary hook arch_msi_check_device() from generic MSI code. Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-...@vger.kernel.org Cc: Michael Ellerman

[PATCH v2 0/3] PCI/MSI: Remove arch_msi_check_device()

2014-09-07 Thread Alexander Gordeev
Hello, This is a cleanup effort to get rid of arch_msi_check_device() function. I am sending v2 series, since kbuild for v1 reports compile errors on ppc4xx and Armada 370. Still, I have not checked the fixes on these platforms. Changes since v1: - patch 1: 'pdev' undeclared compile error

Re: bit fields data tearing

2014-09-07 Thread James Bottomley
On Sun, 2014-09-07 at 16:41 -0400, Peter Hurley wrote: On 09/07/2014 03:04 PM, James Bottomley wrote: On Sun, 2014-09-07 at 09:21 -0700, Paul E. McKenney wrote: On Sat, Sep 06, 2014 at 10:07:22PM -0700, James Bottomley wrote: On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote: On

Re: bit fields data tearing

2014-09-07 Thread James Bottomley
On Sun, 2014-09-07 at 16:39 -0700, H. Peter Anvin wrote: How many PARISC systems do we have that actually do real work on Linux? I'd be very surprised if this problem didn't exist on all alignment requiring architectures, like PPC and Sparc as well. I know it would be very convenient if all the