On 12/15/2023 9:39 PM, Andrew Lunn wrote:
You keep answering with short sentences without touching the root of the
problem. I don't know exactly why, but I feel this discussion leads
nowhere. After long discussion you finally admitted that clocks came
from another device - Wifi. It took us like 6 emails?
So last statement: if you have clock provider and clock consumer, you
must represent it in the bindings or provide rationale why it should not
or must not be represented in the bindings. So far I do not see any of
such arguments.
If you use arguments like:
"My driver....": sorry, bindings are not about drivers
"I don't have clock driver for WiFi": sorry, it does not matter if you
can write one, right?
Please reach internally your colleagues to solve these problems and make
review process smoother.
Yes, i strongly agree with this. Its not our job as maintainers to
educate big companies like Qualcomm how to write Linux drivers. There
are more experienced driver writer within Qualcomm, you need to make
contact with them, and get them to help you. Or you need to outsource
the driver development to one of the companies which write mainline
Linux drivers.
Andrew
Understand this, sorry for some easy mistakes happens here.
i will sync with internal team before pushing the next patch set.
Thanks a lot.
