On Thu, Aug 08, 2024 at 12:15:03PM -0400, Frank Li wrote: > On Thu, Aug 08, 2024 at 04:55:14PM +0100, Conor Dooley wrote: > > On Thu, Aug 08, 2024 at 11:51:34AM -0400, Frank Li wrote: > > > On Thu, Aug 08, 2024 at 04:34:32PM +0100, Conor Dooley wrote: > > > > On Thu, Aug 08, 2024 at 11:31:20AM -0400, Frank Li wrote: > > > > > The mass production lx2160 rev2 use designware PCIe Controller. Old Rev1 > > > > > which use mobivel PCIe controller was not supported. Although uboot > > > > > fixup can change compatible string fsl,lx2160a-pcie to fsl,ls2088a-pcie > > > > > since 2019, it is quite confused and should correctly reflect hardware > > > > > status in fsl-lx2160a.dtsi. > > > > > > > > This does not begin to explain why removing the soc-specific compatible, > > > > and instead putting the compatible for another soc is the right fix. > > > > Come up with a new compatible for this device, that perhaps falls back > > > > to the ls2088a, but this change doesn't seem right to me. > > > > > > It can't fallback to fsl,ls2088a-pcie if fsl,lx2160a-pcie exist, which are > > > totally imcompatible between fsl,ls2088a-pcie and fsl,lx2160a-pcie. > > > > > > Previous dtb can work just because uboot dynamtic change fsl,lx2160a-pcie > > > to fsl,ls2088a-pcie when boot kernel. > > > > > > fsl,lx2160a-pcie should be removed because Rev1 have not mass productioned. > > > > Please re-read what I wrote. I said to come up with a new compatible for > > this device, not fall back from the existing fsl,lx2160a-pcie to > > fsl,ls2088a-pcie. > > According to my understand, It needn't add new compatible string if nothing > difference. for example, it use fsl,vf610-i2c for all i2c without add > new soc-specific fsl,lx2160-i2c. No, you should have soc-specific compatibles regardless. Just because you got away with it once, doesn't mean I'm not going to complain about it here! > So far lx2160a-pcie is the same as ls2088a-pcie.
Attachment:
signature.asc
Description: PGP signature
