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. Best regards, Krzysztof
