While converting code to use for_each_node_by_type I noticed a
number of coding style issues.
Signed-off-by: Anton Blanchard
---
Index: linux-powerpc/arch/powerpc/kernel/setup_64.c
===
--- linux-powerpc.orig/arch/powerpc/kernel/setu
Use for_each_node_by_type instead of open coding it.
Signed-off-by: Anton Blanchard
---
Index: linux-powerpc/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-powerpc.orig/arch/powerpc/kernel/machine_kexec_64.c 2011-08-10
16:1
During memory hotplug testing, I got the following warning:
ERROR: Bad of_node_put() on /memory@0
of_node_release
kref_put
of_node_put
of_find_node_by_type
hot_add_node_scn_to_nid
hot_add_scn_to_nid
memory_add_physaddr_to_nid
...
of_find_node_by_type() loop does of_node_put for us so remove th
CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6, thus
breaking clear_pages(), probably others too.
This patch adds a new "Processor Type" entry for e500mc, and makes e500 systems
depend on PPC_E500_V1_V2.
Cc: Kumar Gala
Signed-off-by: Baruch Siach
---
Changes from v2:
Hi Scott,
On Mon, Aug 08, 2011 at 02:42:52PM -0500, Scott Wood wrote:
> On 08/08/2011 04:07 AM, Baruch Siach wrote:
> > CONFIG_E500MC breaks e500/e500v2 systems. It defines L1_CACHE_SHIFT to 6,
> > thus
> > breaking clear_pages(), probably others too.
> >
> > This patch adds a new "Processor Typ
On Tue, Aug 09, 2011 at 06:31:48PM +0200, Alexander Graf wrote:
> Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
> enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
> mode.
Don't we want to enable it only for 64-bit hosts? Trying to run a
PAP
In working with the socketcan developers, we have come to the conclusion
the Documentation...fsl-flexcan.txt device tree documentation needs to
be cleaned up. The driver does not depend upon any properties other
than the required properties so we are removing the file. Additionally,
the p1010*dts
I added a simple clock source for the p1010rdb so the flexcan driver
could determine a clock frequency. The p1010 can device only has an
oscillator of system bus frequency divided by 2.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde ,
Acked-by: Wolfgang Grandegger ,
To: U Bhaskar-B22300
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger
powerpc does not have a mach-/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kerne
With all the patches applied, my p1010rdb works for communicating between
its two can ports and also can communicate with an external PSOC. I have
done no testing beyond compile testing on an arm system as I have no
access to an arm based system.
For the first three patches in the series, I beli
> Mostly correct, yes. x86 isn't immune to the group problem, it shows up
> for us any time there's a PCIe-to-PCI bridge in the device hierarchy.
> We lose resolution of devices behind the bridge. As you state though, I
> think of this as only a constraint on what we're able to do with those
> d
On Mon, 2011-08-08 at 11:28 +0300, Avi Kivity wrote:
> On 08/03/2011 05:04 AM, David Gibson wrote:
> > I still don't understand the distinction you're making. We're saying
> > the group is "owned" by a given user or guest in the sense that no-one
> > else may use anything in the group (including h
On Tue, 2011-08-09 at 20:01 +0300, Avi Kivity wrote:
> On 08/09/2011 07:51 PM, Alexander Graf wrote:
> >> Just put your own (or your employers'). If someone contributed to
> >> the code they can add their copyrights (or ask you do do it before
> >> inclusion).
> >>
> >> It would be good to get P
I guess my poor wording may have gotten me in trouble. I am getting
ready to repost this patch, but I want to ensure I am getting it as
right as possible.
I think I should reword the commit message to indicate we are removing
the Documentation/.../fsl-flexcan.txt file which has essentially become
On 08/09/2011 02:32 PM, Wolfgang Grandegger wrote:
> On 08/09/2011 08:17 PM, Scott Wood wrote:
>> On 08/09/2011 09:43 AM, Robin Holt wrote:
>>> In working with the socketcan developers, we have come to the conclusion
>>> the fsl-flexcan device tree bindings need to be cleaned up.
>>> The driver do
On 08/09/2011 02:49 PM, Wolfgang Grandegger wrote:
> Yes. The doc for the bindings we speak about
>
> http://lxr.linux.no/#linux+v3.0.1/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
>
> sneaked into the kernel without been presented on any mailing list and
> without the corresponding
On 08/09/2011 09:13 PM, Scott Wood wrote:
> On 08/09/2011 01:45 PM, Robin Holt wrote:
>> On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
>>> On 08/09/2011 09:43 AM, Robin Holt wrote:
In working with the socketcan developers, we have come to the conclusion
the fsl-flexcan devic
On 08/09/2011 08:17 PM, Scott Wood wrote:
> On 08/09/2011 09:43 AM, Robin Holt wrote:
>> In working with the socketcan developers, we have come to the conclusion
>> the fsl-flexcan device tree bindings need to be cleaned up.
>> The driver does not depend upon any properties other than the required
On 08/09/2011 01:45 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
>> On 08/09/2011 09:43 AM, Robin Holt wrote:
>>> In working with the socketcan developers, we have come to the conclusion
>>> the fsl-flexcan device tree bindings need to be cleaned up.
>>> The
On Tue, Aug 09, 2011 at 01:17:47PM -0500, Scott Wood wrote:
> On 08/09/2011 09:43 AM, Robin Holt wrote:
> > In working with the socketcan developers, we have come to the conclusion
> > the fsl-flexcan device tree bindings need to be cleaned up.
> > The driver does not depend upon any properties ot
On 08/09/2011 09:43 AM, Robin Holt wrote:
> In working with the socketcan developers, we have come to the conclusion
> the fsl-flexcan device tree bindings need to be cleaned up.
> The driver does not depend upon any properties other than the required
> properties
> so we are removing the file.
On 08/09/2011 12:46 AM, smitha.va...@wipro.com wrote:
> Thank Scott. I am working on a legacy project Which is using 2.6.21
> linux kernel so the device tree is based on that.
Your original e-mail said you were using 2.6.38 ("I have bringup WR
linux 2.6.38 on a custom mpc8247 board").
> Can you l
On 08/09/2011 07:51 PM, Alexander Graf wrote:
Just put your own (or your employers'). If someone contributed to
the code they can add their copyrights (or ask you do do it before
inclusion).
It would be good to get Paul's or Ben's so that the unimportant
characters between the whitespace get
On 08/09/2011 06:49 PM, Avi Kivity wrote:
On 08/09/2011 07:46 PM, Alexander Graf wrote:
On 08/09/2011 06:40 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in
kernel space,
most prominently the page table invali
On 08/09/2011 06:42 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (
On 08/09/2011 07:46 PM, Alexander Graf wrote:
On 08/09/2011 06:40 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in
kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patc
On 08/09/2011 06:40 PM, Avi Kivity wrote:
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in
kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR
On 08/09/2011 07:31 PM, Alexander Graf wrote:
In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (so almost nobody can use it).
Did you mea
On 08/09/2011 07:31 PM, Alexander Graf wrote:
When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.
We keep the old PVR based way around for backwards compatibility, but
once user space uses th
When running a PAPR guest, we need to handle a few hypercalls in kernel space,
most prominently the page table invalidation (to sync the shadows).
So this patch adds handling for a few PAPR hypercalls to PR mode KVM. I tried
to share the code with HV mode, but it ended up being a lot easier this w
Now that Book3S PV mode can also run PAPR guests, we can add a PAPR cap and
enable it for all Book3S targets. Enabling that CAP switches KVM into PAPR
mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/powerpc.c |5 +
include/linux/kvm.h|1 +
2 files changed, 6 insertio
PAPR defines hypercalls as SC1 instructions. Using these, the guest modifies
page tables and does other privileged operations that it wouldn't be allowed
to do in supervisor mode.
This patch adds support for PR KVM to trap these instructions and route them
through the same PAPR hypercall interface
Recent Linux versions use the CFAR and PURR SPRs, but don't really care about
their contents (yet). So for now, we can simply return 0 when the guest wants
to read them.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_emulate.c |4
1 files changed, 4 insertions(+), 0 deletions
We have 3 privilege levels: problem state, supervisor state and hypervisor
state. Each of them can access different SPRs, so we need to check on every
SPR if it's accessible in the respective mode.
Signed-off-by: Alexander Graf
---
arch/powerpc/kvm/book3s_emulate.c | 25 +++
In KVM for Book3S PPC we currently have 2 implementations. There
is the PR based implementation which works on any POWER system
you pass in and the super fast HV implementation which requires
libre firmware (so almost nobody can use it).
Currently, the two target two different machine types, with
When running a PAPR guest, the guest is not allowed to set SDR1 - instead
the HTAB information is held in internal hypervisor structures. But all of
our current code relies on SDR1 and walking the HTAB like on real hardware.
So in order to not be too intrusive, we simply set SDR1 to the HTAB we ho
When running a PAPR guest, some things change. The privilege level drops
from hypervisor to supervisor, SDR1 gets treated differently and we interpret
hypercalls. For bisectability sake, add the flag now, but only enable it when
all the support code is there.
Signed-off-by: Alexander Graf
---
ar
We need the compute_tlbie_rb in _pr and _hv implementations for papr
soon, so let's move it over to a common header file that both
implementations can leverage.
Signed-off-by: Alexander Graf
---
arch/powerpc/include/asm/kvm_book3s.h | 33 +
arch/powerpc/kvm/book
We have a few traps where we cache the instruction that cause the trap
for analysis later on. Since we now need to be able to distinguish
between SC 0 and SC 1 system calls and the only way to find out which
is which is by looking at the instruction, we also read out the instruction
causing the sys
On Aug 9, 2011, at 10:15 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2011-08-09 at 00:26 -0500, Kumar Gala wrote:
>
>>> + /* Some implementations leave us a hint for the CT */
>>> + ct = ICSWX_GET_CT_HINT(error_code);
>>> + if (ct < 0) {
>>> + /* we have to peek at the instructio
On Tue, 2011-08-09 at 00:26 -0500, Kumar Gala wrote:
> > + /* Some implementations leave us a hint for the CT */
> > + ct = ICSWX_GET_CT_HINT(error_code);
> > + if (ct < 0) {
> > + /* we have to peek at the instruction work to figure out CT */
> > + union cop_ccw ccw;
>
On 08/09/2011 04:55 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:45:58PM +, U Bhaskar-B22300 wrote:
>> Hi Robin,
>> Where are you doing the irq handling ie request_irq() for the powerpc
>> based P1010.
>> Or the existing code of ARM based FlexCAN will work for P1010 ??
>
> It
On 08/09/2011 04:55 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:45:58PM +, U Bhaskar-B22300 wrote:
>> Hi Robin,
>> Where are you doing the irq handling ie request_irq() for the powerpc
>> based P1010.
>> Or the existing code of ARM based FlexCAN will work for P1010 ??
>
> It
Hi Robin,
Where are you doing the irq handling ie request_irq() for the powerpc
based P1010.
Or the existing code of ARM based FlexCAN will work for P1010 ??
--Bhaskar
> -Original Message-
> From: Robin Holt [mailto:h...@sgi.com]
> Sent: Tuesday, August 09, 2011 5:58 PM
>
On Aug 9, 2011, at 12:26 AM, Kumar Gala wrote:
>
> On Aug 8, 2011, at 5:26 PM, Jimi Xenidis wrote:
>
>> This patch adds a fault handler that responds to illegal Coprocessor
>> types. Currently all CTs are treated and illegal. There are two ways
>> to report the fault back to the application.
On Tue, Aug 09, 2011 at 02:45:58PM +, U Bhaskar-B22300 wrote:
> Hi Robin,
> Where are you doing the irq handling ie request_irq() for the powerpc
> based P1010.
> Or the existing code of ARM based FlexCAN will work for P1010 ??
It appears that the of_device stuff got moved under t
In working with the socketcan developers, we have come to the conclusion
the fsl-flexcan device tree bindings need to be cleaned up. The driver
does not depend upon any properties other than the required properties
so we are removing the file. Additionally, the p1010*dts files are not
following t
I added a simple clock source for the p1010rdb so the flexcan driver
could determine a clock frequency. The p1010 can device only has an
oscillator of system bus frequency divided by 2.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde ,
Acked-by: Wolfgang Grandegger ,
To: U Bhaskar-B22300
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger
powerpc does not have a mach-/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
Acked-by: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kerne
Marc, Wolfgang or U Bhaskar,
This patch set should have all your comments included. It is based on
the David S. Miller net-next-2.6 tree commit 19fd617.
This series adds a fifth patch which cleans up and corrects the device
bindigs for the fsl-flexcan nodes.
I have compiled each patch in the se
On 08/09/2011 02:40 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 02:33:31PM +0200, Marc Kleine-Budde wrote:
>> On 08/09/2011 07:55 AM, Robin Holt wrote:
>>> I added a clock source for the p1010rdb so the flexcan driver
>>> could find its clock frequency.
>>>
>>> Signed-off-by: Robin Holt
>>> To
Hi Robin,
On 08/09/2011 02:28 PM, Robin Holt wrote:
> I added a simple clock source for the p1010rdb so the flexcan driver
> could determine a clock frequency. The p1010 can device only has an
> oscillator of system bus frequency divided by 2.
>
> Signed-off-by: Robin Holt
> To: Marc Kleine-Bud
On Monday, August 08, 2011 at 10:17 PM, Liu Gang wrote:
> Subject: [PATCH] rio: Use discovered bit to test if enumeration is
> complete
>
> The discovered bit in PGCCSR register indicates if the device has
> been discovered by system host. In Rapidio system, some agent devices
> can also be master
On Tue, Aug 09, 2011 at 02:33:31PM +0200, Marc Kleine-Budde wrote:
> On 08/09/2011 07:55 AM, Robin Holt wrote:
> > I added a clock source for the p1010rdb so the flexcan driver
> > could find its clock frequency.
> >
> > Signed-off-by: Robin Holt
> > To: Marc Kleine-Budde ,
> > To: Wolfgang Grand
On 08/09/2011 07:55 AM, Robin Holt wrote:
> I added a clock source for the p1010rdb so the flexcan driver
> could find its clock frequency.
>
> Signed-off-by: Robin Holt
> To: Marc Kleine-Budde ,
> To: Wolfgang Grandegger ,
> To: U Bhaskar-B22300
> Cc: socketcan-c...@lists.berlios.de,
> Cc: net.
Make flexcan driver handle register reads in the appropriate endianess.
This was a basic search and replace and then define some inlines.
Signed-off-by: Robin Holt
Acked-by: Marc Kleine-Budde
To: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kerne
I added a simple clock source for the p1010rdb so the flexcan driver
could determine a clock frequency. The p1010 can device only has an
oscillator of system bus frequency divided by 2.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde ,
To: Wolfgang Grandegger ,
To: U Bhaskar-B22300
Cc: socketca
powerpc does not have a mach-/clock.h. When testing, I found neither
arm nor powerpc needed the mach/clock.h at all so I removed it.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
To: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.berlios.de
Cc: net...@vger.kernel.org
On powerpc, the OpenFirmware devices are not matched without specifying
an of_match array. Introduce that array as that is used for matching
on the Freescale P1010 processor.
Signed-off-by: Robin Holt
To: Marc Kleine-Budde
To: Wolfgang Grandegger
To: U Bhaskar-B22300
Cc: socketcan-c...@lists.
Marc, Wolfgang or U Bhaskar,
This patch set should have all your comments included. It is based on
the David S. Miller net-next-2.6 tree commit 19fd617.
I have compiled each patch in the series individually for both arm and
powerpc (cheated on ppc and reordered them with the last patch first so
On Tue, Aug 09, 2011 at 09:11:33AM +0200, Wolfgang Grandegger wrote:
> On 08/09/2011 08:33 AM, Robin Holt wrote:
> > Argh. I sent an earlier (non-working) version of this patch. Here is
> > the correct one.
>
> Please always resend the complete series of patches with an incremented
> version num
On 08/09/2011 01:40 PM, Robin Holt wrote:
> On Tue, Aug 09, 2011 at 09:11:33AM +0200, Wolfgang Grandegger wrote:
>>> + return &p1010_rdb_system_clock;
>>
>> Just returning fsl_get_sys_freq() here would already be fine. I'm also
>> missing the factor of two here:
>>
>> return fsl_get_sys_f
On 08/05/2011 05:23 AM, Anton Blanchard wrote:
KVM_GUEST adds a 1 MB array to the kernel (kvm_tmp) which grew
my kernel enough to cause it to fail to boot.
Dynamically allocating or reducing the size of this array is a
good idea, but in the meantime I think it makes sense to make
KVM_GUEST defau
On Tue, Aug 09, 2011 at 09:11:33AM +0200, Wolfgang Grandegger wrote:
> > + return &p1010_rdb_system_clock;
>
> Just returning fsl_get_sys_freq() here would already be fine. I'm also
> missing the factor of two here:
>
> return fsl_get_sys_freq() / 2;
I am working on the other comm
Hi,
DTS bindings document for mpc8xxx GPIOs implies that to use GPIO as IRQ
one should specify GPIO controller node and GPIO number in device tree
node,
like this:
funkyfpga@0 {
compatible = "funky-fpga";
...
interrupts = <9 2>;
interrupt-parent = <&gpio2>;
On 08/09/2011 08:33 AM, Robin Holt wrote:
> Argh. I sent an earlier (non-working) version of this patch. Here is
> the correct one.
Please always resend the complete series of patches with an incremented
version number. Furthermore, this is not an RFC any more. A prefix
similar to [PATCH nfsl_ge
71 matches
Mail list logo
