Add ACPI ID for DWAPB I2C controller on Sophgo SG2044 so
the SoC can enumerated the device via ACPI.

Signed-off-by: Inochi Amaoto <inochiama@gmail.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index d6e1ee935399..46b2b972f679 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -360,6 +360,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
 	{ "INT3432", 0 },
 	{ "INT3433", 0 },
 	{ "INTC10EF", 0 },
+	{ "SOPHO003", 0 },
 	{}
 };
 MODULE_DEVICE_TABLE(acpi, dw_i2c_acpi_match);
-- 
2.48.1

On Tue, Mar 04, 2025 at 03:02:11PM +0800, Inochi Amaoto wrote:
> Add ACPI ID for DWAPB I2C controller on Sophgo SG2044 so
> the SoC can enumerated the device via ACPI.

Same as per UART:

---8<---

This is fake ACPI ID. Please work with a vendor to issue the proper one.
Vendor ACPI ID registry has no records on Sophgo:
https://uefi.org/ACPI_ID_List?acpi_search=SophGo

NAK.

---8<---

But, it might be that is already in the process of getting proper ACPI vendor
ID, please provide an evidence in such a case.

Otherwise drag the representative of the vendor to this email thread to answer
the question why the heck they abuse ACPI specification.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Mar 04, 2025 at 01:43:27PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 04, 2025 at 03:02:11PM +0800, Inochi Amaoto wrote:
> > Add ACPI ID for DWAPB I2C controller on Sophgo SG2044 so
> > the SoC can enumerated the device via ACPI.
> 
> Same as per UART:
> 
> ---8<---
> 
> This is fake ACPI ID. Please work with a vendor to issue the proper one.
> Vendor ACPI ID registry has no records on Sophgo:
> https://uefi.org/ACPI_ID_List?acpi_search=SophGo
> 
> NAK.
> 
> ---8<---
> 
> But, it might be that is already in the process of getting proper ACPI vendor
> ID, please provide an evidence in such a case.

Looking even closer to the ID, it is completely bogus as it uses CAPITAL O
instead of 0 in device ID part.

> Otherwise drag the representative of the vendor to this email thread to answer
> the question why the heck they abuse ACPI specification.

So, go and work with the vendor to fix their misunderstanding of ACPI and tell
them that they are free to contact me for the details. I will glad to help them
to make right things right.

Also read this success story of similar case:
https://andy-shev.dreamwidth.org/151340.html
and feel free to share with the vendor.

-- 
With Best Regards,
Andy Shevchenko

On Tue, Mar 04, 2025 at 01:43:27PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 04, 2025 at 03:02:11PM +0800, Inochi Amaoto wrote:
> > Add ACPI ID for DWAPB I2C controller on Sophgo SG2044 so
> > the SoC can enumerated the device via ACPI.
> 
> Same as per UART:
> 
> ---8<---
> 
> This is fake ACPI ID. Please work with a vendor to issue the proper one.
> Vendor ACPI ID registry has no records on Sophgo:
> https://uefi.org/ACPI_ID_List?acpi_search=SophGo
> 
> NAK.
> 
> ---8<---
> 
> But, it might be that is already in the process of getting proper ACPI vendor
> ID, please provide an evidence in such a case.
> 
> Otherwise drag the representative of the vendor to this email thread to answer
> the question why the heck they abuse ACPI specification.
> 

OK, I will ask for the vendor and check whether there is some
evidence for it. Now let's pause these patch.

Thanks for your info.

Regards,
Inochi.

On Tue, Mar 04, 2025 at 07:46:09PM +0800, Inochi Amaoto wrote:
> On Tue, Mar 04, 2025 at 01:43:27PM +0200, Andy Shevchenko wrote:
> > On Tue, Mar 04, 2025 at 03:02:11PM +0800, Inochi Amaoto wrote:
> > > Add ACPI ID for DWAPB I2C controller on Sophgo SG2044 so
> > > the SoC can enumerated the device via ACPI.
> > 
> > Same as per UART:
> > 
> > ---8<---
> > 
> > This is fake ACPI ID. Please work with a vendor to issue the proper one.
> > Vendor ACPI ID registry has no records on Sophgo:
> > https://uefi.org/ACPI_ID_List?acpi_search=SophGo
> > 
> > NAK.
> > 
> > ---8<---
> > 
> > But, it might be that is already in the process of getting proper ACPI vendor
> > ID, please provide an evidence in such a case.
> > 
> > Otherwise drag the representative of the vendor to this email thread to answer
> > the question why the heck they abuse ACPI specification.
> 
> OK, I will ask for the vendor and check whether there is some
> evidence for it. Now let's pause these patch.
> 
> Thanks for your info.

You're welcome! As I already replied in another mail, feel free to contact me
or give my contacts to the vendor in order to help them to follow the process.
I will be glad to help.

-- 
With Best Regards,
Andy Shevchenko