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. Regards, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
