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 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?
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.
Hi Johan,
Are you suggesting that we just do something like
num_ports = max( highest usb2 portnum, highest usb3 port num)
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.
Regards,
Krishna,
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/
As you pointed out offline to me that using xhci event notifiers I
mentioned on [3], if it is not acceptable to use them as notifications
to check whether we are in host mode, I believe the only way would be to
use the patches you pushed in.
I still think we'll end up using callbacks from the xhci/core into the
glue driver, but dedicated ones rather than using usb_register_notify().
The fixes I posted can work as a stop-gap solution until then.
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.
So, you are referring to use the patches you pushed today as a partial
way to cleanup layering violations and merge multiport on top of it ? If
so, I am fine with it. I can rebase my changes on top of them.
Right. A bit depending on how your wakeup implementation looks like, it
seems we can merge multiport support and then address the layering
issues which are already present in the driver.
[1]:
https://lore.kernel.org/all/4eb26a54-148b-942f-01c6-64e66541de8b@xxxxxxxxxxx/
[2]:
https://lore.kernel.org/all/ca729f62-672e-d3de-4069-e2205c97e7d8@xxxxxxxxxx/
[3]:
https://lore.kernel.org/all/37fd026e-ecb1-3584-19f3-f8c1e5a9d20a@xxxxxxxxxxx/
Johan
