* [PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: Mark A. Greer @ 2008-01-03 0:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
From: Mark A. Greer <mgreer@mvista.com>
Fix error in booting-without-of.txt that indicates that a node can inherit
its #address-cells and #size-cells definitions from its parent's parent.
This is not correct and the latest dtc enforces it.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
---
Documentation/powerpc/booting-without-of.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index ee0209a..58db5ea 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -671,10 +671,10 @@ device or bus to be described by the device tree.
In general, the format of an address for a device is defined by the
parent bus type, based on the #address-cells and #size-cells
-property. In the absence of such a property, the parent's parent
-values are used, etc... The kernel requires the root node to have
-those properties defining addresses format for devices directly mapped
-on the processor bus.
+properties. Note that the parent's parent definitions of #address-cells
+and #size-cells are not inhereted so every node with children must specify
+them. The kernel requires the root node to have those properties defining
+addresses format for devices directly mapped on the processor bus.
Those 2 properties define 'cells' for representing an address and a
size. A "cell" is a 32-bit number. For example, if both contain 2
^ permalink raw reply related
* Re: [PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: Josh Boyer @ 2008-01-03 1:46 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080103000750.GA22035@mag.az.mvista.com>
On Wed, 2 Jan 2008 17:07:50 -0700
"Mark A. Greer" <mgreer@mvista.com> wrote:
> From: Mark A. Greer <mgreer@mvista.com>
>
> Fix error in booting-without-of.txt that indicates that a node can inherit
> its #address-cells and #size-cells definitions from its parent's parent.
> This is not correct and the latest dtc enforces it.
I'm lazy so I haven't checked myself, but by "latest dtc" does that
mean the DTC that's in the kernel now?
Things are going to be fun when we start saying generic things like
"latest DTC". And when upstream DTC gets new features or enforcements,
we'll have to have all the in-kernel DTS files patched up when that
version of DTC gets merged in-kernel. Just something to keep in mind
as we move along.
josh
^ permalink raw reply
* Re: [patch] powerpc systbl.h broken
From: Stephen Rothwell @ 2008-01-03 2:16 UTC (permalink / raw)
To: Clifford Wolf; +Cc: linuxppc-dev, lkml, stable
In-Reply-To: <20080102141127.GA11870@clifford.at>
Hi Clifford,
Thanks for the report.
PowerPC problems should be reported to linuxppc-dev@ozlabs.org.
This has been fixed in the current (approaching 2.6.24) kernel. It
should be fixed in 2.6.23.xx, so I have cc'd this to
stable@vger.kernel.org (and linuxppc-dev, of course).
(Also, please post patches inline, don't attach them. And you need to
reply to this with a Signed-off-by: line.)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
------------------------------------------------------------------------
From: Clifford Wolf <clifford@clifford.at>
Hi,
In current 2.6.23 (I have checked 2.6.23.12 and 2.6.23.9) the end of
include/asm-powerpc/systbl.h reads:
--snip--
SYSCALL_SPU(getcpu)
COMPAT_SYS(epoll_pwait)
COMPAT_SYS_SPU(utimensat)
COMPAT_SYS(fallocate)
COMPAT_SYS_SPU(signalfd)
COMPAT_SYS_SPU(timerfd)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
--snap--
This obviously does not match the definitions in asm-powerpc/unistd.h:
--snip--
#define __NR_getcpu 302
#define __NR_epoll_pwait 303
#define __NR_utimensat 304
#define __NR_signalfd 305
#define __NR_timerfd 306
#define __NR_eventfd 307
#define __NR_sync_file_range2 308
#define __NR_fallocate 309
--snap--
which breaks the system calls 305 to 309 inclusive.
--- linux-2.6.23.12/include/asm-powerpc/systbl.h.orig 2008-01-02 15:09:04.000000000 +0100
+++ linux-2.6.23.12/include/asm-powerpc/systbl.h 2008-01-02 15:09:29.000000000 +0100
@@ -308,8 +308,8 @@
SYSCALL_SPU(getcpu)
COMPAT_SYS(epoll_pwait)
COMPAT_SYS_SPU(utimensat)
-COMPAT_SYS(fallocate)
COMPAT_SYS_SPU(signalfd)
COMPAT_SYS_SPU(timerfd)
SYSCALL_SPU(eventfd)
COMPAT_SYS_SPU(sync_file_range2)
+COMPAT_SYS(fallocate)
^ permalink raw reply
* Re: [patch] powerpc systbl.h broken
From: Stephen Rothwell @ 2008-01-03 2:54 UTC (permalink / raw)
To: Clifford Wolf; +Cc: linuxppc-dev, lkml, stable
In-Reply-To: <20080103131624.5a3e98e8.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 464 bytes --]
On Thu, 3 Jan 2008 13:16:24 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> This has been fixed in the current (approaching 2.6.24) kernel. It
> should be fixed in 2.6.23.xx, so I have cc'd this to
> stable@vger.kernel.org (and linuxppc-dev, of course).
Should have been stable@kernel.org. (where I have sent another copy of
the email)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: File system problem
From: Jean-Samuel Chenard @ 2008-01-03 3:32 UTC (permalink / raw)
To: linuxppc-embedded, kernelppc
> Date: Wed, 2 Jan 2008 19:50:13 +0100
> From: "mojtaba"
> I am trying to boot a root file system build by buildroot. But I got this
> error" init has generated signal 11 but has no handler for it".
>
> My kernel version is 2.6.24-rc3
> My target system is PPC 405 (XILINX VIRTEX II pro) I am using the 26-12-2=
007
> snapshot of buildroot.
[ ... ]
> Warning: unable to open an initial console.
> init has generated signal 11 but has no handler for it Kernel panic - not
Hi Mojtaba,
I got a similar error on my ML-310 when I tried a new root filesystem.
As far as I recall, I needed to make sure that two entries existed in
/dev, namely:
crw------- 1 root root 5, 1 Jan 1 05:18 console
crw-rw---- 1 root root 1, 3 Dec 10 2007 null
I think that you are missing /dev/console and then init cannot run
since it has nowhere to put its standard output.
You can make those by mounting your CF card on your development host
and (as root) make the nodes:
# mknod -m 660 /dev/console c 5 1
# mknod -m 660 /dev/null c 1 3
In my case, I use the UartLite (ttyUL0) serial port driver, but I'm
pretty sure this is going to fix the problem you are observing.
Regards,
Jean-Samuel
--=20
Ph.D. candidate
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* [PATCH] [POWERPC] arch/powerpc/kernel: use for_each_child_of_node
From: Stephen Rothwell @ 2008-01-03 4:13 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/ibmebus.c | 2 +-
arch/powerpc/kernel/of_platform.c | 4 ++--
arch/powerpc/kernel/pci_32.c | 4 ++--
arch/powerpc/kernel/pci_64.c | 4 ++--
arch/powerpc/kernel/rtas_pci.c | 5 +----
5 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index caae49f..1844359 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -171,7 +171,7 @@ static int ibmebus_create_devices(const struct of_device_id *matches)
root = of_find_node_by_path("/");
- for (child = NULL; (child = of_get_next_child(root, child)); ) {
+ for_each_child_of_node(root, child) {
if (!of_match_node(matches, child))
continue;
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index de36e23..7a60191 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -108,7 +108,7 @@ static int of_platform_bus_create(const struct device_node *bus,
struct of_device *dev;
int rc = 0;
- for (child = NULL; (child = of_get_next_child(bus, child)); ) {
+ for_each_child_of_node(bus, child) {
pr_debug(" create child: %s\n", child->full_name);
dev = of_platform_device_create(child, NULL, parent);
if (dev == NULL)
@@ -170,7 +170,7 @@ int of_platform_bus_probe(struct device_node *root,
rc = of_platform_bus_create(root, matches, &dev->dev);
goto bail;
}
- for (child = NULL; (child = of_get_next_child(root, child)); ) {
+ for_each_child_of_node(root, child) {
if (!of_match_node(matches, child))
continue;
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 47dc754..14e300f 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -276,11 +276,11 @@ scan_OF_pci_childs(struct device_node *parent, pci_OF_scan_iterator filter, void
static struct device_node *scan_OF_for_pci_dev(struct device_node *parent,
unsigned int devfn)
{
- struct device_node *np = NULL;
+ struct device_node *np;
const u32 *reg;
unsigned int psize;
- while ((np = of_get_next_child(parent, np)) != NULL) {
+ for_each_child_of_node(parent, np) {
reg = of_get_property(np, "reg", &psize);
if (reg == NULL || psize < 4)
continue;
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 5949bba..1930f39 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -227,7 +227,7 @@ EXPORT_SYMBOL(of_create_pci_dev);
void __devinit of_scan_bus(struct device_node *node,
struct pci_bus *bus)
{
- struct device_node *child = NULL;
+ struct device_node *child;
const u32 *reg;
int reglen, devfn;
struct pci_dev *dev;
@@ -235,7 +235,7 @@ void __devinit of_scan_bus(struct device_node *node,
DBG("of_scan_bus(%s) bus no %d... \n", node->full_name, bus->number);
/* Scan direct children */
- while ((child = of_get_next_child(node, child)) != NULL) {
+ for_each_child_of_node(node, child) {
DBG(" * %s\n", child->full_name);
reg = of_get_property(child, "reg", ®len);
if (reg == NULL || reglen < 20)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index 99aaae3..433a0a0 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++ b/arch/powerpc/kernel/rtas_pci.c
@@ -280,10 +280,7 @@ void __init find_and_init_phbs(void)
struct pci_controller *phb;
struct device_node *root = of_find_node_by_path("/");
- for (node = of_get_next_child(root, NULL);
- node != NULL;
- node = of_get_next_child(root, node)) {
-
+ for_each_child_of_node(root, node) {
if (node->type == NULL || (strcmp(node->type, "pci") != 0 &&
strcmp(node->type, "pciex") != 0))
continue;
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] [POWERPC] therm_windtunnel: eliminate some build warnings
From: Stephen Rothwell @ 2008-01-03 4:15 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, samuel
We don't care if the device_create_file calls fail, the driver will work
just as well without them, so just issue a runtime warning.
drivers/macintosh/therm_windtunnel.c: In function 'setup_hardware':
drivers/macintosh/therm_windtunnel.c:268: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_windtunnel.c:269: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/macintosh/therm_windtunnel.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/macintosh/therm_windtunnel.c b/drivers/macintosh/therm_windtunnel.c
index 3722402..63ef1f6 100644
--- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -223,6 +223,7 @@ static void
setup_hardware( void )
{
int val;
+ int err;
/* save registers (if we unload the module) */
x.r0 = read_reg( x.fan, 0x00, 1 );
@@ -265,8 +266,11 @@ setup_hardware( void )
x.upind = -1;
/* tune_fan( fan_up_table[x.upind].fan_setting ); */
- device_create_file( &x.of_dev->dev, &dev_attr_cpu_temperature );
- device_create_file( &x.of_dev->dev, &dev_attr_case_temperature );
+ err = device_create_file( &x.of_dev->dev, &dev_attr_cpu_temperature );
+ err |= device_create_file( &x.of_dev->dev, &dev_attr_case_temperature );
+ if (err)
+ printk(KERN_WARNING
+ "Failed to create temperature attribute file(s).\n");
}
static void
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH] [POWERPC] therm_adt746x: eliminate some build warnings
From: Stephen Rothwell @ 2008-01-03 4:17 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
We don't care if the device_create_file calls fail, the driver will work
just as well without them, so just issue a runtime warning.
drivers/macintosh/therm_adt746x.c: In function 'thermostat_init':
drivers/macintosh/therm_adt746x.c:615: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:616: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:617: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:618: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:619: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:620: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:621: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:622: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:623: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:625: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/macintosh/therm_adt746x.c | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/macintosh/therm_adt746x.c b/drivers/macintosh/therm_adt746x.c
index 276945d..54f4942 100644
--- a/drivers/macintosh/therm_adt746x.c
+++ b/drivers/macintosh/therm_adt746x.c
@@ -553,6 +553,7 @@ thermostat_init(void)
struct device_node* np;
const u32 *prop;
int i = 0, offset = 0;
+ int err;
np = of_find_node_by_name(NULL, "fan");
if (!np)
@@ -612,17 +613,20 @@ thermostat_init(void)
return -ENODEV;
}
- device_create_file(&of_dev->dev, &dev_attr_sensor1_temperature);
- device_create_file(&of_dev->dev, &dev_attr_sensor2_temperature);
- device_create_file(&of_dev->dev, &dev_attr_sensor1_limit);
- device_create_file(&of_dev->dev, &dev_attr_sensor2_limit);
- device_create_file(&of_dev->dev, &dev_attr_sensor1_location);
- device_create_file(&of_dev->dev, &dev_attr_sensor2_location);
- device_create_file(&of_dev->dev, &dev_attr_limit_adjust);
- device_create_file(&of_dev->dev, &dev_attr_specified_fan_speed);
- device_create_file(&of_dev->dev, &dev_attr_sensor1_fan_speed);
+ err = device_create_file(&of_dev->dev, &dev_attr_sensor1_temperature);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor2_temperature);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor1_limit);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor2_limit);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor1_location);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor2_location);
+ err |= device_create_file(&of_dev->dev, &dev_attr_limit_adjust);
+ err |= device_create_file(&of_dev->dev, &dev_attr_specified_fan_speed);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor1_fan_speed);
if(therm_type == ADT7460)
- device_create_file(&of_dev->dev, &dev_attr_sensor2_fan_speed);
+ err |= device_create_file(&of_dev->dev, &dev_attr_sensor2_fan_speed);
+ if (err)
+ printk(KERN_WARNING
+ "Failed to create tempertaure attribute file(s).\n");
#ifndef CONFIG_I2C_POWERMAC
request_module("i2c-powermac");
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: How to creat a .config file for a driver and How to use it in adevice driver?????
From: Misbah khan @ 2008-01-03 4:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <477BCE30.8010306@pikatech.com>
Ya i got your point ...the way you told is the very generic way of doing this
but what i need is this :-
Like your any .config if you edit your configuration and restart your
default configuration changes ....The merit of this technique is that i need
not compile the driver with every default config change ....
---Misbah <><
Sean MacLennan-2 wrote:
>
> Misbah khan wrote:
>> Hi all ...
>>
>> i am writing a device driver in which the default configuration for LCD
>> display i need to keep it in a .config file so that as the system boots
>> it
>> take the value from this file and does the initial configuration in the
>> init
>> of the driver. If user changes the .config file content in the next boot
>> the
>> LCD driver should take the new default configuration
>>
>> There will also be a run time config which could be changed at the rum
>> time
>> but will not change the default configuration.
>>
>>
>> i am writing a LCD driver for PPC arch i need to know that how should i
>> creat a .config file and How should i use it my device driver. ??????
>>
>> If you had an exprience in this regard please do share with me ...
>>
>> ----Misbah <><
>>
> You don't. The safe way is to have sane defaults in the driver. Then
> write a user mode app that reads the config file and configures the
> driver properly, probably through ioctls.
>
> Cheers,
> Sean
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
View this message in context: http://www.nabble.com/How-to-creat-a-.config-file-for-a-driver-and-How-to-use-it-in-a-device-driver------tp14576412p14591612.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-03 4:44 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <477BADF5.9060003@freescale.com>
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
> Jon Smirl wrote:
> > On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> >> sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++
> >> sound/soc/fsl/fsl_ssi.h | 224 +++++++
> >
> > I'm confused about this part. You built a driver for the mpc8610 ssi
> > port. This port has a device tree entry.
> >
> > + ssi@16000 {
> > + compatible = "fsl,ssi";
> > + cell-index = <0>;
> > + reg = <16000 100>;
> > + interrupt-parent = <&mpic>;
> > + interrupts = <3e 2>;
> > + fsl,mode = "i2s-slave";
> > + codec {
> > + compatible = "cirrus,cs4270";
> > + /* MCLK source is a stand-alone oscillator */
> > + bus-frequency = <bb8000>;
> > + };
> > + };
> >
> > But then you don't create an of_platform_driver for this device.
> > Instead you create one for the fabric driver, struct
> > of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI
> > driver into it.
>
> That's the best plan I came up with. This is apparently fixed in ASoC
> V2. From ASoC V1's perspective, the fabric driver must be the master.
> However, it doesn't make sense to have a node in the device tree for the
> fabric driver, because there is no such "device". The fabric driver is
> an abstraction. So I need to chose some other node to probe the fabric
> driver with. I chose the SSI, since each SSI can have only one
> codec.
Instantiating the fabric driver off any node is wrong, precisely
because it is an abstraction. The fabric driver should be
instantiated by the platform code.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-03 4:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801020912k50dceaebm11b59c1cee571e56@mail.gmail.com>
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
> On 1/2/08, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 1/2/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > On 1/2/08, Timur Tabi <timur@freescale.com> wrote:
> > > mpc8610_hpcd is the harder one to load since it doesn't have a device
> > > tree entry. What you want to do it match on the compatible field of
> > > the root node.
> > >
> > > static struct of_device_id fabric_of_match[] = {
> > > {
> > > .compatible = "fsl,MPC8610HPCD",
> > > },
> > > {},
> > > };
> > >
> > > But this doesn't work since the root is the device tree isn't passed
> > > down into the device probe code. (Could this be fixed?)
> >
> > The driver can always get the root node. But better yet, instantiate
> > the correct fabric device (probably as a platform_device) from the
> > platform code. Then the correct fabric driver can probe against it.
>
> The meaning of this has finally sunk into my consciousness. The
> platform code can create a device that isn't bound to a driver. So why
> not make this an of_platform_device? This is basically a pseudo
> device that isn't in the device tree.
>
> Alternatively, the best place for this device would be on the ASOC
> bus, but the ASOC bus hasn't been created when the platform code runs.
> Maybe I can figure out a place in the platform code to create this
> device after the ASOC driver has loaded and created the bus. Does the
> platform code get control back after loading all of the device
> drivers?
>
> In the longer term I'd like to kill platform_bus on powerpc and only
> use of_platform_bus. Platform_bus seems to be functioning like a
> catch-all and collecting junk from lots of different platforms.
Not going to happen. of_platform_bus is not the right solution, and
in fact we're looking at moving (gradually) away from using
of_platform_bus, and instead using platform devices (along with the
device node being available for *any* struct device via the
arch_sysdata).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: Outstanding DTC patches?
From: David Gibson @ 2008-01-03 4:48 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1199298062.7345.25.camel@ld0161-tx32>
On Wed, Jan 02, 2008 at 12:21:02PM -0600, Jon Loeliger wrote:
> Folks,
>
> I'd like to release a DTC 1.1 Real Soon Now!
>
> However, I've been back-logged due to the holidays.
> If you have any outstanding DTC or libfdt patches
> that I have not yet applied and that you would like
> in that release, please remind me by reposting it
> and CC:'ing jdl@jdl.com!
I posted this one a while back, but I guess it dropped through the
cracks. There's also the patch I sent you quite a long time ago that
adds a clarifying readme about the licensing situation - that might be
an idea for v1.1, too.
dtc: Remove header information dumping
Currently, when used in -Idtb mode, dtc will dump information about
the input blob's header fields to stderr. This is kind of ugly, and
can get in the way of dtc's real output.
This patch, therefore, removes this. So that there's still a way of
getting this information for debugging purposes, it places something
similar to the removed code into ftdump, replacing the couple of
header fields it currently prints with a complete header dump.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/flattree.c
===================================================================
--- dtc.orig/flattree.c 2007-12-08 12:06:11.000000000 +1100
+++ dtc/flattree.c 2007-12-08 12:13:15.000000000 +1100
@@ -898,15 +898,6 @@
off_mem_rsvmap = be32_to_cpu(fdt->off_mem_rsvmap);
version = be32_to_cpu(fdt->version);
- fprintf(stderr, "\tmagic:\t\t\t0x%x\n", magic);
- fprintf(stderr, "\ttotalsize:\t\t%d\n", totalsize);
- fprintf(stderr, "\toff_dt_struct:\t\t0x%x\n", off_dt);
- fprintf(stderr, "\toff_dt_strings:\t\t0x%x\n", off_str);
- fprintf(stderr, "\toff_mem_rsvmap:\t\t0x%x\n", off_mem_rsvmap);
- fprintf(stderr, "\tversion:\t\t0x%x\n", version );
- fprintf(stderr, "\tlast_comp_version:\t0x%x\n",
- be32_to_cpu(fdt->last_comp_version));
-
if (off_mem_rsvmap >= totalsize)
die("Mem Reserve structure offset exceeds total size\n");
@@ -916,21 +907,15 @@
if (off_str > totalsize)
die("String table offset exceeds total size\n");
- if (version >= 2)
- fprintf(stderr, "\tboot_cpuid_phys:\t0x%x\n",
- be32_to_cpu(fdt->boot_cpuid_phys));
-
size_str = -1;
if (version >= 3) {
size_str = be32_to_cpu(fdt->size_dt_strings);
- fprintf(stderr, "\tsize_dt_strings:\t%d\n", size_str);
if (off_str+size_str > totalsize)
die("String table extends past total size\n");
}
if (version >= 17) {
size_dt = be32_to_cpu(fdt->size_dt_struct);
- fprintf(stderr, "\tsize_dt_struct:\t\t%d\n", size_dt);
if (off_dt+size_dt > totalsize)
die("Structure block extends past total size\n");
}
Index: dtc/ftdump.c
===================================================================
--- dtc.orig/ftdump.c 2007-12-08 12:06:23.000000000 +1100
+++ dtc/ftdump.c 2007-12-08 12:15:09.000000000 +1100
@@ -81,11 +81,13 @@
static void dump_blob(void *blob)
{
struct fdt_header *bph = blob;
+ uint32_t off_mem_rsvmap = be32_to_cpu(bph->off_mem_rsvmap);
+ uint32_t off_dt = be32_to_cpu(bph->off_dt_struct);
+ uint32_t off_str = be32_to_cpu(bph->off_dt_strings);
struct fdt_reserve_entry *p_rsvmap =
- (struct fdt_reserve_entry *)(blob
- + be32_to_cpu(bph->off_mem_rsvmap));
- char *p_struct = blob + be32_to_cpu(bph->off_dt_struct);
- char *p_strings = blob + be32_to_cpu(bph->off_dt_strings);
+ (struct fdt_reserve_entry *)(blob + off_mem_rsvmap);
+ char *p_struct = blob + off_dt;
+ char *p_strings = blob + off_str;
uint32_t version = be32_to_cpu(bph->version);
uint32_t totalsize = be32_to_cpu(bph->totalsize);
uint32_t tag;
@@ -98,8 +100,26 @@
depth = 0;
shift = 4;
- printf("// Version 0x%x tree\n", version);
- printf("// Totalsize 0x%x(%d)\n", totalsize, totalsize);
+ printf("// magic:\t\t0x%x\n", be32_to_cpu(bph->magic));
+ printf("// totalsize:\t\t0x%x (%d)\n", totalsize, totalsize);
+ printf("// off_dt_struct:\t0x%x\n", off_dt);
+ printf("// off_dt_strings:\t0x%x\n", off_str);
+ printf("// off_mem_rsvmap:\t0x%x\n", off_mem_rsvmap);
+ printf("// version:\t\t%d\n", version);
+ printf("// last_comp_version:\t%d\n",
+ be32_to_cpu(bph->last_comp_version));
+ if (version >= 2)
+ printf("// boot_cpuid_phys:\t0x%x\n",
+ be32_to_cpu(bph->boot_cpuid_phys));
+
+ if (version >= 3)
+ printf("// size_dt_strings:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_strings));
+ if (version >= 17)
+ printf("// size_dt_struct:\t0x%x\n",
+ be32_to_cpu(bph->size_dt_struct));
+ printf("\n");
+
for (i = 0; ; i++) {
addr = be64_to_cpu(p_rsvmap[i].address);
size = be64_to_cpu(p_rsvmap[i].size);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Reading a config file in a driver ....
From: Misbah khan @ 2008-01-03 5:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi all ....
I am writing a LCD driver in which the default configuration for LCD would
be loded at the Init . This default configuration if keep in the driver then
for a change in default configuration we need to compile the driver which we
never want . Hence we want a .config file in /etc/lcd.config dir which could
be changed and the next boot will take this configuration as the default
configuration.
I need to know How to read from the config file in the driver form the dir
/etc/lcd.config. The driver would be installed at boot up
Please if any of you have an experience in this or could suggest something
,I would really appriciate ...
----Misbah <><
--
View this message in context: http://www.nabble.com/Reading-a-config-file-in-a-driver-....-tp14591717p14591717.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* MPC8260ADS and linux-2.6
From: suja Baburaj @ 2008-01-03 5:05 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Hi,
I have an MPC8260ADS board with (eldk)linux-2.4.25 working fine on it.
Now i want to try linux-2.6.X on the board.
Which is the latest available linux-2.6 for MPC8260ADS and where to
get it from?
Thanks and Regards,
suja
[-- Attachment #2: Type: text/html, Size: 265 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] Check that the syscall table matches the syscall numbers
From: Stephen Rothwell @ 2008-01-03 5:41 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Hopefully this will catch any out of order additions to the
table in the future.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/systbl.S | 44 ++++++++++++++++++++----
arch/powerpc/platforms/cell/spu_callbacks.c | 3 ++
include/asm-powerpc/systbl.h | 50 +++++++++++++-------------
3 files changed, 65 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/systbl.S b/arch/powerpc/kernel/systbl.S
index 93219c3..89ea6f3 100644
--- a/arch/powerpc/kernel/systbl.S
+++ b/arch/powerpc/kernel/systbl.S
@@ -15,21 +15,50 @@
*/
#include <asm/ppc_asm.h>
+#include <asm/unistd.h>
+
+/*
+ * These are here so that syscall number checking will work.
+ * Do not add any more.
+ */
+#define __NR_llseek __NR__llseek
+#undef __NR_umount
+#define __NR_umount __NR_umount2
+#define __NR_old_getrlimit __NR_getrlimit
+#define __NR_newstat __NR_stat
+#define __NR_newlstat __NR_lstat
+#define __NR_newfstat __NR_fstat
+#define __NR_newuname __NR_uname
+#define __NR_sysctl __NR__sysctl
+#define sys_ugetrlimit sys_getrlimit
#ifdef CONFIG_PPC64
-#define SYSCALL(func) .llong .sys_##func,.sys_##func
-#define COMPAT_SYS(func) .llong .sys_##func,.compat_sys_##func
-#define PPC_SYS(func) .llong .ppc_##func,.ppc_##func
+#define CHECK_SYS(n) .org .sys_call_table + n * 16
+
+#define SYSCALL(func) CHECK_SYS(__NR_##func); \
+ .llong .sys_##func,.sys_##func
+#define COMPAT_SYS(func) CHECK_SYS(__NR_##func); \
+ .llong .sys_##func,.compat_sys_##func
+#define PPC_SYS(func) CHECK_SYS(__NR_##func); \
+ .llong .ppc_##func,.ppc_##func
#define OLDSYS(func) .llong .sys_ni_syscall,.sys_ni_syscall
#define SYS32ONLY(func) .llong .sys_ni_syscall,.compat_sys_##func
#define SYSX(f, f3264, f32) .llong .f,.f3264
+#define SYSCALL_NI .llong .sys_ni_syscall,.sys_ni_syscall
#else
-#define SYSCALL(func) .long sys_##func
-#define COMPAT_SYS(func) .long sys_##func
-#define PPC_SYS(func) .long ppc_##func
+#define CHECK_SYS(n) .org sys_call_table + n * 4
+
+#define SYSCALL(func) CHECK_SYS(__NR_##func); \
+ .long sys_##func
+#define COMPAT_SYS(func) CHECK_SYS(__NR_##func); \
+ .long sys_##func
+#define PPC_SYS(func) CHECK_SYS(__NR_##func); \
+ .long ppc_##func
#define OLDSYS(func) .long sys_##func
-#define SYS32ONLY(func) .long sys_##func
+#define SYS32ONLY(func) CHECK_SYS(__NR_##func); \
+ .long sys_##func
#define SYSX(f, f3264, f32) .long f32
+#define SYSCALL_NI .long sys_ni_syscall
#endif
#define SYSCALL_SPU(func) SYSCALL(func)
#define COMPAT_SYS_SPU(func) COMPAT_SYS(func)
@@ -39,6 +68,7 @@
#ifdef CONFIG_PPC64
#define sys_sigpending sys_ni_syscall
#define sys_old_getrlimit sys_ni_syscall
+#define compat_sys_ugetrlimit compat_sys_getrlimit
.p2align 3
#endif
diff --git a/arch/powerpc/platforms/cell/spu_callbacks.c b/arch/powerpc/platforms/cell/spu_callbacks.c
index dceb8b6..ae203be 100644
--- a/arch/powerpc/platforms/cell/spu_callbacks.c
+++ b/arch/powerpc/platforms/cell/spu_callbacks.c
@@ -40,12 +40,15 @@ static void *spu_syscall_table[] = {
#define OLDSYS(func) sys_ni_syscall,
#define SYS32ONLY(func) sys_ni_syscall,
#define SYSX(f, f3264, f32) sys_ni_syscall,
+#define SYSCALL_NI sys_ni_syscall,
#define SYSCALL_SPU(func) sys_##func,
#define COMPAT_SYS_SPU(func) sys_##func,
#define PPC_SYS_SPU(func) ppc_##func,
#define SYSX_SPU(f, f3264, f32) f,
+#define sys_ugetrlimit sys_getrlimit
+
#include <asm/systbl.h>
};
diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
index 11d5383..fa6c63b 100644
--- a/include/asm-powerpc/systbl.h
+++ b/include/asm-powerpc/systbl.h
@@ -20,7 +20,7 @@ COMPAT_SYS_SPU(time)
SYSCALL_SPU(mknod)
SYSCALL_SPU(chmod)
SYSCALL_SPU(lchown)
-SYSCALL(ni_syscall)
+SYSCALL_NI
OLDSYS(stat)
SYSX_SPU(sys_lseek,ppc32_lseek,sys_lseek)
SYSCALL_SPU(getpid)
@@ -34,11 +34,11 @@ SYSCALL_SPU(alarm)
OLDSYS(fstat)
COMPAT_SYS(pause)
COMPAT_SYS(utime)
-SYSCALL(ni_syscall)
-SYSCALL(ni_syscall)
+SYSCALL_NI
+SYSCALL_NI
COMPAT_SYS_SPU(access)
COMPAT_SYS_SPU(nice)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(sync)
COMPAT_SYS_SPU(kill)
SYSCALL_SPU(rename)
@@ -47,7 +47,7 @@ SYSCALL_SPU(rmdir)
SYSCALL_SPU(dup)
SYSCALL_SPU(pipe)
COMPAT_SYS_SPU(times)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(brk)
SYSCALL_SPU(setgid)
SYSCALL_SPU(getgid)
@@ -56,12 +56,12 @@ SYSCALL_SPU(geteuid)
SYSCALL_SPU(getegid)
SYSCALL(acct)
SYSCALL(umount)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS_SPU(ioctl)
COMPAT_SYS_SPU(fcntl)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS_SPU(setpgid)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSX(sys_ni_syscall,sys_olduname, sys_olduname)
COMPAT_SYS_SPU(umask)
SYSCALL_SPU(chroot)
@@ -101,10 +101,10 @@ SYSCALL_SPU(fchmod)
SYSCALL_SPU(fchown)
COMPAT_SYS_SPU(getpriority)
COMPAT_SYS_SPU(setpriority)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS(statfs)
COMPAT_SYS(fstatfs)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS_SPU(socketcall)
COMPAT_SYS_SPU(syslog)
COMPAT_SYS_SPU(setitimer)
@@ -113,10 +113,10 @@ COMPAT_SYS_SPU(newstat)
COMPAT_SYS_SPU(newlstat)
COMPAT_SYS_SPU(newfstat)
SYSX(sys_ni_syscall,sys_uname,sys_uname)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(vhangup)
-SYSCALL(ni_syscall)
-SYSCALL(ni_syscall)
+SYSCALL_NI
+SYSCALL_NI
COMPAT_SYS_SPU(wait4)
SYSCALL(swapoff)
COMPAT_SYS_SPU(sysinfo)
@@ -126,21 +126,21 @@ SYS32ONLY(sigreturn)
PPC_SYS(clone)
COMPAT_SYS_SPU(setdomainname)
PPC_SYS_SPU(newuname)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS_SPU(adjtimex)
SYSCALL_SPU(mprotect)
SYSX(sys_ni_syscall,compat_sys_sigprocmask,sys_sigprocmask)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL(init_module)
SYSCALL(delete_module)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL(quotactl)
COMPAT_SYS_SPU(getpgid)
SYSCALL_SPU(fchdir)
SYSCALL_SPU(bdflush)
COMPAT_SYS(sysfs)
SYSX_SPU(ppc64_personality,ppc64_personality,sys_personality)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(setfsuid)
SYSCALL_SPU(setfsgid)
SYSCALL_SPU(llseek)
@@ -169,7 +169,7 @@ COMPAT_SYS_SPU(nanosleep)
SYSCALL_SPU(mremap)
SYSCALL_SPU(setresuid)
SYSCALL_SPU(getresuid)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(poll)
COMPAT_SYS(nfsservctl)
SYSCALL_SPU(setresgid)
@@ -190,10 +190,10 @@ SYSCALL_SPU(capget)
SYSCALL_SPU(capset)
COMPAT_SYS(sigaltstack)
SYSX_SPU(sys_sendfile64,compat_sys_sendfile,sys_sendfile)
-SYSCALL(ni_syscall)
-SYSCALL(ni_syscall)
+SYSCALL_NI
+SYSCALL_NI
PPC_SYS(vfork)
-COMPAT_SYS_SPU(getrlimit)
+COMPAT_SYS_SPU(ugetrlimit)
COMPAT_SYS_SPU(readahead)
SYS32ONLY(mmap2)
SYS32ONLY(truncate64)
@@ -204,7 +204,7 @@ SYSX(sys_ni_syscall,sys_fstat64,sys_fstat64)
SYSCALL(pciconfig_read)
SYSCALL(pciconfig_write)
SYSCALL(pciconfig_iobase)
-SYSCALL(ni_syscall)
+SYSCALL_NI
SYSCALL_SPU(getdents64)
SYSCALL_SPU(pivot_root)
SYSX(sys_ni_syscall,compat_sys_fcntl64,sys_fcntl64)
@@ -227,8 +227,8 @@ SYSCALL_SPU(fremovexattr)
COMPAT_SYS_SPU(futex)
COMPAT_SYS_SPU(sched_setaffinity)
COMPAT_SYS_SPU(sched_getaffinity)
-SYSCALL(ni_syscall)
-SYSCALL(ni_syscall)
+SYSCALL_NI
+SYSCALL_NI
SYS32ONLY(sendfile64)
COMPAT_SYS_SPU(io_setup)
SYSCALL_SPU(io_destroy)
@@ -260,7 +260,7 @@ COMPAT_SYS_SPU(fstatfs64)
SYSX(sys_ni_syscall, ppc_fadvise64_64, ppc_fadvise64_64)
PPC_SYS_SPU(rtas)
OLDSYS(debug_setcontext)
-SYSCALL(ni_syscall)
+SYSCALL_NI
COMPAT_SYS(migrate_pages)
COMPAT_SYS(mbind)
COMPAT_SYS(get_mempolicy)
--
1.5.3.7
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Li Li @ 2008-01-03 5:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: Wood Scott, linuxppc-dev, Phillips Kim, Li Tony
In-Reply-To: <901A2F2F-D072-4F03-AA39-9AB6A56EA635@kernel.crashing.org>
On Wed, 2008-01-02 at 23:23 +0800, Kumar Gala wrote:
>
> On Jan 2, 2008, at 5:16 AM, Li Li wrote:
>
> > * The MPC837x PCIE controller hardware resources and SerDes are
> > initiated in u-boot.
> > * Merge the MPC837x PCIE code into arch/powerpc/sysdev/fsl_pci.c
> > * The MPC837x PCIE controller`s configure address bit field is
> uniqe:
> > bus number: bits 31-24
> > device number: bits 23-19
> > function number: bits 18-16
> > ext reg number: bits 11-8
> > reg number: bits 7-2
> > * Add mpc837x_exclude_device to fixup a controller bug.
>
> what is the bug that is being worked around?
>
For Type 0 configure transactions, the PCIE controller do not check the
device number bits and just assume the device number bits are 0.
- tony
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Li Li @ 2008-01-03 6:40 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Wood Scott, linuxppc-dev, Phillips Kim, Li Tony
In-Reply-To: <200801021253.08280.arnd@arndb.de>
On Wed, 2008-01-02 at 19:53 +0800, Arnd Bergmann wrote:
> On Wednesday 02 January 2008, Li Li wrote:
> > #ifdef CONFIG_PCI
> > - for_each_compatible_node(np, "pci", "fsl,mpc8349-pci")
> > - mpc83xx_add_bridge(np);
> > + for_each_compatible_node(np, "pci", "fsl,mpc8349-pci") {
> > + if (primary_pci_bus) {
> > + mpc83xx_add_bridge(np, PPC_83XX_PCI |
> PPC_83XX_PCI_PRIMARY);
> > + primary_pci_bus = 0;
> > + } else
> > + mpc83xx_add_bridge(np, PPC_83XX_PCI);
> > + }
> > +
> > + for_each_compatible_node(np, "pci", "fsl,mpc8377-pcie") {
> > + if (primary_pci_bus) {
> > + mpc83xx_add_bridge(np, PPC_83XX_PCIE |
> PPC_83XX_PCI_PRIMARY);
> > + primary_pci_bus = 0;
> > + } else
> > + mpc83xx_add_bridge(np, PPC_83XX_PCIE);
> > + }
> > +
> > + ppc_md.pci_exclude_device = mpc837x_exclude_device;
> > #endif
>
> A few comments on how I think this can be improved:
>
> * Instead of duplicating this code across all platforms, make a
> single
> function that does the probing in one place (including the #ifdef
> CONFIG_PCI).
>
This code appears in 834x board in first and then copied from one board
to another. It is a legacy issue. :(
Yes. it is the time to remove this duplicates.
> * Better yet, get rid of mpc83xx_add_bridge and make it possible for
> the
> mpc83xx code to use the of_pci_phb_driver from
> arch/powerpc/kernel/of_platform.c. This used to be impossible because
> of the differences between 32 and 64 bit code for PCI probing, but
> I think with the work than benh put into unifying the two, we should
> be pretty close now.
>
This is really a huge task and almost affects all exist boards. We need
more opinions in here.
> * The detection method for the primary bus is somewhat fragile,
> because
> we depend on the order of the nodes in the device tree, which is not
> specified to have a meaning. /Maybe/ there could be a property in
> (at most) one of the PCI host bridge nodes saying that this specific
> bus
> is the primary one.
>
Put this primary in code is more save than in dts.
The dts lacks error checking function. If provide error dts such as two
pci hosts both has primary property will occur chaos.
> * Since you are using exactly the same probing code for pci and pcie,
> you may want to check for a more generic "compatible" property than
> the specific model, so you can use the same code for both.
>
> Arnd <><
>
^ permalink raw reply
* Re: [PATCH -mm] compat_binfmt_elf Kconfig
From: Sam Ravnborg @ 2008-01-03 7:23 UTC (permalink / raw)
To: Roland McGrath; +Cc: linux-arch, linuxppc-dev, Ingo Molnar, linux-kernel
In-Reply-To: <20080102221228.C9D8D26F9A0@magilla.localdomain>
On Wed, Jan 02, 2008 at 02:12:28PM -0800, Roland McGrath wrote:
> I have no opinions about the config symbol names. Among the existing
> precedents for internal/descriptionless symbols I find more not using the
> HAVE_ prefix than those using it.
The convention is newly established - so no suprise.
> The patch versions I've sent now work
> fine, fix the parallel build problem people were seeing, and AFAICT follow
> the style of what's already in common use. At this point, I think it would
> be easiest just to keep them and have you send symbol-renaming patches
> for any and all symbols of this sort that concern you as separate cleanups.
Would love to - but the pile of other kbuild stuff only gets bigger..
Sam
^ permalink raw reply
* Re: [PATCH] [POWERPC] Check that the syscall table matches the syscall
From: Milton Miller @ 2008-01-03 7:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppcdev
Hmmm, in-reply-to on the web archive is broken again, sfr alerted.
On Thu Jan 3 16:41:41 EST 2008, Stephen Rothwell wrote:
> Hopefully this will catch any out of order additions to the
> table in the future.
> #ifdef CONFIG_PPC64
> -#define SYSCALL(func) .llong .sys_##func,.sys_##func
> -#define COMPAT_SYS(func) .llong .sys_##func,.compat_sys_##func
> -#define PPC_SYS(func) .llong .ppc_##func,.ppc_##func
> +#define CHECK_SYS(n) .org .sys_call_table + n * 16
> +
> +#define SYSCALL(func) CHECK_SYS(__NR_##func); \
> + .llong .sys_##func,.sys_##func
> +#define COMPAT_SYS(func) CHECK_SYS(__NR_##func); \
> + .llong .sys_##func,.compat_sys_##func
>
While it may detect misordered additions, it does nothing to check for
holes. Actually, it would hide holes: presently, if you leave a hole
the entry you add at the end of the table will not work / crash the
kernel. After this patch, the hole will crash the kernel but the new
syscall will work.
I'm still thinking this through, but perhaps instead of checking the
numbers by org in asm, we can define another way to include the
systable.h, possibly as a build-only check target.
Something compareing the line number to __NR_##func perhaps cpp into a
simple awk script ...
later,
milton
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Arnd Bergmann @ 2008-01-03 8:14 UTC (permalink / raw)
To: Li Li; +Cc: Wood Scott, linuxppc-dev, Phillips Kim, Li Tony
In-Reply-To: <1199342440.7375.29.camel@Guyver>
On Thursday 03 January 2008, Li Li wrote:
> > * The detection method for the primary bus is somewhat fragile,
> > because
> > we depend on the order of the nodes in the device tree, which is not
> > specified to have a meaning. /Maybe/ there could be a property in
> > (at most) one of the PCI host bridge nodes saying that this specific
> > bus
> > is the primary one.
> >
>
> Put this primary in code is more save than in dts.
> The dts lacks error checking function. If provide error dts such as two
> pci hosts both has primary property will occur chaos.
It's easy enough to just panic() if you find more than one primary bus,
since the information from the device tree is static enough that one
will know how to fix this after seeing the error.
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Li Li @ 2008-01-03 8:31 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Wood Scott, linuxppc-dev, Phillips Kim, Li Tony
In-Reply-To: <200801030914.12628.arnd@arndb.de>
On Thu, 2008-01-03 at 16:14 +0800, Arnd Bergmann wrote:
> On Thursday 03 January 2008, Li Li wrote:
> > > * The detection method for the primary bus is somewhat fragile,
> > > because
> > > we depend on the order of the nodes in the device tree, which is
> not
> > > specified to have a meaning. /Maybe/ there could be a property in
> > > (at most) one of the PCI host bridge nodes saying that this
> specific
> > > bus
> > > is the primary one.
> > >
> >
> > Put this primary in code is more save than in dts.
> > The dts lacks error checking function. If provide error dts such as
> two
> > pci hosts both has primary property will occur chaos.
>
> It's easy enough to just panic() if you find more than one primary
> bus,
> since the information from the device tree is static enough that one
> will know how to fix this after seeing the error.
>
It is just a case. what about if do not find primary pci host.
The current code can prevent this potential error and make system
robust.
- Tony
^ permalink raw reply
* (no subject)
From: Awad, Sinan (GE Healthcare) @ 2008-01-03 8:33 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Hello all
I'm trying to understand if we need to move from MPC8347 to MPC8360 in
our boards.
One of the features that most attracts, is the eTSEC which includes
support for IEEE 1588 PTP time synchronization.
I need to synchronize the clock of 3 boards via ethernet, I need a time
resolution of under 1ms.
Has anyone had the pleasure of playing around with time synchronization
?
Do I really need the hardware capabilities for this type of time
resolution ? or can I implement it in software ?
Thanks in advance.
Sinan
[-- Attachment #2: Type: text/html, Size: 2013 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: #address-cells & #size-cells properties not inherited
From: David Gibson @ 2008-01-03 9:46 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <20080103000750.GA22035@mag.az.mvista.com>
On Wed, Jan 02, 2008 at 05:07:50PM -0700, Mark A. Greer wrote:
> From: Mark A. Greer <mgreer@mvista.com>
>
> Fix error in booting-without-of.txt that indicates that a node can inherit
> its #address-cells and #size-cells definitions from its parent's parent.
> This is not correct and the latest dtc enforces it.
For small values of "enforce"; it's a warning only.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Test (Was: Re: [PATCH] [POWERPC] Check that the syscall table matches the syscall )
From: Stephen Rothwell @ 2008-01-03 10:07 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <cc783558d0d687131f756488692cc34b@bga.com>
On Thu, 3 Jan 2008 01:32:21 -0600 Milton Miller <miltonm@bga.com> wrote:
>
> Hmmm, in-reply-to on the web archive is broken again, sfr alerted.
Just a test ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: [PATCH] powerpc: Add MPC837x PCIE controller RC mode support
From: Arnd Bergmann @ 2008-01-03 10:14 UTC (permalink / raw)
To: Li Li; +Cc: Phillips Kim, linuxppc-dev, Li Tony, Wood Scott
In-Reply-To: <1199349066.4437.5.camel@Guyver>
On Thursday 03 January 2008, Li Li wrote:
>
> > It's easy enough to just panic() if you find more than one primary
> > bus,
> > since the information from the device tree is static enough that one
> > will know how to fix this after seeing the error.
> >
>
> It is just a case. what about if do not find primary pci host.
> The current code can prevent this potential error and make system
> robust.
After some more research, I noticed that the distinction between
primary and secondary host bridges will go away _anyway_, so
I guess we shouldn't worry about it too much.
On powerpc64, we already don't care, as the arch/powerpc/kernel/isa-bridge.c
code takes care of legacy I/O areas there, instead of the PCI code.
It's only needed on machines with legacy ISA devices (PC keyboard,
floppy, ...), and those can be converted to use the isa-bridge code
at some point.
Arnd <><
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox