On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:
> On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
> >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> >index 8465c2a..da6bf61 100644
> >--- a/arch/powerpc/kvm/powerpc.c
> >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_
From: Matteo Facchinetti
Add MPC5125 PSC register layout structure, MPC5125 specific
psc_ops function set and the compatible string.
Signed-off-by: Vladimir Ermakov
Signed-off-by: Matteo Facchinetti
Signed-off-by: Anatolij Gustschin
---
Changes in v2:
- split into two patches to simplify rev
From: Matteo Facchinetti
MPC5125 PSC controller has different register layout than MPC5121.
To support MPC5125 PSC in this driver we have to provide further
psc_ops functions for SoC specific register accesses.
Add new register access functions to the psc_ops structure and
provide MPC52xx and MP
On Fri, May 24, 2013 at 07:49:12PM +0200, Anatolij Gustschin wrote:
> On Wed, 17 Apr 2013 23:21:41 +0200
> Anatolij Gustschin wrote:
>
> > From: Matteo Facchinetti
> >
> > MPC5125 PSC controller has different register layout than MPC5121.
> > To support MPC5125 PSC in this driver we have to pro
On Wed, 17 Apr 2013 23:21:41 +0200
Anatolij Gustschin wrote:
> From: Matteo Facchinetti
>
> MPC5125 PSC controller has different register layout than MPC5121.
> To support MPC5125 PSC in this driver we have to provide further
> psc_ops functions for SoC specific register accesses.
>
> Add new
On Fri, May 24, 2013 at 12:46:36PM -0400, Jason Cooper wrote:
> > Why are you not keen on this? It seems like normal device driver
> > practice, that is what the data field of of_device_id is typically
> > used for..
>
> I'm not keen on it because we don't have a document saying "All kirkwood
> S
On 05/24/2013 07:13 PM, Russell King - ARM Linux wrote:
Do you really want that on ARM? Given the fiasco with the location of
the registers, are you sure you want to place more trust in that
direction? Does it give you a warm fuzzy feeling to know that you
might have to work out some way to pat
On Fri, May 24, 2013 at 01:01:25PM -0400, Jason Cooper wrote:
> On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote:
> > IMO: if you want to go down that road, what you really want is not
> > ever more expressible device trees, but real open firmware,
> > or ACPI or UEFI that can interpre
On Fri, May 24, 2013 at 06:53:15PM +0200, Andrew Lunn wrote:
> > > Why are you not keen on this? It seems like normal device driver
> > > practice, that is what the data field of of_device_id is typically
> > > used for..
> >
> > I'm not keen on it because we don't have a document saying "All kirk
On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote:
> On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth
> wrote:
> > On 05/23/2013 08:40 PM, Jason Cooper wrote:
>
> >> I think marvell,psc1_reset =<>; gives us the most flexibility in
> >> accurately describing the hardware.
> >
>
On Fri, May 24, 2013 at 12:40:26AM +0200, Sebastian Hesselbarth wrote:
> On 05/23/2013 08:40 PM, Jason Cooper wrote:
> >On Thu, May 23, 2013 at 11:53:57AM -0600, Jason Gunthorpe wrote:
> >>On Thu, May 23, 2013 at 01:23:39PM -0400, Jason Cooper wrote:
> >>>Shouldn't it rather be
> >>>
> >>> compat
On Thu, May 23, 2013 at 01:01:40PM -0600, Jason Gunthorpe wrote:
> On Thu, May 23, 2013 at 02:40:28PM -0400, Jason Cooper wrote:
>
> > > But there is a larger problem here then just this one bit.
> > >
> > > The PSC1 register must be set properly for the board layout, and today
> > > we rely on t
The only reason uaccess routines might sleep
is if they fault. Make this explicit.
Arnd Bergmann suggested that the following code
if (!is_kernel_addr((unsigned long)__pu_addr))
might_fault();
can be further simplified by adding a version of might_fault
that includes the ke
On Tue, 2013-05-21 at 13:33 +1000, Alexey Kardashevskiy wrote:
> The enables VFIO on the pSeries platform, enabling user space
> programs to access PCI devices directly.
>
> Signed-off-by: Alexey Kardashevskiy
> Cc: David Gibson
> Signed-off-by: Paul Mackerras
Acked-by: Alex Williamson
> ---
On Tue, 2013-05-21 at 13:33 +1000, Alexey Kardashevskiy wrote:
> VFIO implements platform independent stuff such as
> a PCI driver, BAR access (via read/write on a file descriptor
> or direct mapping when possible) and IRQ signaling.
>
> The platform dependent part includes IOMMU initialization
>
On Friday 24 May 2013, Michael S. Tsirkin wrote:
> So this won't work, unless we add the is_kernel_addr check
> to might_fault. That will become possible on top of this patchset
> but let's consider this carefully, and make this a separate
> patchset, OK?
Yes, makes sense.
Arnd
__
On Fri, May 24, 2013 at 04:00:32PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 22, 2013 at 03:59:01PM +0200, Arnd Bergmann wrote:
> > On Thursday 16 May 2013, Michael S. Tsirkin wrote:
> > > @@ -178,7 +178,7 @@ do {
> > > \
> > >
On Wed, May 22, 2013 at 03:59:01PM +0200, Arnd Bergmann wrote:
> On Thursday 16 May 2013, Michael S. Tsirkin wrote:
> > @@ -178,7 +178,7 @@ do {
> > \
> > long __pu_err; \
> > __
On Fri, May 24, 2013 at 12:40 AM, Sebastian Hesselbarth
wrote:
> On 05/23/2013 08:40 PM, Jason Cooper wrote:
>> I think marvell,psc1_reset =<>; gives us the most flexibility in
>> accurately describing the hardware.
>
>
> IMHO using that is just another workaround for a broken driver. We
> could
Hi Linus !
Here are a few more powerpc fixes for 3.10. Some more P8 related
bits, a bunch of fixes for our P7+/P8 HW crypto drivers, some added
workarounds for those radeons that don't do proper 64-bit MSIs and
a couple of other trivialities by myself.
Cheers,
Ben.
The following changes since co
20 matches
Mail list logo
