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