>>> Tejun Heo <htejun@xxxxxxxxx> 02/02/08 9:16 AM >>> >Jan Beulich wrote: >> Jeff, >> >> while I realize that Intel's documentation may not be consistent with >> anything more generic (which I don't know where to look for), this >> current behavior seems to contradict what Intel documents for ESB2: >> >> "23.3.1.4 PI – Ports Implemented Register (D31:F2) >> Address Offset: ABAR + 0Ch–0Fh Attribute: R/WO, RO >> Default Value: 00000000h Size: 32 bits >> >> This register indicates which ports are exposed to the Intel® >> 631xESB/632xESB I/O Controller Hub. It is loaded by platform BIOS. It >> indicates which ports that the device supports are available for >> software to use. For ports that are not available, software must not >> read or write to registers within that port." > >nr_ports is preferred over port_map when they disagree which shouldn't >happen in the first place. On some earlier ahcis, PI was cleared to >zero and lower nr_port number of ports should be used. The reason why >nr_ports is preferred over PI comes from similar place. Hardware/BIOSen >are more likely to get PI wrong than nr_ports, so... > >Do you have any real case where the above behavior causes problem? It's not strictly a problem (i.e. nothing really mis-behaves), but it made me wonder why the box I saw this on gets 6 ahci device instances set up when spec as well as port map say there ought to be only 5. After looking at the ESB2 spec it seemed that behavior was clearly violating the spec: "For ports that are not available, software must not read or write to registers within that port.", which contradicts status being displayed for (and therefore status being read) from the 6th (not present) port. Jan - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
