Hi Conor, > > +properties: > > + compatible: > > + enum: > > + - realtek,usb2phy > > + - realtek,rtd-usb2phy > > + - realtek,rtd1295-usb2phy > > + - realtek,rtd1395-usb2phy > > + - realtek,rtd1619-usb2phy > > + - realtek,rtd1319-usb2phy > > + - realtek,rtd1619b-usb2phy > > + - realtek,rtd1312c-usb2phy > > + - realtek,rtd1319d-usb2phy > > + - realtek,rtd1315e-usb2phy > > +properties: > > + compatible: > > + enum: > > + - realtek,usb3phy > > + - realtek,rtd-usb3phy > > + - realtek,rtd1295-usb3phy > > + - realtek,rtd1619-usb3phy > > + - realtek,rtd1319-usb3phy > > + - realtek,rtd1619b-usb3phy > > + - realtek,rtd1319d-usb3phy > Ignoring everything else, because I really want Krzysztof or Rob to > review this rather than me, but what's going on here with the > compatibles? > What hardware do "usbNphy" and "rtd-usbNphy" represent? > > You have device-specific compatibles, which is great, but you also allow > only those two generic ones. I had a _brief_ look at the driver, and it > seems like there is no decision making done based on the compatibles, > only on the properties. Is that correct? > If it is, I would understand having "realtek,usb3phy" as a fallback > compatible for "realtek,rtd1619-usb3phy", but I do not get the current > setup. This driver is compatible with all Realtek RTD SoCs without specifying different settings. So use "realtek,usb3phy" as fallback compatible for all SoCs. This is the compatible name we use. Other compatible names simply indicate that the driver supports the SoCs. The name "usbNphy" and "rtd-usbNphy" seem to be more generic for all RTD SoCs, but they are not device-specific compatible. Do you have a better suggestion? > > Also, I really think this should be broken down into two patches, one > for each of USB 2 & 3. Okay, I will split to two patches. Thanks, Stanley
