bus: etzpc: introduce ETZPC firewall controller driver

ETZPC is a peripheral and memory firewall controller that filter accesses
based on Arm TrustZone secure state and Arm CPU privilege execution l

bus: etzpc: introduce ETZPC firewall controller driver

ETZPC is a peripheral and memory firewall controller that filter accesses
based on Arm TrustZone secure state and Arm CPU privilege execution level.
It handles MCU isolation as well.

Signed-off-by: Gatien Chevallier <[email protected]>
Signed-off-by: Alexandre Torgue <[email protected]>

show more ...

bus: rifsc: introduce RIFSC firewall controller driver

RIFSC is a peripheral firewall controller that filter accesses based on
Arm TrustZone secure state, Arm CPU privilege execution level and
Compa

bus: rifsc: introduce RIFSC firewall controller driver

RIFSC is a peripheral firewall controller that filter accesses based on
Arm TrustZone secure state, Arm CPU privilege execution level and
Compartment IDentification of the STM32 SoC subsystems.

Signed-off-by: Gatien Chevallier <[email protected]>
Signed-off-by: Alexandre Torgue <[email protected]>

show more ...

firewall: introduce stm32_firewall framework

Introduce a STM32 firewall framework that offers to firewall consumers
different firewall services such as the ability to check their access
rights again

firewall: introduce stm32_firewall framework

Introduce a STM32 firewall framework that offers to firewall consumers
different firewall services such as the ability to check their access
rights against their firewall controller(s).

The STM32 firewall framework offers a generic API for STM32 firewall
controllers that is defined in their drivers to best fit the
specificity of each firewall.

There are various types of firewalls:
-Peripheral firewalls that filter accesses to peripherals
-Memory firewalls that filter accesses to memories or memory regions
-No type for undefined type of firewall

Signed-off-by: Gatien Chevallier <[email protected]>
Signed-off-by: Alexandre Torgue <[email protected]>

show more ...

bus: add driver for initializing the SSC bus on (some) qcom SoCs

Add bindings for the AHB bus which exposes the SSC (Snapdragon Sensor Core)
block in the global address space. This bus (and the SSC

bus: add driver for initializing the SSC bus on (some) qcom SoCs

Add bindings for the AHB bus which exposes the SSC (Snapdragon Sensor Core)
block in the global address space. This bus (and the SSC block itself) is
present on certain qcom SoCs.

In typical configuration, this bus (as some of the clocks and registers
that we need to manipulate) is not accessible to Linux, and the resources
on this bus are indirectly accessed by communicating with a hexagon CPU
core residing in the SSC block. In this configuration, the hypervisor is
the one performing the bus initialization for the purposes of bringing
the hexagon CPU core out of reset.

However, it is possible to change the configuration, in which case this
driver will initialize the bus.

In combination with drivers for resources on the SSC bus, this driver can
aid in debugging, and for example with a TLMM driver can be used to
directly access SSC-dedicated GPIO pins, removing the need to commit
to a particular usecase during hw design.

Finally, until open firmware for the hexagon core is available, this
approach allows for using sensors hooked up to SSC-dedicated GPIO pins
on mainline Linux simply by utilizing the existing in-tree drivers for
these sensors.

Signed-off-by: Michael Srba <[email protected]>
Reviewed-by: Jeffrey Hugo <[email protected]>
Signed-off-by: Bjorn Andersson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

bus: mhi: Move host MHI code to "host" directory

In preparation of the endpoint MHI support, let's move the host MHI code
to its own "host" directory and adjust the toplevel MHI Kconfig & Makefile.

bus: mhi: Move host MHI code to "host" directory

In preparation of the endpoint MHI support, let's move the host MHI code
to its own "host" directory and adjust the toplevel MHI Kconfig & Makefile.

While at it, let's also move the "pci_generic" driver to "host" directory
as it is a host MHI controller driver.

Reviewed-by: Hemant Kumar <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drivers: bus: Delete CONFIG_SIMPLE_PM_BUS

The simple-pm-bus driver is mandatory for CONFIG_OF based platforms to work
with fw_devlink. So, always compile it in for CONFIG_OF and delete the
config si

drivers: bus: Delete CONFIG_SIMPLE_PM_BUS

The simple-pm-bus driver is mandatory for CONFIG_OF based platforms to work
with fw_devlink. So, always compile it in for CONFIG_OF and delete the
config since it's no longer necessary.

Tested-by: Ulf Hansson <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Tested-by: Damien Le Moal <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Saravana Kannan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: ixp4xx: Add a driver for IXP4xx expansion bus

The Intel IXP4xx SoCs have an expansion bus that is usually just
used for flash memory and configured by the boot loaders and can
be accessed using

bus: ixp4xx: Add a driver for IXP4xx expansion bus

The Intel IXP4xx SoCs have an expansion bus that is usually just
used for flash memory and configured by the boot loaders and can
be accessed using the "simple-bus".

However some devices need more elaborate configuration and then we
need to provide a proper 3-unit address space indicating chip
select for each device and provide timing and similar information.

Cc: Marc Zyngier <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

bus: Add Baikal-T1 APB-bus driver

Baikal-T1 AXI-APB bridge is used to access the SoC subsystem CSRs.
IO requests are routed to this bus by means of the DW AMBA 3 AXI
Interconnect. In case if an atte

bus: Add Baikal-T1 APB-bus driver

Baikal-T1 AXI-APB bridge is used to access the SoC subsystem CSRs.
IO requests are routed to this bus by means of the DW AMBA 3 AXI
Interconnect. In case if an attempted APB transaction stays with no
response for a pre-defined time an interrupt occurs and the bus gets
freed for a next operation. This driver provides the interrupt handler
to detect the erroneous address, prints an error message about the
address fault, updates an errors counter. The counter and the APB-bus
operations timeout can be accessed via corresponding sysfs nodes.
A dedicated sysfs-node can be also used to artificially cause the
bus errors described above.

[arnd: fix build warnings for missing includes and wrong return types]

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Serge Semin <[email protected]>
Cc: Alexey Malahov <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reported-by: kbuild test robot <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

bus: Add Baikal-T1 AXI-bus driver

AXI3-bus is the main communication bus connecting all high-speed
peripheral IP-cores with RAM controller and MIPS P5600 cores on Baikal-T1
SoC. Bus traffic arbitrat

bus: Add Baikal-T1 AXI-bus driver

AXI3-bus is the main communication bus connecting all high-speed
peripheral IP-cores with RAM controller and MIPS P5600 cores on Baikal-T1
SoC. Bus traffic arbitration is done by means of DW AMBA 3 AXI
Interconnect (so called AXI Main Interconnect) routing IO requests from
one SoC block to another. This driver provides a way to detect any bus
protocol errors and device not responding situations by means of an
embedded on top of the interconnect errors handler block (EHB). AXI
Interconnect QoS arbitration tuning is currently unsupported.
The bus doesn't provide a way to detect the interconnected devices,
so they are supposed to be statically defined like by means of the
simple-bus sub-nodes.

[arnd: fix build warnings for missing includes and wrong return types]

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Serge Semin <[email protected]>
Cc: Alexey Malahov <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Reported-by: kbuild test robot <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

bus: Add driver for Integrator/AP logic modules

The logic modules on the Integrator/AP (Application Platform)
are logic tiles with (typically) one or a few peripheral
devices. They are most commonly

bus: Add driver for Integrator/AP logic modules

The logic modules on the Integrator/AP (Application Platform)
are logic tiles with (typically) one or a few peripheral
devices. They are most commonly used for FPGA prototyping.

Using the device tree node for logic tiles, we probe them
in order and check if the special system controller register
confirm their presence before populating the node for a tile.

This supercedes the code in arch/arm/mach-integrator/lm.[c|h]
and makes it possible to populate the tiles using the device
tree instead of boardfile-based descriptions.

Tested with all peripherals including graphics and MMC card
working fine with the IM-PD1 example tile from Arm.

Signed-off-by: Linus Walleij <[email protected]>

show more ...

bus: mhi: core: Add support for registering MHI controllers

This commit adds support for registering MHI controller drivers with
the MHI stack. MHI controller drivers manages the interaction with th

bus: mhi: core: Add support for registering MHI controllers

This commit adds support for registering MHI controller drivers with
the MHI stack. MHI controller drivers manages the interaction with the
MHI client devices such as the external modems and WiFi chipsets. They
are also the MHI bus master in charge of managing the physical link
between the host and client device.

This is based on the patch submitted by Sujeev Dias:
https://lkml.org/lkml/2018/7/9/987

Signed-off-by: Sujeev Dias <[email protected]>
Signed-off-by: Siddartha Mohanadoss <[email protected]>
[jhugo: added static config for controllers and fixed several bugs]
Signed-off-by: Jeffrey Hugo <[email protected]>
[mani: removed DT dependency, splitted and cleaned up for upstream]
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus/ti-pwmss: move TI PWMSS driver from PWM to bus subsystem

The TI PWMSS driver is a simple bus driver for providing power
power management for the PWM peripherals on TI AM33xx SoCs, namely
eCAP, e

bus/ti-pwmss: move TI PWMSS driver from PWM to bus subsystem

The TI PWMSS driver is a simple bus driver for providing power
power management for the PWM peripherals on TI AM33xx SoCs, namely
eCAP, eHRPWM and eQEP. The eQEP is a counter rather than a PWM, so
it does not make sense to have the bus driver in the PWM subsystem
since the PWMSS is not exclusive to PWM devices.

Signed-off-by: David Lechner <[email protected]>
Signed-off-by: Jonathan Cameron <[email protected]>

show more ...

bus: Add support for Moxtet bus

On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a PCIe pass-t

bus: Add support for Moxtet bus

On the Turris Mox router different modules can be connected to the main
CPU board: currently a module with a SFP cage, a module with MiniPCIe
connector, a PCIe pass-through MiniPCIe connector module, a 4-port
switch module, an 8-port switch module, and a 4-port USB3 module.

For example:
[CPU]-[PCIe-pass-through]-[PCIe]-[8-port switch]-[8-port switch]-[SFP]

Each of this modules has an input and output shift register, and these
are connected via SPI to the CPU board.

Via SPI we are able to discover which modules are connected, in which
order, and we can also read some information about the modules (eg.
their interrupt status), and configure them.
From each module 8 bits can be read (of which low 4 bits identify the
module) and 8 bits can be written.

For example from the module with a SFP cage we can read the LOS,
TX-FAULT and MOD-DEF0 signals, while we can write TX-DISABLE and
RATE-SELECT signals.

This driver creates a new bus type, called "moxtet". For each Mox module
it finds via SPI, it creates a new device on the moxtet bus so that
drivers can be written for them.

It also implements a virtual interrupt controller for the modules which
send their interrupt status over the SPI shift register. These modules
do this in addition to sending their interrupt status via the shared
interrupt line. When the shared interrupt is triggered, we read from the
shift register and handle IRQs for all devices which are in interrupt.

The topology of how Mox modules are connected can then be read by
listing /sys/bus/moxtet/devices.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marek Behún <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

bus: add bus driver for accessing Allwinner A64 DE2

The "Display Engine 2.0" (usually called DE2) on the Allwinner A64 SoC
is different from the ones on other Allwinner SoCs. It requires a SRAM
regi

bus: add bus driver for accessing Allwinner A64 DE2

The "Display Engine 2.0" (usually called DE2) on the Allwinner A64 SoC
is different from the ones on other Allwinner SoCs. It requires a SRAM
region to be claimed, otherwise all DE2 subblocks won't be accessible.

Add a bus driver for the Allwinner A64 DE2 part which claims the SRAM
region when probing.

Signed-off-by: Icenowy Zheng <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>

show more ...

HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings

The low-pin-count (LPC) interface of Hip06/Hip07 accesses I/O port space of
peripherals.

Implement the LPC host controller driver whic

HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings

The low-pin-count (LPC) interface of Hip06/Hip07 accesses I/O port space of
peripherals.

Implement the LPC host controller driver which performs the I/O operations
on the underlying hardware. We don't want to touch existing drivers such
as ipmi-bt, so this driver applies the indirect-IO introduced in the
previous patch after registering an indirect-IO node to the indirect-IO
devices list which will be searched by the I/O accessors to retrieve the
host-local I/O port.

The driver config is set as a bool instead of a tristate. The reason here
is that, by the very nature of the driver providing a logical PIO range, it
does not make sense to have this driver as a loadable module. Another more
specific reason is that the Huawei D03 board which includes Hip06 SoC
requires the LPC bus for UART console, so should be built in.

Tested-by: dann frazier <[email protected]>
Signed-off-by: Zou Rongrong <[email protected]>
Signed-off-by: Zhichang Yuan <[email protected]>
Signed-off-by: John Garry <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Rob Herring <[email protected]> # dts part

show more ...

drivers/bus: Move Arm CCN PMU driver

The arm-ccn driver is purely a perf driver for the CCN PMU, not a bus
driver in the sense of the other residents of drivers/bus/, so let's
move it to the appropr

drivers/bus: Move Arm CCN PMU driver

The arm-ccn driver is purely a perf driver for the CCN PMU, not a bus
driver in the sense of the other residents of drivers/bus/, so let's
move it to the appropriate place for SoC PMU drivers. Not to mention
moving the documentation accordingly as well.

Acked-by: Pawel Moll <[email protected]>
Acked-by: Will Deacon <[email protected]>
Signed-off-by: Robin Murphy <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

staging: fsl-mc: Move core bus out of staging

Move the source files out of staging into their final locations:
-mc.h include file in drivers/staging/fsl-mc/include go to include/linux/fsl
-sourc

staging: fsl-mc: Move core bus out of staging

Move the source files out of staging into their final locations:
-mc.h include file in drivers/staging/fsl-mc/include go to include/linux/fsl
-source files in drivers/staging/fsl-mc/bus go to drivers/bus/fsl-mc
-overview.rst, providing an overview of DPAA2, goes to
Documentation/networking/dpaa2/overview.rst

Update or delete other remaining staging files -- Makefile, Kconfig, TODO.
Update dpaa2_eth and dpio staging drivers.
Add integration bits for the documentation build system.

Signed-off-by: Stuart Yoder <[email protected]>
[rebased, add dpaa2_eth and dpio #include updates]
Signed-off-by: Laurentiu Tudor <[email protected]>
[rebased, split irqchip to separate patch]
Signed-off-by: Bogdan Purcareata <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Marc Zyngier <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: add driver for the Technologic Systems NBUS

This driver implements a GPIOs bit-banged bus, called the NBUS by
Technologic Systems. It is used to communicate with the peripherals in
the FPGA on

bus: add driver for the Technologic Systems NBUS

This driver implements a GPIOs bit-banged bus, called the NBUS by
Technologic Systems. It is used to communicate with the peripherals in
the FPGA on the TS-4600 SoM.

Signed-off-by: Sebastien Bourdelin <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

bus: ti-sysc: Add minimal TI sysc interconnect target driver

We can handle the sysc interconnect target module in a generic way
for many TI SoCs. Initially let's just enable runtime PM with
autosusp

bus: ti-sysc: Add minimal TI sysc interconnect target driver

We can handle the sysc interconnect target module in a generic way
for many TI SoCs. Initially let's just enable runtime PM with
autosuspend, and probe the children. This can already be used for
idling interconnect target modules that don't have any device driver
available for the child devices.

For now, the "ti,hwmods" custom binding is still required. That will
be eventually deprecated in later patches. And more features will be
added, such as parsing for sysc capabilities so we can continue
removing the legacy platform data.

Cc: Benoît Cousson <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Nishanth Menon <[email protected]>
Cc: Matthijs van Duin <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Peter Ujfalusi <[email protected]>
Cc: Sakari Ailus <[email protected]>
Cc: Tero Kristo <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: [email protected]
Signed-off-by: Tony Lindgren <[email protected]>

show more ...

bus: Add support for Tegra Generic Memory Interface

The Generic Memory Interface bus can be used to connect high-speed
devices such as NOR flash, FPGAs, DSPs...

Signed-off-by: Mirza Krak <mirza.kra

bus: Add support for Tegra Generic Memory Interface

The Generic Memory Interface bus can be used to connect high-speed
devices such as NOR flash, FPGAs, DSPs...

Signed-off-by: Mirza Krak <[email protected]>
Tested-by: Marcel Ziswiler <[email protected]>
Tested-on: Colibri T20/T30 on EvalBoard V3.x and GMI-Memory Board
Acked-by: Jon Hunter <[email protected]>
[[email protected]: symmetry and coding style OCD]
Signed-off-by: Thierry Reding <[email protected]>

show more ...

bus: davinci: add support for da8xx bus master priority control

Create the driver for the da8xx master peripheral priority
configuration and implement support for writing to the three
Master Priorit

bus: davinci: add support for da8xx bus master priority control

Create the driver for the da8xx master peripheral priority
configuration and implement support for writing to the three
Master Priority registers on da850 SoCs.

Reviewed-by: Kevin Hilman <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
[[email protected]: subject line adjustment]
Signed-off-by: Sekhar Nori <[email protected]>

show more ...

bus: qcom: add EBI2 driver

This adds a driver for the Qualcomm External Bus Interface EBI2
found in the MSM8660 and APQ8060 SoCs (at least).

This was tested with the SMSC9112 ethernet on the APQ806

bus: qcom: add EBI2 driver

This adds a driver for the Qualcomm External Bus Interface EBI2
found in the MSM8660 and APQ8060 SoCs (at least).

This was tested with the SMSC9112 ethernet on the APQ8060
Dragonboard sitting on top of the SLOW CS2.

Some of my understanding if very vague and based on guesses and
extrapolations: the documentation in APQ8060 Qualcomm Application
Processor User Guide 80-N7150-14 Rev. A describes select features but
does not document the register bit fields.

Signed-off-by: Linus Walleij <[email protected]>

show more ...

bus: Add support for Tegra ACONNECT

Add a bus driver for the Tegra ACONNECT which is used to interface to
various devices within the Audio Processing Engine (APE). The purpose
of the bus driver is t

bus: Add support for Tegra ACONNECT

Add a bus driver for the Tegra ACONNECT which is used to interface to
various devices within the Audio Processing Engine (APE). The purpose
of the bus driver is to register child devices that are accessed via
the ACONNECT bus and through the device parent child relationship,
ensure that the appropriate power domain and clocks are enabled for
the ACONNECT when any of the child devices are active. Hence, the
ACONNECT driver simply enables runtime-pm for the ACONNECT device
so that when a child device is resumed, it will enable the power-domain
and clocks associated with the ACONNECT.

Signed-off-by: Jon Hunter <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

bus: uniphier-system-bus: add UniPhier System Bus driver

The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped

bus: uniphier-system-bus: add UniPhier System Bus driver

The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.

This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.

Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x42000000,
0x43000000, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>

show more ...