All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kaehn <kaehndan@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	jikos@kernel.org, benjamin.tissoires@redhat.com,
	bartosz.golaszewski@linaro.org, dmitry.torokhov@gmail.com,
	devicetree@vger.kernel.org, linux-input@vger.kernel.org,
	ethan.twardy@plexus.com
Subject: Re: [PATCH v8 3/3] HID: cp2112: Fwnode Support
Date: Tue, 28 Feb 2023 13:05:54 -0600	[thread overview]
Message-ID: <CAP+ZCCe=f3AtxvC1Z6zPErMEG9BcnCOjApc26n_9yjq2+U72pw@mail.gmail.com> (raw)
In-Reply-To: <Y/03to4XFXPwkGH1@smile.fi.intel.com>

On Mon, Feb 27, 2023 at 5:07 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Mon, Feb 27, 2023 at 08:07:58AM -0600, Danny Kaehn wrote:
> > Bind I2C and GPIO interfaces to subnodes with names
> > "i2c" and "gpio" if they exist, respectively. This
> > allows the GPIO and I2C controllers to be described
> > in firmware as usual. Additionally, support configuring the
> > I2C bus speed from the clock-frequency device property.
>
> A bit shorten indentation...
>
> Nevertheless what I realized now is that this change, despite being OF
> independent by used APIs, still OF-only.

I assumed this would practically be the case -- not because of the casing
reason you gave (wasn't aware of that, thanks for the FYI), but because it
doesn't seem that there's any way to describe USB devices connected to
a USB port in ACPI, at least as far as I can tell (ACPI is still largely a black
box to me). But it seems reasonable that we should try to use the interface
in a way so that it could be described using ACPI at some point (assuming
that it isn't currently possible).

>
> Would it be possible to allow indexed access to child nodes as well, so if
> there are no names, we may still be able to use firmware nodes from the correct
> children?
>

Sure, you mean to fallback to using child nodes by index rather than by name
in the case that that device_get_named_child_node() fails?
Would we need to somehow verify that those nodes are the nodes we expect
them to be? (a.e. node 0 is actually the i2c-controller, node 1 is actually the
gpio-controller).

I don't see a reason why not, though I am curious if there is
precedence for this
strategy, a.e. in other drivers that use named child nodes. In my initial search
through the kernel, I don't think I found anything like this -- does that mean
those drivers also inherently won't work with ACPI?

The only driver I can find which uses device_get_named_child_node and has
an acpi_device_id is drivers/platform/x86/intel/chtwc_int33fe.c

> P.S. The problem with ACPI is that "name" of the child node will be in capital
> letters as it's in accordance with the specification.
>

Knowing that this is the limitation, some other potential resolutions
to potentially
consider might be:

- Uppercase the names of the child nodes for the DT binding -- it appears that
     the child node that chtwc_int33fe.c (the driver mentioned earlier) accesses
     does indeed have an upper-cased name -- though that driver doesn't have
     an of_device_id (makes sense, x86...). It seems named child nodes are
     always lowercase in DT bindings -- not sure if that's a rule, or
just how it
     currently happens to be.
- Do a case invariant compare on the names (and/or check for both lowercase
     and uppercase)
- Remove the use of child nodes, and combine the i2c and gpio nodes into the
    cp2112's fwnode. I didn't do this initially because I wanted to
avoid namespace
    collisions between GPIO hogs and i2c child devices, and thought
that logically
     made sense to keep them separate, but that was before knowing
this limitation
    of ACPI.

What are your / others' thoughts?

Thanks,

Danny Kaehn


> --
> With Best Regards,
> Andy Shevchenko
>
>

  reply	other threads:[~2023-02-28 19:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 14:07 [PATCH v8 0/3] Firmware Support for USB-HID Devices and CP2112 Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 2/3] HID: usbhid: Share USB device firmware node with child HID device Danny Kaehn
2023-02-27 14:07 ` [PATCH v8 3/3] HID: cp2112: Fwnode Support Danny Kaehn
2023-02-27 23:07   ` Andy Shevchenko
2023-02-28 19:05     ` Daniel Kaehn [this message]
2023-03-01 14:59       ` Andy Shevchenko
2023-03-01 15:04         ` Andy Shevchenko
2023-03-02 17:06         ` Benjamin Tissoires
2023-03-06 10:49           ` Andy Shevchenko
2023-03-06 12:36             ` Benjamin Tissoires
2023-03-06 13:07               ` Andy Shevchenko
2023-03-06 14:48                 ` Benjamin Tissoires
2023-03-06 17:01                   ` Andy Shevchenko
2023-03-06 19:40                     ` Daniel Kaehn
2023-03-06 20:36                       ` Andy Shevchenko
2023-03-07 13:17                         ` Benjamin Tissoires
2023-03-07 13:53                           ` Daniel Kaehn
2023-03-07 14:48                             ` Benjamin Tissoires
2023-03-07 18:18                               ` Andy Shevchenko
2023-03-08 15:26                                 ` Benjamin Tissoires
2023-03-08 15:37                                   ` Daniel Kaehn
2023-03-08 15:55                                     ` Benjamin Tissoires
2023-03-08 16:30                                       ` Andy Shevchenko
2023-03-08 16:36                                         ` Andy Shevchenko
2023-03-08 18:32                                           ` Daniel Kaehn
2023-03-09 11:43                                             ` Andy Shevchenko
2023-03-09 11:56                                               ` Andy Shevchenko
2023-03-09  9:38                                         ` Benjamin Tissoires
2023-03-09 13:50                                           ` Andy Shevchenko
2023-03-08 16:20                                   ` Andy Shevchenko
2023-03-07 18:15                             ` Andy Shevchenko
2023-03-07 18:14                           ` Andy Shevchenko
2023-03-07 19:57                             ` Daniel Kaehn
2023-03-08 12:41                               ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP+ZCCe=f3AtxvC1Z6zPErMEG9BcnCOjApc26n_9yjq2+U72pw@mail.gmail.com' \
    --to=kaehndan@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=ethan.twardy@plexus.com \
    --cc=jikos@kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.