[LinuxBIOS] Strange code in src/northbridge/via/vt8623/raminit.c ?

[Eric Poulsen]

While poking around trying to get VGA working, I did a grep for '3123', 
and I found this.  Notice how the variable 'north' is assigned to the 
result of the 'pci_locate_device' call, then immediately re-assigned to 
zero ... and then used.  Is this correct?

static void ddr_ram_setup(const struct mem_controller *ctrl)
{
  device_t north = (device_t) 0;
  uint8_t b, c, bank;
  uint16_t i,j;
  unsigned long bank_address;

print_debug("vt8623 init starting\r\n");
  north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
  north = 0;

pci_write_config8(north,0x75,0x08);

...

}

[LinuxBIOS] Strange code in src/northbridge/via/vt8623/raminit.c ?

[Stefan Reinauer]

* Eric Poulsen  [060424 22:37]:
> While poking around trying to get VGA working, I did a grep for '3123', 
> and I found this.  Notice how the variable 'north' is assigned to the 
> result of the 'pci_locate_device' call, then immediately re-assigned to 
> zero ... and then used.  Is this correct?

It will probably work because the northbridge usually sits on 0:0.0
> print_debug("vt8623 init starting\r\n");
>   north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
>   north = 0;

In the best case this wasts time and space.

Stefan.

[Ronald G Minnich]

Eric Poulsen wrote:
> While poking around trying to get VGA working, I did a grep for '3123', 
> and I found this.  Notice how the variable 'north' is assigned to the 
> result of the 'pci_locate_device' call, then immediately re-assigned to 
> zero ... and then used.  Is this correct?
>
> static void ddr_ram_setup(const struct mem_controller *ctrl)
> {
>   device_t north = (device_t) 0;
>   uint8_t b, c, bank;
>   uint16_t i,j;
>   unsigned long bank_address;
>
> print_debug("vt8623 init starting\r\n");
>   north = pci_locate_device(PCI_ID(0x1106, 0x3123), 0);
>   north = 0;
>
> pci_write_config8(north,0x75,0x08);
>
> ...
>
> }

yeah, it works but is gross. This is part of the overloading that goes 
on in the romcc side of the build step that makes me green.

Basically, in the romcc step, a device_t is a u32. So you're allowed to 
do something that in the gcc step is totally illegal, because device_t 
is this in gcc world:
typedef struct device * device_t;

so in romcc, device_t is a scalar, in gcc, a pointer, and via the magic 
of #ifdef and #define the
pci_x_y
stuff all returns the correct type.

The upside is you can compile most romcc code in gcc and it will work. 
The downside is that it gets confusing.

I'm guessing that hack was put in there because the same, or compatible, 
device has slightly different devids. It would be interesting to look at 
history and see when it happened. Basically romcc is so smart that it 
will optimize out the pci_locate_device anyway.

ron

[LinuxBIOS] Strange code in src/northbridge/via/vt8623/raminit.c ?

[Richard Smith]

> I'm guessing that hack was put in there because the same, or compatible,
> device has slightly different devids. It would be interesting to look at
> history and see when it happened. Basically romcc is so smart that it
> will optimize out the pci_locate_device anyway.

Why would you try and search for a northbridge anyway?  I though by
definition there is one located at 0:0.0.  Does the HT world and dual
channel stuff break that?

[Ronald G Minnich]

Richard Smith wrote:
> > I'm guessing that hack was put in there because the same, or compatible,
> > device has slightly different devids. It would be interesting to look at
> > history and see when it happened. Basically romcc is so smart that it
> > will optimize out the pci_locate_device anyway.
>
> Why would you try and search for a northbridge anyway?  I though by
> definition there is one located at 0:0.0.  Does the HT world and dual
> channel stuff break that?

there are cases where it is not, even going far back, to the Micron 
nortbridge that RLX used. It's good hygiene to look for it.

ron