#
7f38b700 |
|
15-Dec-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: device: Export of_device_make_bus_id() This helper is really handy to create unique device names based on their device tree path, we may need it outside of the OF core (in the NVMEM subsystem) so let's export it. As this helper has nothing patform specific, let's move it to of/device.c instead of of/platform.c so we can add its prototype to of_device.h. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231215111536.316972-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
6ff6e184 |
|
07-Dec-2023 |
Jason Gunthorpe <jgg@ziepe.ca> |
iommmu/of: Do not return struct iommu_ops from of_iommu_configure() Nothing needs this pointer. Return a normal error code with the usual IOMMU semantic that ENODEV means 'there is no IOMMU driver'. Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Hector Martin <marcan@marcan.st> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/2-v2-16e4def25ebb+820-iommu_fwspec_p1_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
4720287c |
|
07-Dec-2023 |
Jason Gunthorpe <jgg@ziepe.ca> |
iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops() This is not being used to pass ops, it is just a way to tell if an iommu driver was probed. These days this can be detected directly via device_iommu_mapped(). Call device_iommu_mapped() in the two places that need to check it and remove the iommu parameter everywhere. Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Moritz Fischer <mdf@kernel.org> Acked-by: Christoph Hellwig <hch@lst.de> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Hector Martin <marcan@marcan.st> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Link: https://lore.kernel.org/r/1-v2-16e4def25ebb+820-iommu_fwspec_p1_jgg@nvidia.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
66a4210b |
|
17-Jul-2023 |
Rob Herring <robh@kernel.org> |
of: Move of_device_{add,register,unregister} to platform.c The declarations for of_device_{add,register,unregister} were moved into of_platform.h, so the implementations should be moved to platform.c as well. Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20230717143718.1715773-2-robh@kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
97c23217 |
|
22-Jun-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: module: Export of_device_uevent() The content of of_device_uevent() is currently hardcoded in a driver that can be compiled as a module. Nothing prevents of_device_uevent() to be exported to modules, most of the other helpers in of/device.c actually are. The reason why this helper was not exported is because it has been so far only useful in drivers/base, which is built-in anyway. With the idea of getting rid of the hardcoded implementation of of_device_uevent() in other places in the kernel, let's export it to GPL modules (very much like its cousins in the same file). Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230622213214.3586530-2-miquel.raynal@bootlin.com
|
#
2f555f58 |
|
04-Apr-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: device: Kill of_device_request_module() A new helper has been introduced, of_request_module(). Users have been converted, this helper can now be deleted. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
e6506f06 |
|
04-Apr-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: Move the request module helper logic to module.c Depending on device.c for pure OF handling is considered backwards. Let's extract the content of of_device_request_module() to have the real logic under module.c. The next step will be to convert users of of_device_request_module() to use the new helper. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-11-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bd7a7ed7 |
|
04-Apr-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: Move of_modalias() to module.c Create a specific .c file for OF related module handling. Move of_modalias() inside as a first step. The helper is exposed through of.h even though it is only used by core files because the users from device.c will soon be split into an OF-only helper in module.c as well as a device-oriented inline helper in of_device.h. Putting this helper in of_private.h would require to include of_private.h from of_device.h, which is not acceptable. Suggested-by: Rob Herring <robh+dt@kernel.org> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-10-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
5c3d15e1 |
|
04-Apr-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: Update of_device_get_modalias() This function only needs a "struct device_node" to work, but for convenience the author (and only user) of this helper did use a "struct device" and put it in device.c. Let's convert this helper to take a "struct device node" instead. This change asks for two additional changes: renaming it "of_modalias()" to fit the current naming, and moving it outside of device.c which will be done in a follow-up commit. Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
b19a4266 |
|
04-Apr-2023 |
Miquel Raynal <miquel.raynal@bootlin.com> |
of: Fix modalias string generation 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 <sboyd@kernel.org> Cc: Peter Chen <peter.chen@kernel.org> Fixes: 9c829c097f2f ("of: device: Support loading a module with OF based modalias") Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230404172148.82422-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
2295bed9 |
|
06-Feb-2023 |
Alexander Stein <alexander.stein@ew.tq-group.com> |
of: device: Do not ignore error code in of_device_uevent_modalias of_device_get_modalias might return an error code, propagate that one. Otherwise the negative, signed integer is propagated to unsigned integer for the comparison resulting in a huge 'sl' size. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230207110531.1060252-3-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
553bd297 |
|
06-Feb-2023 |
Alexander Stein <alexander.stein@ew.tq-group.com> |
of: device: Ignore modalias of reused nodes If of_node is reused, do not use that node's modalias. This will hide the name of the actual device. This is rather prominent in USB glue drivers creating a platform device for the host controller. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230207110531.1060252-2-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
a77ad4bf |
|
10-Jan-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
of: device: make of_device_uevent_modalias() take a const device * of_device_uevent_modalias() does not modify the device pointer passed to it, so mark it constant. In order to properly do this, a number of busses need to have a modalias function added as they were attempting to just point to of_device_uevent_modalias instead of their bus-specific modalias function. This is fine except if the prototype for a bus and device type modalias function diverges and then problems could happen. To prevent all of that, just wrap the call to of_device_uevent_modalias() directly for each bus and device type individually. Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Samuel Holland <samuel@sholland.org> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Liang He <windhl@126.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Lyude Paul <lyude@redhat.com> Cc: Corentin Labbe <clabbe@baylibre.com> Cc: Zou Wei <zou_wei@huawei.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-sunxi@lists.linux.dev Cc: dri-devel@lists.freedesktop.org Cc: devicetree@vger.kernel.org Acked-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230111113018.459199-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
9f041c5d |
|
21-Nov-2022 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
driver core: pass a const * into of_device_uevent() of_device_uevent() does not modify the struct device * passed into it, so make it a const * to enforce this. Also the documentation for the function was really wrong so fix that up at the same time. Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: devicetree@vger.kernel.org Link: https://lore.kernel.org/r/20221121094649.1556002-5-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
f1ad5338 |
|
29-Sep-2022 |
Robin Murphy <robin.murphy@arm.com> |
of: Fix "dma-ranges" handling for bus controllers Commit 951d48855d86 ("of: Make of_dma_get_range() work on bus nodes") relaxed the handling of "dma-ranges" for any leaf node on the assumption that it would still represent a usage error for the property to be present on a non-bus leaf node. However there turns out to be a fiddly case where a bus also represents a DMA-capable device in its own right, such as a PCIe root complex with an integrated DMA engine on its platform side. In such cases, "dma-ranges" translation is entirely valid for devices discovered behind the bus, but should not be erroneously applied to the bus controller device itself which operates in its parent's address space. Fix this by restoring the previous behaviour for the specific case where a device is configured via its own OF node, since it is logical to assume that a device should never represent its own parent bus. Reported-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/112e8f3d3e7c054ecf5e12b5ac0aa5596ec00681.1664455433.git.robin.murphy@arm.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
d17e37c4 |
|
01-Jul-2022 |
Liang He <windhl@126.com> |
of: device: Fix missing of_node_put() in of_dma_set_restricted_buffer We should use of_node_put() for the reference 'node' returned by of_parse_phandle() which will increase the refcount. Fixes: fec9b625095f ("of: Add plumbing for restricted DMA pool") Co-authored-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Liang He <windhl@126.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220702014449.263772-1-windhl@126.com
|
#
9b22c17a |
|
18-Jan-2022 |
Rob Herring <robh@kernel.org> |
of: Check 'of_node_reused' flag on of_match_device() Commit 0f153a1b8193 ("usb: chipidea: Set the DT node on the child device") caused the child device to match on the parent driver instead of the child's driver since the child's DT node pointer matched. The worst case result is a loop of the parent driver probing another instance and creating yet another child device eventually exhausting the stack. If the child driver happens to match first, then everything works fine. A device sharing the DT node should never do DT based driver matching, so let's simply check of_node_reused in of_match_device() to prevent that. Fixes: 0f153a1b8193 ("usb: chipidea: Set the DT node on the child device") Link: https://lore.kernel.org/all/20220114105620.GK18506@ediswmail.ad.cirrus.com/ Reported-by: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Tony Lindgren <tony@atomide.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Peter Chen <peter.chen@nxp.com> Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20220118173404.1891800-1-robh@kernel.org
|
#
31c8025f |
|
17-Sep-2021 |
David Brazdil <dbrazdil@google.com> |
of: restricted dma: Fix condition for rmem init of_dma_set_restricted_buffer fails to handle negative return values from of_property_count_elems_of_size, e.g. when the property does not exist. This results in an attempt to assign a non-existent reserved memory region to the device and a warning being printed. Fix the condition to take negative values into account. Fixes: f3cfd136aef0 ("of: restricted dma: Don't fail device probe on rmem init failure") Cc: Will Deacon <will@kernel.org> Signed-off-by: David Brazdil <dbrazdil@google.com> Acked-by: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210917131423.2760155-1-dbrazdil@google.com Signed-off-by: Rob Herring <robh@kernel.org>
|
#
f3cfd136 |
|
16-Aug-2021 |
Will Deacon <will@kernel.org> |
of: restricted dma: Don't fail device probe on rmem init failure If CONFIG_DMA_RESTRICTED_POOL=n then probing a device with a reference to a "restricted-dma-pool" will fail with a reasonably cryptic error: | pci-host-generic: probe of 10000.pci failed with error -22 Rework of_dma_set_restricted_buffer() so that it does not cause probing failure and instead either returns early if CONFIG_DMA_RESTRICTED_POOL=n or emits a diagnostic if the reserved DMA pool fails to initialise. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
#
ce5cb67c |
|
16-Aug-2021 |
Will Deacon <will@kernel.org> |
of: Move of_dma_set_restricted_buffer() into device.c Rob observes that: | of_dma_set_restricted_buffer() [...] should also be moved to | of/device.c. There's no reason for it to be in of/address.c. It has | nothing to do with address parsing. Move it to of/device.c, as he suggests. Cc: Claire Chang <tientzu@chromium.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Robin Murphy <robin.murphy@arm.com> Suggested-by: Rob Herring <robh+dt@kernel.org> Link: https://lore.kernel.org/r/CAL_JsqJ7ROWWJX84x2kEex9NQ8G+2=ybRuNOobX+j8bjZzSemQ@mail.gmail.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
#
fec9b625 |
|
18-Jun-2021 |
Claire Chang <tientzu@chromium.org> |
of: Add plumbing for restricted DMA pool If a device is not behind an IOMMU, we look up the device node and set up the restricted DMA when the restricted-dma-pool is presented. Signed-off-by: Claire Chang <tientzu@chromium.org> Tested-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Will Deacon <will@kernel.org> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
#
cb61e9db |
|
18-Mar-2021 |
Lee Jones <lee.jones@linaro.org> |
of: device: Fix function name in header and provide missing descriptions Fixes the following W=1 kernel build warning(s): drivers/of/device.c:72: warning: expecting prototype for of_dma_configure(). Prototype was for of_dma_configure_id() instead drivers/of/device.c:263: warning: Function parameter or member 'dev' not described in 'of_device_modalias' drivers/of/device.c:263: warning: Function parameter or member 'str' not described in 'of_device_modalias' drivers/of/device.c:263: warning: Function parameter or member 'len' not described in 'of_device_modalias' drivers/of/device.c:280: warning: Function parameter or member 'dev' not described in 'of_device_uevent' drivers/of/device.c:280: warning: Function parameter or member 'env' not described in 'of_device_uevent' Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: devicetree@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210318104036.3175910-2-lee.jones@linaro.org
|
#
83c4a4ee |
|
11-Feb-2021 |
Rob Herring <robh@kernel.org> |
of: Remove of_dev_{get,put}() of_dev_get() and of_dev_put are just wrappers for get_device()/put_device() on a platform_device. There's also already platform_device_{get,put}() wrappers for this purpose. Let's update the few users and remove of_dev_{get,put}(). Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: Felipe Balbi <balbi@kernel.org> Cc: Julia Lawall <Julia.Lawall@inria.fr> Cc: Gilles Muller <Gilles.Muller@inria.fr> Cc: Nicolas Palix <nicolas.palix@imag.fr> Cc: Michal Marek <michal.lkml@markovi.net> Cc: linuxppc-dev@lists.ozlabs.org Cc: netdev@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-usb@vger.kernel.org Cc: cocci@systeme.lip6.fr Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20210211232745.1498137-2-robh@kernel.org
|
#
89c7cb16 |
|
19-Jan-2021 |
Yong Wu <yong.wu@mediatek.com> |
of/device: Update dma_range_map only when dev has valid dma-ranges The commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") always update dma_range_map even though it was already set, like in the sunxi_mbus driver. the issue is reported at [1]. This patch avoid this(Updating it only when dev has valid dma-ranges). Meanwhile, dma_range_map contains the devices' dma_ranges information, This patch moves dma_range_map before of_iommu_configure. The iommu driver may need to know the dma_address requirements of its iommu consumer devices. [1] https://lore.kernel.org/linux-arm-kernel/5c7946f3-b56e-da00-a750-be097c7ceb32@arm.com/ CC: Frank Rowand <frowand.list@gmail.com> Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset"), Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Yong Wu <yong.wu@mediatek.com> Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210119105203.15530-1-yong.wu@mediatek.com
|
#
495023e4 |
|
02-Nov-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
of: Drop superfluous ULL suffix for ~0 There is no need to specify a "ULL" suffix for "all bits set": "~0" is sufficient, and works regardless of type. In fact adding the suffix makes the code more fragile. Fixes: 48ab6d5d1f09 ("dma-mapping: fix 32-bit overflow with CONFIG_ARM_LPAE=n") Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
48ab6d5d |
|
26-Oct-2020 |
Geert Uytterhoeven <geert+renesas@glider.be> |
dma-mapping: fix 32-bit overflow with CONFIG_ARM_LPAE=n On r8a7791/koelsch and shmobile_defconfig, PCIe probing fails with: rcar-pcie fe000000.pcie: Adjusted size 0x0 invalid rcar-pcie: probe of fe000000.pcie failed with error -22 of_dma_get_range() returns the following map: cpu_start 0x40000000 dma_start 0x40000000 size 0x080000000 offset 0 cpu_start 0x00000000 dma_start 0x00000000 size 0x100000000 offset 0 If CONFIG_ARM_LPAE=n, dma_addr_t is 32-bit. Hence when assigning r->dma_start + r->size to dma_end, this value will be truncated to 32-bit, yielding zero when processing the second table entry. Consequently, both dma_start and dma_end will be zero, leading to a zero size. Fix this by changing the dma_start and dma_end variables from dma_addr_t to u64. Fixes: e0d072782c734d27 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
0a0f0d8b |
|
22-Sep-2020 |
Christoph Hellwig <hch@lst.de> |
dma-mapping: split <linux/dma-mapping.h> Split out all the bits that are purely for dma_map_ops implementations and related code into a new <linux/dma-map-ops.h> header so that they don't get pulled into all the drivers. That also means the architecture specific <asm/dma-mapping.h> is not pulled in by <linux/dma-mapping.h> any more, which leads to a missing includes that were pulled in by the x86 or arm versions in a few not overly portable drivers. Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
e0d07278 |
|
17-Sep-2020 |
Jim Quinlan <james.quinlan@broadcom.com> |
dma-mapping: introduce DMA range map, supplanting dma_pfn_offset The new field 'dma_range_map' in struct device is used to facilitate the use of single or multiple offsets between mapping regions of cpu addrs and dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only capable of holding a single uniform offset and had no region bounds checking. The function of_dma_get_range() has been modified so that it takes a single argument -- the device node -- and returns a map, NULL, or an error code. The map is an array that holds the information regarding the DMA regions. Each range entry contains the address offset, the cpu_start address, the dma_start address, and the size of the region. of_dma_configure() is the typical manner to set range offsets but there are a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel driver code. These cases now invoke the function dma_direct_set_offset(dev, cpu_addr, dma_addr, size). Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com> [hch: various interface cleanups] Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com>
|
#
a081bd4a |
|
19-Jun-2020 |
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> |
of/device: Add input id to of_dma_configure() Devices sitting on proprietary busses have a device ID space that is owned by the respective bus and related firmware bindings. In order to let the generic OF layer handle the input translations to an IOMMU id, for such busses the current of_dma_configure() interface should be extended in order to allow the bus layer to provide the device input id parameter - that is retrieved/assigned in bus specific code and firmware. Augment of_dma_configure() to add an optional input_id parameter, leaving current functionality unchanged. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Laurentiu Tudor <laurentiu.tudor@nxp.com> Link: https://lore.kernel.org/r/20200619082013.13661-8-lorenzo.pieralisi@arm.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
#
45586c70 |
|
03-Feb-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
treewide: remove redundant IS_ERR() before error code check 'PTR_ERR(p) == -E*' is a stronger condition than IS_ERR(p). Hence, IS_ERR(p) is unneeded. The semantic patch that generates this commit is as follows: // <smpl> @@ expression ptr; constant error_code; @@ -IS_ERR(ptr) && (PTR_ERR(ptr) == - error_code) +PTR_ERR(ptr) == - error_code // </smpl> Link: http://lkml.kernel.org/r/20200106045833.1725-1-masahiroy@kernel.org Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Cc: Julia Lawall <julia.lawall@lip6.fr> Acked-by: Stephen Boyd <sboyd@kernel.org> [drivers/clk/clk.c] Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> [GPIO] Acked-by: Wolfram Sang <wsa@the-dreams.de> [drivers/i2c] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [acpi/scan.c] Acked-by: Rob Herring <robh@kernel.org> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
a7ba70f1 |
|
21-Nov-2019 |
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> |
dma-mapping: treat dev->bus_dma_mask as a DMA limit Using a mask to represent bus DMA constraints has a set of limitations. The biggest one being it can only hold a power of two (minus one). The DMA mapping code is already aware of this and treats dev->bus_dma_mask as a limit. This quirk is already used by some architectures although still rare. With the introduction of the Raspberry Pi 4 we've found a new contender for the use of bus DMA limits, as its PCIe bus can only address the lower 3GB of memory (of a total of 4GB). This is impossible to represent with a mask. To make things worse the device-tree code rounds non power of two bus DMA limits to the next power of two, which is unacceptable in this case. In the light of this, rename dev->bus_dma_mask to dev->bus_dma_limit all over the tree and treat it as such. Note that dev->bus_dma_limit should contain the higher accessible DMA address. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
8e94fd36 |
|
24-Apr-2019 |
Jojo Zeng <jojo_zeng@126.com> |
of/device.c: fix the wrong comments the comments which discribed the input parameters of of_match_device(). the name is changed, so fix it. Signed-off-by: Jojo Zeng <jojo_zeng@126.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
e8b1dee2 |
|
29-Aug-2018 |
Rob Herring <robh@kernel.org> |
of: Use device_type helpers to access the node type Remove directly accessing device_node.type pointer and use the accessors instead. This will eventually allow removing the type pointer. Cc: Frank Rowand <frowand.list@gmail.com> Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
6778be4e |
|
07-Nov-2018 |
Robin Murphy <robin.murphy@arm.com> |
of/device: Really only set bus DMA mask when appropriate 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 <aaro.koskinen@iki.fi> Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Robert Richter <robert.richter@cavium.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
dc3c0550 |
|
24-Aug-2018 |
Christoph Hellwig <hch@lst.de> |
dma-mapping: remove dma_deconfigure This goes through a lot of hooks just to call arch_teardown_dma_ops. Replace it with a direct call instead. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
|
#
a613b26a |
|
27-Aug-2018 |
Rob Herring <robh@kernel.org> |
of: Convert to using %pOFn instead of device_node.name 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 <frank.rowand@sony.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: netdev@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org>
|
#
4d8bde88 |
|
23-Jul-2018 |
Robin Murphy <robin.murphy@arm.com> |
OF: Don't set default coherent DMA mask 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 <robin.murphy@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
6c2fb2ea |
|
23-Jul-2018 |
Robin Murphy <robin.murphy@arm.com> |
of/device: Set bus DMA mask as appropriate 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 <robin.murphy@arm.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
3d6ce86e |
|
03-May-2018 |
Christoph Hellwig <hch@lst.de> |
drivers: remove force dma flag from buses 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 <nipun.gupta@nxp.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # PCI parts Reviewed-by: Rob Herring <robh@kernel.org> [hch: tweaked the changelog a bit] Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
af6074fc |
|
26-Dec-2017 |
Rob Herring <robh@kernel.org> |
of: Use SPDX license tag for DT files Convert remaining DT files to use SPDX-License-Identifier tags. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
d89e2378 |
|
12-Oct-2017 |
Robin Murphy <robin.murphy@arm.com> |
drivers: flag buses which demand DMA configuration 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 <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
72328883 |
|
31-Aug-2017 |
Robin Murphy <robin.murphy@arm.com> |
of: restrict DMA configuration 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 <hch@lst.de> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
6d7e3bf8 |
|
25-Aug-2017 |
Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
of: Use PLATFORM_DEVID_NONE definition Use dedicated definition instead of plain -1 where it's appropriate. No functional change intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
8c2a75e5 |
|
23-Aug-2017 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
of/device: Fix of_device_get_modalias() buffer handling 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] [<ffffff800891ede8>] vsnprintf+0x348/0x6d8 [ 3.060308] [<ffffff800891f248>] snprintf+0x48/0x50 [ 3.060316] [<ffffff80086a7c80>] of_device_get_modalias+0x108/0x160 [ 3.060322] [<ffffff80086a7cf8>] 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 <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
08ab58d9 |
|
23-Aug-2017 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
of/device: Prevent buffer overflow in of_device_modalias() 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 <robh@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
ee7b1f31 |
|
11-Aug-2017 |
Robin Murphy <robin.murphy@arm.com> |
of: fix DMA mask generation 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 <stefan.wahren@i2se.com> Reported-by: Andreas Färber <afaerber@suse.de> Reported-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
|
#
bc575064 |
|
21-Jul-2017 |
Rob Herring <robh@kernel.org> |
of/device: use of_property_for_each_string to parse compatible strings 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 <robh@kernel.org>
|
#
0d638a07 |
|
01-Jun-2017 |
Rob Herring <robh@kernel.org> |
of: Convert to using %pOF instead of full_name 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 <robh@kernel.org>
|
#
a37b19a3 |
|
27-May-2017 |
Sricharan R <sricharan@codeaurora.org> |
iommu/of: Ignore all errors except EPROBE_DEFER While deferring the probe of IOMMU masters, xlate and add_device callbacks called from of_iommu_configure can pass back error values like -ENODEV, which means the IOMMU cannot be connected with that master for real reasons. Before the IOMMU probe deferral, all such errors were ignored. Now all those errors are propagated back, killing the master's probe for such errors. Instead ignore all the errors except EPROBE_DEFER, which is the only one of concern and let the master work without IOMMU, thus restoring the old behavior. Also make explicit that of_dma_configure handles only -EPROBE_DEFER from of_iommu_configure. Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Magnus Damn <magnus.damn@gmail.com> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
7b07cbef |
|
10-Apr-2017 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
iommu: of: Handle IOMMU lookup failure with deferred probing or error Failures to look up an IOMMU when parsing the DT iommus property need to be handled separately from the .of_xlate() failures to support deferred probing. The lack of a registered IOMMU can be caused by the lack of a driver for the IOMMU, the IOMMU device probe not having been performed yet, having been deferred, or having failed. The first case occurs when the device tree describes the bus master and IOMMU topology correctly but no device driver exists for the IOMMU yet or the device driver has not been compiled in. Return NULL, the caller will configure the device without an IOMMU. The second and third cases are handled by deferring the probe of the bus master device which will eventually get reprobed after the IOMMU. The last case is currently handled by deferring the probe of the bus master device as well. A mechanism to either configure the bus master device without an IOMMU or to fail the bus master device probe depending on whether the IOMMU is optional or mandatory would be a good enhancement. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
efc8551a |
|
10-Apr-2017 |
Sricharan R <sricharan@codeaurora.org> |
of: device: Fix overflow of coherent_dma_mask Size of the dma-range is calculated as coherent_dma_mask + 1 and passed to arch_setup_dma_ops further. It overflows when the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF, resulting in size getting passed as 0 wrongly. Fix this by passsing in max(mask, mask + 1). Note that in this case when the mask is set to full 64bits, we will be passing the mask itself to arch_setup_dma_ops instead of the size. The real fix for this should be to make arch_setup_dma_ops receive the mask and handle it, to be done in the future. Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sricharan R <sricharan@codeaurora.org> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
3f186677 |
|
10-Apr-2017 |
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> |
of: dma: Make of_dma_deconfigure() public As part of moving DMA initializing to probe time the of_dma_deconfigure() function will need to be called from different source files. Make it public and move it to drivers/of/device.c where the of_dma_configure() function is. Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
0634c295 |
|
22-Mar-2017 |
Rob Herring <robh@kernel.org> |
of: Add function for generating a DT modalias with a newline The modalias sysfs attr is lacking a newline for DT aliases on platform devices. The macio and ibmebus correctly add the newline, but open code it. Introduce a new function, of_device_modalias(), that fills the buffer with the modalias including the newline and update users of the old of_device_get_modalias function. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
bcf54d53 |
|
16-Jan-2017 |
Rob Herring <robh@kernel.org> |
of: fix of_device_get_modalias returned length when truncating buffers If the length of the modalias is greater than the buffer size, then the modalias is truncated. However the untruncated length is returned which will cause an error. Fix this to return the truncated length. If an error in the case was desired, then then we should just return -ENOMEM. The reality is no device will ever have 4KB of compatible strings to hit this case. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com>
|
#
7a3b7cd3 |
|
28-Dec-2016 |
Stephen Boyd <stephen.boyd@linaro.org> |
of: device: Export of_device_{get_modalias, uvent_modalias} to modules The ULPI bus can be built as a module, and it will soon be calling these functions when it supports probing devices from DT. Export them so they can be used by the ULPI module. Acked-by: Rob Herring <robh@kernel.org> Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Peter Chen <peter.chen@nxp.com>
|
#
9c829c09 |
|
28-Dec-2016 |
Stephen Boyd <stephen.boyd@linaro.org> |
of: device: Support loading a module with OF based modalias In the case of ULPI devices, we want to be able to load the driver before registering the device so that we don't get stuck in a loop waiting for the phy module to appear and failing usb controller probe. Currently we request the ulpi module via the ulpi ids, but in the DT case we might need to request it with the OF based modalias instead. Add a common function that allows anyone to request a module with the OF based modalias. Acked-by: Rob Herring <robh@kernel.org> Cc: <devicetree@vger.kernel.org> Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org> Signed-off-by: Peter Chen <peter.chen@nxp.com>
|
#
53c92d79 |
|
07-Apr-2016 |
Robin Murphy <Robin.Murphy@arm.com> |
iommu: of: enforce const-ness of struct iommu_ops As a set of driver-provided callbacks and static data, there is no compelling reason for struct iommu_ops to be mutable in core code, so enforce const-ness throughout. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>
|
#
56f2de81 |
|
24-Aug-2015 |
Zhen Lei <thunder.leizhen@huawei.com> |
of: to support binding numa node to specified device in devicetree For now, in function device_add, the new device will be forced to inherit the numa node of its parent. But this will override the device's numa node which configured in devicetree. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
#
4f59d711 |
|
24-Aug-2015 |
Zhen Lei <thunder.leizhen@huawei.com> |
of: to support binding numa node to specified device in devicetree For now, in function device_add, the new device will be forced to inherit the numa node of its parent. But this will override the device's numa node which configured in devicetree. Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Rob Herring <robh@kernel.org>
|
#
3386e0fa |
|
06-May-2015 |
Joachim Eastwood <manabian@gmail.com> |
of: add helper function to retrive match data It's a common operation for device drivers to retrive the data member from of_device_id struct in their probe function. Most driver end up doing: const struct of_device_id *match; match = of_match_device(driver_of_match, &pdev->dev); driver->data = match->data; With the of_device_get_match_data helper function all this can done in one go. Signed-off-by: Joachim Eastwood <manabian@gmail.com> [robh: add missing inline to dummmy declaration] Signed-off-by: Rob Herring <robh@kernel.org>
|
#
9a6d7298 |
|
03-Mar-2015 |
Murali Karicheri <m-karicheri2@ti.com> |
of: Calculate device DMA masks based on DT dma-range size Calculate the dma_mask and coherent_dma_mask based on the dma-range values set in DT for the device. Limit the mask to lower of the default mask and mask calculated. Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> CC: Joerg Roedel <joro@8bytes.org> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Will Deacon <will.deacon@arm.com> CC: Russell King <linux@arm.linux.org.uk> CC: Arnd Bergmann <arnd@arndb.de> CC: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
|
#
0c79c81c |
|
02-Mar-2015 |
Murali Karicheri <m-karicheri2@ti.com> |
of: Fix size when dma-range is not used Fix the dma-range size when the DT attribute is missing, i.e., set size to dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask. Also add code to check invalid values of size configured in DT and log error. Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> (AMD Seattle) Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> CC: Joerg Roedel <joro@8bytes.org> CC: Grant Likely <grant.likely@linaro.org> CC: Rob Herring <robh+dt@kernel.org> CC: Russell King <linux@arm.linux.org.uk> CC: Arnd Bergmann <arnd@arndb.de>
|
#
1f5c69aa |
|
02-Mar-2015 |
Murali Karicheri <m-karicheri2@ti.com> |
of: Move of_dma_configure() to device.c to help re-use Move of_dma_configure() to device.c so it can be re-used for PCI devices to obtain DMA configuration from DT. Also add a second argument so that for PCI, the DT node of root bus host bridge can be used to obtain the DMA configuration for the slave PCI device. Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> (AMD Seattle) Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Rob Herring <robh+dt@kernel.org> CC: Joerg Roedel <joro@8bytes.org> CC: Grant Likely <grant.likely@linaro.org> CC: Russell King <linux@arm.linux.org.uk> CC: Arnd Bergmann <arnd@arndb.de>
|
#
c05aba2b |
|
04-Jul-2014 |
Pantelis Antoniou <pantelis.antoniou@konsulko.com> |
of: rename of_aliases_mutex to just of_mutex We're overloading usage of of_aliases_mutex for sysfs changes, so rename to something that is more generic. Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Grant Likely <grant.likely@linaro.org>
|
#
b9f73067 |
|
14-Jan-2014 |
Zhang Rui <rui.zhang@intel.com> |
platform: introduce OF style 'modalias' support for platform bus Fix a problem that, the platform bus supports the OF style modalias in .uevent() call, but not in its device 'modalias' sysfs attribute. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ced4eec9 |
|
06-Dec-2012 |
Stepan Moskovchenko <stepanm@codeaurora.org> |
of: Output devicetree alias names in uevent In some situations, userspace may want to resolve a device by function and logical number (ie, "serial0") rather than by the base address or full device path. Being able to resolve a device by alias frees userspace from the burden of otherwise having to maintain a mapping between device addresses and their logical assignments on each platform when multiple instances of the same hardware block are present in the system. Although the uevent device attribute contains devicetree compatible information and the full device path, the uevent does not list the alises that may have been defined for the device. Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org> [grant.likely: Removed OF_ALIAS_N field; I don't think it's needed] [grant.likely: Added #ifndef _LINUX_OF_PRIVATE_H wrapper] Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
07d57a32 |
|
01-Feb-2012 |
Grant Likely <grant.likely@secretlab.ca> |
drivercore: Output common devicetree information in uevent When userspace needs to find a specific device, it currently isn't easy to resolve a /sys/devices/ path from a specific device tree node. Nor is it easy to obtain the compatible list for devices. This patch generalizes the code that inserts OF_* values into the uevent device attribute so that any device that is attached to an OF node will have that information exported to userspace. Without this patch only platform devices and some powerpc-specific busses have access to this data. The original function also creates a MODALIAS property for the compatible list, but that code has not been generalized into the common case because it has the potential to break module loading on a lot of bus types. Bus types are still responsible for their own MODALIAS properties. Boot tested on ARM and compile tested on PowerPC and SPARC. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tobias Klauser <tklauser@distanz.ch> Cc: Frederic Lambert <frdrc66@gmail.com> Cc: Rob Herring <rob.herring@calxeda.com> Cc: Mark Brown <broonie@sirena.org.uk> Cc: "David S. Miller" <davem@davemloft.net> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
#
710ac54b |
|
17-Feb-2011 |
Grant Likely <grant.likely@secretlab.ca> |
dt/powerpc: move of_bus_type infrastructure to ibmebus arch/powerpc/kernel/ibmebus.c is the only remaining user of the of_bus_type support code for initializing the bus and registering drivers. All others have either been switched to the vanilla platform bus or already have their own infrastructure. This patch moves the functionality that ibmebus is using out of drivers/of/{platform,device}.c and into ibmebus.c where it is actually used. Also renames the moved symbols from of_platform_* to ibmebus_bus_* to reflect the actual usage. This patch is part of moving all of the of_platform_bus_type users over to the platform_bus_type. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
7096d042 |
|
20-Oct-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/device: Rework to use common platform_device_alloc() for allocating devices The current code allocates and manages platform_devices created from the device tree manually. It also uses an unsafe shortcut for allocating the platform_device and the resource table at the same time. (which I added in the last rework; sorry). This patch refactors the code to use platform_device_alloc() for allocating new devices. This reduces the amount of custom code implemented by of_platform, eliminates the unsafe alloc trick, and has the side benefit of letting the platform_bus code manage freeing the device data and resources when the device is freed. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: "David S. Miller" <davem@davemloft.net> Cc: Michal Simek <monstr@monstr.eu>
|
#
2dc11581 |
|
06-Aug-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/device: Replace struct of_device with struct platform_device of_device is just an alias for platform_device, so remove it entirely. Also replace to_of_device() with to_platform_device() and update comment blocks. This patch was initially generated from the following semantic patch, and then edited by hand to pick up the bits that coccinelle didn't catch. @@ @@ -struct of_device +struct platform_device Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Reviewed-by: David S. Miller <davem@davemloft.net>
|
#
94a0cb1f |
|
22-Jul-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/device: Replace of_device with platform_device in includes and core code of_device is currently just an #define alias to platform_device until it gets removed entirely. This patch removes references to it from the include directories and the core drivers/of code. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: David S. Miller <davem@davemloft.net>
|
#
eca39301 |
|
08-Jun-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of: Merge of_platform_bus_type with platform_bus_type of_platform_bus was being used in the same manner as the platform_bus. The only difference being that of_platform_bus devices are generated from data in the device tree, and platform_bus devices are usually statically allocated in platform code. Having them separate causes the problem of device drivers having to be registered twice if it was possible for the same device to appear on either bus. This patch removes of_platform_bus_type and registers all of_platform bus devices and drivers on the platform bus instead. A previous patch made the of_device structure an alias for the platform_device structure, and a shim is used to adapt of_platform_drivers to the platform bus. After all of of_platform_bus drivers are converted to be normal platform drivers, the shim code can be removed. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Acked-by: David S. Miller <davem@davemloft.net>
|
#
8cec0e7b |
|
08-Jun-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/device: Add OF style matching helper function Add of_driver_match_device() helper function. This function can be used by bus types to determine if a driver works with a device when using OF style matching. If CONFIG_OF is unselected, then it is a nop. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: Greg Kroah-Hartman <gregkh@suse.de> CC: Michal Simek <monstr@monstr.eu> CC: Grant Likely <grant.likely@secretlab.ca> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Stephen Rothwell <sfr@canb.auug.org.au> CC: linux-kernel@vger.kernel.org CC: microblaze-uclinux@itee.uq.edu.au CC: linuxppc-dev@ozlabs.org CC: devicetree-discuss@lists.ozlabs.org
|
#
34a1c1e8 |
|
08-Jun-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of: Modify of_device_get_modalias to be passed struct device Now that the of_node pointer is part of struct device, of_device_get_modalias could be used on any struct device that has the device node pointer set. This patch changes of_device_get_modalias to accept a struct device instead of a struct of_device. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: Michal Simek <monstr@monstr.eu> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Wolfram Sang <w.sang@pengutronix.de> CC: Stephen Rothwell <sfr@canb.auug.org.au> CC: microblaze-uclinux@itee.uq.edu.au CC: linuxppc-dev@ozlabs.org
|
#
dd27dcda |
|
08-Jun-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of/device: merge of_device_uevent Merge common code between powerpc and microblaze Signed-off-by: Grant Likely <grant.likely@secretlab.ca> CC: Michal Simek <monstr@monstr.eu> CC: Wolfram Sang <w.sang@pengutronix.de> CC: Stephen Rothwell <sfr@canb.auug.org.au> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: microblaze-uclinux@itee.uq.edu.au CC: linuxppc-dev@ozlabs.org
|
#
44504b2b |
|
13-Apr-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of: change of_match_device to work with struct device The of_node pointer is now stored directly in struct device, so of_match_device() should work with any device, not just struct of_device. This patch changes the interface to of_match_device() to accept a struct device instead of struct of_device. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
61c7a080 |
|
13-Apr-2010 |
Grant Likely <grant.likely@secretlab.ca> |
of: Always use 'struct device.of_node' to get device node pointer. The following structure elements duplicate the information in 'struct device.of_node' and so are being eliminated. This patch makes all readers of these elements use device.of_node instead. (struct of_device *)->node (struct dev_archdata *)->prom_node (sparc) (struct dev_archdata *)->of_node (powerpc & microblaze) Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
|
#
6098e2ee |
|
26-Oct-2008 |
Jeremy Kerr <jk@ozlabs.org> |
OF-device: Don't overwrite numa_node in device registration Currently, the numa_node of OF-devices will be overwritten during device_register, which simply sets the node to -1. On cell machines, this means that devices can't find their IOMMU, which is referenced through the device's numa node. Set the numa node for OF devices with no parent, and use the lower-level device_initialize and device_add functions, so that the node is preserved. We can remove the call to set_dev_node in of_device_alloc, as it will be overwritten during register. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
4589f1fe |
|
05-Aug-2008 |
Joachim Fenkes <fenkes@de.ibm.com> |
powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus devices Recent of_platform changes made of_bus_type_init() overwrite the bus type's .dev_attrs list, meaning that the "name" attribute that ibmebus devices previously had is no longer present. This is a user-visible regression which breaks the userspace eHCA support, since the eHCA userspace driver relies on the name attribute to check for valid adapters. This fixes it by providing the "name" attribute in the generic OF device code instead. Tested on POWER. Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
09e67ca2 |
|
15-May-2008 |
Stephen Rothwell <sfr@canb.auug.org.au> |
[POWERPC] Move of_device_get_modalias to drivers/of Commit 140b932f8cb6cced10b96860651a198b1b89cbb9 ("Create modalias file in sysfs for of_platform bus") needs this to avoid breaking the sparc builds. Just move the code and add whitespace around some binary operators. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
140b932f |
|
24-Apr-2008 |
Olaf Hering <olaf@aepfle.de> |
[POWERPC] Create modalias file in sysfs for of_platform bus Create /sys/bus/of_platform/devices/*/modalias file to allow autoloading of modules. Modalias files are already present for many other bus types. This adds also a newline to the devspec files. Also create a devspec file for mac-io devices. They were created as a side effect. Use correct buffer size for mac-io modalias buffer. Tested on iBook1 and Efika. Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
283029d1 |
|
08-Jan-2008 |
Grant Likely <grant.likely@secretlab.ca> |
[POWERPC] Add of_find_matching_node() helper function Similar to of_find_compatible_node(), of_find_matching_node() and for_each_matching_node() allow you to iterate over the device tree looking for specific nodes, except that they take of_device_id tables instead of strings. This also moves of_match_node() from driver/of/device.c to driver/of/base.c to colocate it with the of_find_matching_node which depends on it. Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Paul Mackerras <paulus@samba.org>
|
#
f898f8db |
|
01-May-2007 |
Stephen Rothwell <sfr@canb.auug.org.au> |
Begin consolidation of of_device.h This just moves the common stuff from the arch of_device.h files to linux/of_device.h. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Paul Mackerras <paulus@samba.org> Acked-by: David S. Miller <davem@davemloft.net>
|
#
f85ff305 |
|
01-May-2007 |
Stephen Rothwell <sfr@canb.auug.org.au> |
Begin to consolidate of_device.c This moves all the common parts for the Sparc, Sparc64 and PowerPC of_device.c files into drivers/of/device.c. Apart from the simple move, Sparc gains of_match_node() and a call to of_node_put in of_release_dev(). PowerPC gains better recovery if device_create_file() fails in of_device_register(). Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Paul Mackerras <paulus@samba.org> Acked-by: David S. Miller <davem@davemloft.net>
|