Dear Albert ARIBAUD,
In message 4C84D13C.8040702@free.fr you wrote:
Er... no, it isn't. cmd_ide can support no more than two busses, the offsets of which are defined by CONFIG_SYS_ATA_IDE0_OFFSET, and optional CONFIG_SYS_ATA_IDE1_OFFSET if CONFIG_SYS_IDE_MAXBUS > 0 (note that these have _IDE in their names although they are not IDE per se).
So you cannot have more than two busses.
I see.
Moreover, the way it is done, if you want a third bus you have to modify cmd_ide.c to introduce CONFIG_SYS_ATA_IDE2_OFFSET, and once again later if you need a fourth one -- this does not scale well.
Agreed.
OTOH, my proposal to group offsets in CONFIG_SYS_ATA_IDE_OFFSETS ("IDE" kept in name to match the original CONFIG_SYS_ATA_IDEx_OFFSET names, but I can live without this "IDE") makes it scalable: the config option provides both the number of busses and their offsets, and the cmd_ide code would need no change to accomodate any number of busses.
I'm not sure about the IDE in the name (it's offset of IDE register structures, isn't it?), but that's not really important. I agree about the rest.
I meant that neither IDE or ATA standards restrict the maximum number of busses that can coexist in a given system; only the system designer can introduce such a limit.
OK.
I don't mean 'hack' in any negative way; what I mean is that restricting the number of devices to less than twice the number of busses is not mandated by any standard, and aims not at providing functionality but at reducing footprint.
Agreed.
- as for ide_bus_offset[] and ide_dev_desc[], and any other existing
array based on CONFIG_SYS_IDE_MAXBUS or CONFIG_SYS_IDE_MAXDEVICE, they are not going to grow any bigger with my proposal since neither config option will increase.
We might chnage this to dynamically allocated structures. maybe that would make more sense then?
Best regards,
Wolfgang Denk