On Tue, Jul 14, 2020 at 11:12 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > On Tue, Jul 14, 2020 at 10:59:44AM -0600, Rob Herring wrote: > > On Tue, Jul 14, 2020 at 10:43 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > > > On Tue, Jul 14, 2020 at 10:35:12AM -0600, Rob Herring wrote: > > > > On Tue, Jul 14, 2020 at 10:15 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > > > > > > > > > On Tue, Jul 14, 2020 at 10:16:04AM -0400, Martin K. Petersen wrote: > > > > > > > > > > > > Eric, > > > > > > > > > > > > > Add the vendor-specific registers and clock for Qualcomm ICE (Inline > > > > > > > Crypto Engine) to the device tree node for the UFS host controller on > > > > > > > sdm845, so that the ufs-qcom driver will be able to use inline crypto. > > > > > > > > > > > > I would like to see an Acked-by for this patch before I merge it. > > > > > > > > > > > > > > > > Andy, Bjorn, or Rob: can you give Acked-by? > > > > > > > > DTS changes should go in via the QCom tree. > > > > > > > > > > So, the DTS patch can't be applied without the driver patches since then the > > > driver would misinterpret the ICE registers as the dev_ref_clk_ctrl registers. > > > > That sounds broken, but there's no context here for me to comment > > further. DTS changes should work with old/stable kernels. I'd suggest > > you get a review from Bjorn on the driver first. > > > > The "breaking" change is that the dev_ref_clk_ctrl registers are now identified > by name instead of assumed to be index 1. > > A reviewer had complained about the device-mapper bindings of this driver before > (https://lkml.kernel.org/r/158334171487.7173.5606223900174949177@xxxxxxxxxxxxxxxxxxxxxxxxxx). > Changing to identifying the registers by name seemed like an improvement. > > If needed I can add a hole at index 1 to make the DTS changes work with > old/stable kernels too, but I didn't know that is a requirement. (Normally for > Linux kernel development, kernel-internal refactoring is always allowed > upstream.) dtb <-> kernel is an ABI and not an internal interface. The dts files are hosted in the kernel for convenience as that's where the vast majority of h/w support is. The DT parts are also generated as a standalone repo[1] using git-filter-branch for other projects to use. > If I do this, would this hack have to be carried forever, or would > we be able to fix it up eventually? Is there any deprecation period for DTS, or > do the latest DTS have to work with a 20 year old kernel? With the above being said, it's up to the individual platform maintainers to decide whether breaking the ABI is okay or how long to worry about compatibility. My only requirement is documenting that a change does break compatibility. Given this is probably an optional driver, they may not care. BTW, we have broken (and fixed) 1998 era PowerMac G3s not too long ago. That's the opposite direction with old DT (firmware really) and new kernel. Rob [1] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
