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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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

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

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

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>

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: NGrant Likely <grant.likely@secretlab.ca>

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: NJeremy Kerr <jk@ozlabs.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

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: NJoachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Commit 140b932f ("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: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NPaul Mackerras <paulus@samba.org>