On Wed, Aug 19, 2026 at 04:53:36PM +0530, Vishnu Santhosh wrote: > > 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. >
If that's the actual problem, then the fix seems to be to just remove the offending snippet! But this isn't the actual problem you're trying to solve. > 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. > Don't describe the path that took you here, explain why there should be a bam-dmux subnode. Regards, Bjorn > [1] https://lore.kernel.org/all/[email protected]/ > > Thanks, > Vishnu > > >
