- 28 7月, 2018 2 次提交
-
-
由 Robin Murphy 提交于
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: NRobin Murphy <robin.murphy@arm.com> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
由 Robin Murphy 提交于
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: NRobin Murphy <robin.murphy@arm.com> Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 03 5月, 2018 1 次提交
-
-
由 Christoph Hellwig 提交于
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: NNipun Gupta <nipun.gupta@nxp.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # PCI parts Reviewed-by: NRob Herring <robh@kernel.org> [hch: tweaked the changelog a bit] Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 08 1月, 2018 1 次提交
-
-
由 Rob Herring 提交于
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: NFrank Rowand <frank.rowand@sony.com> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 19 10月, 2017 1 次提交
-
-
由 Robin Murphy 提交于
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 72328883 ("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: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 01 9月, 2017 1 次提交
-
-
由 Robin Murphy 提交于
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: 09515ef5 ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices") Reported-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 25 8月, 2017 3 次提交
-
-
由 Andy Shevchenko 提交于
Use dedicated definition instead of plain -1 where it's appropriate. No functional change intended. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Bjorn Andersson 提交于
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: bc575064 ("of/device: use of_property_for_each_string to parse compatible strings") Cc: Rob Herring <robh@kernel.org> Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Bjorn Andersson 提交于
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: 0634c295 ("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: NBjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 17 8月, 2017 1 次提交
-
-
由 Robin Murphy 提交于
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: 9a6d7298 ("of: Calculate device DMA masks based on DT dma-range size") Reported-by: NStefan Wahren <stefan.wahren@i2se.com> Reported-by: NAndreas Färber <afaerber@suse.de> Reported-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NChristoph Hellwig <hch@lst.de>
-
- 02 8月, 2017 1 次提交
-
-
由 Rob Herring 提交于
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: NRob Herring <robh@kernel.org>
-
- 19 7月, 2017 1 次提交
-
-
由 Rob Herring 提交于
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: NRob Herring <robh@kernel.org>
-
- 30 5月, 2017 1 次提交
-
-
由 Sricharan R 提交于
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: 7b07cbef ("iommu: of: Handle IOMMU lookup failure with deferred probing or error") Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org> Tested-by: NMagnus Damn <magnus.damn@gmail.com> Signed-off-by: NSricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 20 4月, 2017 3 次提交
-
-
由 Laurent Pinchart 提交于
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: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NLaurent Pichart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NSricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Sricharan R 提交于
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: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NSricharan R <sricharan@codeaurora.org> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Laurent Pinchart 提交于
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: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 23 3月, 2017 1 次提交
-
-
由 Rob Herring 提交于
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: NRob 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: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 3月, 2017 1 次提交
-
-
由 Rob Herring 提交于
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: NRob Herring <robh@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com>
-
- 20 1月, 2017 2 次提交
-
-
由 Stephen Boyd 提交于
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: NRob Herring <robh@kernel.org> Cc: <devicetree@vger.kernel.org> Signed-off-by: NStephen Boyd <stephen.boyd@linaro.org> Signed-off-by: NPeter Chen <peter.chen@nxp.com>
-
由 Stephen Boyd 提交于
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: NRob Herring <robh@kernel.org> Cc: <devicetree@vger.kernel.org> Signed-off-by: NStephen Boyd <stephen.boyd@linaro.org> Signed-off-by: NPeter Chen <peter.chen@nxp.com>
-
- 09 5月, 2016 1 次提交
-
-
由 Robin Murphy 提交于
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: NThierry Reding <treding@nvidia.com> Signed-off-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
- 18 10月, 2015 1 次提交
-
-
由 Zhen Lei 提交于
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: NZhen Lei <thunder.leizhen@huawei.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 18 9月, 2015 1 次提交
-
-
由 Zhen Lei 提交于
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: NZhen Lei <thunder.leizhen@huawei.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 29 5月, 2015 1 次提交
-
-
由 Joachim Eastwood 提交于
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: NJoachim Eastwood <manabian@gmail.com> [robh: add missing inline to dummmy declaration] Signed-off-by: NRob Herring <robh@kernel.org>
-
- 13 3月, 2015 1 次提交
-
-
由 Murali Karicheri 提交于
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: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NCatalin 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>
-
- 04 3月, 2015 2 次提交
-
-
由 Murali Karicheri 提交于
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: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com> Acked-by: NWill 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>
-
由 Murali Karicheri 提交于
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: NMurali Karicheri <m-karicheri2@ti.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Acked-by: NRob 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>
-
- 07 7月, 2014 1 次提交
-
-
由 Pantelis Antoniou 提交于
We're overloading usage of of_aliases_mutex for sysfs changes, so rename to something that is more generic. Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
- 17 1月, 2014 1 次提交
-
-
由 Zhang Rui 提交于
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: NZhang Rui <rui.zhang@intel.com> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 06 2月, 2013 1 次提交
-
-
由 Stepan Moskovchenko 提交于
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: NStepan 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: NGrant Likely <grant.likely@secretlab.ca>
-
- 02 2月, 2012 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NGreg 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>
-
- 28 2月, 2011 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca>
-
- 22 10月, 2010 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant 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>
-
- 06 8月, 2010 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca> Reviewed-by: NDavid S. Miller <davem@davemloft.net>
-
- 24 7月, 2010 2 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NDavid S. Miller <davem@davemloft.net>
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca> Acked-by: NDavid S. Miller <davem@davemloft.net>
-
- 06 7月, 2010 3 次提交
-
-
由 Grant Likely 提交于
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: NGrant 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
-
由 Grant Likely 提交于
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: NGrant 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
-
由 Grant Likely 提交于
Merge common code between powerpc and microblaze Signed-off-by: NGrant 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
-
- 22 5月, 2010 1 次提交
-
-
由 Grant Likely 提交于
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: NGrant Likely <grant.likely@secretlab.ca>
-