On Thu, Jun 06, 2024 at 10:47:52PM +0300, Andy Shevchenko wrote: > On Thu, Jun 06, 2024 at 10:54:53AM -0500, Danny Kaehn wrote: > > On Thu, Jun 06, 2024 at 02:42:42AM +0300, Andy Shevchenko wrote: > > > On Wed, Jun 05, 2024 at 06:12:43PM -0500, Danny Kaehn wrote: > > ... > > > > > Changes in v11: > > > > - Eliminate 'gpio' subnode for DT and ACPI for the CP2112 per comment > > > > from Rob H. > > > > > > Hmm... I don't know much about DT, but how is this supposed to work in ACPI? > > > I mean if we want to refer to the GPIO in GpioIo() or GpioInt() resources, > > > what should we put there as ACPI path? > > > > What I tested was essentially taking what Benjamin had done in [1], just > > removing the "GPIO" device and combining it with the parent device (the > > CP2112 itself). So for the example below, I believe the path would be > > "\_SB_.PCI0.SE9_.RHUB.CP2_". If I get the chance (and can figure out how > > to do it using ACPI) I'll try to add a "gpio-keys" or something to the > > system using this path and make sure that works. > > This is counter intuitive and doesn't follow other (ACPI) devices with GPIO. > So whatever you do for DT I don't care much, but let's not remove subnode > for ACPI case. > Fair enough, will let this sit for a moment to see if there are comments from Rob/Krzysztof, and otherwise will rework the driver to support the different models for DT and ACPI. For what it's worth, combining the GPIO chip and CP2112 nodes in DT also seems unintuitive to me, and it seems there's other bindings for multi-function devices which define a separate child "gpio" node, so I'm not sure why it's not desired here. Thanks, Danny Kaehn
