ARM: 9415/1: amba: Add dev_is_amba() function and export it for modules

Add dev_is_amba() function to determine
whether the device is a AMBA device.

Suggested-by: Andy Shevchenko <andriy.shevchenko

ARM: 9415/1: amba: Add dev_is_amba() function and export it for modules

Add dev_is_amba() function to determine
whether the device is a AMBA device.

Suggested-by: Andy Shevchenko <[email protected]>
Signed-off-by: Kunwu Chan <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9416/1: amba: make amba_bustype constant

Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move

ARM: 9416/1: amba: make amba_bustype constant

Since commit d492cc2573a0 ("driver core: device.h: make struct
bus_type a const *"), the driver core can properly handle constant
struct bus_type, move the amba_bustype variable to be a constant
structure as well, placing it into read-only memory which can not be
modified at runtime.

Cc: Greg Kroah-Hartman <[email protected]>
Suggested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kunwu Chan <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9361/1: amba: store owner from modules with amba_driver_register()

Modules registering driver with amba_driver_register() often forget to
set .owner field. The field is used by some of other k

ARM: 9361/1: amba: store owner from modules with amba_driver_register()

Modules registering driver with amba_driver_register() often forget to
set .owner field. The field is used by some of other kernel parts for
reference counting (try_module_get()), so it is expected that drivers
will set it.

Solve the problem by moving this task away from the drivers to the core
amba bus code, just like we did for platform_driver in
commit 9447057eaff8 ("platform_device: use a macro instead of
platform_driver_register").

Link: https://lore.kernel.org/r/[email protected]

Reviewed-by: Andi Shyti <[email protected]>
Acked-by: Suzuki K Poulose <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

amba: move to_amba_device() to use container_of_const

to_amba_device() now properly keeps the const-ness of the dev pointer
passed into it, while as before it could be lost.

Signed-off-by: Prathu B

amba: move to_amba_device() to use container_of_const

to_amba_device() now properly keeps the const-ness of the dev pointer
passed into it, while as before it could be lost.

Signed-off-by: Prathu Baronia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 9229/1: amba: Fix use-after-free in amba_read_periphid()

After commit f2d3b9a46e0e ("ARM: 9220/1: amba: Remove deferred device
addition"), it became possible for amba_read_periphid() to be invo

ARM: 9229/1: amba: Fix use-after-free in amba_read_periphid()

After commit f2d3b9a46e0e ("ARM: 9220/1: amba: Remove deferred device
addition"), it became possible for amba_read_periphid() to be invoked
concurrently from two threads for a particular AMBA device.

Consider the case where a thread (T0) is registering an AMBA driver, and
searching for all of the devices it can match with on the AMBA bus.
Suppose that another thread (T1) is executing the deferred probe work,
and is searching through all of the AMBA drivers on the bus for a driver
that matches a particular AMBA device. Assume that both threads begin
operating on the same AMBA device and the device's peripheral ID is
still unknown.

In this scenario, the amba_match() function will be invoked for the
same AMBA device by both threads, which means amba_read_periphid()
can also be invoked by both threads, and both threads will be able
to manipulate the AMBA device's pclk pointer without any synchronization.
It's possible that one thread will initialize the pclk pointer, then the
other thread will re-initialize it, overwriting the previous value, and
both will race to free the same pclk, resulting in a use-after-free for
whichever thread frees the pclk last.

Add a lock per AMBA device to synchronize the handling with detecting the
peripheral ID to avoid the use-after-free scenario.

The following KFENCE bug report helped detect this problem:
==================================================================
BUG: KFENCE: use-after-free read in clk_disable+0x14/0x34

Use-after-free read at 0x(ptrval) (in kfence-#19):
clk_disable+0x14/0x34
amba_read_periphid+0xdc/0x134
amba_match+0x3c/0x84
__driver_attach+0x20/0x158
bus_for_each_dev+0x74/0xc0
bus_add_driver+0x154/0x1e8
driver_register+0x88/0x11c
do_one_initcall+0x8c/0x2fc
kernel_init_freeable+0x190/0x220
kernel_init+0x10/0x108
ret_from_fork+0x14/0x3c
0x0

kfence-#19: 0x(ptrval)-0x(ptrval), size=36, cache=kmalloc-64

allocated by task 8 on cpu 0 at 11.629931s:
clk_hw_create_clk+0x38/0x134
amba_get_enable_pclk+0x10/0x68
amba_read_periphid+0x28/0x134
amba_match+0x3c/0x84
__device_attach_driver+0x2c/0xc4
bus_for_each_drv+0x80/0xd0
__device_attach+0xb0/0x1f0
bus_probe_device+0x88/0x90
deferred_probe_work_func+0x8c/0xc0
process_one_work+0x23c/0x690
worker_thread+0x34/0x488
kthread+0xd4/0xfc
ret_from_fork+0x14/0x3c
0x0

freed by task 8 on cpu 0 at 11.630095s:
amba_read_periphid+0xec/0x134
amba_match+0x3c/0x84
__device_attach_driver+0x2c/0xc4
bus_for_each_drv+0x80/0xd0
__device_attach+0xb0/0x1f0
bus_probe_device+0x88/0x90
deferred_probe_work_func+0x8c/0xc0
process_one_work+0x23c/0x690
worker_thread+0x34/0x488
kthread+0xd4/0xfc
ret_from_fork+0x14/0x3c
0x0

Cc: Saravana Kannan <[email protected]>
Cc: [email protected]
Fixes: f2d3b9a46e0e ("ARM: 9220/1: amba: Remove deferred device addition")
Reported-by: Guenter Roeck <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Signed-off-by: Isaac J. Manjarres <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management

The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space

bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management

The devices on platform/amba/fsl-mc/PCI buses could be bound to drivers
with the device DMA managed by kernel drivers or user-space applications.
Unfortunately, multiple devices may be placed in the same IOMMU group
because they cannot be isolated from each other. The DMA on these devices
must either be entirely under kernel control or userspace control, never
a mixture. Otherwise the driver integrity is not guaranteed because they
could access each other through the peer-to-peer accesses which by-pass
the IOMMU protection.

This checks and sets the default DMA mode during driver binding, and
cleanups during driver unbinding. In the default mode, the device DMA is
managed by the device driver which handles DMA operations through the
kernel DMA APIs (see Documentation/core-api/dma-api.rst).

For cases where the devices are assigned for userspace control through the
userspace driver framework(i.e. VFIO), the drivers(for example, vfio_pci/
vfio_platfrom etc.) may set a new flag (driver_managed_dma) to skip this
default setting in the assumption that the drivers know what they are
doing with the device DMA.

Calling iommu_device_use_default_domain() before {of,acpi}_dma_configure
is currently a problem. As things stand, the IOMMU driver ignored the
initial iommu_probe_device() call when the device was added, since at
that point it had no fwspec yet. In this situation,
{of,acpi}_iommu_configure() are retriggering iommu_probe_device() after
the IOMMU driver has seen the firmware data via .of_xlate to learn that
it actually responsible for the given device. As the result, before
that gets fixed, iommu_use_default_domain() goes at the end, and calls
arch_teardown_dma_ops() if it fails.

Cc: Greg Kroah-Hartman <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Stuart Yoder <[email protected]>
Cc: Laurentiu Tudor <[email protected]>
Signed-off-by: Lu Baolu <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Jason Gunthorpe <[email protected]>
Reviewed-by: Robin Murphy <[email protected]>
Tested-by: Eric Auger <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

amba: Use driver_set_override() instead of open-coding

Use a helper to set driver_override to reduce the amount of duplicated
code. Make the driver_override field const char, because it is not
modi

amba: Use driver_set_override() instead of open-coding

Use a helper to set driver_override to reduce the amount of duplicated
code. Make the driver_override field const char, because it is not
modified by the core and it matches other subsystems.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 9173/1: amba: kill amba_find_match()

There is no one use amba_find_match(), kill it.

Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Russell King (Oracle) <rmk+kernel@ar

ARM: 9173/1: amba: kill amba_find_match()

There is no one use amba_find_match(), kill it.

Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: 9172/1: amba: Cleanup amba pclk operation

There is no user about amba_pclk_[un]prepare() besides pl330.c,
directly use clk_[un]prepare(). After this, all the function about
amba pclk operation,

ARM: 9172/1: amba: Cleanup amba pclk operation

There is no user about amba_pclk_[un]prepare() besides pl330.c,
directly use clk_[un]prepare(). After this, all the function about
amba pclk operation, enable, disable, [un]prepare could be killed.

Acked-by: Vinod Koul <[email protected]>
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

arm: remove zte zx platform left-over

Commit 89d4f98ae90d ("ARM: remove zte zx platform") missed to remove some
definitions for this platform's debug and serial, e.g., code dependent on
the config D

arm: remove zte zx platform left-over

Commit 89d4f98ae90d ("ARM: remove zte zx platform") missed to remove some
definitions for this platform's debug and serial, e.g., code dependent on
the config DEBUG_ZTE_ZX.

Fortunately, ./scripts/checkkconfigsymbols.py detects this and warns:

DEBUG_ZTE_ZX
Referencing files: arch/arm/include/debug/pl01x.S

Further review by Arnd Bergmann identified even more dead code in the
amba serial driver.

Remove all this left-over from the zte zx platform.

Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Lukas Bulwahn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 9121/1: amba: Drop unused functions about APB/AHB devices add

No one use the following functions, kill them.

amba_aphb_device_add()
amba_apb_device_add()
amba_apb_device_add_res()
amba

ARM: 9121/1: amba: Drop unused functions about APB/AHB devices add

No one use the following functions, kill them.

amba_aphb_device_add()
amba_apb_device_add()
amba_apb_device_add_res()
amba_ahb_device_add()
amba_ahb_device_add_res()

Cc: Linus Walleij <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Kefeng Wang <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

ARM: amba: Allow some ARM_AMBA users to compile with COMPILE_TEST

CONFIG_VFIO_AMBA has a light use of AMBA, adding some inline fallbacks
when AMBA is disabled will allow it to be compiled under COMP

ARM: amba: Allow some ARM_AMBA users to compile with COMPILE_TEST

CONFIG_VFIO_AMBA has a light use of AMBA, adding some inline fallbacks
when AMBA is disabled will allow it to be compiled under COMPILE_TEST and
make VFIO easier to maintain.

Signed-off-by: Jason Gunthorpe <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Eric Auger <[email protected]>
Signed-off-by: Alex Williamson <[email protected]>

show more ...

amba: Make the remove callback return void

All amba drivers return 0 in their remove callback. Together with the
driver core ignoring the return value anyhow, it doesn't make sense to
return a value

amba: Make the remove callback return void

All amba drivers return 0 in their remove callback. Together with the
driver core ignoring the return value anyhow, it doesn't make sense to
return a value here.

Change the remove prototype to return void, which makes it explicit that
returning an error value doesn't work as expected. This simplifies changing
the core remove callback to return void, too.

Reviewed-by: Ulf Hansson <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]> # for drivers/memory
Acked-by: Mark Brown <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Suzuki K Poulose <[email protected]> # for hwtracing/coresight
Acked-By: Vinod Koul <[email protected]> # for dmaengine
Acked-by: Guenter Roeck <[email protected]> # for watchdog
Acked-by: Wolfram Sang <[email protected]> # for I2C
Acked-by: Takashi Iwai <[email protected]> # for sound
Acked-by: Vladimir Zapolskiy <[email protected]> # for memory/pl172
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Uwe Kleine-König <[email protected]>

show more ...

amba: Initialize dma_parms for amba devices

It's currently the amba driver's responsibility to initialize the pointer,
dma_parms, for its corresponding struct device. The benefit with this
approach

amba: Initialize dma_parms for amba devices

It's currently the amba driver's responsibility to initialize the pointer,
dma_parms, for its corresponding struct device. The benefit with this
approach allows us to avoid the initialization and to not waste memory for
the struct device_dma_parameters, as this can be decided on a case by case
basis.

However, it has turned out that this approach is not very practical. Not
only does it lead to open coding, but also to real errors. In principle
callers of dma_set_max_seg_size() doesn't check the error code, but just
assumes it succeeds.

For these reasons, let's do the initialization from the common amba bus at
the device registration point. This also follows the way the PCI devices
are being managed, see pci_device_add().

Suggested-by: Christoph Hellwig <[email protected]>
Cc: Russell King <[email protected]>
Cc: <[email protected]>
Tested-by: Haibo Chen <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "amba: Initialize dma_parms for amba devices"

This reverts commit 5caf6102e32ead7ed5d21b5309c1a4a7d70e6a9f. It still
needs some more work and that will happen for the next release cycle,
not

Revert "amba: Initialize dma_parms for amba devices"

This reverts commit 5caf6102e32ead7ed5d21b5309c1a4a7d70e6a9f. It still
needs some more work and that will happen for the next release cycle,
not this one.

Cc: <[email protected]>
Cc: Russell King <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Ludovic Barre <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

amba: Initialize dma_parms for amba devices

It's currently the amba driver's responsibility to initialize the pointer,
dma_parms, for its corresponding struct device. The benefit with this
approach

amba: Initialize dma_parms for amba devices

It's currently the amba driver's responsibility to initialize the pointer,
dma_parms, for its corresponding struct device. The benefit with this
approach allows us to avoid the initialization and to not waste memory for
the struct device_dma_parameters, as this can be decided on a case by case
basis.

However, it has turned out that this approach is not very practical. Not
only does it lead to open coding, but also to real errors. In principle
callers of dma_set_max_seg_size() doesn't check the error code, but just
assumes it succeeds.

For these reasons, let's do the initialization from the common amba bus at
the device registration point. This also follows the way the PCI devices
are being managed, see pci_device_add().

Cc: <[email protected]>
Cc: Russell King <[email protected]>
Suggested-by: Christoph Hellwig <[email protected]>
Tested-by: Ludovic Barre <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Ulf Hansson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of th

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

Based on 2 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 8836/1: drivers: amba: Update component matching to use the CoreSight UCI values.

The patches provide an update of amba_device and matching code to handle
the additional registers required for

ARM: 8836/1: drivers: amba: Update component matching to use the CoreSight UCI values.

The patches provide an update of amba_device and matching code to handle
the additional registers required for the Class 0x9 (CoreSight) UCI.

The *data pointer in the amba_id is used by the driver to provide extended
ID register values for matching.

CoreSight components where PID/CID pair is currently sufficient for
unique identification need not provide this additional information.

Signed-off-by: Mike Leach <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Reviewed-by: Suzuki K Poulose <[email protected]>
Tested-by: Sai Prakash Ranjan <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8838/1: drivers: amba: Updates to component identification for driver matching.

The CoreSight specification (ARM IHI 0029E), updates the ID register
requirements for components on an AMBA bus,

ARM: 8838/1: drivers: amba: Updates to component identification for driver matching.

The CoreSight specification (ARM IHI 0029E), updates the ID register
requirements for components on an AMBA bus, to cover both traditional
ARM Primecell type devices, and newer CoreSight and other components.

The Peripheral ID (PID) / Component ID (CID) pair is extended in certain
cases to uniquely identify components. CoreSight components related to
a single function can share Peripheral ID values, and must be further
identified using a Unique Component Identifier (UCI). e.g. the ETM, CTI,
PMU and Debug hardware of the A35 all share the same PID.

Bits 15:12 of the CID are defined to be the device class.
Class 0xF remains for PrimeCell and legacy components.
Class 0x9 defines the component as CoreSight (CORESIGHT_CID above)
Class 0x0, 0x1, 0xB, 0xE define components that do not have driver support
at present.
Class 0x2-0x8,0xA and 0xD-0xD are presently reserved.

The specification futher defines which classes of device use the standard
CID/PID pair, and when additional ID registers are required.

This patch introduces the amba_cs_uci_id structure which will be used in
all coresight drivers for indentification via the private data pointer in
the amba_id structure.

Existing drivers that currently use the amba_id->data pointer for private
data are updated to use the amba_cs_uci_id->data pointer. Macros and
inline functions are added to simplify this code.

Signed-off-by: Mike Leach <[email protected]>
Reviewed-by: Mathieu Poirier <[email protected]>
Reviewed-by: Suzuki K Poulose <[email protected]>
Tested-by: Sai Prakash Ranjan <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

tty: amba-pl011: probe ZTE device from AMBA bus with a pseudo-ID

There is no Peripheral Identification Registers on ZTE PL011 device, so
although the driver amba-pl011 is ready to work for ZTE devic

tty: amba-pl011: probe ZTE device from AMBA bus with a pseudo-ID

There is no Peripheral Identification Registers on ZTE PL011 device, so
although the driver amba-pl011 is ready to work for ZTE device, the
device cannot be probed by the driver at all.

With arm,primecell-periphid DT bindings (bindings/arm/primecell.txt) in
place, it should be the cleanest the way to use a pseudo-ID to probe the
device from AMBA bus. We create an unofficial vendor number
AMBA_VENDOR_LINUX, which will practically never become an official
vendor ID, and takes Configuration, Revision number, and Part number as
input to compose a pseudo-ID for ZTE device.

Also, since we start using vendor_zte to probe ZTE device, the
__maybe_unused for vendor_zte is removed.

Signed-off-by: Russell King <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers/hwtracing: make coresight-* explicitly non-modular

None of the Kconfig currently controlling compilation of any of
the files here are tristate, meaning that none of it currently
is being bui

drivers/hwtracing: make coresight-* explicitly non-modular

None of the Kconfig currently controlling compilation of any of
the files here are tristate, meaning that none of it currently
is being built as a module by anyone.

We need not be concerned about .remove functions and blocking the
unbind sysfs operations, since that was already done in a recent
commit.

Lets remove any remaining modular references, so that when reading the
drivers there is no doubt they are builtin-only.

All drivers get mostly the same changes, so they are handled in batch.
Changes are (1) convert to builtin_amba_driver, (2) delete module.h
include where unused, and (3) relocate the description into the
comments so we don't need MODULE_DESCRIPTION and associated tags.

The etm3x and etm4x use module_param_named, and have been adjusted
to just include moduleparam.h for that purpose.

In commit f309d4443130bf814e991f836e919dca22df37ae ("platform_device:
better support builtin boilerplate avoidance") we introduced the
builtin_driver macro.

Here we use that support and extend it to amba driver registration,
so where a driver is clearly non-modular and builtin-only, we can
update with the simple mapping of

module_amba_driver(...) ---> builtin_amba_driver(...)

Since module_amba_driver() uses the same init level priority as
builtin_amba_driver() the init ordering remains unchanged with
this commit.

Cc: Mathieu Poirier <[email protected]>
Cc: [email protected]
Signed-off-by: Paul Gortmaker <[email protected]>
Signed-off-by: Mathieu Poirier <[email protected]>
Acked-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ARM: 8446/1: amba: Remove unused callbacks for legacy system PM

Signed-off-by: Ulf Hansson <[email protected]>
Signed-off-by: Russell King <[email protected]>

ARM: 8256/1: driver coamba: add device binding path 'driver_override'

As already demonstrated with PCI [1] and the platform bus [2], a
driver_override property in sysfs can be used to bypass the id

ARM: 8256/1: driver coamba: add device binding path 'driver_override'

As already demonstrated with PCI [1] and the platform bus [2], a
driver_override property in sysfs can be used to bypass the id
matching of a device to a AMBA driver. This can be used by VFIO to
bind to any AMBA device requested by the user.

[1] http://lists-archives.com/linux-kernel/28030441-pci-introduce-new-device-binding-path-using-pci_dev-driver_override.html
[2] https://www.redhat.com/archives/libvir-list/2014-April/msg00382.html

Signed-off-by: Antonios Motakis <[email protected]>
Reviewed-by: Kim Phillips <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8207/1: amba: Use inlines instead of macros for amba_pclk_enable/disable

Replace the amba_pclk_enable and amba_pclk_disable macros with static
inline functions and remove checks for IS_ERR. The

ARM: 8207/1: amba: Use inlines instead of macros for amba_pclk_enable/disable

Replace the amba_pclk_enable and amba_pclk_disable macros with static
inline functions and remove checks for IS_ERR. The amba bus clock won't
be ERR because probe would fail before the use of these functions.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...

ARM: 8200/1: amba: Add helpers for (un)preparing AMBA clock v12

Add amba_pclk_prepare() and amba_pclk_unprepare() inline functions for
handling the AMBA bus clock by device drivers.

Signed-off-by:

ARM: 8200/1: amba: Add helpers for (un)preparing AMBA clock v12

Add amba_pclk_prepare() and amba_pclk_unprepare() inline functions for
handling the AMBA bus clock by device drivers.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...