From: Rob Herring <firstname.lastname@example.org>
To: Michal Simek <email@example.com>
Cc: "firstname.lastname@example.org" <email@example.com>,
Michal Simek <firstname.lastname@example.org>, git <email@example.com>,
Piyush Mehta <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>,
Linux USB List <firstname.lastname@example.org>,
Wolfram Sang <email@example.com>
Subject: Re: [PATCH v2 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub
Date: Thu, 4 Mar 2021 14:02:23 -0600 [thread overview]
Message-ID: <CAL_JsqJZBbu+UXqUNdZwg-uv0PAsNg55026PTwhKr5wQtxCjVQ@mail.gmail.com> (raw)
On Wed, Feb 24, 2021 at 7:38 AM Michal Simek <firstname.lastname@example.org> wrote:
> Hi Rob,
> On 2/11/21 3:42 PM, Rob Herring wrote:
> > On Thu, Feb 11, 2021 at 3:35 AM Michal Simek <email@example.com> wrote:
> >> Hi Rob,
> >> On 2/10/21 11:22 PM, Rob Herring wrote:
> >>> On Tue, Feb 09, 2021 at 11:48:09AM +0100, Michal Simek wrote:
> >>>> From: Piyush Mehta <firstname.lastname@example.org>
> >>>> Added dt binding for usb5744 driver.
> >>>> Signed-off-by: Piyush Mehta <email@example.com>
> >>>> Signed-off-by: Michal Simek <firstname.lastname@example.org>
> >>>> ---
> >>>> Changes in v2: None
> >>>> .../bindings/usb/microchip,usb5744.yaml | 56 +++++++++++++++++++
> >>>> MAINTAINERS | 1 +
> >>>> 2 files changed, 57 insertions(+)
> >>>> create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
> >>>> diff --git a/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..fe222f6db81d
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml
> >>>> @@ -0,0 +1,56 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>> +%YAML 1.2
> >>>> +---
> >>>> +$id: "http://devicetree.org/schemas/usb/microchip,usb5744.yaml#"
> >>>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> >>>> +
> >>>> +title: Bindings for the Microchip USB5744 4-port Hub Controller
> >>>> +
> >>>> +description:
> >>>> + Microchip’s USB5744 SmartHub™ IC is a 4 port, SuperSpeed (SS)/Hi-Speed (HS),
> >>>> + low power, low pin count configurable and fully compliant with the USB 3.1
> >>>> + Gen 1 specification. The USB5744 also supports Full Speed (FS) and Low Speed
> >>>> + (LS) USB signaling, offering complete coverage of all defined USB operating
> >>>> + speeds. The new SuperSpeed hubs operate in parallel with the USB 2.0
> >>>> + controller, so 5 Gbps SuperSpeed data transfers are not affected by slower
> >>>> + USB 2.0 traffic.
> >>>> +
> >>>> +maintainers:
> >>>> + - Piyush Mehta <email@example.com>
> >>>> + - Michal Simek <firstname.lastname@example.org>
> >>>> +
> >>>> +properties:
> >>>> + compatible:
> >>>> + const: microchip,usb5744
> >>>> +
> >>>> + reg:
> >>>> + maxItems: 1
> >>>> + description: |
> >>>> + Specifies the i2c slave address, it is required and should be 0x2d
> >>>> + if I2C is used.
> >>> If I2C is not used, then this should be underneath the USB host as a USB
> >>> device. That also implies a different compatible string. I'd suggest you
> >>> just say I2C is required if that's your use.
> >> We can't say that i2c is required because we have both cases. One is
> >> really usb hub connected over i2c which at least requires to send one
> >> smbus command to start operate. But it can be extended to add more
> >> features - limit speeds, disable ports, etc.
> >> And the second is really the same usb hub without i2c connected which
> >> runs in default mode. But reset is required to ensure proper reset
> >> sequence.
> >> Hub also have external clock chip which is not handled now because it is
> >> just crystal on the board but if you want I can also model it via fixed
> >> clock and call clock enable for it.
> >> It is the same use case as is with
> >> Documentation/devicetree/bindings/usb/usb3503.txt
> > Yes, there are examples of how we don't want to do it.
> >> Can you please elaborate why different compatible string should be used?
> >> It is still the same device and not quite sure why different compatible
> >> string should be used.
> >> Do you also want to example where this node is the part of usb node?
> > See usb/usb-device.txt. And there is this under review.
> > For these cases with I2C, I'd really rather see the hub always under
> > the USB bus with a link to the I2C bus when connected.
> I read that thread and also looked at his device and it is very similar
> to this one. Binding should also have information about i2c or spi. It
> is the same case here that you can use this hub without any bus
> connected which works in default mode. Or when i2c/smbus is connected
> and the hub is waiting for initialization sequence. And I expect spi
> behaves very similarly but don't have this setup here.
> Do we have any binding doc which is using suggested bus link?
'i2c-bus' or 'ddc-i2c-bus' properties for I2C. Don't think we have
anything for SPI, but I'd expect it would be similar though we'd need
a cell for the chip-select.
linux-arm-kernel mailing list
next prev parent reply other threads:[~2021-03-04 20:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 10:48 [PATCH v2 0/2] usb: misc: Add support for Microchip USB5744 Michal Simek
2021-02-09 10:48 ` [PATCH v2 1/2] dt-bindings: usb: misc: Add binding for Microchip usb5744 hub Michal Simek
2021-02-10 22:22 ` Rob Herring
2021-02-11 9:35 ` Michal Simek
2021-02-11 14:42 ` Rob Herring
2021-02-24 13:37 ` Michal Simek
2021-03-04 20:02 ` Rob Herring [this message]
2021-02-09 10:48 ` [PATCH v2 2/2] usb: misc: usb5744: Add support for USB hub controller Michal Simek
2021-02-09 11:20 ` Greg Kroah-Hartman
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).