> I thought downstream kept kernels and DTs in sync, so the dts could be
> fixed?
For Pixel the kernel and DT are in sync, but I'm not sure about other devices.
The problem in general though is now everyone would need to do a special
coordination when updating to the newer LTS version to make sure their kernel
matches the new DT.
On 02/26/2025, Rob Herring wrote:
> On Wed, Feb 26, 2025 at 2:31 PM Zijun Hu <zijun_hu@xxxxxxxxxx> wrote:
> >
> > On 2025/2/27 03:45, Rob Herring wrote:
> > >> Right, I think it's already backported to the LTS kernels, but if it breaks any
> > >> in-tree users then we'd have to revert it. I just like Rob's idea to instead
> > >> change the spec for obvious reasons 🙂
> > > While if it is downstream, it doesn't exist, I'm reverting this for now.
> >
> > perhaps, it is better for us to slow down here.
> >
> > 1) This change does not break any upstream code.
> > is there downstream code which is publicly visible and is broken by
> > this change ?
>
> We don't know that unless you tested every dts file. We only know that
> no one has reported an issue yet.
>
> Even if we did test everything, there are DT's that aren't in the
> kernel tree. It's not like this downstream DT is using some
> undocumented binding or questionable things. It's a standard binding.
>
> Every time this code is touched, it breaks. This is not even the only
> breakage right now[1].
You can find the Pixel 6/7/8/9 device trees on android.googlesource.com.
You can see for zuma based devices (Pixel 9 for example) they have this [1]:
&reserved_memory {
#address-cells = <2>;
#size-cells = <1>;
vstream: vstream {
compatible = "shared-dma-pool";
reusable;
size = <0x4800000>;
alignment = <0x0 0x00010000>;
alloc-ranges = <0x9 0x80000000 0x80000000>,
<0x9 0x00000000 0x80000000>,
<0x8 0x80000000 0x80000000>,
<0x0 0x80000000 0x80000000>;
};
I understand this code is downstream, but as a general principle we shouldn't
break backwards compatibilty.
Thanks,
Will
[1] https://android.googlesource.com/kernel/devices/google/zuma/+/refs/heads/android-gs-shusky-6.1-android16-dp/dts/gs101-dma-heap.dtsi#147
>
> > 2) IMO, the spec may be right.
> > The type of size is enough to express any alignment wanted.
> > For several kernel allocators. type of 'alignment' should be the type
> > of 'size', NOT the type of 'address'
>
> As I said previously, it can be argued either way.
>
> Rob
>
> [1] https://lore.kernel.org/all/20250226115044.zw44p5dxlhy5eoni@xxxxxxxxxxxxxx/
