Hi Krishna, and sorry about the delay in following up on this. As usual, there are just way too many threads and this one in particular requires a bit of thought. On Sat, May 20, 2023 at 11:18:52PM +0530, Krishna Kurapati PSSNV wrote: > On 5/17/2023 10:07 PM, Johan Hovold wrote: > > I don't think we should be adding more of these layering violations. A > > parent device driver has no business messing with the driver data for a > > child device which may or may not even have probed yet. > > > > I added a FIXME elsewhere in the driver about fixing up the current > > instances that have already snuck in (which in some sense is even worse > > by accessing driver data of a grandchild device). > > > > We really need to try sort this mess out and how to properly handle the > > interactions between these layers (e.g. glue, dwc3 core and xhci). This > > will likely involve adding callbacks from the child to the parent, for > > example, when the child is suspending. > I agree with you, but in this case I believe there is no other way we > can find the number of ports present. Unless its a dt property which > parent driver can access the child's of node and get the details. Like > done in v4 [1]. But it would be adding redundant data into DT as pointed > out by Rob and Krzysztof and so we removed these properties. 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 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? 2. The driver is already accessing driver data of the child device so arguably your series is not really making things much worse than they already are. I've just sent a couple of fixes to address some of the symptoms of this layering violation here: https://lore.kernel.org/lkml/20230607100540.31045-1-johan+linaro@xxxxxxxxxx/ Getting this fixed properly is going to take a bit of work, and depending on how your multiport wake up implementation is going to look like, adding support for multiport controllers may not make this much harder to address. So perhaps we can indeed merge support for multiport and then get back to cleaning this up. Johan
