current dtc patch

[ron minnich]

no ack in it, for your viewing pleasure.

Tested on dbe62.

ron

[Carl-Daniel Hailfinger]

On 04.09.2008 18:04, ron minnich wrote:
> no ack in it, for your viewing pleasure.
>
> Tested on dbe62.

Looks nice.
Acked-by: Carl-Daniel Hailfinger

Ron, I trust you to make the right choice. You select the patch (yours
or mine) and commit it. I have almost no experience with dtc and
although I think I understand the simple parts of the device model, your
experience trumps mine in any case. (I don't have any emotional
attachment to my patch, it was born out of need.)

Oh, and any of your current and future dtc/dts changes for uniqueness,
collision avoidance and multiple links have my carte blanche. Feel free
to apply it anywhere if compile tested on qemu, geodelx and k8.
Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[Carl-Daniel Hailfinger]

On 05.09.2008 22:22, Carl-Daniel Hailfinger wrote:
> On 04.09.2008 18:04, ron minnich wrote:
> > no ack in it, for your viewing pleasure.
> >
> > Tested on dbe62.
>
> Looks nice.
> Acked-by: Carl-Daniel Hailfinger

It exploded with the current dts of the AMD Serengeti, though, and
produced this statictree.c excerpt:
> struct device dev_ioport_2e = {
>         .path = {{.type=DEVICE_PATH_IOPORT,{.ioport={.iobase=0x2e}}},

One opening bracket too many.
>     .device_configuration = &ioport_2e,
>     .next = &dev_domain_0,
>     .links = 0,
>     .bus = &dev_domain_0.link[0],
>     .next = &dev_domain_0,
>     .dtsname = "ioport_2e",
>     .enabled = 1
>
> };

Regards,
Carl-Daniel

[ron minnich]

On Fri, Sep 5, 2008 at 1:39 PM, Carl-Daniel Hailfinger
 wrote:
> On 05.09.2008 22:22, Carl-Daniel Hailfinger wrote:
> > On 04.09.2008 18:04, ron minnich wrote:
> > > no ack in it, for your viewing pleasure.
> > >
> > > Tested on dbe62.
> >
> > Looks nice.
> > Acked-by: Carl-Daniel Hailfinger
>
> It exploded with the current dts of the AMD Serengeti, though, and
> produced this statictree.c excerpt:
> > struct device dev_ioport_2e = {
> >         .path = {{.type=DEVICE_PATH_IOPORT,{.ioport={.iobase=0x2e}}},
>
> One opening bracket too many.
> >     .device_configuration = &ioport_2e,
> >     .next = &dev_domain_0,
> >     .links = 0,
> >     .bus = &dev_domain_0.link[0],
> >     .next = &dev_domain_0,
> >     .dtsname = "ioport_2e",
> >     .enabled = 1
> >
> > };
>
> Regards,
> Carl-Daniel

yeah my bad I fixed that.

ron

[Carl-Daniel Hailfinger]

On 05.09.2008 22:45, ron minnich wrote:
> On Fri, Sep 5, 2008 at 1:39 PM, Carl-Daniel Hailfinger
>  wrote:
> > On 05.09.2008 22:22, Carl-Daniel Hailfinger wrote:
> > > On 04.09.2008 18:04, ron minnich wrote:
> > > > no ack in it, for your viewing pleasure.
> > > >
> > > > Tested on dbe62.
> > >
> > > Looks nice.
> > > Acked-by: Carl-Daniel Hailfinger
> >
> > It exploded with the current dts of the AMD Serengeti, though, and
> > produced this statictree.c excerpt:
> > > struct device dev_ioport_2e = {
> > >         .path = {{.type=DEVICE_PATH_IOPORT,{.ioport={.iobase=0x2e}}},
> >
> > One opening bracket too many.
> > >     .device_configuration = &ioport_2e,
> > >     .next = &dev_domain_0,
> > >     .links = 0,
> > >     .bus = &dev_domain_0.link[0],
> > >     .next = &dev_domain_0,
> > >     .dtsname = "ioport_2e",
> > >     .enabled = 1
> > >
> > > };
> >
> > Regards,
> > Carl-Daniel
>
> yeah my bad I fixed that.

Oh, and another bug: The statictree.c code now refers to nonexisting
links. Look at this snippet:
struct device dev_root = {
        .path = { .type = DEVICE_PATH_ROOT },
        .next = &dev_cpu_0,
        .links = 0,
        .bus = &dev_root.link[0],
        .next = &dev_cpu_0,
        .ops = &default_dev_ops_root,
        .dtsname = "root",
        .enabled = 1
};
struct device dev_cpu_0 = {
        .path = {.type=DEVICE_PATH_CPU,{.cpu={ .id = 0x0 }}},
        .sibling = &dev_apic_0,
        .next = &dev_apic_0,
        .links = 0,
        .bus = &dev_root.link[0],   //DOES NOT EXIST
        .next = &dev_apic_0,
        .dtsname = "cpus",
        .enabled = 1
};

Maybe using my patch is really the better choice. I'll admit anytime
that my naming scheme is overly verbose and you're free to change it.

Regards,
Carl-Daniel

[ron minnich]

On Fri, Sep 5, 2008 at 7:57 PM, Carl-Daniel Hailfinger
 wrote:
> Maybe using my patch is really the better choice. I'll admit anytime
> that my naming scheme is overly verbose and you're free to change it.

go ahead and commit your patch and I'll work with it as is

ron