[+RobH, Robin] On Wed, Oct 16, 2019 at 05:29:50PM +0200, Marek Vasut wrote: [...] > >> The firmware provides all the ranges which are available and usable, > >> that's the hardware description and that should be in the DT. > > > > If the HW (given that those dma-ranges are declared for the PCI host > > controller) can't be programmed to enable those DMA ranges - those > > ranges are neither available nor usable, ergo DT is broken. > > The hardware can be programmed to enable those DMA ranges, just not all > of them at the same time. Ok, we are down to DT bindings interpretation then. > It's not the job of the bootloader to guess which ranges might the next > stage like best. By the time this series: https://patchwork.ozlabs.org/user/todo/linux-pci/?series=132419 is merged, your policy will require the host controller driver to remove the DMA ranges that could not be programmed in the inbound address decoders from the dma_ranges list, otherwise things will fall apart. > >> The firmware cannot decide the policy for the next stage (Linux in > >> this case) on which ranges are better to use for Linux and which are > >> less good. Linux can then decide which ranges are best suited for it > >> and ignore the other ones. > > > > dma-ranges is a property that is used by other kernel subsystems eg > > IOMMU other than the RCAR host controller driver. The policy, provided > > there is one should be shared across them. You can't leave a PCI > > host controller half-programmed and expect other subsystems (that > > *expect* those ranges to be DMA'ble) to work. > > > > I reiterate my point: if firmware is broken it is better to fail > > the probe rather than limp on hoping that things will keep on > > working. > > But the firmware is not broken ? See above, it depends on how the dma-ranges property is interpreted, hopefully we can reach consensus in this thread, I won't merge a patch that can backfire later unless we all agree that what it does is correct. Lorenzo
