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,
