On Fri, Jun 09, 2023, Johan Hovold wrote: > On Thu, Jun 08, 2023 at 05:57:23PM +0000, Thinh Nguyen wrote: > > On Thu, Jun 08, 2023, Krishna Kurapati PSSNV wrote: > > > On 6/8/2023 3:12 PM, Johan Hovold wrote: > > > > On Thu, Jun 08, 2023 at 01:21:02AM +0530, Krishna Kurapati PSSNV wrote: > > > > > On 6/7/2023 5:07 PM, Johan Hovold wrote: > > > > > > > > > > So there at least two issues with this series: > > > > > > > > > > > > 1. accessing xhci registers from the dwc3 core > > > > > > 2. accessing driver data of a child device > > > > > > > > > > > > 1. The first part about accessing xhci registers goes against the clear > > > > > > separation between glue, core and xhci that Felipe tried to maintain. > > > > > > > > > > > > I'm not entirely against doing this from the core driver before > > > > > > registering the xhci platform device as the registers are unmapped > > > > > > afterwards. But if this is to be allowed, then the implementation should > > > > > > be shared with xhci rather than copied verbatim. > > > > The core will just be looking at the HW capability registers and > > accessing the ports capability. Our programming guide also listed the > > host capability registers in its documentation. We're not driving the > > xhci controller here. We're initializing some of the core configs base > > on its capability. > > > > We're duplicating the logic here and not exactly doing it verbatim. > > Let's try not to share the whole xhci header where we should not have > > visibility over. Perhaps it makes sense in some other driver, but let's > > not do it here. > > The patch series even copied the kernel doc verbatim. This is just not > the way things are supposed to be done upstream. We share defines and > implementations all the time, but we should not be making copies of > them. We had some fixes to the kernel doc as it's incorrect description. Perhaps we can fully rewrite the kernel-doc if that what makes it better. We can share define implementations if they are meant to be shared. However, with the current way xhci header is implemented, it's not meant to be shared with dwc3. You agreed that we are violating this in some driver, but you're also insistent that we should not duplicate the logic to avoid this violation. Perhaps I'm not a maintainer here long enough to know some violation is better kept. If sharing the xhci header is what it takes to get this through, then fine. > > > > > > > > > > > > > The alternative that avoids this issue entirely could indeed be to > > > > > > simply count the number of PHYs described in DT as Rob initially > > > > > > suggested. Why would that not work? > > > > See below. > > > > > > > > > > > > > The reason why I didn't want to read the Phy's from DT is explained in > > > > > [1]. I felt it makes the code unreadable and its very tricky to read the > > > > > phy's properly, so we decided we would initialize phy's for all ports > > > > > and if a phy is missing in DT, the corresponding member in > > > > > dwc->usbX_generic_phy[] would be NULL and any phy op on it would be a NOP. > > > > > > > > That doesn't sound too convincing. Can't you just iterate over the PHYs > > > > described in DT and determine the maximum port number used for HS and > > > > SS? > > > > > Also as per Krzysztof suggestion on [2], we can add a compatible to read > > > > > number of phy's / ports present. This avoids accessing xhci members > > > > > atleast in driver core. But the layering violations would still be present. > > > > > > > > Yes, but if the information is already available in DT it's better to use > > > > it rather than re-encode it in the driver. > > > > Are you suggesting that we just do something like > > > num_ports = max( highest usb2 portnum, highest usb3 port num) > > > > Why do we want to do this? This makes num_ports ambiguous. Let's not > > sacrifice clarity for some lines of code. > > This is not about lines of code, but avoiding the bad practice of > copying code around and, to some degree, maintaining the separation > between the glue, core, and xhci which Felipe (perhaps mistakingly) has > fought for. We're talking about combining num_usb3_ports and num_usb2_ports here, what does that have to do with layer separation? > > If you just need to know how many PHYs you have in DT so that you can > iterate over that internal array, you can just look at the max index in > DT where the indexes are specified in the first place. > > Don't get hung up on the current variable names, those can be renamed to > match the implementation. Call it max_ports or whatever. It doesn't matter what variable name is given, it doesn't change the fact that this "num_ports" or "max_ports" obfuscated usb2 vs usb3 ports just for this specific implementation. So, don't do that. > > > > If so, incase the usb2 phy of quad port controller is missing in DT, we > > > would still read num_usb2_ports as 4 but the usb2_generic_phy[1] would be > > > NULL and any phy ops would still be NOP. But we would be getting rid of > > > reading the xhci registers compeltely in core driver. > > > > > > Thinh, Bjorn, can you also let us know your views on this. > > > > > > 1. Read: > > > num_usb3_ports = highest usb3 port index in DT > > > num_usb2_ports = max( highest usb2 port index, num_usb3_ports) > > > > > > 2. Read the same by parsing xhci registers as done in recent versions of > > > this series. > > > > DT is not reliable to get this info. As noted, the DT may skip some > > ports and still be fine. However, the driver doesn't know which port > > reflects which port config index without the exact port count. > > That's not correct. DT provides the port indexes already, for example: > > phy-names = "usb2-port0", "usb3-port0", > "usb2-port1", "usb3-port1", > "usb2-port2", > "usb2-port3"; > > So if you just need this to iterate over the PHYs all the information > needed is here. > > If you need to access ports which do not have a PHY described in DT, > then this is not going to suffice, but I have not seen anyone claim that > that is needed yet. Perhaps I misunderstand the conversation. However, there isn't a method that everyone's agree on yet regarding DT [*]. Perhaps this indicates it may not be the best approach. You can resume the conversation if you want to: [*] https://lore.kernel.org/linux-usb/9671cade-1820-22e1-9db9-5c9836414908@xxxxxxxxxxx/#t > > > More importantly, the host controller that lives on the PCI bus will not > > use DT. This can be useful for some re-configurations if the controller > > is a PCI device and that goes through the dwc3 code path. > > Ok, this is a bit hand wavy, but if this ever turns out to be needed it > can also be implemented then. What does hand wavy mean? We have case where it's useful outside of this, and it would be useful for PCI device too: https://lore.kernel.org/linux-usb/20230517233218.rjfmvptrexgkpam3@xxxxxxxxxxxx/ > > Or just generalise the xhci implementation for parsing these registers > and reuse that from the start. (As a bonus you'd shrink the kernel text > size by getting rid of that iffy inline implementation.) > I don't like the iffy inline function either. We changed that here. To rework the xhci header and define its global header seems a bit excessive just for dwc3 to get the port capability. Regardless, as I've said, if we _must_, perhaps we can just import xhci-ext-caps.h instead of the whole xhci.h. BR, Thinh
