On Wed, Sep 13, 2023 at 10:31:49AM +0200, Konrad Dybcio wrote: > > The applicable voters should likely be defined in the target-specific > > headers, rather than the common qcom,icc.h. The bit range used for them > > could be common, but each target may only support a small subset of the > > total set of possible voters across all targets. > I'm not sure how client drivers would then choose the > correct path other than > > switch (soc) { > case 8450: > tag = QCOM_ICC_TAG_VOTER_8450_HLOS; > break; > case 8550: > tag = QCOM_ICC_TAG_VOTER_8550_HLOS; > break; > ... > } > > which would be unacceptable. The same general way it's handled for the endpoint bindings, which are already target-specific. Any client drivers hardcoding the endpoint bindings in their driver would have to include the appropriate, target-specific binding header (e.g. qcom,sm8550-rpmh.h). That would only be possible if their driver file is itself target-specific. Otherwise, it would have to pull the endpoint bindings from devicetree. Or just use the recommended of_icc_get() and let devicetree do everything for them. Same for the target-specific voter tag bindings. Clients can also specify their tags in devicetree. They don't actually have to call icc_set_tag() directly. For example: #include <dt-bindings/interconnect/qcom,sm8450.h> interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_VOTER_DISP &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_VOTER_DISP>; Then when they call of_icc_get() for this path it'll automatically have QCOM_ICC_TAG_VOTER_DISP set for them.