Following the conversion to managed devm_* APIs, update the driver to use
the PCI-specific managed APIs.

Use pcim_enable_device() to properly enable the PCI device and
pcim_request_region() to manage the I/O port region.

Switching to pcim_enable_device() also addresses the fact that
pci_disable_device() was  missing in the driver lifecycle, as the
managed API now automatically handles the disablement when the driver
unbinds.

Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Filippo Muscherà <filippo.muschera@gmail.com>
---
 drivers/i2c/busses/i2c-amd8111.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-amd8111.c b/drivers/i2c/busses/i2c-amd8111.c
index dd9ac4bb6704..3e8f7a59df51 100644
--- a/drivers/i2c/busses/i2c-amd8111.c
+++ b/drivers/i2c/busses/i2c-amd8111.c
@@ -427,6 +427,10 @@ static int amd8111_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	if (!(pci_resource_flags(dev, 0) & IORESOURCE_IO))
 		return -ENODEV;
 
+	error = pcim_enable_device(dev);
+	if (error)
+		return error;
+
 	smbus = devm_kzalloc(&dev->dev, sizeof(struct amd_smbus), GFP_KERNEL);
 	if (!smbus)
 		return -ENOMEM;
@@ -439,8 +443,9 @@ static int amd8111_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	if (error)
 		return -ENODEV;
 
-	if (!devm_request_region(&dev->dev, smbus->base, smbus->size, amd8111_driver.name))
-		return -EBUSY;
+	error = pcim_request_region(dev, 0, amd8111_driver.name);
+	if (error)
+		return error;
 
 	smbus->adapter.owner = THIS_MODULE;
 	snprintf(smbus->adapter.name, sizeof(smbus->adapter.name),
-- 
2.52.0

Hi Filippo,

On Tue, Feb 24, 2026 at 11:22:16AM +0100, Filippo Muscherà wrote:
> Following the conversion to managed devm_* APIs, update the driver to use
> the PCI-specific managed APIs.
> 
> Use pcim_enable_device() to properly enable the PCI device and
> pcim_request_region() to manage the I/O port region.
> 
> Switching to pcim_enable_device() also addresses the fact that
> pci_disable_device() was  missing in the driver lifecycle, as the
> managed API now automatically handles the disablement when the driver
> unbinds.
> 
> Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Filippo Muscherà <filippo.muschera@gmail.com>

Please, don't send a new patch as a in-reply-to to a different
patch. I personally don't like patches sent as reply to a
different thread, it makes my work as reviewer more difficult.

Said that, I would ask Jean to give an ack here.

Thanks,
Andi

On Tue, Feb 24, 2026 at 11:22:16AM +0100, Filippo Muscherà wrote:
> Following the conversion to managed devm_* APIs, update the driver to use
> the PCI-specific managed APIs.
> 
> Use pcim_enable_device() to properly enable the PCI device and
> pcim_request_region() to manage the I/O port region.
> 
> Switching to pcim_enable_device() also addresses the fact that
> pci_disable_device() was  missing in the driver lifecycle, as the
> managed API now automatically handles the disablement when the driver
> unbinds.

Looking at the code now I see the difference this patch may bring.
I was under impression that there is pci_enable_device() already in
the code. But it is not the case, which makes quite a different
enumeration flow (it will write CMD register and touch some bits
that might be sensitive). While the code looks okay and I can even
Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
the change needs to be tested on real hardware before going in.

...

>  	if (!(pci_resource_flags(dev, 0) & IORESOURCE_IO))
>  		return -ENODEV;

While it seems now being unneeded, I would leave this check in place until
somebody who knows the platform better can come up with a clear justification
for its removal. It also sounds aligned with the above remark. It might be
we can not do this patch at all.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Feb 24, 2026 at 12:38:13PM +0200, Andy Shevchenko wrote:
> Looking at the code now I see the difference this patch may bring.
> I was under impression that there is pci_enable_device() already in
> the code. But it is not the case, which makes quite a different
> enumeration flow (it will write CMD register and touch some bits
> that might be sensitive). While the code looks okay and I can even
> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com>
> the change needs to be tested on real hardware before going in.

Hi Andy,

Thanks for the review and the Acked-by.
Unfortunately I don't have access to an AMD8111 system to test if
pcim_enable_device() causes any regressions.

I completely see the point you're making now. I was focusing purely on
the API modernization and I didn't consider these legacy implications.

I leave it entirely up to you and the subsystem maintainers whether to
queue this patch for testing or just drop it to avoid any risks.

Best regards,
Filippo