| Message ID | 20250507131143.2243079-1-mike.looijmans@topic.nl |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] usb: misc: onboard_usb_dev: Add support for TI TUSB8044 hub | expand |
On Wed, May 07, 2025 at 03:11:43PM +0200, Mike Looijmans wrote: > The TI USB8044 is similar to the USB8041. Similar how? Why's a fallback not suitable? > > Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> > --- > > Documentation/devicetree/bindings/usb/ti,usb8041.yaml | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > index c2e29bd61e11..fd6b35a40a5b 100644 > --- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml > @@ -4,7 +4,7 @@ > $id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# > $schema: http://devicetree.org/meta-schemas/core.yaml# > > -title: TI USB8041 USB 3.0 hub controller > +title: TI USB8041 and USB8044 USB 3.0 hub controllers > > maintainers: > - Alexander Stein <alexander.stein@ew.tq-group.com> > @@ -17,6 +17,8 @@ properties: > enum: > - usb451,8140 > - usb451,8142 > + - usb451,8440 > + - usb451,8442 > > reg: true > > -- > 2.34.1 > > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijmans@topic.nl > W: www.topic.nl > > Please consider the environment before printing this e-mail
On 08-05-2025 16:58, Conor Dooley wrote: > On Wed, May 07, 2025 at 03:11:43PM +0200, Mike Looijmans wrote: >> The TI USB8044 is similar to the USB8041. > Similar how? Why's a fallback not suitable? I don't quite understand what is meant by "fallback" here? It's similar in that the USB8044 provides the same functionality and can use the same driver as the USB8041, all that is needed is to add the PID/VID values. M. > >> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> >> --- >> >> Documentation/devicetree/bindings/usb/ti,usb8041.yaml | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml >> index c2e29bd61e11..fd6b35a40a5b 100644 >> --- a/Documentation/devicetree/bindings/usb/ti,usb8041.yaml >> +++ b/Documentation/devicetree/bindings/usb/ti,usb8041.yaml >> @@ -4,7 +4,7 @@ >> $id: http://devicetree.org/schemas/usb/ti,usb8041.yaml# >> $schema: http://devicetree.org/meta-schemas/core.yaml# >> >> -title: TI USB8041 USB 3.0 hub controller >> +title: TI USB8041 and USB8044 USB 3.0 hub controllers >> >> maintainers: >> - Alexander Stein <alexander.stein@ew.tq-group.com> >> @@ -17,6 +17,8 @@ properties: >> enum: >> - usb451,8140 >> - usb451,8142 >> + - usb451,8440 >> + - usb451,8442 >> >> reg: true >> >> -- >> 2.34.1 >> >> >> Met vriendelijke groet / kind regards, >> >> Mike Looijmans >> System Expert >> >> >> TOPIC Embedded Products B.V. >> Materiaalweg 4, 5681 RJ Best >> The Netherlands >> >> T: +31 (0) 499 33 69 69 >> E: mike.looijmans@topic.nl >> W: www.topic.nl >> >> Please consider the environment before printing this e-mail
On Thu, May 08, 2025 at 05:19:03PM +0200, Mike Looijmans wrote: > On 08-05-2025 16:58, Conor Dooley wrote: > > On Wed, May 07, 2025 at 03:11:43PM +0200, Mike Looijmans wrote: > > > The TI USB8044 is similar to the USB8041. > > Similar how? Why's a fallback not suitable? > > I don't quite understand what is meant by "fallback" here? A fallback compatible, since you;re using the same match data as the 8041. > It's similar in that the USB8044 provides the same functionality and can use > the same driver as the USB8041, all that is needed is to add the PID/VID > values. Is this onboard_dev_id_table table with the vid/pid used in combination with dt, or in-place of dt when device detection is dynamic? If the latter, why can't dt use a fallback compatible since the handling is identical to the 8041?
On 08-05-2025 17:53, Conor Dooley wrote: > On Thu, May 08, 2025 at 05:19:03PM +0200, Mike Looijmans wrote: >> On 08-05-2025 16:58, Conor Dooley wrote: >>> On Wed, May 07, 2025 at 03:11:43PM +0200, Mike Looijmans wrote: >>>> The TI USB8044 is similar to the USB8041. >>> Similar how? Why's a fallback not suitable? >> I don't quite understand what is meant by "fallback" here? > A fallback compatible, since you;re using the same match data as the > 8041. I think it would work. It would look strange though, having to put an additional vid/pid in the devicetree to make it work. >> It's similar in that the USB8044 provides the same functionality and can use >> the same driver as the USB8041, all that is needed is to add the PID/VID >> values. > Is this onboard_dev_id_table table with the vid/pid used in combination > with dt, or in-place of dt when device detection is dynamic? If the > latter, why can't dt use a fallback compatible since the handling is > identical to the 8041? My basic understanding is: The devicetree match creates a platform device that controls the reset pin of the hub. It's basic task is to de-assert the reset, so the hub starts negotiating. This part also works with the 8041 devicetree entry (which is how I first tried to get it up and running). The VID/PID table then matches the hub on the USB bus, which can then be associated with its platform device. Since the 8044 reports a different VID/PID, this part only worked when I added the entries to the tables.
On Fri, May 09, 2025 at 07:56:35AM +0200, Mike Looijmans wrote: > On 08-05-2025 17:53, Conor Dooley wrote: > > On Thu, May 08, 2025 at 05:19:03PM +0200, Mike Looijmans wrote: > > > On 08-05-2025 16:58, Conor Dooley wrote: > > > > On Wed, May 07, 2025 at 03:11:43PM +0200, Mike Looijmans wrote: > > > > > The TI USB8044 is similar to the USB8041. > > > > Similar how? Why's a fallback not suitable? > > > I don't quite understand what is meant by "fallback" here? > > A fallback compatible, since you;re using the same match data as the > > 8041. > > I think it would work. It would look strange though, having to put an > additional vid/pid in the devicetree to make it work. That's how a huge number of other devices work in devicetree when handling differs between devices. > > > It's similar in that the USB8044 provides the same functionality and can use > > > the same driver as the USB8041, all that is needed is to add the PID/VID > > > values. > > Is this onboard_dev_id_table table with the vid/pid used in combination > > with dt, or in-place of dt when device detection is dynamic? If the > > latter, why can't dt use a fallback compatible since the handling is > > identical to the 8041? > > My basic understanding is: > > The devicetree match creates a platform device that controls the reset pin > of the hub. It's basic task is to de-assert the reset, so the hub starts > negotiating. This part also works with the 8041 devicetree entry (which is > how I first tried to get it up and running). > > The VID/PID table then matches the hub on the USB bus, which can then be > associated with its platform device. Since the 8044 reports a different > VID/PID, this part only worked when I added the entries to the tables. Right, so you do actually need to use the dt entry /and/ the dynamic data? In that case, there's little value in a fallback, since you need non-fallback information in the driver for things to work. If that's a correct understanding, Acked-by: Conor Dooley <conor.dooley@microchip.com>
diff --git a/drivers/usb/misc/onboard_usb_dev.c b/drivers/usb/misc/onboard_usb_dev.c index 9660b7fe8ee3..c4252186621b 100644 --- a/drivers/usb/misc/onboard_usb_dev.c +++ b/drivers/usb/misc/onboard_usb_dev.c @@ -556,6 +556,8 @@ static const struct usb_device_id onboard_dev_id_table[] = { { USB_DEVICE(VENDOR_ID_TI, 0x8027) }, /* TI USB8020B 2.0 HUB */ { USB_DEVICE(VENDOR_ID_TI, 0x8140) }, /* TI USB8041 3.0 HUB */ { USB_DEVICE(VENDOR_ID_TI, 0x8142) }, /* TI USB8041 2.0 HUB */ + { USB_DEVICE(VENDOR_ID_TI, 0x8440) }, /* TI USB8044 3.0 HUB */ + { USB_DEVICE(VENDOR_ID_TI, 0x8442) }, /* TI USB8044 2.0 HUB */ { USB_DEVICE(VENDOR_ID_VIA, 0x0817) }, /* VIA VL817 3.1 HUB */ { USB_DEVICE(VENDOR_ID_VIA, 0x2817) }, /* VIA VL817 2.0 HUB */ {} diff --git a/drivers/usb/misc/onboard_usb_dev.h b/drivers/usb/misc/onboard_usb_dev.h index 367c5c418ae6..b0bc53f781e6 100644 --- a/drivers/usb/misc/onboard_usb_dev.h +++ b/drivers/usb/misc/onboard_usb_dev.h @@ -86,6 +86,8 @@ static const struct of_device_id onboard_dev_match[] = { { .compatible = "usb451,8027", .data = &ti_tusb8020b_data, }, { .compatible = "usb451,8140", .data = &ti_tusb8041_data, }, { .compatible = "usb451,8142", .data = &ti_tusb8041_data, }, + { .compatible = "usb451,8440", .data = &ti_tusb8041_data, }, + { .compatible = "usb451,8442", .data = &ti_tusb8041_data, }, { .compatible = "usb4b4,6504", .data = &cypress_hx3_data, }, { .compatible = "usb4b4,6506", .data = &cypress_hx3_data, }, { .compatible = "usb4b4,6570", .data = &cypress_hx2vl_data, },
The TUSB8044 is similar to the TUSB8041. This adds the PID/VID values and allows to specify the reset GPIO signal on the board. Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> --- drivers/usb/misc/onboard_usb_dev.c | 2 ++ drivers/usb/misc/onboard_usb_dev.h | 2 ++ 2 files changed, 4 insertions(+)