All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Danny Kaehn <danny.kaehn@plexus.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Benjamin Tissoires <bentiss@kernel.org>,
	Andi Shyti <andi.shyti@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jiri Kosina <jikos@kernel.org>,
	devicetree@vger.kernel.org, linux-input@vger.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Ethan Twardy <ethan.twardy@plexus.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
	Leo Huang <leohu@nvidia.com>, Arun D Patil <arundp@nvidia.com>,
	Willie Thai <wthai@nvidia.com>,
	Ting-Kai Chen <tingkaic@nvidia.com>
Subject: Re: [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge
Date: Wed, 28 Jan 2026 18:05:53 +0200	[thread overview]
Message-ID: <aXoz4Xs8csdxXeZU@smile.fi.intel.com> (raw)
In-Reply-To: <3db84b61-e463-4362-b142-59d3ca6eae90@kernel.org>

On Wed, Jan 28, 2026 at 04:48:18PM +0100, Krzysztof Kozlowski wrote:
> On 28/01/2026 13:49, Andy Shevchenko wrote:
> > On Wed, Jan 28, 2026 at 11:35:25AM +0100, Krzysztof Kozlowski wrote:
> >> On Tue, Jan 27, 2026 at 10:02:17AM -0600, Danny Kaehn wrote:

...

> >> That's actually rule communicated many times, also documented in writing
> >> bindings and in recent talks.
> > 
> > Does DT represents HW in this case? Shouldn't I²C controller be the same node?
> > Why not? This is inconsistent for the device that is multi-functional. And from
> > my understanding the firmware description (DT, ACPI, you-name-it) must follow
> > the HW. I don't see how it's done in this case.
> 
> What is inconsistent exactly? What sort of rule tells that every little
> function needs a device node? It's first time I hear about any of such
> rule and for all this time we already NAKed it so many times (node per
> GPIO, node per clock, node per every little pin).

That we should represent the HW as is. There is no "rule", there is a common
sense. Of course, it's possible to have all-in-one node, but this may lead
to a disaster when there are tons of devices in the Multi Functional HW
and some of them use the same properties. How would you distinguish HW
with two GPIO banks, two I²C controllers, et cetera? That's what my common
sense tells to me, putting all eggs into one bucket is just a mine field
for the future.

-- 
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2026-01-28 16:06 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 14:47 [PATCH v13 0/3] Firmware Support for USB-HID Devices and CP2112 Danny Kaehn
2026-01-27 14:47 ` [PATCH v13 1/3] dt-bindings: i2c: Add CP2112 HID USB to SMBus Bridge Danny Kaehn
2026-01-27 16:02   ` Danny Kaehn
2026-01-27 21:00     ` Andy Shevchenko
2026-01-28 10:35     ` Krzysztof Kozlowski
2026-01-28 12:49       ` Andy Shevchenko
2026-01-28 15:06         ` Conor Dooley
2026-01-28 15:51           ` Andy Shevchenko
2026-01-28 15:52             ` Krzysztof Kozlowski
2026-01-28 15:52           ` Krzysztof Kozlowski
2026-01-28 17:24             ` Conor Dooley
2026-01-28 20:14               ` Danny Kaehn
2026-01-28 15:48         ` Krzysztof Kozlowski
2026-01-28 16:05           ` Andy Shevchenko [this message]
2026-01-28 19:52             ` Krzysztof Kozlowski
2026-01-28 20:43               ` Andy Shevchenko
2026-01-28 20:05       ` Danny Kaehn
2026-01-29 16:01   ` Rob Herring (Arm)
2026-02-06  7:55   ` Andy Shevchenko
2026-01-27 14:47 ` [PATCH v13 2/3] HID: cp2112: Fwnode Support Danny Kaehn
2026-01-27 20:06   ` Andy Shevchenko
2026-01-29 18:36     ` Danny Kaehn
2026-01-30  7:53       ` Andy Shevchenko
2026-01-27 14:47 ` [PATCH v13 3/3] HID: cp2112: Configure I2C Bus Speed from Firmware Danny Kaehn
2026-01-27 14:54   ` Danny Kaehn

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=aXoz4Xs8csdxXeZU@smile.fi.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=andi.shyti@kernel.org \
    --cc=arundp@nvidia.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=bentiss@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=danny.kaehn@plexus.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=ethan.twardy@plexus.com \
    --cc=jikos@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=leohu@nvidia.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=tingkaic@nvidia.com \
    --cc=wthai@nvidia.com \
    /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.