user/sven/linux.git/drivers/of/device.c, branch v4.19.114

of: Convert to using %pOFn instead of device_node.name

2019-02-06T16:30:15Z

commit a613b26a50136ae90ab13943afe90bcbd34adb44 upstream. In preparation to remove the node name pointer from struct device_node, convert printf users to use the %pOFn format specifier. Reviewed-by: Frank Rowand Cc: Andrew Lunn Cc: Florian Fainelli Cc: netdev@vger.kernel.org Signed-off-by: Rob Herring Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

of/device: Really only set bus DMA mask when appropriate

2018-11-27T15:13:05Z

[ Upstream commit 6778be4e520959659b27a441c06a84c9cb009085 ] of_dma_configure() was *supposed* to be following the same logic as acpi_dma_configure() and only setting bus_dma_mask if some range was specified by the firmware. However, it seems that subtlety got lost in the process of fitting it into the differently-shaped control flow, and as a result the force_dma==true case ends up always setting the bus mask to the 32-bit default, which is not what anyone wants. Make sure we only touch it if the DT actually said so. Fixes: 6c2fb2ea7636 ("of/device: Set bus DMA mask as appropriate") Reported-by: Aaro Koskinen Reported-by: Jean-Philippe Brucker Tested-by: Aaro Koskinen Tested-by: John Stultz Tested-by: Geert Uytterhoeven Tested-by: Robert Richter Signed-off-by: Robin Murphy Signed-off-by: Rob Herring Signed-off-by: Sasha Levin

OF: Don't set default coherent DMA mask

2018-07-27T17:01:07Z

Now that we can track upstream DMA constraints properly with bus_dma_mask instead of trying (and failing) to maintain it in coherent_dma_mask, it doesn't make much sense for the firmware code to be touching the latter at all. It's merely papering over bugs wherein a driver has failed to call dma_set_coherent_mask() *and* the bus code has not initialised any default value. We don't really want to encourage more drivers coercing dma_mask so we'll continue to fix that up if necessary, but add a warning to help flush out any such buggy bus code that remains. Signed-off-by: Robin Murphy Acked-by: Ard Biesheuvel Signed-off-by: Christoph Hellwig

of/device: Set bus DMA mask as appropriate

2018-07-27T17:01:05Z

When an explicit DMA limit is described by firmware, we need to remember it regardless of how drivers might subsequently update their devices' masks. The new bus_dma_mask field does that. Signed-off-by: Robin Murphy Acked-by: Ard Biesheuvel Signed-off-by: Christoph Hellwig

drivers: remove force dma flag from buses

2018-05-03T14:25:08Z

With each bus implementing its own DMA configuration callback, there is no need for bus to explicitly set the force_dma flag. Modify the of_dma_configure function to accept an input parameter which specifies if implicit DMA configuration is required when it is not described by the firmware. Signed-off-by: Nipun Gupta Acked-by: Bjorn Helgaas # PCI parts Reviewed-by: Rob Herring [hch: tweaked the changelog a bit] Signed-off-by: Christoph Hellwig

of: Use SPDX license tag for DT files

2018-01-08T14:22:45Z

Convert remaining DT files to use SPDX-License-Identifier tags. Cc: Benjamin Herrenschmidt Cc: Guennadi Liakhovetski Cc: Paul Mackerras Cc: Pantelis Antoniou Reviewed-by: Frank Rowand Reviewed-by: Philippe Ombredanne Signed-off-by: Rob Herring

drivers: flag buses which demand DMA configuration

2017-10-19T14:34:52Z

We do not want the common dma_configure() pathway to apply indiscriminately to all devices, since there are plenty of buses which do not have DMA capability, and if their child devices were used for DMA API calls it would only be indicative of a driver bug. However, there are a number of buses for which DMA is implicitly expected even when not described by firmware - those we whitelist with an automatic opt-in to dma_configure(), assuming that the DMA address space and the physical address space are equivalent if not otherwise specified. Commit 723288836628 ("of: restrict DMA configuration") introduced a short-term fix by comparing explicit bus types, but this approach is far from pretty, doesn't scale well, and fails to cope at all with bus drivers which may be built as modules, like host1x. Let's refine things by making that opt-in a property of the bus type, which neatly addresses those problems and lets the decision of whether firmware description of DMA capability should be optional or mandatory stay internal to the bus drivers themselves. Signed-off-by: Robin Murphy Acked-by: Rob Herring Acked-by: Greg Kroah-Hartman Acked-by: Thierry Reding Signed-off-by: Christoph Hellwig

Merge tag 'dma-mapping-4.14' of git://git.infradead.org/users/hch/dma-mapping

2017-09-12T20:30:06Z

Pull dma-mapping updates from Christoph Hellwig: - removal of the old dma_alloc_noncoherent interface - remove unused flags to dma_declare_coherent_memory - restrict OF DMA configuration to specific physical busses - use the iommu mailing list for dma-mapping questions and patches * tag 'dma-mapping-4.14' of git://git.infradead.org/users/hch/dma-mapping: dma-coherent: fix dma_declare_coherent_memory() logic error ARM: imx: mx31moboard: Remove unused 'dma' variable dma-coherent: remove an unused variable MAINTAINERS: use the iommu list for the dma-mapping subsystem dma-coherent: remove the DMA_MEMORY_MAP and DMA_MEMORY_IO flags dma-coherent: remove the DMA_MEMORY_INCLUDES_CHILDREN flag of: restrict DMA configuration dma-mapping: remove dma_alloc_noncoherent and dma_free_noncoherent i825xx: switch to switch to dma_alloc_attrs au1000_eth: switch to dma_alloc_attrs sgiseeq: switch to dma_alloc_attrs dma-mapping: reduce dma_mapping_error inline bloat

Merge tag 'devicetree-for-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux

2017-09-07T21:43:33Z

Pull DeviceTree updates from Rob Herring: "There's a few orphans in the conversion to %pOF printf specifiers included here that no one else picked up. Summary: - Convert more DT code to use of_property_read_* API. - Improve DT overlay support when adding multiple overlays - Convert printk's to %pOF format specifiers. Most went via subsystem trees, but picked up the remaining orphans - Correct unittests to use preferred "okay" for "status" property value - Add a KASLR seed property - Vendor prefixes for Mellanox, Theobroma System, Adaptrum, Moxa - Fix modalias buffer handling - Clean-up of include paths for building dtbs - Add bindings for amc6821, isl1208, tsl2x7x, srf02, and srf10 devices - Add nvmem bindings for MediaTek MT7623 and MT7622 SoC - Add compatible string for Allwinner H5 Mali-450 GPU - Fix links to old OpenFirmware docs with new mirror on devicetree.org - Remove status property from binding doc examples" * tag 'devicetree-for-4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux: (45 commits) devicetree: Adjust status "ok" -> "okay" under drivers/of/ dt-bindings: Remove "status" from examples dt-bindings: pinctrl: sh-pfc: Use generic node name dt-bindings: Add vendor Mellanox dt-binding: net/phy: fix interrupts description virt: Convert to using %pOF instead of full_name macintosh: Convert to using %pOF instead of full_name ide: pmac: Convert to using %pOF instead of full_name microblaze: Convert to using %pOF instead of full_name dt-bindings: usb: musb: Grammar s/the/to/, s/is/are/ of: Use PLATFORM_DEVID_NONE definition of/device: Fix of_device_get_modalias() buffer handling of/device: Prevent buffer overflow in of_device_modalias() dt-bindings: add amc6821, isl1208 trivial bindings dt-bindings: add vendor prefix for Theobroma Systems of: search scripts/dtc/include-prefixes path for both CPP and DTC of: remove arch/$(SRCARCH)/boot/dts from include search path for CPP of: remove drivers/of/testcase-data from include search path for CPP of: return of_get_cpu_node from of_cpu_device_node_get if CPUs are not registered iio: srf08: add device tree binding for srf02 and srf10 ...

of: restrict DMA configuration

2017-09-01T07:49:17Z

Moving DMA configuration to happen later at driver probe time had the unnoticed side-effect that we now perform DMA configuration for *every* device represented in DT, rather than only those explicitly created by the of_platform and PCI code. As Christoph points out, this is not really the best thing to do. Whilst there may well be other DMA-capable buses that can benefit from having their children automatically configured after the bridge has probed, there are also plenty of others like USB, MDIO, etc. that definitely do not support DMA and should not be indiscriminately processed. The good news is that in most cases the DT "dma-ranges" property serves as an appropriate indicator - per a strict interpretation of the spec, anything lacking a "dma-ranges" property should be considered not to have a mapping of DMA address space from its children to its parent, thus anything for which of_dma_get_range() does not succeed does not need DMA configuration. Certain bus types have a general expectation of DMA capability and carry a well-established precedent that an absent "dma-ranges" implies the same as the empty property, so we automatically opt those in to DMA configuration regardless, to avoid regressing most existing platforms. Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: Christoph Hellwig Signed-off-by: Robin Murphy Acked-by: Rob Herring Signed-off-by: Christoph Hellwig