> Date: Sun, 25 Jul 2021 12:29:21 +0100 > From: Stuart Henderson <s...@spacehopper.org> > > On 2021/07/25 13:25, Mark Kettenis wrote: > > > Date: Sun, 25 Jul 2021 12:08:09 +0100 > > > From: Stuart Henderson <s...@spacehopper.org> > > > > > > On 2021/07/25 14:55, Jonathan Matthew wrote: > > > > On Thu, Jul 22, 2021 at 10:45:17PM -0400, Ashton Fagg wrote: > > > > > I have two devices here based on the JMicron JMB585 chipset. This diff > > > > > adds the required pcidev IDs and sets disables native command queuing > > > > > in > > > > > the driver. FreeBSD does something similar for this device: > > > > > > > > > > https://github.com/freebsd/freebsd-src/commit/16b766eed443043f4216d50e40ba283e74f992c2 > > > > > > > > Can you explain how you came to the conclusion that you'd need to > > > > disable NCQ? The FreeBSD commit you link to doesn't appear to do that > > > > as they're not applying the AHCI_Q_NONCQ flag to these devices. > > > > Does it not work with NCQ enabled? > > > > > > > > > > That FreeBSD commit prevents using their "hw.ahci.force" tunable on the > > > device, it's used for attaching as AHCI to certain known chips even if > > > they're set in legacy IDE mode. > > > > > > Does it work to just add the vid/pid to the ahci_devices[] array > > > without a specific attach function? (like > > > PCI_PRODUCT_ASMEDIA_ASM1061_SATA). > > > > Hmm, that suggests that the right fix might actually be to add > > pciide(4) on riscv64. > > The FreeBSD commit is "do not allow hw.ahci.force to work with this > device" so kind-of the opposite of that.
Actually, the commit doesn't set the AHCI_Q_NOFORCE flag for this particular JMicron device, which seems to indicate that they do allow hw.ahci.force to work with this device. And that means that adding support for it in ahci(4) is fine (and given the 64-bit DMA issue, the most desirable option).
