Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master
driver can be probed on AMD platforms.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
---
drivers/i3c/master/dw-i3c-master.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
index 8d694672c110..1a7c300b6d45 100644
--- a/drivers/i3c/master/dw-i3c-master.c
+++ b/drivers/i3c/master/dw-i3c-master.c
@@ -1748,12 +1748,19 @@ static const struct of_device_id dw_i3c_master_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match);
+static const struct acpi_device_id amd_i3c_device_match[] = {
+ { "AMDI0015" },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match);
+
static struct platform_driver dw_i3c_driver = {
.probe = dw_i3c_probe,
.remove_new = dw_i3c_remove,
.driver = {
.name = "dw-i3c-master",
.of_match_table = dw_i3c_master_of_match,
+ .acpi_match_table = amd_i3c_device_match,
.pm = &dw_i3c_pm_ops,
},
};
--
2.34.1
On 11/8/24 9:33 AM, Shyam Sundar S K wrote: > Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master > driver can be probed on AMD platforms. > > Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> > --- > drivers/i3c/master/dw-i3c-master.c | 7 +++++++ > 1 file changed, 7 insertions(+) > Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Hi On 11/8/24 9:33 AM, Shyam Sundar S K wrote: > Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master > driver can be probed on AMD platforms. > > Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> > --- > drivers/i3c/master/dw-i3c-master.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c > index 8d694672c110..1a7c300b6d45 100644 > --- a/drivers/i3c/master/dw-i3c-master.c > +++ b/drivers/i3c/master/dw-i3c-master.c > @@ -1748,12 +1748,19 @@ static const struct of_device_id dw_i3c_master_of_match[] = { > }; > MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match); > > +static const struct acpi_device_id amd_i3c_device_match[] = { > + { "AMDI0015" }, > + { } > +}; > +MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match); > + > static struct platform_driver dw_i3c_driver = { > .probe = dw_i3c_probe, > .remove_new = dw_i3c_remove, > .driver = { > .name = "dw-i3c-master", > .of_match_table = dw_i3c_master_of_match, > + .acpi_match_table = amd_i3c_device_match, > .pm = &dw_i3c_pm_ops, > }, > }; Am I right this and patch 5/5 can be independent from rest of the series? To me it looks these two patches enable bus communication and thus be useful without rest of the series while latter need more discussion (I'll have some notes coming) and Cc'ing linux-acpi.
Hi Jarkko, On 11/12/2024 13:46, Jarkko Nikula wrote: > Hi > > On 11/8/24 9:33 AM, Shyam Sundar S K wrote: >> Add AMDI0015 _HID for Designware I3C driver so that the dw-i3c-master >> driver can be probed on AMD platforms. >> >> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> >> --- >> drivers/i3c/master/dw-i3c-master.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/i3c/master/dw-i3c-master.c >> b/drivers/i3c/master/dw-i3c-master.c >> index 8d694672c110..1a7c300b6d45 100644 >> --- a/drivers/i3c/master/dw-i3c-master.c >> +++ b/drivers/i3c/master/dw-i3c-master.c >> @@ -1748,12 +1748,19 @@ static const struct of_device_id >> dw_i3c_master_of_match[] = { >> }; >> MODULE_DEVICE_TABLE(of, dw_i3c_master_of_match); >> +static const struct acpi_device_id amd_i3c_device_match[] = { >> + { "AMDI0015" }, >> + { } >> +}; >> +MODULE_DEVICE_TABLE(acpi, amd_i3c_device_match); >> + >> static struct platform_driver dw_i3c_driver = { >> .probe = dw_i3c_probe, >> .remove_new = dw_i3c_remove, >> .driver = { >> .name = "dw-i3c-master", >> .of_match_table = dw_i3c_master_of_match, >> + .acpi_match_table = amd_i3c_device_match, >> .pm = &dw_i3c_pm_ops, >> }, >> }; > > Am I right this and patch 5/5 can be independent from rest of the series? Right. 1/5 and 5/5 can be grouped. But rest of the other patches are equally important because they drive the usecase. > > To me it looks these two patches enable bus communication and thus be > useful without rest of the series while latter need more discussion > (I'll have some notes coming) and Cc'ing linux-acpi. I have Cc'ed linux-acpi in this revision. Do you have any feedback for patches 2-4 ? Thanks, Shyam
Hi On 11/12/24 10:48 AM, Shyam Sundar S K wrote: >> Am I right this and patch 5/5 can be independent from rest of the series? > > Right. 1/5 and 5/5 can be grouped. But rest of the other patches are > equally important because they drive the usecase. > >> >> To me it looks these two patches enable bus communication and thus be >> useful without rest of the series while latter need more discussion >> (I'll have some notes coming) and Cc'ing linux-acpi. > > I have Cc'ed linux-acpi in this revision. Do you have any feedback for > patches 2-4 ? > Yes, I'm reviewing them and only the patch 2/5 was Cc'ed to linux-acpi. Patchset split would serve better in my opinion enabling basic communication and have an other set concentrating more complex scenario we were try to get input from ACPI folks.
On 11/12/2024 15:18, Jarkko Nikula wrote: > Hi > > On 11/12/24 10:48 AM, Shyam Sundar S K wrote: >>> Am I right this and patch 5/5 can be independent from rest of the >>> series? >> >> Right. 1/5 and 5/5 can be grouped. But rest of the other patches are >> equally important because they drive the usecase. >> >>> >>> To me it looks these two patches enable bus communication and thus be >>> useful without rest of the series while latter need more discussion >>> (I'll have some notes coming) and Cc'ing linux-acpi. >> >> I have Cc'ed linux-acpi in this revision. Do you have any feedback for >> patches 2-4 ? >> > Yes, I'm reviewing them and only the patch 2/5 was Cc'ed to linux-acpi. > > Patchset split would serve better in my opinion enabling basic > communication and have an other set concentrating more complex > scenario we were try to get input from ACPI folks. Ok. I can copy the linux-apci for patches from 2-4 after your feedback on the current series. Can atleast patches 1/5 and 5/5 be independently applied for -next so they we don't miss out this cycle? Thanks, Shyam
© 2016 - 2024 Red Hat, Inc.