devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Kaehlcke <mka@chromium.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 1/3] dt-bindings: usb: Add binding for TI USB8041 hub controller
Date: Tue, 12 Jul 2022 14:25:00 -0700	[thread overview]
Message-ID: <Ys3mrAukkXXDHopg@google.com> (raw)
In-Reply-To: <34e2a75a-b6dc-d5ae-4820-58cee2b0dd29@linaro.org>

On Tue, Jul 12, 2022 at 11:12:06PM +0200, Krzysztof Kozlowski wrote:
> On 12/07/2022 19:25, Matthias Kaehlcke wrote:
> > Hi Alexander,
> > 
> > On Tue, Jul 12, 2022 at 05:06:25PM +0200, Alexander Stein wrote:
> >> The TI USB8041 is a USB 3.0 hub controller with 4 ports.
> >>
> >> This initial version of the binding only describes USB related aspects
> >> of the USB8041, it does not cover the option of connecting the controller
> >> as an i2c slave.
> >>
> >> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> >> ---
> >> Well, this is essentially a ripoff of
> >> Documentation/devicetree/bindings/usb/realtek,rts5411.yaml with USB IDs
> >> replaced, reset-gpio added and example adjusted.
> >> IMHO this should be merged together with realtek,rts5411.yaml. Is it ok
> >> to rename bindings files? I guess a common onboard-usb-hub.yaml matching
> >> the driver seens reasonable. Any recommendations how to proceed?
> > 
> > It's a tradeoff between keeping the individual bindings simple and avoid
> > unnecessary duplication. The current RTS5411 and TI USB8041 bindings are
> > very similar, which suggests combining them. However over time hubs with
> > diverging features could be added (e.g. with multiple regulators, a link
> > to an I2C/SPI bus, a clock, ...). With that a common binding might become
> > too messy.
> > 
> > From a quick look through Documentation/devicetree/bindings it doesn't
> > seem common to have generic bindings that cover components from multiple
> > vendors. In that sense I'm leaning towards separate bindings.
> > 
> > Rob, do you have any particular preference or suggestion?
> 
> Not Rob, but my suggestion is not to merge bindings of unrelated
> devices, even if they are the same class. By unrelated I mean, made by
> different companies, designed differently and having nothing in common
> by design. Bindings can be still similar, but should not be merged just
> because they are similar.

Thanks for your advice, let's keep separate bindings then.

  reply	other threads:[~2022-07-12 21:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-12 15:06 [PATCH 1/3] dt-bindings: usb: Add binding for TI USB8041 hub controller Alexander Stein
2022-07-12 15:06 ` [PATCH 2/3] usb: misc: onboard_usb_hub: Add reset-gpio support Alexander Stein
2022-07-12 18:18   ` Matthias Kaehlcke
2022-07-13  6:46     ` Alexander Stein
2022-07-13 16:59       ` Matthias Kaehlcke
2022-07-14  6:10         ` Alexander Stein
2022-07-12 15:06 ` [PATCH 3/3] usb: misc: onboard_usb_hub: Add TI USB8041 hub support Alexander Stein
2022-07-12 17:25 ` [PATCH 1/3] dt-bindings: usb: Add binding for TI USB8041 hub controller Matthias Kaehlcke
2022-07-12 21:12   ` Krzysztof Kozlowski
2022-07-12 21:25     ` Matthias Kaehlcke [this message]
2022-07-12 21:32       ` Krzysztof Kozlowski
2022-07-13  6:09         ` Alexander Stein
2022-07-12 21:16 ` Krzysztof Kozlowski
2022-07-12 21:28   ` Matthias Kaehlcke
2022-07-12 21:32     ` Krzysztof Kozlowski
2022-07-13  7:20   ` Alexander Stein
2022-07-13  7:58     ` Krzysztof Kozlowski

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=Ys3mrAukkXXDHopg@google.com \
    --to=mka@chromium.org \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-usb@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).