Re: [PATCH 6/7] samples/devsec: Introduce a "Device Security TSM" sample driver

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Aug 26, 2025 at 08:52:58PM -0700, Dan Williams wrote:
> +static int devsec_pci_probe(struct pci_dev *pdev,
> +			    const struct pci_device_id *id)
> +{
> +	void __iomem *base;
> +	int rc;
> +
> +	rc = pcim_enable_device(pdev);
> +	if (rc)
> +		return dev_err_probe(&pdev->dev, rc, "enable failed\n");
> +
> +	base = pcim_iomap_region(pdev, 0, KBUILD_MODNAME);
> +	if (IS_ERR(base))
> +		return dev_err_probe(&pdev->dev, PTR_ERR(base),
> +				     "iomap failed\n");
> +
> +	rc = device_cc_probe(&pdev->dev);
> +	if (rc)
> +		return rc;

I really don't understand what the proposal is here?

device_cc_probe() doesn't save anything, doesn't this just get into an
endless loop of EPROBE_DEFER? Usually the kernel will retry these
things during booting?

How does userspace accept through the sysfs retrigger probing?

As we discussed in the prior chain we need to have a policy decision
before auto-binding drivers at all in a CC environment, I don't see
that in the code though the cover letter talked about it??

How does the kernel/userspace tell the difference between drivers that
want this early binding and those that don't?

Can you write out the whole flow from a userspace perspective in one
of the commit messages?

This also disables BME, we talked about that a lot, the commit
messages didn't seem to describe what solution was settled on here?

Jason