uart/pci: use different probe return values

[royger]

Summary

For PCI devices listed in pci_ns8250_ids return BUS_PROBE_SPECIFIC, while
for generic UART devices not explicitly listed in pci_ns8250_ids return
BUS_PROBE_GENERIC. This allows more specific drivers to take over those
devices, and the generic UART PCI driver will only be used as a fallback.

This fixes an issue where the UART PCI driver would attach to multiport PCI
UART devices, that instead need to use the puc(4) driver to multiplex the
device.

Reported by: markj
Sponsored by: Citrix Systems R&D

[markj]

This fixes my problem, but if my device wasn't in the puc(4) device table, uart(4) would still try to attach to it and trigger the hang. So, there might still be some problem with the original change. Certainly this is incrementally better, so it's okay with me.

sys/dev/uart/uart_bus_pci.c

289

295

[royger]

In D56467#1292553, @markj wrote:

This fixes my problem, but if my device wasn't in the puc(4) device table, uart(4) would still try to attach to it and trigger the hang. So, there might still be some problem with the original change. Certainly this is incrementally better, so it's okay with me.

Yeah, puc(4) should likely be expanded to take over any generic PCI UART device with multiple ports? I think it was already broken before my change, as uart(4) would already take over multiport PCIP_SIMPLECOMM_UART_16450A devices. My change expanded that (wrong) behavior to PCIP_SIMPLECOMM_UART_16550A devices also.

Maybe someone more familiar with the PCI serial stuff can provide some guidance whether the puc(4) driver could be made to attach to generic multiport cards? I certainly don't know how to detect those from the PCI config space fields.

[markj]

In D56467#1292560, @royger wrote:

In D56467#1292553, @markj wrote:

This fixes my problem, but if my device wasn't in the puc(4) device table, uart(4) would still try to attach to it and trigger the hang. So, there might still be some problem with the original change. Certainly this is incrementally better, so it's okay with me.

Yeah, puc(4) should likely be expanded to take over any generic PCI UART device with multiple ports? I think it was already broken before my change, as uart(4) would already take over multiport PCIP_SIMPLECOMM_UART_16450A devices. My change expanded that (wrong) behavior to PCIP_SIMPLECOMM_UART_16550A devices also.

Maybe someone more familiar with the PCI serial stuff can provide some guidance whether the puc(4) driver could be made to attach to generic multiport cards? I certainly don't know how to detect those from the PCI config space fields.

Digging a bit, I don't think there's a generic way to detect them. So I'm not sure we can do better.

[royger]

I will hold off committing this until the evening (a couple of hours from now), in case there's further feedback. Otherwise I don't want to keep your setup broken. We can always revert later on if we find a better approach.

[imp]

In D56467#1292563, @markj wrote:

In D56467#1292560, @royger wrote:

In D56467#1292553, @markj wrote:

This fixes my problem, but if my device wasn't in the puc(4) device table, uart(4) would still try to attach to it and trigger the hang. So, there might still be some problem with the original change. Certainly this is incrementally better, so it's okay with me.

Yeah, puc(4) should likely be expanded to take over any generic PCI UART device with multiple ports? I think it was already broken before my change, as uart(4) would already take over multiport PCIP_SIMPLECOMM_UART_16450A devices. My change expanded that (wrong) behavior to PCIP_SIMPLECOMM_UART_16550A devices also.

Maybe someone more familiar with the PCI serial stuff can provide some guidance whether the puc(4) driver could be made to attach to generic multiport cards? I certainly don't know how to detect those from the PCI config space fields.

Digging a bit, I don't think there's a generic way to detect them. So I'm not sure we can do better.

There's no way to do it generically, hence the puc table. At best you can do is single ports, but even then the divisor issue makes many of them not work.