Re: [PATCH v3] dt-bindings: remoteproc: qcom,shikra-pas: Allow bam-dmux subnode
Vishnu Santhosh <[email protected]>
| Newsgroups | org.kernel.vger.linux-remoteproc,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 14-08-2026 02:35 pm, Krzysztof Kozlowski wrote: > On Thu, Aug 13, 2026 at 04:55:54PM +0530, Vishnu Santhosh wrote: >> Allow an optional bam-dmux subnode under qcom,shikra-mpss-pas by >> referencing qcom,bam-dmux.yaml. > I still miss the answer why. Last time you said in present tense that > this node exists there, which I objected. The answer to my objections is > to provide proper reason why you are adding this, why you are doing it. > Answer almost never is: repeat what the diff is doing. > > You change something in the bindings because something exists in the > hardware and it was missed in initial submission, and you explain the > impact of that "missing". > > Best regards, > Krzysztof Understood. The reason is not that there is already an in-tree DTS that fails validation today. Rather, it is driven by the intended Shikra MPSS topology. In the earlier Shikra BAM-DMUX DTS posting, the bam-dmux node was initially placed outside the modem remoteproc node. Based on review feedback from Stephan [1], it was requested that bam-dmux be moved under the modem remoteproc node instead. The rationale was that placing the bam-dmux node at the top level makes it impossible for userspace to associate it with a remoteproc instance (in this case, the modem). This binding change therefore exists to describe the intended Shikra MPSS child-node topology. The DTS user of this binding has not been merged yet. Its next revision is being held until a separate discussion regarding an XPU violation is concluded. Our intention is to get the required binding changes merged first so that the DT patch can be sent once those discussions are complete. Please let me know if adding the above context to the commit message is what you are expecting. [1] https://lore.kernel.org/all/[email protected]/ Thanks, Vishnu >