[Forgot the cc]
Begin forwarded message:
Date: Wed, 25 Mar 2009 15:08:17 +1100
From: Stephen Rothwell
To: Rusty Russell
Cc: linux-n...@vger.kernel.org
Subject: linux-next: manual merge of the rr tree with the powerpc tree
Hi Rusty,
Today's linux-next merge of the rr tree got a conflict in
ar
Right, now turn it into a proper patch submission :-)
if (result < 0)
printk(KERN_WARNING "wdrtas: reading the thermal sensor "
- "faild: %li\n", result);
+ "faild: %i\n", result);
else
temperature = ((tem
Rusty's patch to change our sysfs access to various registers
to use smp_call_function_single() introduced a whole bunch of
warnings. This fixes them
Signed-off-by: Benjamin Herrenschmidt
---
I've also now fixed my build test tool to report warnings properly
so hopefully I won't miss that next t
On Mar 24, 2009, at 4:13 PM, Johns Daniel wrote:
On Tue, Mar 24, 2009 at 3:54 PM, Kumar Gala
wrote:
On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
Could somebody please explain the declaration of the PCIe interrupts
in the device tree?
I was under the impression that PCIe interrupts i
On Tue, 2009-03-24 at 16:59 +1100, Jeremy Kerr wrote:
> Michael,
>
> > Wouldn't this still be a problem on a UP kernel?
>
> I don't believe so - stores should be ordered with respect to the
> current CPU, and in the UP case we still get a barrier().
But what if the CPU decides to do the store t
David Miller wrote on 25/03/2009 00:29:13:
> From: Joakim Tjernlund
> Date: Wed, 25 Mar 2009 00:08:53 +0100
>
> > David Miller wrote on 24/03/2009 23:49:02:
> > >
> > > From: Joakim Tjernlund
> > > Date: Tue, 24 Mar 2009 23:45:13 +0100
> > >
> > > > I don't follow. Are these mandatory now? T
From: Joakim Tjernlund
Date: Wed, 25 Mar 2009 00:08:53 +0100
> David Miller wrote on 24/03/2009 23:49:02:
> >
> > From: Joakim Tjernlund
> > Date: Tue, 24 Mar 2009 23:45:13 +0100
> >
> > > I don't follow. Are these mandatory now? They were not in the old
> > > impl. either.
> >
> > See ether
David Miller wrote on 24/03/2009 23:49:02:
>
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 23:45:13 +0100
>
> > I don't follow. Are these mandatory now? They were not in the old
> > impl. either.
>
> See ether_setup() which is called indirectly via alloc_etherdev().
>
> Yawn...
Same here
On Wed, 25 Mar 2009 01:31:32 am Utz Bacher wrote:
> Adrian Reber wrote on 24.03.2009 13:31:31:
> > On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> > > The buffer passed to the ibm,get-system-parameter RTAS call must be
> > > in the RMA. To ensure we pass an address in the RMA use rt
On Tue, 24 Mar 2009 11:31:31 pm Adrian Reber wrote:
> On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> > The buffer passed to the ibm,get-system-parameter RTAS call must be
> > in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
> > for the actual RTAS call and then
From: Joakim Tjernlund
Date: Tue, 24 Mar 2009 23:45:13 +0100
> I don't follow. Are these mandatory now? They were not in the old
> impl. either.
See ether_setup() which is called indirectly via alloc_etherdev().
Yawn...
___
Linuxppc-dev mailing list
L
David Miller wrote on 24/03/2009 22:22:09:
>
> From: Joakim Tjernlund
> Date: Tue, 24 Mar 2009 11:37:11 +0100
>
> > David Miller wrote on 23/03/2009 19:49:28:
> > >
> > > From: Joakim Tjernlund
> > > Date: Mon, 23 Mar 2009 11:17:39 +0100
> > >
> > > > Sorry for the WS damaged patch, but my
On Tue, Mar 24, 2009 at 3:54 PM, Kumar Gala wrote:
>
> On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
>
> Could somebody please explain the declaration of the PCIe interrupts
>> in the device tree?
>>
>> I was under the impression that PCIe interrupts in the PowerPC Linux
>> kernel default to u
Adrian Reber wrote on 24.03.2009 13:31:31:
> On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> > The buffer passed to the ibm,get-system-parameter RTAS call must be
> > in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
> > for the actual RTAS call and then copy the
From: Joakim Tjernlund
Date: Tue, 24 Mar 2009 11:37:11 +0100
> David Miller wrote on 23/03/2009 19:49:28:
> >
> > From: Joakim Tjernlund
> > Date: Mon, 23 Mar 2009 11:17:39 +0100
> >
> > > Sorry for the WS damaged patch, but my current company mailer cannot
> > > handle inline patches. Due to
On Tue, 2009-03-24 at 12:45 +0100, Adrian Reber wrote:
> On Tue, Mar 24, 2009 at 03:27:18PM +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2009-03-16 at 13:35 +0100, Adrian Reber wrote:
> > > Using the RTAS watchdog driver to read out the temperature crashes
> > > on a PXCAB:
> > >
> > > Unable
On Mar 24, 2009, at 3:24 PM, Johns Daniel wrote:
Could somebody please explain the declaration of the PCIe interrupts
in the device tree?
I was under the impression that PCIe interrupts in the PowerPC Linux
kernel default to using INTx signaling (vs. external IRQ pin assertion
and MSI signalin
Could somebody please explain the declaration of the PCIe interrupts
in the device tree?
I was under the impression that PCIe interrupts in the PowerPC Linux
kernel default to using INTx signaling (vs. external IRQ pin assertion
and MSI signaling). Am I right?
If so, then do the interrupt-map lin
From: Anton Vorontsov
Date: Tue, 24 Mar 2009 18:37:34 +0300
> This patch fixes following build error:
>
> CC ucc_geth.o
> ucc_geth.c: In function 'ucc_geth_probe':
> ucc_geth.c:3644: error: implicit declaration of function 'uec_mdio_bus_name'
> make[2]: *** [ucc_geth.o] Error 1
>
> Signe
Scott Wood wrote:
> On Thu, Mar 19, 2009 at 04:16:07PM +0100, Wolfgang Grandegger wrote:
>> +Optional properties:
>> +- fsl,upm-mar-offset : use the UPM machine address register to drive a
>> + custom chip select logic using the specified
>> + offset.
>
> Your e
From: Grant Likely
This is a driver for the LocalPlus bus FIFO device
Signed-off-by: Grant Likely
---
arch/powerpc/include/asm/mpc52xx.h| 11 +
arch/powerpc/platforms/52xx/Kconfig |4
arch/powerpc/platforms/52xx/Makefile |1
arch/powerpc/platforms/52
From: Grant Likely
This patch adds an interface for controlling the timer function of the
MPC5200 GPT devices.
Signed-off-by: Grant Likely
---
arch/powerpc/include/asm/mpc52xx.h|7 ++
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 133 +++--
2 files changed,
These aren't actually done yet, but I've received some interest in them,
so I'm posting the current state.
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/lis
On Mar 24, 2009, at 11:00 AM, Scott Wood wrote:
On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
The gianfar node @ 25000 was missing its ranges prop for the mdio bus
and provided an explicit ranges property on gian...@24000 to match
all other .dts
Signed-off-by: Kumar Gala
---
ar
On Tue, Mar 24, 2009 at 9:39 AM, Stefan Roese wrote:
> On Tuesday 24 March 2009, Grant Likely wrote:
>> >> Sounds to me like a physmap_of driver bug. I don't think there is any
>> >> advantage in changing the partition syntax since concatenated flash
>> >> will always be used as a single device.
On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
> The gianfar node @ 25000 was missing its ranges prop for the mdio bus
> and provided an explicit ranges property on gian...@24000 to match
> all other .dts
>
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts |
On Tue, Mar 24, 2009 at 09:49:59AM +0100, Simon Kagstrom wrote:
> My problem is that I can't figure out how to express this correctly in
> the device tree for the board. My device tree looks like this ("isf" is
> the name of the FPGA):
>
> i...@c002 {
> #address-cells = <1>
On Tuesday 24 March 2009, Grant Likely wrote:
> >> Sounds to me like a physmap_of driver bug. I don't think there is any
> >> advantage in changing the partition syntax since concatenated flash
> >> will always be used as a single device. It doesn't make any sense to
> >> try and span partitions
This patch fixes following build error:
CC ucc_geth.o
ucc_geth.c: In function 'ucc_geth_probe':
ucc_geth.c:3644: error: implicit declaration of function 'uec_mdio_bus_name'
make[2]: *** [ucc_geth.o] Error 1
Signed-off-by: Anton Vorontsov
---
On Tue, Mar 24, 2009 at 08:15:13AM -0500, Kuma
On Tue, Mar 24, 2009 at 3:07 AM, Stefan Roese wrote:
> On Monday 23 March 2009, Grant Likely wrote:
>> On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese wrote:
>> > I just noticed that physmap_of can't handle multiple devices of different
>> > type described in one device node. For example the Intel
On Mar 24, 2009, at 9:20 AM, Anton Vorontsov wrote:
On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
The gianfar node @ 25000 was missing its ranges prop for the mdio bus
and provided an explicit ranges property on gian...@24000 to match
all other .dts
Signed-off-by: Kumar Gala
--
The gian...@25000 node was missing its ranges prop for the mdio bus
and provided an explicit ranges property on gian...@24000 to match
change from commit:
commit 70b3adbba056f5d9081f1ec9b4a629e3c7502072
Author: Anton Vorontsov
Date: Thu Mar 19 21:01:45 2009 +0300
powerpc/83xx: Move gianfar
On Tue, Mar 24, 2009 at 08:35:45AM -0500, Kumar Gala wrote:
> The gianfar node @ 25000 was missing its ranges prop for the mdio bus
> and provided an explicit ranges property on gian...@24000 to match
> all other .dts
>
> Signed-off-by: Kumar Gala
> ---
I think this part is missing:
diff --git
On Tue, 2009-03-24 at 14:27 +0100, Benjamin Krill wrote:
> >>On Fri, 2009-01-23 at 17:18 +0100, Benjamin Krill wrote:
> >>> SLOF has a further node which could not be evaluate
> >>> by the current routine. The current routine returns
> >>> because the node hasn't the required reg property. As
> >>>
The gianfar node @ 25000 was missing its ranges prop for the mdio bus
and provided an explicit ranges property on gian...@24000 to match
all other .dts
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/mpc8313erdb.dts |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/a
On Mar 19, 2009, at 1:01 PM, Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = <> properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so
On Mar 19, 2009, at 1:01 PM, Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = <> properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so
On Mar 19, 2009, at 1:01 PM, Anton Vorontsov wrote:
Currently it doesn't matter where the mdio nodes are placed, but with
power management support (i.e. when sleep = <> properties will take
effect), mdio nodes placement will become important: mdio controller
is a part of the ethernet block, so
On Mar 19, 2009, at 1:01 PM, Anton Vorontsov wrote:
This patch adds pmc nodes to the device tree files so that the boards
will able to use standby capability of MPC837x processors. The MPC837x
PMC controllers are compatible with MPC8349 ones (i.e. no deep sleep).
sleep = <> properties are used
>>On Fri, 2009-01-23 at 17:18 +0100, Benjamin Krill wrote:
>>> SLOF has a further node which could not be evaluate
>>> by the current routine. The current routine returns
>>> because the node hasn't the required reg property. As
>>> fix this patch adds a check to determine the partition
>>> child n
Anton, Andy
Can you take a look at the recent net-next tree and make sure that the
merge between the fsl_pq_mdio.c support and the patch that went into
2.6.29 to fix fixed-link support in ucc_geth.c is correct and still
works.
See commits:
Merge branch master... (8be7cdccacfbfc707
On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
> The buffer passed to the ibm,get-system-parameter RTAS call must be
> in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
> for the actual RTAS call and then copy the result to value. We can't
> just make it static bec
On Tue, Mar 24, 2009 at 03:27:18PM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2009-03-16 at 13:35 +0100, Adrian Reber wrote:
> > Using the RTAS watchdog driver to read out the temperature crashes
> > on a PXCAB:
> >
> > Unable to handle kernel paging request for data at address 0xfe347b50
> >
Arnd Bergmann wrote:
> On Wednesday 18 March 2009, mon...@monstr.eu wrote:
>> From: Michal Simek
>>
>>
>> Signed-off-by: Michal Simek
>> ---
>> arch/microblaze/include/asm/of_device.h | 45 ++
>> arch/microblaze/include/asm/of_platform.h | 64 ++
>> arch/microblaze/include/asm/prom.h
David Miller wrote on 23/03/2009 19:49:28:
>
> From: Joakim Tjernlund
> Date: Mon, 23 Mar 2009 11:17:39 +0100
>
> > Sorry for the WS damaged patch, but my current company mailer cannot
> > handle inline patches. Due to this we are setting up a new mail system
> > but it will be a few days befor
Hi!
I'm working on a custom Freescale 8544-based board and having some
trouble with getting the device tree right. In particular, we have a
setup which looks like this:
* We have an FPGA which contains a few serial ports, an interrupt
controller and some other devices
* The serial ports are "n
On Monday 23 March 2009, Grant Likely wrote:
> On Mon, Mar 23, 2009 at 4:51 AM, Stefan Roese wrote:
> > I just noticed that physmap_of can't handle multiple devices of different
> > type described in one device node. For example the Intel P30 48F4400
> > (64MByte) consists internally of 2 non-iden
47 matches
Mail list logo
