Re: [PATCH v13 05/10] usb: dwc3: qcom: Refactor IRQ handling in QCOM Glue driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/24/2023 12:26 PM, Johan Hovold wrote:

You need to provide this information so that we can determine what the
binding should look like. The implementation would also be simplified if
we don't have to add random hacks to it just because we don't know why
the vendor driver you refer does not use it currently on this particular
platform.

Also I plan on splitting the patchset into 4 parts (essentially 4 diff
series):

1. Bindings update for hs_phy_irq's
2. DT patches for MP controller and platform specific files
3. Core driver update for supporting multiport
4. QCOM driver update for supporting wakeup/suspend/resume

This is in accordance to [1] and that way qcom code won't block core
driver changes from getting merged. Core driver changes are independent
and are sufficient to get multiport working.

No, you clearly did not understand [1] at all. And stop trying to game
the upstreaming process. Bindings and driver patches go together. The
devicetree changes can be sent separately in case of USB but only
*after* the first set has been merged.

If the code had been in good shape from the start it would have been
merged by now. Just learn from your mistakes and next time things will
be smoother.


I agree that bindings should go first. My point is core bindings are already approved and merged and just wanted to check if core driver changes can be merged without glue blocking them. Core driver changes have nothing to do with interrupt handling in glue. If we get the core changes merged separately after fixing the nits mentioned, we can take up this interrupt handling in glue in parallel. I am just trying to see if we can start merging independent portions of code. I agree that my glue driver changes are still not upto mark. But that has nothing to do with core driver changes.

Please let me know if that is appropriate because I think functionality intended by changes in core is independent of glue driver and glue bindings. If anything glue is partially dependent on core changes (like the MAX_PORTS macro etc., but not the other way around).

Regards,
Krishna,




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux