kernel/linux.git/drivers/of/device.c, branch v4.17.1

of: Use SPDX license tag for DT files

2018-01-08T14:22:45+00:00

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:52+00:00

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:06+00:00

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:33+00:00

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:17+00:00

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

of: Use PLATFORM_DEVID_NONE definition

2017-08-25T15:50:31+00:00

Use dedicated definition instead of plain -1 where it's appropriate. No functional change intended. Signed-off-by: Andy Shevchenko Signed-off-by: Rob Herring

of/device: Fix of_device_get_modalias() buffer handling

2017-08-24T16:52:51+00:00

of_device_request_module() calls of_device_get_modalias() with "len" 0, to calculate the size of the buffer needed to store the result, but due to integer promotion the ssize_t "len" will be compared as unsigned with strlen(compat) and the loop will generally never break. This results in a call to snprintf() with a negative len, which triggers below warning, followed by a dereference of a invalid pointer: [ 3.060067] WARNING: CPU: 0 PID: 51 at lib/vsprintf.c:2122 vsnprintf+0x348/0x6d8 ... [ 3.060301] [] vsnprintf+0x348/0x6d8 [ 3.060308] [] snprintf+0x48/0x50 [ 3.060316] [] of_device_get_modalias+0x108/0x160 [ 3.060322] [] of_device_request_module+0x20/0x88 ... Further more of_device_get_modalias() is supposed to return the number of bytes needed to store the entire modalias, so the loop needs to continue accumulate the total size even though the buffer is full. Finally the function is not expected to ensure space for the NUL, nor include it in the returned size, so only 1 should be added to the length of "compat" in the loop (to account for the character 'C'). Fixes: bc575064d688 ("of/device: use of_property_for_each_string to parse compatible strings") Cc: Rob Herring Signed-off-by: Bjorn Andersson Signed-off-by: Rob Herring

of/device: Prevent buffer overflow in of_device_modalias()

2017-08-24T16:52:38+00:00

As of_device_get_modalias() returns the number of bytes that would have been written to the target string, regardless of how much did fit in the buffer, it's possible that the returned index points beyond the buffer passed to of_device_modalias() - causing memory beyond the buffer to be null terminated. Fixes: 0634c2958927 ("of: Add function for generating a DT modalias with a newline") Cc: Rob Herring Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Rob Herring

of: fix DMA mask generation

2017-08-17T08:23:45+00:00

Historically, DMA masks have suffered some ambiguity between whether they represent the range of physical memory a device can access, or the address bits a device is capable of driving, particularly since on many platforms the two are equivalent. Whilst there are some stragglers left (dma_max_pfn(), I'm looking at you...), the majority of DMA code has been cleaned up to follow the latter definition, not least since it is the only one which makes sense once IOMMUs are involved. In this respect, of_dma_configure() has always done the wrong thing in how it generates initial masks based on "dma-ranges". Although rounding down did not affect the TI Keystone platform where dma_addr + size is already a power of two, in any other case it results in a mask which is at best unnecessarily constrained and at worst unusable. BCM2837 illustrates the problem nicely, where we have a DMA base of 3GB and a size of 1GB - 16MB, giving dma_addr + size = 0xff000000 and a resultant mask of 0x7fffffff, which is then insufficient to even cover the necessary offset, effectively making all DMA addresses out-of-range. This has been hidden until now (mostly because we don't yet prevent drivers from simply overwriting this initial mask later upon probe), but due to recent changes elsewhere now shows up as USB being broken on Raspberry Pi 3. Make it right by rounding up instead of down, such that the mask correctly correctly describes all possisble bits the device needs to emit. Fixes: 9a6d7298b083 ("of: Calculate device DMA masks based on DT dma-range size") Reported-by: Stefan Wahren Reported-by: Andreas Färber Reported-by: Hans Verkuil Signed-off-by: Robin Murphy Acked-by: Rob Herring Signed-off-by: Christoph Hellwig

of/device: use of_property_for_each_string to parse compatible strings

2017-08-01T17:24:06+00:00

Instead of directly parsing the compatible property, use the of_property_for_each_string() helper to iterate over each compatible string. This reduces the LoC and makes the functions easier to understand. Signed-off-by: Rob Herring