No longer exporting _len(); seems we do not need that publicly.
Add a bool option to alloc the ie space which we may need for
other uses (such as LinuxKPI).
Cleanup.

Looks ok to me; Do we assume that no kmods from port would still use this?

In general looks ok to me; didn't entirely review it. "Glanced-at-by: bz"

Oki doki. Continue as you want. "Glanced-at-by: bz"

I haven't fully checked all cases but in general LGTM.

Thanks for pointing this out!

I am not sure I like the idea of making jid's a first-class citizen just because our mgmt interface once did and we kept it for historic purpose and backward compat and habits are hard to change.

Use 0/1 instead of false/true for the IS_*() macros so that prepocessor
directives (#if) are more happy.

@hselasky I think the only way to avoid this problem in the future is to audit Makefiles for everything and then insist on all of the option being defined and then I'd be happy to come back to your suggestion and enforce it.

Thanks @hselasky . Can you clarify on this one a bit more?

Thanks @markj ! Does it look good now?

Address comments from @markj.
Bump .Dd date in man page to tomorrow.

Anyone any last comments; I'd love to commit this before Monday.

Anyone any last comments; I'd love to commit this before Monday.

Anyone any last comments; I'd love to commit this before Monday.

Anyone any last comments; I'd love to commit this before Monday.

Moved devres framework and k*alloc release function into its own implementation
file as requested. For now leave headers as they are; may reconsider when
bringing in more devres consumers.

In addition to firmware changes, also the PCI and devres changes
got factored out into the respective child reviews now.

In D26598#629837, @manu wrote:

TBH this is to big for me to review, if you could split the review based on the commits (as I hope you didn't commit this whole thing in one commit) that would be easier to review.

@manu works for Intel.

Changes since last:

• add request_firmware_direct() needed by DRM.

Changes since the last one:

• I hope I addressed all comments some way
• firmware changes are in D27414 now (update in a few minutes)
• Cleaned up some PCI bits migrated more parts into lkpifill_pci_dev()
• That plus a dev release function allows DRM to also work with "dev/kobj" magic and get the proper cleanup; the current code is still a short-cut but one I think we can live with. pci_dev_put() seems to do the right thing and I can still unload i915kms.ko.
• Implemented the devres bits we need for devm_k*alloc() and devm_kasprintf() and the DRM parts (I do have more devres cleanup in my local tree but that's unrelated to DRM so will come later to keep this one smaller).

@manu, did we come to the conclusion last year that currently doing this all natively was not always working and we are going with this one as the next (first) step? I'd love to commit this as soon as firmware(9) changes are in and D26598 is updated and accepted, so that we don't have to update DRM ports too often.

Update reveting the check @markj pointed out.
Also updating date of man page for tomorrow.

I'll get @markj's request in. Anything else as I'd like to commit it the next days (once I have all my workspaces and branches over to main).

In theory I like this change. Can you please upload it with full context either using arc or if doing diff file upload using -U10000?

I think it might help the discussion to update the review here to the latest version?

Looks ok to me; I don't particularly like the special cases but it seems fine.

Looks good scrolling through now.

I haven't tested it but this looks good, and thank you for harmonising the alloc! Much appreciated!
I think you may want to wait for @hselasky or @kib for the mlx[45] changes as well. (I mention as neither of them is a linuxkpi member yet from what I can see).

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.

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.

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

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]?

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...

In D27434#612902, @hselasky wrote:

The order of the enumeration list doesn't matter. It is exported to user-space as strings.

I am not sure if I can sort the new quirk type into the middle of the enum list or if I should rather add it to the end?