CVS commit: [netbsd-11] src/sys/dev
"Martin Husemann" <[email protected]> Sun, 2 Aug 2026 13:39:14 +0000
| Newsgroups | gmane.os.netbsd.devel.cvs |
|---|---|
| Message-ID | <[email protected]> |
Module Name: src Committed By: martin Date: Sun Aug 2 13:39:13 UTC 2026 Modified Files: src/sys/dev/ic [netbsd-11]: isp_netbsd.h src/sys/dev/pci [netbsd-11]: isp_pci.c Log Message: Pull up following revision(s) (requested by thorpej in ticket #403): sys/dev/pci/isp_pci.c: revision 1.123 sys/dev/ic/isp_netbsd.h: revision 1.77 It has been observed in the wild that some individual instances of ISP10[24]0 controllers don't seem to like getting a 64-bit DMA address from our driver (at least, there seems to be some sort of incorrect handling vis a vis the RQSTYPE_A64 message in isp_intr()). Upon inspection, it was noted that in isp_pci_dmasetup(), the decision to use RQSTYPE_T3RQS vs RQSTYPE_T2RQS was conditional on sizeof(bus_addr_t) being larger than sizeof(uint32_t). However, this isn't the correct predicate; instead, the choice should be dependent on what the largest value that bus_addr_t will have. As it happans, the PCI layer makes a distinction between 32-bit and 64-bit DMA windows, and isp_pci's use of the regular "pa->pa_dmat" would ensure that the DMA address always fits within 32-bits. Therefore, there was never a reason to use RQSTYPE_T3RQS, regardless of the size of bus_addr_t. As such, we tweak the code to depend explicitly on a new isp_use_dma64 flag, which is initialized by the bus front-end according to the DMA window selection that's been made. Along those lines, add code to correctly determine if a 64-bit DMA window should be used, but leave it disabled for now, until we can sort out the issue with RQSTYPE_A64. To generate a diff of this commit: cvs rdiff -u -r1.76 -r1.76.34.1 src/sys/dev/ic/isp_netbsd.h cvs rdiff -u -r1.122 -r1.122.34.1 src/sys/dev/pci/isp_pci.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.