linuxkpi: pci check for resource disabled to avoid probing

[bz]

Summary

There are cases when drivers misbehave or one simply does
not want a driver to probe in first place (maybe because there
is a 2nd driver).
Check for resource_disabled() in linux_pci_probe() and return
ENXIO to avoid successful probing in case hints are specified
to disable that driver/unit combination.

MFC after: 1 week

[emaste]

Seems sensible to me

[imp]

compat/linuxkpi/common/src/linux_pci.c

218

This needs to be in attach, not probe.
We claim this device, but don't then don't proceed to attach the driver is what disabled means.
Though device_attach() should just do the right thing.
Otherwise it will reject all the devices which is wrong too...

[imp]

The reason it needs to be in attach, and not probe, is that we set the device to the next available unit in probe. If we reject this device, the unit isn't consumed so the next time we have a device with the same name / unit we'll reject it too and never claim any. This makes it hard to disable only the first one, for example...

[bz]

In D27436#613059, @imp wrote:

The reason it needs to be in attach, and not probe, is that we set the device to the next available unit in probe. If we reject this device, the unit isn't consumed so the next time we have a device with the same name / unit we'll reject it too and never claim any. This makes it hard to disable only the first one, for example...

That's a good reason (we do similar in probe/identify elsewhere so maybe need to have a look or those are special 1-attachment-ever-only).

The problem I was trying to solve was "I don't want this driver to attach but the other one".

Do we have any way of doing that user-controlled (and not by probe priority as that's not user controlled and you cannot just toggle left or right) [when you need both drivers attached to different devices]?

[emaste]

we do similar in probe/identify elsewhere so maybe need to have a look

Yeah, I looked at other probe cases so we should take a holistic look.

[bz]

Do we have any way of doing that user-controlled (and not by probe priority as that's not user controlled and you cannot just toggle left or right) [when you need both drivers attached to different devices]?

Something like devctl detach/attach would work if one can live with the original driver attaching.

pptdevs -ish might also work; probably would have to do the logic based on that and then against device_get_name()? Something like that?

[bz]

The topic has shifted so shift audience a bit as well.

[imp]

In D27436#613103, @bz wrote:

In D27436#613059, @imp wrote:

The reason it needs to be in attach, and not probe, is that we set the device to the next available unit in probe. If we reject this device, the unit isn't consumed so the next time we have a device with the same name / unit we'll reject it too and never claim any. This makes it hard to disable only the first one, for example...

That's a good reason (we do similar in probe/identify elsewhere so maybe need to have a look or those are special 1-attachment-ever-only).

The problem I was trying to solve was "I don't want this driver to attach but the other one".

Do we have any way of doing that user-controlled (and not by probe priority as that's not user controlled and you cannot just toggle left or right) [when you need both drivers attached to different devices]?

So why do you need that? This hasn't come up in 20 odd years, so we should understand why first...

We've never provided anything like that, nor has it been needed... so I'd like to understand the use case.

devctl can do it after the fact, of course...

I wrote something that lets you change the PNP info for a device to allow it to masquerade as an old device. But never completely fixed it...

But you are asking for something new. Something drivers should know nothing about. You are asking really for the ability to tie a device to a driver in some way. There are many issues with this since most drivers can only attach to specific cards.

[bz]

So why do you need that? This hasn't come up in 20 odd years, so we should understand why first...

We've never provided anything like that, nor has it been needed... so I'd like to understand the use case.

devctl can do it after the fact, of course...

I wrote something that lets you change the PNP info for a device to allow it to masquerade as an old device. But never completely fixed it...

But you are asking for something new. Something drivers should know nothing about. You are asking really for the ability to tie a device to a driver in some way. There are many issues with this since most drivers can only attach to specific cards.

Yes, I have two drivers which both can attach to cards; one can attach to old and new ones, the other only to old ones. I need the new one on the new card and the new or the old one on the old card.

Given this seems to be something very specific apparently, I'll hack myself a local solution I can live with for the time being and let this one go unless you'd be interested in further investigating. Let me know and I'll keep this open or abandon it.

[imp]

In D27436#613320, @bz wrote:

So why do you need that? This hasn't come up in 20 odd years, so we should understand why first...

We've never provided anything like that, nor has it been needed... so I'd like to understand the use case.

devctl can do it after the fact, of course...

I wrote something that lets you change the PNP info for a device to allow it to masquerade as an old device. But never completely fixed it...

But you are asking for something new. Something drivers should know nothing about. You are asking really for the ability to tie a device to a driver in some way. There are many issues with this since most drivers can only attach to specific cards.

Yes, I have two drivers which both can attach to cards; one can attach to old and new ones, the other only to old ones. I need the new one on the new card and the new or the old one on the old card.

Hmmm, that's a different thing than I thought you were asking... which sounded more like macOS' bind the driver in userland which would take a lot of work, imho, to get right.

The typical thing that's done is for the old driver to return a smaller number than the new driver so the new driver is preferred on new cards, but the old driver or the new driver can attach to the old cards (the old driver when the new one isn't loaded, the new one preferentially). devctl rescan will let you rescan the device if the wrong driver is attached. But this probe routine always returns '0' which means 'take it no matter what and disable further probing' which isn't what you want in this case (though normally it's fine).

If you'd like to control that administratively, w/o devctl, then we're in uncharted territory (though the current disabled stuff should work w/o this change).

Given this seems to be something very specific apparently, I'll hack myself a local solution I can live with for the time being and let this one go unless you'd be interested in further investigating. Let me know and I'll keep this open or abandon it.

I'd love to help you solve your problem, so let me know what you think of these suggestions.

[jhb]

We have this situation today btw with mfi(4) and mrsas(4) where they both support some of the same adapters. mrsas(4) is preferred by default via the return value from it's probe routine, but I think you can set a driver-specific tunable to prefer mfi(4) instead. That is probably the right way to handle the case Bjoern described rather than this change. I agree with Warner that this sort of change in probe is not going to work in a way that is useful. It seems what you want is to disable a driver, but the disabled hints disable specific devices.

[bz]

While we should review the drivers doing this thing in probe requests, I'll go with the tunable, which sounds fine to me for now.
Thanks a lot for the discussion.