Hi all,
I was wondering, since arch/powerpc is now based on device trees,
shouldn't the cpm_uart driver (or at least a branch of it for
arch/powerpc) be changed to use of_platform_bus_type instead of
platform_bus_type? In my opinion, cpm_uart driver should take all its
configuration (uart
On Mon, Jul 16, Will Schmidt wrote:
> On Fri, 2007-07-13 at 19:05 +0200, Olaf Hering wrote:
> > 2.6.21 arch/powerpc/configs/iseries_defconfig works on an i825 with v5r4
> > 2.6.22 arch/powerpc/configs/iseries_defconfig does not. But it works on
> > a i820 with v5r3.
> > 2.6.22 boots ok with CONFIG
Segher Boessenkool writes:
> The device tree describes _all_ hardware in the system,
> not just the things that are somewhat harder to probe
> for.
Actually, for embedded systems, the device tree is really only
required to describe the things that it's useful for the Linux kernel
to know.
The po
Hm, it seems that, after all, cpm_uart works fine without any board
specific code whatsoever. Sorry about the fuss. My mistake
Regards
Alex
On Tue, 17 Jul 2007 14:55:30 +0300, Alexandros Kostopoulos
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I was wondering, since arch/powerpc is now based o
Hi Vitaly,
I believe that your patch is addresses by my patch in 2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
ehci_fsl-update-for-mpc831x-support.patch
- Leo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf
Hi Vitaly,
The max_ep_nr will be read from DCCPARAMS register with my patch in
2.6.23 queue:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
fsl_usb2_udc-get-max-ep-number-from-dccparams-register.patch
- Leo
> -Original Message-
> From: [EMAIL PROTECTED]
> [mail
On Tuesday 17 July 2007, Mark Zhan wrote:
> On Tue, 2007-07-17 at 03:02 +0200, Arnd Bergmann wrote:
> > On Monday 16 July 2007, Mark Zhan wrote:
> > > - cpm_uart_data.uart_clk = ppc_proc_freq;
> > > + if (strstr(model, "SMC")) {
> > > + cpm_uart_dev
> This utilises pretend phy, making access to it via device tree.
> GiGE switch
> is connected to TSEC1 with fixed gigE link, so we need to emulate it
> via artificial PHY to make it work.
Even if "pretend phy" in the device tree would be a good
idea (and it's not)...
> #s
On Tuesday 17 July 2007, Mark Zhan wrote:
> Hi Arnd,
>
> > > +/*
> > > + * For SBCPQ2 board, the interrupt of M48T59 RTC chip
> > > + * will generate a machine check exception. We use a
> > > + * fake irq to give the platform machine_check_exception() hook
> > > + * a chance to call the driver IS
This patch replaces the pmu sleep notifier that adb had with
suspend/resume hooks in a new platform driver/device.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/macintosh/adb.c | 96
This patch kills the obsolete awacs dmasound because it is in
the way of doing power management improvements since it uses
ancient API.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Cc: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch contains only
This patch kills off the remnants of the ancient sleep notifiers.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
drivers/macintosh/via-pmu.c | 71
include/linux/pmu.h | 36 --
On Tue, Jul 17, 2007 at 03:28:31PM +0200, Johannes Berg wrote:
> This patch kills the obsolete awacs dmasound because it is in
> the way of doing power management improvements since it uses
> ancient API.
>
> Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
> Cc: Benjamin Herrenschmidt <[EMAIL PRO
> > The rtc M48T59 driver is not specific to my board, it is probably used
> > by other board. So I can't register the rtc intr handler as the mcheck
> > exception handler. And in the other side, there are also other machine
> > check sources, right?
> >
> > So here I add a platform mcheck hook fo
On Tue, 2007-07-17 at 15:37 +0200, Adrian Bunk wrote:
> > sound/oss/dmasound/Kconfig | 14
>
> That's not in your patch, most likely because it's already removed as
> scheduled.
Ah, good point, I just removed it manually from the patch knowing that
it was gone from the config.
> T
On Tue, 2007-07-17 at 14:06 +0200, Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
> > On Tue, 2007-07-17 at 03:02 +0200, Arnd Bergmann wrote:
> > > On Monday 16 July 2007, Mark Zhan wrote:
> > > > - cpm_uart_data.uart_clk = ppc_proc_freq;
> > > > + if (
On Tuesday 17 July 2007, Mark Zhan wrote:
> Yes, basically I agree what you say. That should be the right way.
>
> but, the current situation is that: in all DTS files that are using smc
> or scc as uart device, all device node definitions have the same
> "compatible" property -- "cpm_uart"
>
>
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> Since the rtc m48t59 driver has already gone into the -mm source tree,
> and I think, it is an ugly way to make the irq handler a global
> function:-)
>
> If the driver is not built-in, and I still get the mach check exception,
> it will turn out that
> + #address-cells = <0>;
> + #size-cells = <0>;
No need for these.
>>>
>>> Isn't a good practice to put #address-cells in interrupt controller
>>> nodes?
>>
>> It is not.
>
> Well, that's debatable... but yes, a strict reading of the spec would
> say that you shou
Based on the Kurobox DTS files.
Signed-off-by: Oyvind Repvik <[EMAIL PROTECTED]>
Signed-off-by: Jon Loeliger <[EMAIL PROTECTED]>
---
Comments welcome, of course.
arch/powerpc/boot/dts/storcenter.dts | 142 ++
1 files changed, 142 insertions(+), 0 deletions(-)
> Right. See, there are people like me that don't know what the
> default values
> are/should be. Having them explicitly listed, even if it's
> redundant, serves
> as a good learning aid.
_Only_ if it's redundant. Not if it has a meaning different
from having the property not there at all.
On Tue, 2007-07-17 at 15:06 +0200, Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
> > Yes, basically I agree what you say. That should be the right way.
> >
> > but, the current situation is that: in all DTS files that are using smc
> > or scc as uart device, all device node def
On Tue, 17 Jul 2007 20:18:35 +0800
"Li Yang-r58472" <[EMAIL PROTECTED]> wrote:
> Hi Vitaly,
>
> I believe that your patch is addresses by my patch in 2.6.23 queue:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.22/usb-
> ehci_fsl-update-for-mpc831x-support.patch
>
okay, nm th
> Comments welcome, of course.
Well you asked for it :-)
> +/ {
> + model = "StorCenter";
If you can find a real model number, put it in here,
instead.
> + compatible = "storcenter";
Needs a manufacturer name in there.
> + PowerPC,603e { /* Really 8241 */
+ if (strstr(model, "SMC")) {
+ cpm_uart_dev =
platform_device_register_simple("fsl-cpm-smc:uart",
+ i, &r
[0], 3);
+ } else if (strstr(model, "SCC")) {
>>> You
On Tuesday 17 July 2007, Mark Zhan wrote:
>
> > Well, AFAICS, all of them currently use scc. The 8xx platforms don't
> > even build correctly in the mainline kernel, so I guess it would
> > be good to change them to also list fsl,cpm-smc in the compatible
> > property.
>
> That probably could be
> but, the current situation is that: in all DTS files that are using
> smc
> or scc as uart device, all device node definitions have the same
> "compatible" property -- "cpm_uart"
>
> So what I do here is just following the upstream source tree.
True enough. OTOH, it doesn't help to continue s
On Tuesday 17 July 2007, Segher Boessenkool wrote:
> > If the compatible property contains "fsl,cpm-smc\0cpm_uart", you
> > can scan for
> > either of them. The loop will iterate over all cpm_uart compatible
> > devices,
> > while the later test will look for an fsl,cpm-smc compatible device.
>
This patchset enables TCP checksum offload support for IPV4
on ibmveth. This completely eliminates the generation and checking of
the checksum for packets that are completely virtual and never
touch a physical network. A simple TCP_STREAM netperf run on
a virtual network with maximum mtu set yield
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 120 +++-
linux-2.6-bjking1/drivers/net/ibmveth
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers
Yeah. Giving the warning is a good thing though.
>>>
>>> No, it isn't; it's just noise, if we're not ever going to do
>>> anything
>>> to prevent the behaviour - and we can't.
>>
>> The same userland code will not run correctly on PPC64 or BookE
>> systems. Is that not a reason to warn?
>
Add ethtool hooks to ibmveth to retrieve driver statistics.
Signed-off-by: Brian King <[EMAIL PROTECTED]>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 53 +++-
1 file changed, 52 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_driver_
> From: Roy Zang <[EMAIL PROTECTED]>
>
> Change the pci express controller node name from pci
> to pcie in device tree.
>
> Signed-off-by: Roy Zang <[EMAIL PROTECTED]>
Looks good, thanks!
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
ht
On Jul 17, 2007, at 9:52 AM, Vitaly Bordug wrote:
> On Tue, 17 Jul 2007 20:18:35 +0800
> "Li Yang-r58472" <[EMAIL PROTECTED]> wrote:
>
>> Hi Vitaly,
>>
>> I believe that your patch is addresses by my patch in 2.6.23 queue:
>> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/
>> 2.6/2.6.2
>> The device tree describes _all_ hardware in the system,
>> not just the things that are somewhat harder to probe
>> for.
>
> Actually, for embedded systems, the device tree is really only
> required to describe the things that it's useful for the Linux kernel
> to know.
Sure, for example it cou
Arnd Bergmann wrote:
> On Tuesday 17 July 2007, Mark Zhan wrote:
>
>>>Well, AFAICS, all of them currently use scc. The 8xx platforms don't
>>>even build correctly in the mainline kernel, so I guess it would
>>>be good to change them to also list fsl,cpm-smc in the compatible
>>>property.
>>
>>That
Per conversations with BenH, iommu virtual merging should no longer
be considered to be an "experimental" feature. In particular,
CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/Kconfig | 11 ++-
On Tue, Jul 17, 2007 at 02:59:46AM +0200, Arnd Bergmann wrote:
> This is a step in the wrong direction. CPUINFO_{VENDOR,MACHINE}
> comes from a platform specific header file, so you can not
> use these definitions in platform independent code without
> breaking multiplatform kernels.
My patchset j
On Tue, 2007-07-17 at 16:57 +0200, Segher Boessenkool wrote:
>
> > + [EMAIL PROTECTED] {
> > + device_type = "rom";
>
> I'm sure you know I find this "rom" binding to be crap.
> However, I didn't yet write up the "cfi" binding, so I
> can't complain ;-)
Not all chips are CFI complian
On Jul 17, 2007, at 10:18 AM, Segher Boessenkool wrote:
> Yeah. Giving the warning is a good thing though.
No, it isn't; it's just noise, if we're not ever going to do
anything
to prevent the behaviour - and we can't.
>>>
>>> The same userland code will not run correctly
> + np = of_find_compatible_node(NULL, "cpm-pic", "CPM2");
> + if (np == NULL) {
> + printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
> + return;
> + }
This looks like your device tree is wrong. Shouldn't the interrupt
controller have devi
On Tue, Jul 17, 2007 at 04:49:13AM +0400, Vitaly Bordug wrote:
> + np = of_find_node_by_type(NULL, "cpu");
> + if (np != 0) {
> + const unsigned int *fp =
> + get_property(np, "clock-frequency", NULL);
> + if (fp != 0)
> + loop
>>> Way back when, I distinctly recall aborting my plans to implement
>>> per-page exec on 40x, precisely because of executables like this.
>>
>> I noticed some comments to that effect in the BookE code,
>> yes. It seems userland has been fixed enough that you
>> could think about enabling it agai
>>> + [EMAIL PROTECTED] {
>>> + device_type = "rom";
>>
>> I'm sure you know I find this "rom" binding to be crap.
>> However, I didn't yet write up the "cfi" binding, so I
>> can't complain ;-)
>
> Not all chips are CFI compliant.
I know :-)
> Be sure to write up the "jedec"
It's in
Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Olaf Hering wrote:
>> This driver (or the generic PS3 code) has appearently problems with
>> O_DIRECT.
>> glibc aborts parted because the malloc metadata get corrupted. While it
>> is reproducible, the place where it crashes changes with every versi
This just comments on code style, not semantics... I agree with Segher
that this isn't the way to do it.
On Tue, Jul 17, 2007 at 04:49:37AM +0400, Vitaly Bordug wrote:
> +#if defined(CONFIG_FIXED_MII_1000_FDX)
> +
> +static int fixed_set_link (void)
> +{
> + struct fixed_info *phyinfo = fixed
On Tue, Jul 17, 2007 at 04:58:32AM +0400, Vitaly Bordug wrote:
> diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
> b/arch/powerpc/boot/dts/mpc8313erdb.dts
> index 1b351dc..c330e79 100644
> --- a/arch/powerpc/boot/dts/mpc8313erdb.dts
> +++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
> @@ -90,6 +90,7
On Tue, Jul 17, 2007 at 02:55:30PM +0300, Alexandros Kostopoulos wrote:
> I was wondering, since arch/powerpc is now based on device trees,
> shouldn't the cpm_uart driver (or at least a branch of it for
> arch/powerpc) be changed to use of_platform_bus_type instead of
> platform_bus_type?
Y
On Tue, 17 Jul 2007 11:36:45 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 17, 2007 at 04:49:13AM +0400, Vitaly Bordug wrote:
> > + np = of_find_node_by_type(NULL, "cpu");
> > + if (np != 0) {
> > + const unsigned int *fp =
> > + get_property(np, "clock-
On Tue, 17 Jul 2007 11:43:31 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> This just comments on code style, not semantics... I agree with Segher
> that this isn't the way to do it.
That's nm, I'll rather include specific field into mac node,
so the function below will be rewritten.
--
Sincere
> Here's some anecdotal evidence :)
> http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
Right, but then we went on to say that we probably want to use
multiple vectors to separate out multiple HCA ports rather than
send/sreceive on the same port. And the current IPoIB implemen
Vitaly Bordug wrote:
> On Tue, 17 Jul 2007 11:36:45 -0500
> Scott Wood <[EMAIL PROTECTED]> wrote:
>>We should be removing this from board files that have it, not adding it
>>to ones that don't.
>
> Yet many boards still have this stuff (like pretty recent 86xx) - should
> we at least add some comm
On Tue, 2007-07-17 at 12:48, Vitaly Bordug wrote:
> 't.
> >
> Yet many boards still have this stuff (like pretty recent 86xx) - should
> we at least add some comments or clean that up?
Hrm. Alright. I'm on deck for a patch here, I see... :-)
But you might notice that the most recent board port
For those interested, here's my current 4xx patch series. There are a few
cleanups as a pre-requisite for 40x support, some minimal Walnut support, and
another round of Bamboo patches. These are all based off of Paul's current
tree.
Patches 1 through 7 are likely ready to be merged if there are
Add MMU definitions for 40x platforms. Also fixes two warnings in 40x_mmu.c.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/mm/40x_mmu.c |4 +-
include/asm-powerpc/mmu-40x.h | 65 ++
include/asm-powerpc/mmu.h |3 +
3 file
At present, various parts of the serial code use unsigned long to
define resource addresses. This is a problem, because some 32-bit
platforms have physical addresses larger than 32-bits, and have mmio
serial uarts located above the 4GB point.
This patch changes the type of mapbase in both struct
Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
behavior is identical, this also changes the set_dec function to reload the PIT
on 40x to match the behavior 44x currently has.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c |2 +-
Board support for the PPC405 Walnut evaluation board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig | 14 +++
arch/powerpc/platforms/40x/Makefile |2 -
arch/powerpc/platforms/40x/walnut.c | 68
arch/powerpc/p
Remove some leftover cruft in the 40x Kconfig file. Also make sure we
select WANT_DEVICE_TREE for 40x.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig | 77 -
arch/powerpc/platforms/Kconfig.cputype |1
2 files chang
AMCC Bamboo board DTS
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/bamboo.dts | 248 +++
1 file changed, 248 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
@@ -0,0 +1,248 @@
+/*
+ * Device Tree Source fo
Remove inclusion of __res on 40x. We don't need it in arch/powerpc
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_40x.S |1 -
arch/powerpc/kernel/ppc_ksyms.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/kernel/ppc_k
Device tree source file for the PPC405 Walnut evaluation board.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/walnut.dts | 153 +++
1 file changed, 153 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/walnut.dts
@@ -0
Add support for the AMCC Bamboo board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/configs/bamboo_defconfig | 906 ++
arch/powerpc/platforms/44x/Kconfig| 15
arch/powerpc/platforms/44x/Makefile |1
arch/powerpc/platforms/44x/bamboo
Rename the 44x.c wrapper file to 4xx.c and make the fixup_memsize function
common for all of 4xx. Also adds a common function to reset ethernet and a
40x reset function.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.c| 85 --
arch/
Add zImage wrapper for walnut board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/Makefile |3 -
arch/powerpc/boot/treeboot-walnut.c | 92
2 files changed, 94 insertions(+), 1 deletion(-)
--- linux-2.6.orig/arch/powerpc/b
Walnut board defconfig
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/configs/walnut_defconfig | 776 ++
1 file changed, 776 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/configs/walnut_defconfig
@@ -0,0 +1,776 @@
+#
+# Automatically gen
Add a bootwrapper for Bamboo
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |1
arch/powerpc/boot/Makefile |5 -
arch/powerpc/boot/bamboo.c | 126
arch/powerpc/boot/dcr.h | 11 ++
On Tue, 17 Jul 2007, Vitaly Bordug wrote:
> > Please don't do this; drivers/i2c/chips/ds1337.c is deprecated. You
> > should be using the RTC-class driver in drivers/rtc/rtc-ds1307.c, which
> > has a non-device-specific API that can be used.
> >
> > The ppc_md RTC functions should really just go
From: Domen Puncer <[EMAIL PROTECTED]>
Low-power mode implementation for Lite5200b.
Some I/O registers are also saved here.
A recent U-Boot that supports this (lite5200b_PM_config) is needed.
Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Signed-off-by: Sylvain Munaut <[EMAIL PROTECTED]>
---
Hi
On Mon, 2007-07-09 at 16:48, Scott Wood wrote:
> In older versions of glibc (through 2.3), the dynamic linker executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; t
On Tue, 2007-07-17 at 11:09 -0500, Linas Vepstas wrote:
> Per conversations with BenH, iommu virtual merging should no longer
> be considered to be an "experimental" feature. In particular,
> CONFIG_VMERGE has been set to "y" in te defconfigs for quite a while.
>
> Signed-off-by: Linas Vepstas <[
hello,
Upon investigating the below issue further, I found that
pte_alloc_map() calls kmap_atomic. The allocated pte page must be
unmapped before invoking any function that might_sleep.
In this case clear_huge_page() is being called without invoking
pte_unmap(). The 'normal' counterpart of hugetl
> Yes, I shouldn't say "defaulted" -- a unit interrupt specifier
> simply has no unit address part, in an interrupt domain that
> doesn't correspond to a "normal" bus. But saying it like this
> is a little bit inexact, and it uses more words.
>
> > which is why I tend to prefer having it
> > exp
> Quoting Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH 01/10] IB/ehca: Support for multiple event queues
>
> > Here's some anecdotal evidence :)
> > http://lists.openfabrics.org/pipermail/general/2007-May/035758.html
>
> Right, but then we went on to say that we probably want to use
Robert P. J. Day writes:
> -config CONFIG_CHECK_CACHE_COHERENCY
> +config CHECK_CACHE_COHERENCY
Please also fix the occurrence in
arch/powerpc/platforms/embedded6xx/Kconfig.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org
Jon Loeliger wrote:
> But luckily, this gave me the opportunity to then realize that
> we should give a great big...
>
> Amen-brother-by: Jon Loeliger <[EMAIL PROTECTED]>
>
> to this patch from Scott.
>
> So, an official plea to Paul to apply this to his tree.
Segher has a newer patch that supe
On Wed, 4 Jul 2007, Segher Boessenkool wrote:
> Your device is an rs5c372b. So, that's what you put in
> your device tree. Simple so far, right?
>
> Now some OF I2C code goes looking for IIC devices in the
> device tree. It finds this thing, and from a table or
> something it derives that it h
On Tue, 17 Jul 2007, Paul Mackerras wrote:
> Robert P. J. Day writes:
>
> > -config CONFIG_CHECK_CACHE_COHERENCY
> > +config CHECK_CACHE_COHERENCY
>
> Please also fix the occurrence in
> arch/powerpc/platforms/embedded6xx/Kconfig.
ah, i completely missed that one. i'll resubmit the patch shortly
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
arch/powerpc/configs/prpmc2800_defconfig |2 +-
arch/powerpc/platforms/Kconfig.cputype |2 +-
arch/powerpc/platforms/embedded6xx/Kconfig |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/c
On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> >
> > Which is simply incorrect.
>
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a sin
Jon Loeliger wrote:
> How about "[EMAIL PROTECTED]" instead?
>
> That would be similar to:
> [EMAIL PROTECTED] {
> and
>[EMAIL PROTECTED] {
How about just "[EMAIL PROTECTED]"? Those model numbers in the names are a
PITA to find from limited functionality environments such as the
So, like, the other day Segher Boessenkool mumbled:
> > +/ {
> > + model = "StorCenter";
>
> If you can find a real model number, put it in here, instead.
Yep, "StorCenter" is it. No model numer/name beyond that.
> > + compatible = "storcenter";
>
> Needs a manufacturer name in there.
Rig
A: They haven't been posted yet.
Q: How do we know Segher has new patches?
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > But luckily, this gave me the opportunity to then realize that
> > we should give a great big...
> >
> > Amen-brother-by: Jon Loeliger <[EMAIL PR
Jon Loeliger wrote:
> A: They haven't been posted yet.
>
> Q: How do we know Segher has new patches?
He sent it to me to test, and I told him it worked...
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinf
So, like, the other day Scott Wood mumbled:
> Jon Loeliger wrote:
> > How about "[EMAIL PROTECTED]" instead?
>
> How about just "[EMAIL PROTECTED]"? Those model numbers in the names are a
> PITA to find from limited functionality environments such as the
> bootwrapper, require things like stdou
> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.
I fail why anyone would ever want to do it though :-)
> It could lead people to write code that doe
The patch titled
powerpc: add missing DATA_DATA
has been removed from the -mm tree. Its filename was
add-missing-data_data-in-powerpc.patch
This patch was dropped because it was merged into mainline or a subsystem tree
--
Subject: po
The current code assumes "foo-bar" must always be compatible with a node
compatible with "foo", which breaks device trees where this is not so.
The "case" part is also wrong according to Open Firmware, but it's more
likely to have drivers and/or device trees depending on it, and thus
needs to be h
Convert spaces to tabs, and add a few newlines where appropriate.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 376 +-
1 files changed, 189 insertions(+), 187 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8272ads.d
The IDE header file uses type definitions that are undefined if the
CONFIG_BLOCK is deselected. This causes a compilation failure in
setup_32.c.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ppc_ksyms.c |2 ++
arch/powerpc/kernel/setup_32.c |4 +++-
2 files chang
The CPU15 erratum on MPC8xx chips can cause incorrect code execution
under certain circumstances, where there is a conditional or indirect
branch in the last word of a page, with a target in the last cache line
of the next page. This patch implements one of the suggested
workarounds, by forcing a
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/.gitignore |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index eec7af7..3270335 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc
On arch/ppc, Soft_emulate_8xx was used when full math emulation was
turned off to emulate a minimal subset of floating point load/store
instructions, to avoid needing a soft-float toolchain. This function
is called, but not present, on arch/powerpc, causing a build error
if floating point emulatio
This lets udelay() work properly on platforms which use dt_fixup_cpu_clocks.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/devtree.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/devtree.c b/arch/powerpc/boot/devtree.c
index c99
1. The check whether ranges fits in the buffer was using elements rather
than bytes.
2. Empty ranges were not properly treated as transparent, and missing
ranges were treated as transparent.
3. The loop terminated when translating from the root rather than to. Once
bug #2 was fixed, it failed due
This can be used rather than doing a simple strcmp, which will fail to
handle multiple compatible entries.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/devtree.c | 50 ++-
arch/powerpc/boot/ops.h |1 +
2 files changed, 36 in
1. ft_create_node was returning the internal pointer rather than a phandle.
2. ft_find_device_rel was treating lookups relative to root as an error.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/flatdevtree.c | 12
1 files changed, 8 insertions(+), 4 deletions
Also, include types.h from io.h, so callers don't have to.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
arch/powerpc/boot/io.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
index 3297
U-boots more recent than when ppcboot.h was forked allow the board config
file to enable additional ethernet ports explicitly, rather than
using a hardcoded list of targets. This allows bootwrapper platform
files to do the same.
Fortunately, nothing after the ethernet addresses is of interest to
1 - 100 of 176 matches
Mail list logo
