On 9/4/2023 11:46 PM, Krzysztof Kozlowski wrote:
On 04/09/2023 18:09, Vignesh Viswanathan wrote:
On 9/4/2023 9:31 PM, Konrad Dybcio wrote:
On 4.09.2023 08:42, Krzysztof Kozlowski wrote:
On 04/09/2023 07:50, Vignesh Viswanathan wrote:
qcom,ipq6018-tcsr-mutex maps to incorrect config of IPQ6018 and is
dropped from the devictree.
No, it is not dropped.
IPQ6018 will use qcom,tcsr-mutex compatible
string.
No, it will not.
Drop qcom,ipq6018-tcsr-mutex compatible string from
qcom_hwspinlock_of_match table.
Why? Do not write what you are doing here, but why you are doing it.
More importantly, looks like the ipq6018 compatible was added after
support for this SoC was introduced (see f5e303aefc06 and 5bf635621245a),
so if it's going to use of_tcsr_mutex data with the fallback compat, the
SoC-specific compatible can be removed from the driver.
Hi Konrad, Krzysztof,
I was planning to update the SOC-specific compatible for IPQ6018
qcom,ipq6018-tcsr-mutex to point to of_tcsr_mutex data in the of_match
table in the hwspinlock driver in V2.
Do you think this would be okay? or should I go ahead with removal of
IPQ6018 specific compatible so that it falls back to of_tcsr_mutex?
Remove, it's not needed in the driver.
Ack, will remove in V2.
Best regards,
Krzysztof
