On Wed, Aug 18, 2010 at 02:31:42PM -0500, Timur Tabi wrote:
> On Tue, Jun 8, 2010 at 2:55 PM, Anton Vorontsov wrote:
> > The mpc85xx_mds_setup_arch() function is incomprehensible
> > and unmaintainable. Factor out all QE specific stuff into
> > mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys(
On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > The timer/alarm stuff is "ancillary" and is not at all necessary. It
> > is just a "nice to have." I will happily remove it, if it is too
> > troubling for people.
>
> If th
From: Benjamin Herrenschmidt
Date: Thu, 19 Aug 2010 15:23:23 +1000
> Similar here, but using atomic_long_t instead so it works for 32-bit too
> for me. I suppose we could make that part common indeed.
>
> What about asm-generic/rwsem-atomic.h or rwsem-cmpxchg.h ?
Using rwsem-cmpxchg.h sounds b
On Tue, 2010-08-17 at 22:28 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Wed, 18 Aug 2010 15:03:23 +1000
>
> > I tried various tricks but so far they didn't work. I'll have another
> > look tomorrow, but I may end up having to keep all the crap typecasts.
>
> The casts are p
Currently, we can add a lot of reservations over a small range, this
does a simple check to verify the previous entry is not the same
as the current one and skips it if so
Signed-off-by: Matthew McClintock
---
kexec/arch/ppc/fixup_dtb.c | 28 +---
1 files changed, 17 in
We always remove the old entry, and add it back if it is needed
on for the kexec'ed kernel
Signed-off-by: Matthew McClintock
---
kexec/arch/ppc/fixup_dtb.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/kexec/arch/ppc/fixup_dtb.c b/kexec/arch/ppc/fi
This patch series fixes a few issues I have discovered with my previous
patch series. Nothing new has been added.
v2: Missed signoff, removed initializing variable twice
Matthew McClintock (3):
Ramdisk address was not copied correctly on kexec'ed kernel
Prevent multiple reservations for cpu-r
Signed-off-by: Matthew McClintock
---
kexec/arch/ppc/fixup_dtb.c |2 +-
kexec/arch/ppc/kexec-ppc.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kexec/arch/ppc/fixup_dtb.c b/kexec/arch/ppc/fixup_dtb.c
index 26c23a3..09f9ac1 100644
--- a/kexec/arch/ppc/fixup_dtb.c
On Wed, 2010-08-18 at 11:45 -0500, Dave Kleikamp wrote:
> Sorry! Forgot to change the subject.
>
> Shaggy
>
> On Wed, 2010-08-18 at 11:44 -0500, Dave Kleikamp wrote:
> > Josh,
> > Here are some bug fixes for the powerpc-4xx tree. It'd be nice if they
> > could make it into 2.6.46.
Yeah and I'm
Hi Wolfgang,
On Wed, 18 Aug 2010 22:56:46 +0200 Wolfgang Denk wrote:
>
> drivers/ata/sata_dwc_460ex.c: At top level:
> drivers/ata/sata_dwc_460ex.c:1592: warning: 'struct of_device' declared
> inside parameter list
> drivers/ata/sata_dwc_460ex.c:1592: warning: its scope is only this definition
On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote:
>>
> > So while to me, it think it would be more ideal (or maybe just less
> > different) to have a read-only interface (like the RTC), leaving PTPd to
> > manage offset calculat
Dear Rupjyoti,
drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
CC drivers/ata/sata_dwc_460ex.o
drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the locati
The dlpar code can cause a deadlock to occur when making the RTAS
configure-connector call. This occurs because we make kmalloc calls,
which can block, while parsing the rtas_data_buf and holding the
rtas_data_buf_lock. This an cause issues if someone else attempts
to grab the rtas_data_bug_lock.
On Tue, Jun 8, 2010 at 2:55 PM, Anton Vorontsov wrote:
> The mpc85xx_mds_setup_arch() function is incomprehensible
> and unmaintainable. Factor out all QE specific stuff into
> mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys().
>
> Also move QE stuff out of mpc85xx_mds_pic_init().
>
> The dif
pci_device_to_OF_node() can return null, and list_for_each_entry will
never enter the loop when dev is NULL, so it looks like this test is
a typo.
Reported-by: Julia Lawall
Signed-off-by: Grant Likely
---
arch/powerpc/kernel/pci_of_scan.c |2 +-
1 files changed, 1 insertions(+), 1 deletions
Sorry! Forgot to change the subject.
Shaggy
On Wed, 2010-08-18 at 11:44 -0500, Dave Kleikamp wrote:
> Josh,
> Here are some bug fixes for the powerpc-4xx tree. It'd be nice if they
> could make it into 2.6.46.
>
> Thanks,
> Shaggy
>
> Dave Kleikamp (4):
> powerpc/47x: Make sure mcsr is clea
There are two entries for .cpu_user_features in
arch/powerpc/kernel/cputable.c. Remove the one that doesn't belong
Signed-off-by: Dave Kleikamp
---
arch/powerpc/kernel/cputable.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/power
The interrupt stacks need to be indexed by the physical cpu since the
critical, debug and machine check handlers use the contents of SPRN_PIR to
index the critirq_ctx, dbgirq_ctx, and mcheckirq_ctx arrays.
Signed-off-by: Dave Kleikamp
---
arch/powerpc/kernel/irq.c | 15 ---
ar
Signed-off-by: Dave Kleikamp
---
arch/powerpc/mm/tlb_nohash_low.S |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index cfa7682..b9d9fed 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm
Josh,
Here are some bug fixes for the powerpc-4xx tree. It'd be nice if they
could make it into 2.6.46.
Thanks,
Shaggy
Dave Kleikamp (4):
powerpc/47x: Make sure mcsr is cleared before enabling machine check
interrupts
powerpc/47x: Remove redundant line from cputable.c
powerpc/4xx: Inde
Clear the machine check syndrom register before enabling machine check
interrupts. The initial state of the tlb can lead to parity errors being
flagged early after a cold boot.
Signed-off-by: Dave Kleikamp
---
arch/powerpc/kernel/head_44x.S |4
1 files changed, 4 insertions(+), 0 delet
On Wednesday 18 August 2010, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote:
> > On Tuesday 17 August 2010, Richard Cochran wrote:
> > > I've been looking at offering the PTP clock as a posix clock, and it
> > > is not as hard as I first thought. The PTP cloc
Hi,
Thanks for all your replies. Now I want to enable interrupts on some GPIO
pins(GPIO pins number 224, 225, 226, 227, 228 and 229 i.e gpiochip224's pins
0 to 5). I configured these pins as input(GPIOF_IN) during gpio request. I
am able to request gpio pins successfully.
#define GPIO_CHIP0_BASE
On Tue, Aug 17, 2010 at 01:36:29PM +0200, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Richard Cochran wrote:
> > I've been looking at offering the PTP clock as a posix clock, and it
> > is not as hard as I first thought. The PTP clock or clocks just have
> > to be registered as one of the pos
Hi,
My system is MPC870 based and I'm enabling the I2C driver and the
ds1339 RTC driver. When the kernel tries to probe the RTC chip (slave
address 0x68), the first write seems OK but the subsequent read times
out. I applied the I2C/SPI microcode patch, which doesn't seem
necessary though. Below i
On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote:
> Why would system time not be adjusted to the PTP time?
>
> This is my main concern, that we're presenting a fractured API to
> userland. Suddenly there isn't just system time, but ptp time as well,
> and possibly multiple different ptp
26 matches
Mail list logo