linux-stable.git/drivers/of/device.c, branch v4.14.331

of: Fix modalias string generation

2023-05-17T09:11:43+00:00

[ Upstream commit b19a4266c52de78496fe40f0b37580a3b762e67d ]

The helper generating an OF based modalias (of_device_get_modalias())
works fine, but due to the use of snprintf() internally it needs a
buffer one byte longer than what should be needed just for the entire
string (excluding the '\0'). Most users of this helper are sysfs hooks
providing the modalias string to users. They all provide a PAGE_SIZE
buffer which is way above the number of bytes required to fit the
modalias string and hence do not suffer from this issue.

There is another user though, of_device_request_module(), which is only
called by drivers/usb/common/ulpi.c. This request module function is
faulty, but maybe because in most cases there is an alternative, ULPI
driver users have not noticed it.

In this function, of_device_get_modalias() is called twice. The first
time without buffer just to get the number of bytes required by the
modalias string (excluding the null byte), and a second time, after
buffer allocation, to fill the buffer. The allocation asks for an
additional byte, in order to store the trailing '\0'. However, the
buffer *length* provided to of_device_get_modalias() excludes this extra
byte. The internal use of snprintf() with a length that is exactly the
number of bytes to be written has the effect of using the last available
byte to store a '\0', which then smashes the last character of the
modalias string.

Provide the actual size of the buffer to of_device_get_modalias() to fix
this issue.

Note: the "str[size - 1] = '\0';" line is not really needed as snprintf
will anyway end the string with a null byte, but there is a possibility
that this function might be called on a struct device_node without
compatible, in this case snprintf() would not be executed. So we keep it
just to avoid possible unbounded strings.

Cc: Stephen Boyd 
Cc: Peter Chen 
Fixes: 9c829c097f2f ("of: device: Support loading a module with OF based modalias")
Signed-off-by: Miquel Raynal 
Reviewed-by: Rob Herring 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

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

of: Convert to using %pOF instead of full_name

2017-07-18T22:09:18+00:00

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.

Signed-off-by: Rob Herring