On 28/08/2025 21:16, Odelu Kukatla wrote:
On 8/24/2025 2:38 PM, Krzysztof Kozlowski wrote:
On 20/08/2025 10:51, Odelu Kukatla wrote:
On 8/13/2025 11:32 AM, Krzysztof Kozlowski wrote:
On 13/08/2025 07:55, Odelu Kukatla wrote:
On 8/12/2025 3:47 PM, Krzysztof Kozlowski wrote:
On 08/08/2025 16:02, Odelu Kukatla wrote:
Add reg and clocks properties to enable the clocks required
for accessing QoS configuration.
Nothing here explains why EXISTING hardware is being changed. I also
remember big discussions and big confusing patches regarding sa8775p
(its rename, dropping/changing all providers), and this patch feels like
pieces of it without proper justification.
Thanks for the review.
I have added description in cover letter, i will add here as well in next revision.> And this is hidden ABI break, no justification, no mentioning either.
Again we are discussing basics of ABI breaking patches?
If you are talking ABI break if we load old DT which may lead to crash, we have .qos_requires_clocks flag which takes care of skipping QoS if required clocks are not enabled.we have addressed this issue through https://lore.kernel.org/all/20240704125515.22194-1-quic_okukatla@xxxxxxxxxxx/
Format your emails correctly, it's difficult to read.
Your binding did not require reg and clocks. Now it requires reg and
clocks. This is called ABI break.
Please follow Qualcomm extensive upstreaming guide, it explains this,
doesn't it? Or follow writing bindings...
Thanks for your review and guidance.
I agree that adding reg and clocks properties to existing bindings is an
ABI break. The sa8775p is a relatively older platform, and when the
interconnect provider driver was initially upstreamed, QoS configuration
support was not available in the framework. As a result, QoS was not
enabled at that time.
That's irrelevant reason. Writing bindings since long time ask pretty
clearly to describe hardware completely, regardless whether Linux
supports this or not.
It does not matter if you enable QoS or not.
I agree with you. Ideally, the bindings should have described the
hardware fully from the beginning. However, this was not done at the
time of initial upstreaming, and the driver was contributed by someone
from the community. I’m working now to improve the binding by adding the
missing pieces to support QoS configuration.
Well, no. The driver was crontributed by:
commit 3655a63f9661b1fff313d8795200ff420282a87b
Author: Shazad Hussain <quic_shazhuss@xxxxxxxxxxx>
Date: Wed Jan 18 15:08:25 2023 +0100
interconnect: qcom: add a driver for sa8775p
That's definitely not 'someone from the community'.
--
With best wishes
Dmitry
