We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
> >
On Wed, Aug 01, 2007 at 03:04:22PM +1000, David Gibson wrote:
> On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> > >> +UIC0: interrupt-controller0 {
> > >> +compatible = "ibm,uic-440gp","ibm,uic";
> > >
> > > The first compatible entry should always be t
On Wed, 1 Aug 2007, Segher Boessenkool wrote:
> > > > + strncpy(info->driver_name, i2c_devices[i].i2c_driver,
> > > > KOBJ_NAME_LEN);
> > > > + strncpy(info->type, i2c_devices[i].i2c_type,
> > > > I2C_NAME_SIZE);
> > >
> > > Why not just strcpy(), btw?
> >
> > Becaus
Michael Neuling writes:
> + slb_shadow_update(mk_esid_data(VMALLOC_START, 1),
> + mk_vsid_data(VMALLOC_START, vflags), 1);
Could you re-jig slb_shadow_update to take ea, slot and vflags, and
call mk_[ev]sid_data itself, rather than exposing mk_esid_data a
>>> I just got asked about ipv6 support in yaboot and a quick
>>> investigation
>>> showed _no_ knowledge of the address formats in the code.
>>>
>>> Should I be submitting an RFC for a full parser that can pick that
>>> apart? Or does has someone have code lurking in the shadows, that
>>> just n
On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> >> + { /* 440EPX - without Security/Kasumi */
> >> + .pvr_mask = 0xffff,
> >> + .pvr_value = 0x28D4,
> >> + .cpu_name = "440EPX - no Security/Kasumi",
On Wed, Aug 01, 2007 at 06:57:33AM +0200, Segher Boessenkool wrote:
> >> + UIC0: interrupt-controller0 {
> >> + compatible = "ibm,uic-440gp","ibm,uic";
> >
> > The first compatible entry should always be the precise model, so in
> > this case "ibm,uic-440epx".
>
> This isn't really _requ
>> +{ /* 440EPX - without Security/Kasumi */
>> +.pvr_mask = 0xffff,
>> +.pvr_value = 0x28D4,
>> +.cpu_name = "440EPX - no Security/Kasumi",
>> +.cpu_features = CPU_FTRS_44X,
>> +
>> +UIC0: interrupt-controller0 {
>> +compatible = "ibm,uic-440gp","ibm,uic";
>
> The first compatible entry should always be the precise model, so in
> this case "ibm,uic-440epx".
This isn't really _required_, but it is a very good idea in
almost all cases (the exception is for ve
We sometimes change the vmalloc segment in slb_flush_and_rebolt but we
never updated with slb shadow buffer. This fixes it. Thanks to paulus
for finding this.
Also added some write barriers to ensure the shadow buffer is always
valid.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Paulu
On Wed, 01 Aug 2007 05:16:27 +0200 Gabriel C <[EMAIL PROTECTED]> wrote:
>
> arch/powerpc/platforms/iseries/it_lp_naca.h | 87
> +++--
NAK this part as it just makes a lot of the lines more than 80 characters
for no real gain on a platform that is moving on ...
--
Cheers,
Hi,
This patch fixes some interrrupt -> interrupt typos and the comments in
it_lp_naca.h
Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/embedded6xx/holly.c|2 +-
arch/powerpc/platforms/embedded6xx/linkstation.c |2 +-
arch/powerpc/platforms/
On Wed, 01 Aug 2007 11:03:12 +1000, Paul Mackerras wrote:
> Doug Maxey writes:
>
> > I just got asked about ipv6 support in yaboot and a quick investigation
> > showed _no_ knowledge of the address formats in the code.
> >
> > Should I be submitting an RFC for a full parser that can pick that
>
On Mon, Jul 30, 2007 at 07:16:28PM +0400, Valentine Barshak wrote:
> AMCC 440EPx Sequoia board support.
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> ---
> arch/powerpc/kernel/cputable.c | 36 +++
> arch/powerpc/kernel/head_44x.S |2 -
> arch/powerpc
On Tue, Jul 31, 2007 at 01:42:46PM +0200, Stefan Roese wrote:
> On Tuesday 31 July 2007, Valentine Barshak wrote:
> > > Is treeboot-* really needed on Sequoia? From my understanding this is
> > > only needed for platforms using OpenBIOS as bootloader.
> >
> > Right, it's not used for u-boot. I've i
On Mon, Jul 30, 2007 at 07:12:45PM +0400, Valentine Barshak wrote:
> This patch adds DCR defines needed for 440EP/440EPx clock initialization.
> These defines have been introduced in the Bamboo support by Josh Boyer
> and are needed for Sequoia as well.
These should really go in the same patch tha
On Mon, Jul 30, 2007 at 07:06:48PM +0400, Valentine Barshak wrote:
> AMCC Sequoia board DTS
>
> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/sequoia.dts | 292
> ++
> 1 files changed, 292 insertions(+)
>
> diff -ruN linu
Doug Maxey writes:
> I just got asked about ipv6 support in yaboot and a quick investigation
> showed _no_ knowledge of the address formats in the code.
>
> Should I be submitting an RFC for a full parser that can pick that
> apart? Or does has someone have code lurking in the shadows, that
>
Some new machines use the "ibm,dynamic-reconfiguration-memory" property
to provide memory layout information, rather than via memory nodes.
There is a bug in the code to parse this property for start addresses over
4GB, we throw away the high bits and add apparently duplicate regions. This
results
On Tue, Jul 31, 2007 at 11:11:57PM +0200, Segher Boessenkool wrote:
> > Ok, figured out why. When I push, then pop a quilt patch some of the
> > files end up with their original contents, but changed timestamps.
> > That altered stat information causes git-diff-index to give false
> > indications
Arnd Bergmann wrote:
> On Wednesday 01 August 2007, Dave Jiang wrote:
>> Doh! I sent out the reworked patches right before your comments. Do you
>> happen
>> to know where I can find an example of how to do this? In regards to making a
>> platform_device a child of the PCI host bridge that is
> The hardware is called (E)IDE, the protocol is called ATA.
> Or that's what I was told -- I think there's some historic
> revisionism involved, too.
ATA is the interface and standards for the ANSI standards based disk
attachment. IDE "Integrated Drive Electronics" is a marketing name used
to cov
>>> In that case, I would display the node full path.
>>
>> Those tend to be quite long, in the cases where there are
>> multiple interrupt controllers in the system; and really
>> useless otherwise. I think the interrupt controllers should
>> still just fill in the names "manually".
>
> They tend
On Wed, 2007-08-01 at 00:13 +0200, Segher Boessenkool wrote:
> >>> Which makes me think (again) that we should have an optional
> >>> device_node
> >>> pointer in irq_host. I know you said you wanted the irq stuff to be
> >>> OF
> >>> agnostic, but the reality is most of the implementations do hav
>>> + strncpy(info->driver_name, i2c_devices[i].i2c_driver,
>>> KOBJ_NAME_LEN);
>>> + strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
>>
>> Why not just strcpy(), btw?
>
> Because target strings are finite length, and sources are just
> pointers to
> some constant
>>I never suggested that -- what I did suggest was make of_serial.c
>> recognize certain chip types and register them with 8250 driver.
>
> What would be the advantage of maintaining a list of chips whose only
> difference is register spacing, rather than just using reg-shift and
> being done w
>>> + [EMAIL PROTECTED] {
>>> + compatible = "mmio-ide";
>>> + device_type = "ide";
>
>> Why not "ata"?
The hardware is called (E)IDE, the protocol is called ATA.
Or that's what I was told -- I think there's some historic
revisionism involved, too.
> Also, what mmio-
> This doesn't mean that shift is better anyway. If everyone
> considers it
> better, I give up. But be warned that shift (stride) is not the only
> property
> characterizing register accesses -- the regs might be only accessible
> as
> 16/32-bit quantities, for example (16-bit is a real wor
On Wednesday 01 August 2007, Dave Jiang wrote:
> Doh! I sent out the reworked patches right before your comments. Do you happen
> to know where I can find an example of how to do this? In regards to making a
> platform_device a child of the PCI host bridge that is Thanks!
>
When you use an op
Arnd Bergmann wrote:
> On Tuesday 31 July 2007, Dave Jiang wrote:
>> Actually it seems that for me to grab the interrupt number I have to do the
>> platform device creation in fsl_soc.c and call arch_init() instead of doing
>> it
>> from fsl_add_bridge(). fsl_add_bridge() is called way too early a
>>> Which makes me think (again) that we should have an optional
>>> device_node
>>> pointer in irq_host. I know you said you wanted the irq stuff to be
>>> OF
>>> agnostic, but the reality is most of the implementations do have an
>>> OF
>>> node. And all of the newer irq_host implementations do
> + spi1pio:[EMAIL PROTECTED] {
There should be whitespace after the label. @01 should be
spelled @1. Except there is no "reg" property. What is this
stuff, anyway?
> + pio-map = <
> + /* port pin dir open_drain assignment
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/macintosh/therm_adt746x.c | 17298 -> 17244 (-54 bytes)
drivers/macintosh/therm_adt746x.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
--- linux-2.6.23-rc1-mm1-a/drivers/macintosh/therm_adt746x.c2007-07-26
13:07:4
On Tuesday 31 July 2007, Dave Jiang wrote:
> Actually it seems that for me to grab the interrupt number I have to do the
> platform device creation in fsl_soc.c and call arch_init() instead of doing it
> from fsl_add_bridge(). fsl_add_bridge() is called way too early and the mpic
> interrupt mappin
Freescale MPC85xx SoC support for EDAC. Used on PPC platforms. Development
and testing done on PPC Freescale MPC8548CDS.
The driver provides error reporting for L2 cache error registers, the
memory controller error registers, and the PCI error registers. The error
reporting can be done two ways, v
>>> [EMAIL PROTECTED] {
>>> device_type = "spi";
>>> + device-id = <1>;
>>
>> Can we just use the reg value for bus_num in the kernel.
>
> Sure, technically nothing prevents this. But, QE specs names
> SPIs by these ids.
As a minimum the property n
Creating a platform device for the PCI error registers in order for the
mpc85xx EDAC driver to pick up proper resources. This is to prevent the EDAC
driver from monopolizing the of_device and thus preventing future PCI code from
using the PCI of_device(s).
Signed-off-by: Dave Jiang <[EMAIL PROTECT
Publish the devices listed in dts under SOC as of_device just like what
mpc85xx_mds platforms do. The 85xx cds and ads platforms currently do not
export the devices in dts as of_device.
I need the memory controller, L2 cache-controller, and the PCI controller
published as of_device so the mpc85xx
> Naming devices for human consumption is a more general problem than
> device-id addresses; I'd like to see a standard "label" property added
> to
> the device tree spec that software could use to present a
> human-friendly
> label that corresponds to markings on the case, position on the board,
> Unless the DTS guys thinks otherwise, just rename to "cpu_qe".
> "qe" would then be reserved for true QE mode.
If I understand it correctly, this is a property of how the
driver works, not how the hardware works / is connected; so
there should be _no_ such property in the device tree.
If I unde
On Tue, 2007-07-31 at 21:42 +0200, Segher Boessenkool wrote:
> > Which makes me think (again) that we should have an optional
> > device_node
> > pointer in irq_host. I know you said you wanted the irq stuff to be OF
> > agnostic, but the reality is most of the implementations do have an OF
> > no
> As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse
> controller
> on the PegasosPPC. This is because of a feature/bug in the OF device
> tree:
> the "device_type" attribute is an empty string instead of "8042" as the
> kernel expects. This patch (against 2.6.22.1) adds a seconda
> Ok, figured out why. When I push, then pop a quilt patch some of the
> files end up with their original contents, but changed timestamps.
> That altered stat information causes git-diff-index to give false
> indications of changed files, so setlocalversion adds the -dirty.
> Running git status,
> I'd like to make an official DTC Version 1.0.0 release soon!
> To that end, I've published a repo on jdl.com with a v1.0.0-rc1
> tag on it. I anticipate some updates to the Documentation before
> a final 1.0.0 release still. However, if you have something
> you would like to have be in The Real
On Tue, 31 Jul 2007 21:11:01 BST, Paul Nasrat wrote:
>On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:
>> Howdy!
>>
>> I just got asked about ipv6 support in yaboot and a quick investigation
>> showed _no_ knowledge of the address formats in the code.
>
>We really just use OF for obp-tftp and
Arnd Bergmann wrote:
> On Monday 30 July 2007, Dave Jiang wrote:
>> I don't believe that EDAC core has been loaded at the time of 85xx PCI
>> initialization. Plus, the EDAC driver can be loaded as a kernel module. So
>> that
>> probably won't work
>
> ok, good point.
>
>> Also, instead of ha
[POWERPC]: Fix num_cpus calculation in smp_call_function_map().
In smp_call_function_map(), num_cpus is set to the number of online CPUs minus
one. However, if the CPU mask does not include all CPUs (except the one we're
running on), the routine will hang in the first while() loop until the 8 seco
� wrote:
> Hi all,
>
> looking at the PS3 as one of the few PowerPC workstation options the RAM
> is obviously quite limitted with just 256MB.
Can I recommend in the future you send this kind of PS3 specific inquiry to
the cbe-oss-dev mailing list?
[EMAIL PROTECTED]
https://ozlabs.org/mail
On Tue, 2007-07-31 at 14:21 -0500, Doug Maxey wrote:
> Howdy!
>
> I just got asked about ipv6 support in yaboot and a quick investigation
> showed _no_ knowledge of the address formats in the code.
We really just use OF for obp-tftp and don't have our own ip stack, as
there is no 1275 standard fo
> Which makes me think (again) that we should have an optional
> device_node
> pointer in irq_host. I know you said you wanted the irq stuff to be OF
> agnostic, but the reality is most of the implementations do have an OF
> node. And all of the newer irq_host implementations do, with the
> except
Howdy!
I just got asked about ipv6 support in yaboot and a quick investigation
showed _no_ knowledge of the address formats in the code.
Should I be submitting an RFC for a full parser that can pick that
apart? Or does has someone have code lurking in the shadows, that
just needed some prompti
> The ppc64 version appends ',"a"' to the kprobes.text section line. Is
> this needed here as well? Could someone elaborate on exactly what its
> purpose is?
It's the (ELF) section attributes for the section. If this
is executable code, it should be "ax"; if it's writable, it
should be "wa"; if
> + l) RapidIO
"FSL PowerPC bridge RapidIO" or something like that -- you
aren't doing a _generic_ rapidio binding here.
> + RapidIO is a definition of a system interconnect. This node add
> + the support for RapidIO processor in kernel. The node name is
> + suggested to be 'rapidio'.
> +
>>> +- #address-cells : Address representation for
>> "rapidio" devices.
>>> + This field represents the number of cells needed to represent
>>> + the RapidIO address of the registers.
>>
>> Can you explain this a little further. I'm a bit confused by
>> 'RapidIO address of the regis
Jan-Bernd Themann wrote:
> On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
>> Second, you still need to set skb->ip_summed = CHECKSUM_UNNECESSARY
>> when modified packets are flushed, else the stack will see bad
>> checksums for packets from CHECKSUM_COMPLETE drivers using the
>> skb interfac
Stefan Roese wrote:
> On Tuesday 31 July 2007, Valentine Barshak wrote:
>>> Is treeboot-* really needed on Sequoia? From my understanding this is
>>> only needed for platforms using OpenBIOS as bootloader.
>> Right, it's not used for u-boot. I've included it just in case.
>
> I think we should dro
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Th
On Tuesday 31 July 2007, Valentine Barshak wrote:
> > Is treeboot-* really needed on Sequoia? From my understanding this is
> > only needed for platforms using OpenBIOS as bootloader.
>
> Right, it's not used for u-boot. I've included it just in case.
I think we should drop it, when it's not used
Stefan Roese wrote:
> On Monday 30 July 2007, Valentine Barshak wrote:
>> A bootwrapper code for Sequoia.
>>
>> Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/boot/44x.h |1
>> arch/powerpc/boot/Makefile |6
>> arch/powerpc/boot/cuboot-se
Hi,
Thanks for finding these bugs! I'll post an updated version soon (2 patches
with no separate Kconfig patches, one LRO and one eHEA patch). See comments
below.
Thanks,
Jan-Bernd
On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
> I was working on testing the myri10ge patch, and I ran into
WARNING: vmlinux.o(.text+0x605d4): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.prealloc' and '.ps3_power_save')
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/ps3/setup.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Ch
WARNING: vmlinux.o(.text+0x2a9c4): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.update_dn_pci_info' and
'.pci_dn_reconfig_notifier')
WARNING: vmlinux.o(.text+0x36430): Section mismatch: reference to
.init.text:.__alloc_bootmem (between '.mpic_msi_init_allocator' and
'.f
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:netdev-
> [EMAIL PROTECTED] On Behalf Of Andrew Gallatin
> Sent: Monday, July 30, 2007 10:43 AM
> To: Linas Vepstas
> Cc: Jan-Bernd Themann; netdev; Thomas Klein; Jeff Garzik; Jan-Bernd
> Themann; linux-kernel; linux-ppc; Christoph Ra
63 matches
Mail list logo
