On Thu, Nov 21, 2019 at 02:26:15PM +0100, Nicolas Saenz Julienne wrote: > On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote: > > On Wed, Nov 20, 2019 at 08:53:30PM +0100, Nicolas Saenz Julienne wrote: > > One purpose of this function is to validate that the information given in the > > device tree is valid - I've seen other feedback on these lists where the view > > is taken that 'it's not the job of the kernel to validate the DT'. Subscribing > > to this view would be a justification for removing this validation - > > especially > > given that the bindings you include have only one dma-range (in any case if > > there are constraints you ought to include them in the binding document). > > > > Though the problem with this point of view is that if the DT is wrong, it may > > be possible for the driver to work well enough to do some function but with > > some horrible side effects that are difficult to track down to a bad DT. > > As for the validation, I think in this specific case it's still worthwhile. As > you might know, there is a bug on the first revision of RPI4's PCIe integration > which blocks any access higher than 3GB. Further revisions fix this and allow > full memory addressing. > > I've been working with Phil Elwell (from the RPi foundation) to solve this in a > way that plays well with upstream and this driver (I'll be able to test the new > revision before this gets in). The solution is, unsurprisingly, for the > firmware to edit the DTB passed to the kernel based on the board revision. > Given that there is some live manipulation of the dma-ranges I'd rather leave > the validation check. > > If you don't disagree with the above I'll add an extra code comment explaining > why we feel the need to verify the device-tree contents. I'll be interested in seeing it. Thanks, Andrew Murray > > Regards, > Nicolas >
