Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

pci: Remove <common.h> and add needed includes

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

drivers: use dev_read_addr_ptr when cast to pointer

The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Add defines for normal and subtractive PCI bridges

Add following two new PCI class codes defines into pci_ids.h include file:

PCI_CLASS_BRIDGE_PCI_NORMAL
PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update comment about Command/Direct mode

Code is changing PCIe controller from Command mode to Direct mode.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Register controller also when no PCIe card is connected

Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not try to access other buses when link is down

If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Ensure that root port is always on root zero bus

Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.

This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.

Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.

So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.

After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use dev_read_addr()

There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cleanup macro names

Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.

After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.

Rename some macros for consistency with other macros.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use standard register macros from pci.h

PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.

Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.

Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: Add standard PCIe ECAM macros

Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.

Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.

Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.

U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Program the data strobe for config read requests

According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.

Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.

Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix condition for CRS response

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting bars on PCI Bridge

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update private structure documentation

There were several changes for this structure but the documentation was
not changed at the time. Fix this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cosmetic change

Update indentation in driver's private structure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not automatically enable bus mastering on PCI Bridge

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Add support for accessing PCI Bridge on root bus

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix pcie_advk_link_up()

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't spam about PIO Response Status

Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().

For example CRS is not an error status, it just says that the request
should be retried.

Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement re-issuing config requests on CRS response

According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.

Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.

This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.

Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable returning CRS response

There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.

Therefore disable returning CRS response for now.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix handling PIO config error responses

Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.

So implement this logic in pci-aardvark.c driver properly.

aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.

More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.

And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.

These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix typo in comment

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix configuring PCIe resources

The `ranges` DT property of the PCIe node is currently ignored by
Aardvark driver - all entries are used as transparent PCIe MEM, despite
some of them being defined for IO in DT.

This is because the driver does not setup PCIe outbound windows and thus
a default configuration is used.

This can cause an external abort on CPU when a device driver tries to
access non-MEM space.

Setup the PCIe windows according to the `ranges` property for all
non-MEM resources (currently only IO) and also non-transparent MEM
resources.

Because Linux expects that bootloader does not setup Aardvark PCIe
windows, disable them before booting Linux.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible

Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable bus mastering when unloading driver

Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's
remove method, which is called before booting Linux kernel.

This ensures that PCIe device which was initialized and used by U-Boot
cannot do new DMA transfers until Linux initializes PCI subsystem and loads
appropriate drivers for the device.

During initialization of PCI subsystem Linux in fact disables this bus
mastering on Root Bridge (and later enables it when driver is loaded and
configured), but there is a possibility of a small window after U-Boot
boots Linux when bus mastering is enabled, which is not correct.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe

During our debugging of the Aardvark driver in Linux we have discovered
that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard
PCIe Link Control Register for PCIe Root Bridge. This led us to discover
that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding
comment by this macro's usage is misleading; this bit in fact controls
Retrain Link, which, according to PCIe base spec is defined as:

A write of 1b to this bit initiates Link retraining by directing the
Physical Layer LTSSM to the Recovery state. If the LTSSM is already in
Recovery or Configuration, re-entering Recovery is permitted but not
required.

Entering Recovery state is normally done from LTSSM L0, L0s and L1 states.
But since the pci-aardvark.c driver enables Link Training just a few lines
above, the controller is not in L0 ready state yet. So setting aardvark bit
PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this
place.

Moreover, trying to enter LTSSM Recovery state without other configuration
is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since
Recovery state is not entered, these issues are not triggered.

Remove code which tries to enter LTSSM Recovery state completely.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix processing PIO transfers

Trying to clear PIO_START register when it is non-zero (which indicates
that previous PIO transfer has not finished yet) causes an External
Abort with SError 0xbf000002.

This bug is currently worked around in TF-A by handling External Aborts
in EL3 and ignoring this particular SError.

This workaround was also discussed at:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

Implement a proper fix to prevent this External Abort. As it is not
possible to cancel a pending PIO transfer, simply do not start a new one
if previous has not finished yet. In this case return an error to the
caller.

In most cases this SError happens when there is no PCIe card connected
or when PCIe link is down. The reason is that in these cases a PIO
transfer takes about 1.44 seconds. For this reason we also increase the
wait timeout in pcie_advk_wait_pio() to 1.5 seconds.

If PIO read transfer for PCI_VENDOR_ID register times out, or if it
isn't possible to read it yet because previous transfer is not finished,
return Completion Retry Status value instead of failing, to give the
caller a chance to send a new read request.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement workaround for the readback value of VEND_ID

Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):

The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.

The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).

Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.

This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

Fix usage of VL805 XHCI PCIe controller when it is connected via PCIe to
Armada 3720 SOC. Without this U-Boot crashes when trying to access
enumerated USB devices connected to this XHCI PCIe controller.

This should be done according to the PCIe Link Initialization sequence, as
defined in Marvell Armada 3720 Functional Specification.

Linux has this code too.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Fix printing debug messages

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2021.01-rc5' into next

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>

Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"

This reverts commit 828d32621686aec593076d16445d39b9b8d49c05.

This change revers code which asserting PERST# signal when unloading
driver. Driver's remove callback is still there as it is used for other
functionality.

Asserting PERST# signal prior booting kernel is causing that A3720 boards
(Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and
4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900)
and anymore. When PERST# signal is not asserted these cards are detected
correctly. As this is regression for existing stable Linux kernel versions
revert this problematic change in U-Boot.

To make cards working with OpenWRT 4.14 kernel it is needed to disable link
training prior booting kernel, which is already done in driver's remove
callback.

Described issue is in Linux kernel pci aardvark driver which is (hopefully)
fixed in latest upstream versions. Latest upstream versions should be able
to initialize PCIe bus and detects cards independently of the link training
and PERST# signal state.

So with this change, U-Boot on A3720 boards should be able to boot OpenWRT
4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

dm: Avoid accessing seq directly

At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.

The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename ofdata_to_platdata() to of_to_plat()

This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

arm64: a37xx: pci: Disable link training when unloading driver

As required by PCI Express spec a delay for at least 100ms after
de-asserting PERST# signal is needed before link training is enabled.

Linux kernels prior to 5.8 version do not automatically disable link
training before de-asserting PERST# signal, therefore this requirement is
not fulfilled.

Above requirement is needed for proper detection of some Compex PCIe WiFi
cards. Otherwise Linux kernel cannot detect it.

To allow using those PCIe cards with older Linux kernel versions booted by
U-Boot compiled with U-Boot a37xx pci driver, disable link training in
U-Boot when unloading this pci driver.

Thanks to DM_FLAG_OS_PREPARE flag, U-Boot automatically unload this driver
when booting Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Depends on DM_GPIO

For proper initialization of aardvark pci driver it is required to
de-assert reset GPIO. So depeneds on DM_GPIO option.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Assert PERST# signal when unloading driver

This change ensures that PCIe card is put into reset state when U-Boot
stops using it.

DM_FLAG_OS_PREPARE ensures that U-Boot executes driver's remove callback
prior booting Linux kernel.

Linux kernel pci-aardvark driver needs to reset PCIe card via PERST# signal
prior initializing it. If it does not issue reset then some PCIe cards
(specially Compex WiFi cards) are not detected at all.

Putting PCIe card into reset state prior booting Linux kernel would ensure
that card would be properly reset at time when Linux kernel starts
initializing pci-aardvark driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT

Change active-high to active-low and change DT property name from
reset-gpio to reset-gpios. This format of gpio reset is used by
pci-aardvark driver in Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

common: Drop linux/delay.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Create a new header file for 'compat' features

At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: pci: Update the PCI read_config() method to const dev *

At present this method uses a non-const udevice pointer, but the call
should not modify the device. Use a const pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: gpio: Allow control of GPIO uclass in SPL

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

arm64: a37xx: pci: add support for aardvark pcie driver

This patch introduced the Aardvark PCIe driver based
driver model.
The PCIe driver is supposed to work in Root Complex
mode. It only supports X1 lane width.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38725
Reviewed-by: Victor Gu <xigu@marvell.com>
Reviewed-by: Hua Jing <jinghua@marvell.com>
Tested-by: Hua Jing <jinghua@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Ken Ma <make@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>

pci: Remove <common.h> and add needed includes

Remove <common.h> from this driver directory and when needed
add missing include files directly.

Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>

drivers: use dev_read_addr_ptr when cast to pointer

The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Add defines for normal and subtractive PCI bridges

Add following two new PCI class codes defines into pci_ids.h include file:

PCI_CLASS_BRIDGE_PCI_NORMAL
PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update comment about Command/Direct mode

Code is changing PCIe controller from Command mode to Direct mode.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Register controller also when no PCIe card is connected

Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not try to access other buses when link is down

If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Ensure that root port is always on root zero bus

Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.

This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.

Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.

So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.

After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use dev_read_addr()

There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cleanup macro names

Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.

After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.

Rename some macros for consistency with other macros.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use standard register macros from pci.h

PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.

Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.

Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: Add standard PCIe ECAM macros

Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.

Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.

Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.

U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Program the data strobe for config read requests

According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.

Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.

Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix condition for CRS response

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting bars on PCI Bridge

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update private structure documentation

There were several changes for this structure but the documentation was
not changed at the time. Fix this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cosmetic change

Update indentation in driver's private structure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not automatically enable bus mastering on PCI Bridge

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Add support for accessing PCI Bridge on root bus

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix pcie_advk_link_up()

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't spam about PIO Response Status

Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().

For example CRS is not an error status, it just says that the request
should be retried.

Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement re-issuing config requests on CRS response

According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.

Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.

This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.

Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable returning CRS response

There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.

Therefore disable returning CRS response for now.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix handling PIO config error responses

Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.

So implement this logic in pci-aardvark.c driver properly.

aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.

More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.

And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.

These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix typo in comment

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix configuring PCIe resources

The `ranges` DT property of the PCIe node is currently ignored by
Aardvark driver - all entries are used as transparent PCIe MEM, despite
some of them being defined for IO in DT.

This is because the driver does not setup PCIe outbound windows and thus
a default configuration is used.

This can cause an external abort on CPU when a device driver tries to
access non-MEM space.

Setup the PCIe windows according to the `ranges` property for all
non-MEM resources (currently only IO) and also non-transparent MEM
resources.

Because Linux expects that bootloader does not setup Aardvark PCIe
windows, disable them before booting Linux.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible

Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable bus mastering when unloading driver

Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's
remove method, which is called before booting Linux kernel.

This ensures that PCIe device which was initialized and used by U-Boot
cannot do new DMA transfers until Linux initializes PCI subsystem and loads
appropriate drivers for the device.

During initialization of PCI subsystem Linux in fact disables this bus
mastering on Root Bridge (and later enables it when driver is loaded and
configured), but there is a possibility of a small window after U-Boot
boots Linux when bus mastering is enabled, which is not correct.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe

During our debugging of the Aardvark driver in Linux we have discovered
that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard
PCIe Link Control Register for PCIe Root Bridge. This led us to discover
that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding
comment by this macro's usage is misleading; this bit in fact controls
Retrain Link, which, according to PCIe base spec is defined as:

A write of 1b to this bit initiates Link retraining by directing the
Physical Layer LTSSM to the Recovery state. If the LTSSM is already in
Recovery or Configuration, re-entering Recovery is permitted but not
required.

Entering Recovery state is normally done from LTSSM L0, L0s and L1 states.
But since the pci-aardvark.c driver enables Link Training just a few lines
above, the controller is not in L0 ready state yet. So setting aardvark bit
PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this
place.

Moreover, trying to enter LTSSM Recovery state without other configuration
is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since
Recovery state is not entered, these issues are not triggered.

Remove code which tries to enter LTSSM Recovery state completely.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix processing PIO transfers

Trying to clear PIO_START register when it is non-zero (which indicates
that previous PIO transfer has not finished yet) causes an External
Abort with SError 0xbf000002.

This bug is currently worked around in TF-A by handling External Aborts
in EL3 and ignoring this particular SError.

This workaround was also discussed at:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

Implement a proper fix to prevent this External Abort. As it is not
possible to cancel a pending PIO transfer, simply do not start a new one
if previous has not finished yet. In this case return an error to the
caller.

In most cases this SError happens when there is no PCIe card connected
or when PCIe link is down. The reason is that in these cases a PIO
transfer takes about 1.44 seconds. For this reason we also increase the
wait timeout in pcie_advk_wait_pio() to 1.5 seconds.

If PIO read transfer for PCI_VENDOR_ID register times out, or if it
isn't possible to read it yet because previous transfer is not finished,
return Completion Retry Status value instead of failing, to give the
caller a chance to send a new read request.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement workaround for the readback value of VEND_ID

Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):

The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.

The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).

Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.

This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

Fix usage of VL805 XHCI PCIe controller when it is connected via PCIe to
Armada 3720 SOC. Without this U-Boot crashes when trying to access
enumerated USB devices connected to this XHCI PCIe controller.

This should be done according to the PCIe Link Initialization sequence, as
defined in Marvell Armada 3720 Functional Specification.

Linux has this code too.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Fix printing debug messages

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2021.01-rc5' into next

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>

Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"

This reverts commit 828d32621686aec593076d16445d39b9b8d49c05.

This change revers code which asserting PERST# signal when unloading
driver. Driver's remove callback is still there as it is used for other
functionality.

Asserting PERST# signal prior booting kernel is causing that A3720 boards
(Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and
4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900)
and anymore. When PERST# signal is not asserted these cards are detected
correctly. As this is regression for existing stable Linux kernel versions
revert this problematic change in U-Boot.

To make cards working with OpenWRT 4.14 kernel it is needed to disable link
training prior booting kernel, which is already done in driver's remove
callback.

Described issue is in Linux kernel pci aardvark driver which is (hopefully)
fixed in latest upstream versions. Latest upstream versions should be able
to initialize PCIe bus and detects cards independently of the link training
and PERST# signal state.

So with this change, U-Boot on A3720 boards should be able to boot OpenWRT
4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

dm: Avoid accessing seq directly

At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.

The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename ofdata_to_platdata() to of_to_plat()

This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

arm64: a37xx: pci: Disable link training when unloading driver

As required by PCI Express spec a delay for at least 100ms after
de-asserting PERST# signal is needed before link training is enabled.

Linux kernels prior to 5.8 version do not automatically disable link
training before de-asserting PERST# signal, therefore this requirement is
not fulfilled.

Above requirement is needed for proper detection of some Compex PCIe WiFi
cards. Otherwise Linux kernel cannot detect it.

To allow using those PCIe cards with older Linux kernel versions booted by
U-Boot compiled with U-Boot a37xx pci driver, disable link training in
U-Boot when unloading this pci driver.

Thanks to DM_FLAG_OS_PREPARE flag, U-Boot automatically unload this driver
when booting Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Depends on DM_GPIO

For proper initialization of aardvark pci driver it is required to
de-assert reset GPIO. So depeneds on DM_GPIO option.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Assert PERST# signal when unloading driver

This change ensures that PCIe card is put into reset state when U-Boot
stops using it.

DM_FLAG_OS_PREPARE ensures that U-Boot executes driver's remove callback
prior booting Linux kernel.

Linux kernel pci-aardvark driver needs to reset PCIe card via PERST# signal
prior initializing it. If it does not issue reset then some PCIe cards
(specially Compex WiFi cards) are not detected at all.

Putting PCIe card into reset state prior booting Linux kernel would ensure
that card would be properly reset at time when Linux kernel starts
initializing pci-aardvark driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT

Change active-high to active-low and change DT property name from
reset-gpio to reset-gpios. This format of gpio reset is used by
pci-aardvark driver in Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

common: Drop linux/delay.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Create a new header file for 'compat' features

At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: pci: Update the PCI read_config() method to const dev *

At present this method uses a non-const udevice pointer, but the call
should not modify the device. Use a const pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: gpio: Allow control of GPIO uclass in SPL

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

arm64: a37xx: pci: add support for aardvark pcie driver

This patch introduced the Aardvark PCIe driver based
driver model.
The PCIe driver is supposed to work in Root Complex
mode. It only supports X1 lane width.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38725
Reviewed-by: Victor Gu <xigu@marvell.com>
Reviewed-by: Hua Jing <jinghua@marvell.com>
Tested-by: Hua Jing <jinghua@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Ken Ma <make@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>

drivers: use dev_read_addr_ptr when cast to pointer

The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.

Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

pci: Add defines for normal and subtractive PCI bridges

Add following two new PCI class codes defines into pci_ids.h include file:

PCI_CLASS_BRIDGE_PCI_NORMAL
PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update comment about Command/Direct mode

Code is changing PCIe controller from Command mode to Direct mode.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Register controller also when no PCIe card is connected

Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not try to access other buses when link is down

If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Ensure that root port is always on root zero bus

Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.

This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.

Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.

So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.

After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use dev_read_addr()

There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cleanup macro names

Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.

After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.

Rename some macros for consistency with other macros.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use standard register macros from pci.h

PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.

Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.

Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: Add standard PCIe ECAM macros

Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.

Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.

Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.

U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Program the data strobe for config read requests

According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.

Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.

Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix condition for CRS response

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting bars on PCI Bridge

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update private structure documentation

There were several changes for this structure but the documentation was
not changed at the time. Fix this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cosmetic change

Update indentation in driver's private structure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not automatically enable bus mastering on PCI Bridge

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Add support for accessing PCI Bridge on root bus

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix pcie_advk_link_up()

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't spam about PIO Response Status

Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().

For example CRS is not an error status, it just says that the request
should be retried.

Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement re-issuing config requests on CRS response

According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.

Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.

This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.

Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable returning CRS response

There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.

Therefore disable returning CRS response for now.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix handling PIO config error responses

Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.

So implement this logic in pci-aardvark.c driver properly.

aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.

More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.

And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.

These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix typo in comment

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix configuring PCIe resources

The `ranges` DT property of the PCIe node is currently ignored by
Aardvark driver - all entries are used as transparent PCIe MEM, despite
some of them being defined for IO in DT.

This is because the driver does not setup PCIe outbound windows and thus
a default configuration is used.

This can cause an external abort on CPU when a device driver tries to
access non-MEM space.

Setup the PCIe windows according to the `ranges` property for all
non-MEM resources (currently only IO) and also non-transparent MEM
resources.

Because Linux expects that bootloader does not setup Aardvark PCIe
windows, disable them before booting Linux.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible

Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable bus mastering when unloading driver

Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's
remove method, which is called before booting Linux kernel.

This ensures that PCIe device which was initialized and used by U-Boot
cannot do new DMA transfers until Linux initializes PCI subsystem and loads
appropriate drivers for the device.

During initialization of PCI subsystem Linux in fact disables this bus
mastering on Root Bridge (and later enables it when driver is loaded and
configured), but there is a possibility of a small window after U-Boot
boots Linux when bus mastering is enabled, which is not correct.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe

During our debugging of the Aardvark driver in Linux we have discovered
that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard
PCIe Link Control Register for PCIe Root Bridge. This led us to discover
that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding
comment by this macro's usage is misleading; this bit in fact controls
Retrain Link, which, according to PCIe base spec is defined as:

A write of 1b to this bit initiates Link retraining by directing the
Physical Layer LTSSM to the Recovery state. If the LTSSM is already in
Recovery or Configuration, re-entering Recovery is permitted but not
required.

Entering Recovery state is normally done from LTSSM L0, L0s and L1 states.
But since the pci-aardvark.c driver enables Link Training just a few lines
above, the controller is not in L0 ready state yet. So setting aardvark bit
PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this
place.

Moreover, trying to enter LTSSM Recovery state without other configuration
is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since
Recovery state is not entered, these issues are not triggered.

Remove code which tries to enter LTSSM Recovery state completely.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix processing PIO transfers

Trying to clear PIO_START register when it is non-zero (which indicates
that previous PIO transfer has not finished yet) causes an External
Abort with SError 0xbf000002.

This bug is currently worked around in TF-A by handling External Aborts
in EL3 and ignoring this particular SError.

This workaround was also discussed at:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

Implement a proper fix to prevent this External Abort. As it is not
possible to cancel a pending PIO transfer, simply do not start a new one
if previous has not finished yet. In this case return an error to the
caller.

In most cases this SError happens when there is no PCIe card connected
or when PCIe link is down. The reason is that in these cases a PIO
transfer takes about 1.44 seconds. For this reason we also increase the
wait timeout in pcie_advk_wait_pio() to 1.5 seconds.

If PIO read transfer for PCI_VENDOR_ID register times out, or if it
isn't possible to read it yet because previous transfer is not finished,
return Completion Retry Status value instead of failing, to give the
caller a chance to send a new read request.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement workaround for the readback value of VEND_ID

Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):

The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.

The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).

Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.

This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

Fix usage of VL805 XHCI PCIe controller when it is connected via PCIe to
Armada 3720 SOC. Without this U-Boot crashes when trying to access
enumerated USB devices connected to this XHCI PCIe controller.

This should be done according to the PCIe Link Initialization sequence, as
defined in Marvell Armada 3720 Functional Specification.

Linux has this code too.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Fix printing debug messages

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2021.01-rc5' into next

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>

Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"

This reverts commit 828d32621686aec593076d16445d39b9b8d49c05.

This change revers code which asserting PERST# signal when unloading
driver. Driver's remove callback is still there as it is used for other
functionality.

Asserting PERST# signal prior booting kernel is causing that A3720 boards
(Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and
4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900)
and anymore. When PERST# signal is not asserted these cards are detected
correctly. As this is regression for existing stable Linux kernel versions
revert this problematic change in U-Boot.

To make cards working with OpenWRT 4.14 kernel it is needed to disable link
training prior booting kernel, which is already done in driver's remove
callback.

Described issue is in Linux kernel pci aardvark driver which is (hopefully)
fixed in latest upstream versions. Latest upstream versions should be able
to initialize PCIe bus and detects cards independently of the link training
and PERST# signal state.

So with this change, U-Boot on A3720 boards should be able to boot OpenWRT
4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

dm: Avoid accessing seq directly

At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.

The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename ofdata_to_platdata() to of_to_plat()

This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

arm64: a37xx: pci: Disable link training when unloading driver

As required by PCI Express spec a delay for at least 100ms after
de-asserting PERST# signal is needed before link training is enabled.

Linux kernels prior to 5.8 version do not automatically disable link
training before de-asserting PERST# signal, therefore this requirement is
not fulfilled.

Above requirement is needed for proper detection of some Compex PCIe WiFi
cards. Otherwise Linux kernel cannot detect it.

To allow using those PCIe cards with older Linux kernel versions booted by
U-Boot compiled with U-Boot a37xx pci driver, disable link training in
U-Boot when unloading this pci driver.

Thanks to DM_FLAG_OS_PREPARE flag, U-Boot automatically unload this driver
when booting Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Depends on DM_GPIO

For proper initialization of aardvark pci driver it is required to
de-assert reset GPIO. So depeneds on DM_GPIO option.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Assert PERST# signal when unloading driver

This change ensures that PCIe card is put into reset state when U-Boot
stops using it.

DM_FLAG_OS_PREPARE ensures that U-Boot executes driver's remove callback
prior booting Linux kernel.

Linux kernel pci-aardvark driver needs to reset PCIe card via PERST# signal
prior initializing it. If it does not issue reset then some PCIe cards
(specially Compex WiFi cards) are not detected at all.

Putting PCIe card into reset state prior booting Linux kernel would ensure
that card would be properly reset at time when Linux kernel starts
initializing pci-aardvark driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT

Change active-high to active-low and change DT property name from
reset-gpio to reset-gpios. This format of gpio reset is used by
pci-aardvark driver in Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

common: Drop linux/delay.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Create a new header file for 'compat' features

At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: pci: Update the PCI read_config() method to const dev *

At present this method uses a non-const udevice pointer, but the call
should not modify the device. Use a const pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: gpio: Allow control of GPIO uclass in SPL

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

arm64: a37xx: pci: add support for aardvark pcie driver

This patch introduced the Aardvark PCIe driver based
driver model.
The PCIe driver is supposed to work in Root Complex
mode. It only supports X1 lane width.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38725
Reviewed-by: Victor Gu <xigu@marvell.com>
Reviewed-by: Hua Jing <jinghua@marvell.com>
Tested-by: Hua Jing <jinghua@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Ken Ma <make@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>

pci: Add defines for normal and subtractive PCI bridges

Add following two new PCI class codes defines into pci_ids.h include file:

PCI_CLASS_BRIDGE_PCI_NORMAL
PCI_CLASS_BRIDGE_PCI_SUBTRACTIVE

And use these defines in all U-Boot code for describing PCI class codes for
normal and subtractive PCI bridges.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update comment about Command/Direct mode

Code is changing PCIe controller from Command mode to Direct mode.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Register controller also when no PCIe card is connected

Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not try to access other buses when link is down

If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Ensure that root port is always on root zero bus

Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.

This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.

Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.

So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.

After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use dev_read_addr()

There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cleanup macro names

Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.

After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.

Rename some macros for consistency with other macros.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use standard register macros from pci.h

PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.

Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.

Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: Add standard PCIe ECAM macros

Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.

Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.

Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.

U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Program the data strobe for config read requests

According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.

Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.

Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix condition for CRS response

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting bars on PCI Bridge

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update private structure documentation

There were several changes for this structure but the documentation was
not changed at the time. Fix this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cosmetic change

Update indentation in driver's private structure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not automatically enable bus mastering on PCI Bridge

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Add support for accessing PCI Bridge on root bus

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix pcie_advk_link_up()

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't spam about PIO Response Status

Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().

For example CRS is not an error status, it just says that the request
should be retried.

Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement re-issuing config requests on CRS response

According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.

Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.

This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.

Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable returning CRS response

There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.

Therefore disable returning CRS response for now.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix handling PIO config error responses

Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.

So implement this logic in pci-aardvark.c driver properly.

aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.

More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.

And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.

These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix typo in comment

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix configuring PCIe resources

The `ranges` DT property of the PCIe node is currently ignored by
Aardvark driver - all entries are used as transparent PCIe MEM, despite
some of them being defined for IO in DT.

This is because the driver does not setup PCIe outbound windows and thus
a default configuration is used.

This can cause an external abort on CPU when a device driver tries to
access non-MEM space.

Setup the PCIe windows according to the `ranges` property for all
non-MEM resources (currently only IO) and also non-transparent MEM
resources.

Because Linux expects that bootloader does not setup Aardvark PCIe
windows, disable them before booting Linux.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible

Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable bus mastering when unloading driver

Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's
remove method, which is called before booting Linux kernel.

This ensures that PCIe device which was initialized and used by U-Boot
cannot do new DMA transfers until Linux initializes PCI subsystem and loads
appropriate drivers for the device.

During initialization of PCI subsystem Linux in fact disables this bus
mastering on Root Bridge (and later enables it when driver is loaded and
configured), but there is a possibility of a small window after U-Boot
boots Linux when bus mastering is enabled, which is not correct.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe

During our debugging of the Aardvark driver in Linux we have discovered
that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard
PCIe Link Control Register for PCIe Root Bridge. This led us to discover
that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding
comment by this macro's usage is misleading; this bit in fact controls
Retrain Link, which, according to PCIe base spec is defined as:

A write of 1b to this bit initiates Link retraining by directing the
Physical Layer LTSSM to the Recovery state. If the LTSSM is already in
Recovery or Configuration, re-entering Recovery is permitted but not
required.

Entering Recovery state is normally done from LTSSM L0, L0s and L1 states.
But since the pci-aardvark.c driver enables Link Training just a few lines
above, the controller is not in L0 ready state yet. So setting aardvark bit
PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this
place.

Moreover, trying to enter LTSSM Recovery state without other configuration
is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since
Recovery state is not entered, these issues are not triggered.

Remove code which tries to enter LTSSM Recovery state completely.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix processing PIO transfers

Trying to clear PIO_START register when it is non-zero (which indicates
that previous PIO transfer has not finished yet) causes an External
Abort with SError 0xbf000002.

This bug is currently worked around in TF-A by handling External Aborts
in EL3 and ignoring this particular SError.

This workaround was also discussed at:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

Implement a proper fix to prevent this External Abort. As it is not
possible to cancel a pending PIO transfer, simply do not start a new one
if previous has not finished yet. In this case return an error to the
caller.

In most cases this SError happens when there is no PCIe card connected
or when PCIe link is down. The reason is that in these cases a PIO
transfer takes about 1.44 seconds. For this reason we also increase the
wait timeout in pcie_advk_wait_pio() to 1.5 seconds.

If PIO read transfer for PCI_VENDOR_ID register times out, or if it
isn't possible to read it yet because previous transfer is not finished,
return Completion Retry Status value instead of failing, to give the
caller a chance to send a new read request.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement workaround for the readback value of VEND_ID

Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):

The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.

The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).

Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.

This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

Fix usage of VL805 XHCI PCIe controller when it is connected via PCIe to
Armada 3720 SOC. Without this U-Boot crashes when trying to access
enumerated USB devices connected to this XHCI PCIe controller.

This should be done according to the PCIe Link Initialization sequence, as
defined in Marvell Armada 3720 Functional Specification.

Linux has this code too.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Fix printing debug messages

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2021.01-rc5' into next

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>

Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"

This reverts commit 828d32621686aec593076d16445d39b9b8d49c05.

This change revers code which asserting PERST# signal when unloading
driver. Driver's remove callback is still there as it is used for other
functionality.

Asserting PERST# signal prior booting kernel is causing that A3720 boards
(Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and
4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900)
and anymore. When PERST# signal is not asserted these cards are detected
correctly. As this is regression for existing stable Linux kernel versions
revert this problematic change in U-Boot.

To make cards working with OpenWRT 4.14 kernel it is needed to disable link
training prior booting kernel, which is already done in driver's remove
callback.

Described issue is in Linux kernel pci aardvark driver which is (hopefully)
fixed in latest upstream versions. Latest upstream versions should be able
to initialize PCIe bus and detects cards independently of the link training
and PERST# signal state.

So with this change, U-Boot on A3720 boards should be able to boot OpenWRT
4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

dm: Avoid accessing seq directly

At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.

The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename ofdata_to_platdata() to of_to_plat()

This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

arm64: a37xx: pci: Disable link training when unloading driver

As required by PCI Express spec a delay for at least 100ms after
de-asserting PERST# signal is needed before link training is enabled.

Linux kernels prior to 5.8 version do not automatically disable link
training before de-asserting PERST# signal, therefore this requirement is
not fulfilled.

Above requirement is needed for proper detection of some Compex PCIe WiFi
cards. Otherwise Linux kernel cannot detect it.

To allow using those PCIe cards with older Linux kernel versions booted by
U-Boot compiled with U-Boot a37xx pci driver, disable link training in
U-Boot when unloading this pci driver.

Thanks to DM_FLAG_OS_PREPARE flag, U-Boot automatically unload this driver
when booting Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Depends on DM_GPIO

For proper initialization of aardvark pci driver it is required to
de-assert reset GPIO. So depeneds on DM_GPIO option.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Assert PERST# signal when unloading driver

This change ensures that PCIe card is put into reset state when U-Boot
stops using it.

DM_FLAG_OS_PREPARE ensures that U-Boot executes driver's remove callback
prior booting Linux kernel.

Linux kernel pci-aardvark driver needs to reset PCIe card via PERST# signal
prior initializing it. If it does not issue reset then some PCIe cards
(specially Compex WiFi cards) are not detected at all.

Putting PCIe card into reset state prior booting Linux kernel would ensure
that card would be properly reset at time when Linux kernel starts
initializing pci-aardvark driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT

Change active-high to active-low and change DT property name from
reset-gpio to reset-gpios. This format of gpio reset is used by
pci-aardvark driver in Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

common: Drop linux/delay.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Create a new header file for 'compat' features

At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: pci: Update the PCI read_config() method to const dev *

At present this method uses a non-const udevice pointer, but the call
should not modify the device. Use a const pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: gpio: Allow control of GPIO uclass in SPL

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

arm64: a37xx: pci: add support for aardvark pcie driver

This patch introduced the Aardvark PCIe driver based
driver model.
The PCIe driver is supposed to work in Root Complex
mode. It only supports X1 lane width.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38725
Reviewed-by: Victor Gu <xigu@marvell.com>
Reviewed-by: Hua Jing <jinghua@marvell.com>
Tested-by: Hua Jing <jinghua@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Ken Ma <make@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update comment about Command/Direct mode

Code is changing PCIe controller from Command mode to Direct mode.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Register controller also when no PCIe card is connected

Allow access to config space of PCIe Root Port (which is always present on
the root bus) even when PCIe link is down or no card is connected.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not try to access other buses when link is down

If a PIO request is executed while link-down, the whole controller gets
stuck in a non-functional state, and even after link comes up again, PIO
requests won't work anymore, and a reset of the whole PCIe controller is
needed. Therefore we need to prevent sending PIO requests while the link
is down.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Ensure that root port is always on root zero bus

Writing to the PCI_PRIMARY_BUS register of the root port should not change
bus number on which is root port present.

This PCI_PRIMARY_BUS register is used only for correct configuration of
legacy PCI stuff, like forwarding of PCI special cycles between buses.

Aardvark HW does not support PCI special cycles, so it does not have HW
register for PCI_PRIMARY_BUS and therefore it does not matter what is
stored in this register.

So fix this issue and do not use PCI_PRIMARY_BUS register in pci-aardvark.c
driver for moving root bus of the root port.

After this change there is no reason for storing bus number (zero) into
first_busno variable, so remove this variable.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use dev_read_addr()

There is only one base address, so use dev_read_addr() instead of dev_read_addr_index().

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cleanup macro names

Remove "PCI_" prefix from all macros which are aardvark specific to not
conflict with macros defined in global include file pci.h. Instead add
"ADVK_" prefix for them so it is visible that they are aardvark specific.

After "ADVK_" prefix append keyword which describes register group, so it
would be clear to which register each macro value belongs.

Rename some macros for consistency with other macros.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Use standard register macros from pci.h

PCI config space of the aardvark PCIe Root Port is available only in
internal aardvark memory space starting at offset 0x0. PCI Express
registers (PCI_EXP_*) start at offset 0xc0. And Advanced Error Reporting
registers (PCI_ERR_*) start at offset 0x100.

Replace custom aardvark register macros by standard PCI macros from
include/pci.h file with fixed offset.

Some DEVCTL and AER macros are not defined in include/pci.h file, so define
them in the same way as in linux uapi header file pci_regs.h.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: pci_mvebu, pci_aardvark: Fix size of configuration cache

Since u32 takes up 4 bytes, we need to divide the number of u32s by 4
for cfgcache.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

pci: Add standard PCIe ECAM macros

Lot of PCIe controllers are using ECAM addressing. So add common ECAM
macros into U-Boot's pci.h header file which can be suitable for most
PCI controller drivers.

Replace custom ECAM address macros in every PCI controller driver by new
ECAM macros from U-Boot's pci.h header file.

Similar macros are defined also in Linux kernel. There is a small
difference between Linux and these new U-Boot macros.

U-Boot's PCIE_ECAM_OFFSET() takes device and function numbers in separate
arguments. Linux's PCIE_ECAM_OFFSET() takes device and function numbers
encoded in one argument. The reason is that U-Boot's PCI_DEVFN() macro is
different than Linux's PCI_SLOT() macro. So having device and function
numbers in separate arguments makes code more straightforward.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Program the data strobe for config read requests

According to the Armada 3720 Functional Specification Data Strobe applies
for both read and write config requests.

Data strobe bits configure which bytes from the start address should be
returned for read request. Set value 0xf (all 4 bits) into Data Strobe
register to read all four bytes from specified 32-bit config space
register. Same value for Data Strobe register is programmed by Linux
pci-aardvark.c driver for config read requests.

Without this patch pci-aardvark driver sets data strobe register only
during config write operations. So any followup config read operations
could result with just partial datai returned (if previous write operation
was not 32-bit wide). This patch fixes it and ensures that config read
operations always read all bytes from requested register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix condition for CRS response

As stated in comment above the code, CRS response can be returned to OS
only for 4-byte PCI_VENDOR_ID config read request. So fix the code.

Fixes: 1d7ad68559e2 ("arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting bars on PCI Bridge

PCI Bridge which represents Aardvark PCIe Root Port does not have
configurable bars.

So ensure that write operation to bars registers on PCI Bridge is noop and
bars registers always contain zero address which indicates that bars are
unsupported.

After this change U-Boot 'pci bar 0.0.0' command does not show any
allocated bars for PCI Bridge device.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Update private structure documentation

There were several changes for this structure but the documentation was
not changed at the time. Fix this.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Cosmetic change

Update indentation in driver's private structure.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Handle propagation of CRSSVE bit from PCIe Root Port

Now that PCI Bridge (PCIe Root Port) for Aardvark is emulated in U-Boot,
add support for handling and propagation of CRSSVE bit.

When CRSSVE bit is unset (default), driver has to reissue config
read/write request on CRS response.

CRSSVE bit is supported only when CRSVIS bit is provided in read-only
Root Capabilities register. So manually inject this CRSVIS bit into read
response for that register.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not automatically enable bus mastering on PCI Bridge

Now that PCI Bridge is working for the PCIe Root Port, U-Boot's PCI_PNP
code automatically enables memory access and bus mastering when needed.

We do not need to enable it when setting the HW up.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Add support for accessing PCI Bridge on root bus

Aardvark does not have a real PCIe Root Port device on the root bus.
Instead it has PCIe registers of PCIe Root Port device mapped in
internal Aardvark memory space starting at offset 0xc0.

The PCIe Root Port itself is normally available as a PCI Bridge device
on the root bus with bus number zero. Aardvark instead has the
configuration registers of this PCI Bridge at offset 0x00 of Aardvark's
memory space, but the class code of this device is Mass Storage
Controller (0x010400), instead of PCI Bridge (0x600400), which causes
U-Boot to fail to recognize it as a P2P Bridge

Add a hook into the pcie_advk_read_config() / pcie_advk_write_config()
functions to redirect access for root bus from PIO transfer to this
internal Aardvark memory space. This will allow U-Boot to access
configuration space of this PCI Bridge which represents PCIe Root Port.

Redirect access to PCI Bridge registers in range 0x10 - 0x34 to driver's
internal buffer (cfgcache[]). This is because at those addresses
Aardvark has different registers, incompatible with config space of a
PCI Bridge.

Redirect access to PCI Bridge register PCI_ROM_ADDRESS1 (0x38) to
Aardvark internal address for that register (0x30).

When reading PCI Bridge register PCI_HEADER_TYPE, set it explicitly to
value Type 1 (PCI_HEADER_TYPE_BRIDGE) as PCI Bridge must be of Type 1.

When writing to PCI_PRIMARY_BUS or PCI_SECONDARY_BUS registers on this
PCI Bridge, correctly update driver's first_busno and sec_busno
variables, so that pcie_advk_addr_valid() function can check if address
of any device behind the root bus is valid and that PIO transfers are
started with correct config type (1 vs 0), which is required for
accessing devices behind some PCI bridge after the root bus.

U-Boot's PCI_PNP code sets primary and secondary bus numbers as relative
to the configured bus number of the root bus. This is done so that
U-Boot can support multiple PCIe host bridges or multiple root port
buses, when internal bus numbers are different.

Now that root bus is available, update code in pcie_advk_read_config()
and pcie_advk_write_config() functions to correctly calculate real
Aardvark bus number of the target device from U-Boot's bus number as:
busno = PCI_BUS(bdf) - dev_seq(bus)

Stefan: Small fix of header masking as suggested by Pali.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix pcie_advk_link_up()

Aardvark reports Disabled and Hot Reset LTSSM states as values >= 0x20.
Link is not up in these states, so fix pcie_advk_link_up() function.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't spam about PIO Response Status

Use dev_dbg() instead of dev_err() in pcie_advk_check_pio_status().

For example CRS is not an error status, it just says that the request
should be retried.

Without this, U-Boot spams the terminal with
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x100000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x108000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x110000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x120000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x128000
pcie_advk pcie@d0070000: Non-posted PIO Response Status: UR, 0xc80 @ 0x130000
...
when a device is not connected to a PCIe switch (Unsupported Request
from the switch).

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement re-issuing config requests on CRS response

According to PCIe base specification, if CRS Software Visibility is not
enabled, the Root Complex must re-issue the Configuration Request as a new
Request.

Normally this part of Root Complex is implemented in hardware but aardvark
is somehow special and does not implement it in hardware and expect that
handling of config requests are fully implemented in software.

This re-issuing functionality is required also because U-Boot does not
support CRS Software Visibility feature and therefore expects that Root
Complex re-issues requests as is specified in PCIe base specification.

Retry / re-issue config request up to the PIO_MAX_RETRIES, to prevent
infinite loop. After retry count exceed PIO_MAX_RETRIES, returns failure.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable returning CRS response

There was mistake in commit 4cd61c43fd51 ("arm: a37xx: pci: Fix handling
PIO config error responses"). U-Boot does not support handling of CRS
return value for PCI_VENDOR_ID config read request and also does not set
CRSSVE bit.

Therefore disable returning CRS response for now.

Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 4cd61c43fd51 ("arm: a37xx: pci: Fix handling PIO config error responses")
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix handling PIO config error responses

Returning fabricated CRS value (0xFFFF0001) by PCIe Root Complex to OS is
allowed only for 4-byte PCI_VENDOR_ID config read request and only when
CRSSVE bit in Root Port PCIe device is enabled. In all other error PCIe
Root Complex must return all-ones.

So implement this logic in pci-aardvark.c driver properly.

aardvark HW does not have Root Port PCIe device and U-Boot does not
implement emulation of this device. So expect that CRSSVE bit is set as
U-Boot can already handle CRS value for PCI_VENDOR_ID config read request.

More callers of pci_bus_read_config() function in U-Boot do not check for
return value, but check readback value. Therefore always fill readback
value in pcie_advk_read_config() function. On error fill all-ones of
correct size as it is required for PCIe Root Complex.

And also correctly propagates error from failed config write request to
return value of pcie_advk_write_config() function. Most U-Boot callers
ignores this return value, but it is a good idea to return correct value
from function.

These issues about return value of failed config read requests, including
special handling of CRS were reported by Lorenzo and Bjorn for Linux kernel
driver pci-aardvark together with quotes from PCIe r4.0 spec, see details:
https://lore.kernel.org/linux-pci/20210624213345.3617-1-pali@kernel.org/t/#u

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix typo in comment

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Extend validation for PCIe resources and oubound windows

Remapped address of PCIe outbound window may have set only bits from the
mask. Add additional check that remapped address which is calculated from
PCIe bus address specified in DTS file is valid.

Remove also useless clearing of low 16 bits in win_mask. As win_size is
power of two and is at least 0x10000 it means that it always has zero low
16 bits.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix configuring PCIe resources

The `ranges` DT property of the PCIe node is currently ignored by
Aardvark driver - all entries are used as transparent PCIe MEM, despite
some of them being defined for IO in DT.

This is because the driver does not setup PCIe outbound windows and thus
a default configuration is used.

This can cause an external abort on CPU when a device driver tries to
access non-MEM space.

Setup the PCIe windows according to the `ranges` property for all
non-MEM resources (currently only IO) and also non-transparent MEM
resources.

Because Linux expects that bootloader does not setup Aardvark PCIe
windows, disable them before booting Linux.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix DT compatible string to Linux' DT compatible

Change DT compatible string for A3700 PCIe from 'marvell,armada-37xx-pcie'
to 'marvell,armada-3700-pcie' to make U-Boot A3700 PCIe DT node compatible
with Linux' DT node.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Disable bus mastering when unloading driver

Disable Root Bridge I/O space, memory space and bus mastering in Aardvark's
remove method, which is called before booting Linux kernel.

This ensures that PCIe device which was initialized and used by U-Boot
cannot do new DMA transfers until Linux initializes PCI subsystem and loads
appropriate drivers for the device.

During initialization of PCI subsystem Linux in fact disables this bus
mastering on Root Bridge (and later enables it when driver is loaded and
configured), but there is a possibility of a small window after U-Boot
boots Linux when bus mastering is enabled, which is not correct.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Don't put link into LTSSM Recovery state during probe

During our debugging of the Aardvark driver in Linux we have discovered
that the PCIE_CORE_LINK_CTRL_STAT_REG register in fact controls standard
PCIe Link Control Register for PCIe Root Bridge. This led us to discover
that the name of the PCIE_CORE_LINK_TRAINING macro and the corresponding
comment by this macro's usage is misleading; this bit in fact controls
Retrain Link, which, according to PCIe base spec is defined as:

A write of 1b to this bit initiates Link retraining by directing the
Physical Layer LTSSM to the Recovery state. If the LTSSM is already in
Recovery or Configuration, re-entering Recovery is permitted but not
required.

Entering Recovery state is normally done from LTSSM L0, L0s and L1 states.
But since the pci-aardvark.c driver enables Link Training just a few lines
above, the controller is not in L0 ready state yet. So setting aardvark bit
PCIE_CORE_LINK_TRAINING does not actually enter Recovery state at this
place.

Moreover, trying to enter LTSSM Recovery state without other configuration
is causing issues for some cards (e.g. Atheros AR9xxx and QCA9xxx). Since
Recovery state is not entered, these issues are not triggered.

Remove code which tries to enter LTSSM Recovery state completely.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Fix processing PIO transfers

Trying to clear PIO_START register when it is non-zero (which indicates
that previous PIO transfer has not finished yet) causes an External
Abort with SError 0xbf000002.

This bug is currently worked around in TF-A by handling External Aborts
in EL3 and ignoring this particular SError.

This workaround was also discussed at:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=3c7dcdac5c50
https://lore.kernel.org/linux-pci/20190316161243.29517-1-repk@triplefau.lt/
https://lore.kernel.org/linux-pci/971be151d24312cc533989a64bd454b4@www.loen.fr/
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1541

Implement a proper fix to prevent this External Abort. As it is not
possible to cancel a pending PIO transfer, simply do not start a new one
if previous has not finished yet. In this case return an error to the
caller.

In most cases this SError happens when there is no PCIe card connected
or when PCIe link is down. The reason is that in these cases a PIO
transfer takes about 1.44 seconds. For this reason we also increase the
wait timeout in pcie_advk_wait_pio() to 1.5 seconds.

If PIO read transfer for PCI_VENDOR_ID register times out, or if it
isn't possible to read it yet because previous transfer is not finished,
return Completion Retry Status value instead of failing, to give the
caller a chance to send a new read request.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Implement workaround for the readback value of VEND_ID

Marvell Armada 3720 Functional Errata, Guidelines, and Restrictions
document describes in erratum 4.1 PCIe value of vendor ID (Ref #: 243):

The readback value of VEND_ID (RD0070000h [15:0]) is 1B4Bh, while it
should read 11ABh.

The firmware can write the correct value, 11ABh, through VEND_ID
(RD0076044h [15:0]).

Implement this workaround in U-Boot PCIe controller driver aardvark for
both PCI vendor id and PCI subsystem vendor id.

This change affects PCI vendor id of PCIe root bridge emulated by Linux
kernel. With this change Linux kernel reports correct vendor id 11AB.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Set Max Payload Size and Max Read Request Size to 512 bytes

Fix usage of VL805 XHCI PCIe controller when it is connected via PCIe to
Armada 3720 SOC. Without this U-Boot crashes when trying to access
enumerated USB devices connected to this XHCI PCIe controller.

This should be done according to the PCIe Link Initialization sequence, as
defined in Marvell Armada 3720 Functional Specification.

Linux has this code too.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Fix printing debug messages

Value pcie->dev in function pcie_advk_probe() is not initialized yet
so use dev as argument for dev_dbg()/dev_warn().

Function pcie_advk_wait_pio() itself prints error message on failure
so do not print duplicate error message in caller.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

Merge tag 'v2021.01-rc5' into next

Prepare v2021.01-rc5

Signed-off-by: Tom Rini <trini@konsulko.com>

Revert "arm64: a37xx: pci: Assert PERST# signal when unloading driver"

This reverts commit 828d32621686aec593076d16445d39b9b8d49c05.

This change revers code which asserting PERST# signal when unloading
driver. Driver's remove callback is still there as it is used for other
functionality.

Asserting PERST# signal prior booting kernel is causing that A3720 boards
(Turris MOX and Espressobin) with stable Linux kernel versions 4.14 and
4.19 are not able to detect some PCIe cards (e.g. Compex WLE200 and WLE900)
and anymore. When PERST# signal is not asserted these cards are detected
correctly. As this is regression for existing stable Linux kernel versions
revert this problematic change in U-Boot.

To make cards working with OpenWRT 4.14 kernel it is needed to disable link
training prior booting kernel, which is already done in driver's remove
callback.

Described issue is in Linux kernel pci aardvark driver which is (hopefully)
fixed in latest upstream versions. Latest upstream versions should be able
to initialize PCIe bus and detects cards independently of the link training
and PERST# signal state.

So with this change, U-Boot on A3720 boards should be able to boot OpenWRT
4.14 kernel, stable 4.14 and 4.19 kernels and also latest mainline kernels.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

dm: Avoid accessing seq directly

At present various drivers etc. access the device's 'seq' member directly.
This makes it harder to change the meaning of that member. Change access
to go through a function instead.

The drivers/i2c/lpc32xx_i2c.c file is left unchanged for now.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename ofdata_to_platdata() to of_to_plat()

This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: treewide: Rename auto_alloc_size members to be shorter

This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.

Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.

Signed-off-by: Simon Glass <sjg@chromium.org>

arm64: a37xx: pci: Disable link training when unloading driver

As required by PCI Express spec a delay for at least 100ms after
de-asserting PERST# signal is needed before link training is enabled.

Linux kernels prior to 5.8 version do not automatically disable link
training before de-asserting PERST# signal, therefore this requirement is
not fulfilled.

Above requirement is needed for proper detection of some Compex PCIe WiFi
cards. Otherwise Linux kernel cannot detect it.

To allow using those PCIe cards with older Linux kernel versions booted by
U-Boot compiled with U-Boot a37xx pci driver, disable link training in
U-Boot when unloading this pci driver.

Thanks to DM_FLAG_OS_PREPARE flag, U-Boot automatically unload this driver
when booting Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>

arm64: a37xx: pci: Depends on DM_GPIO

For proper initialization of aardvark pci driver it is required to
de-assert reset GPIO. So depeneds on DM_GPIO option.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Assert PERST# signal when unloading driver

This change ensures that PCIe card is put into reset state when U-Boot
stops using it.

DM_FLAG_OS_PREPARE ensures that U-Boot executes driver's remove callback
prior booting Linux kernel.

Linux kernel pci-aardvark driver needs to reset PCIe card via PERST# signal
prior initializing it. If it does not issue reset then some PCIe cards
(specially Compex WiFi cards) are not detected at all.

Putting PCIe card into reset state prior booting Linux kernel would ensure
that card would be properly reset at time when Linux kernel starts
initializing pci-aardvark driver.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

arm64: a37xx: pci: Make PCIe Reset GPIO DT compatible with Linux kernel DT

Change active-high to active-low and change DT property name from
reset-gpio to reset-gpios. This format of gpio reset is used by
pci-aardvark driver in Linux kernel.

Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Konstantin Porotchkin <kostap@marvell.com>
Tested-by: Andre Heider <a.heider@gmail.com>

common: Drop linux/bitops.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

common: Drop linux/delay.h from common header

Move this uncommon header out of the common header.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: core: Create a new header file for 'compat' features

At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.

Move the compatibility features into a separate header file.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: pci: Update the PCI read_config() method to const dev *

At present this method uses a non-const udevice pointer, but the call
should not modify the device. Use a const pointer.

Signed-off-by: Simon Glass <sjg@chromium.org>

dm: gpio: Allow control of GPIO uclass in SPL

At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass
is included in SPL/TPL without any control for boards. Some boards may
want to disable this to reduce code size where GPIOs are not needed in
SPL or TPL.

Add a new Kconfig option to permit this. Default it to 'y' so that
existing boards work correctly.

Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to
preserve the current behaviour. Also update the 74x164 GPIO driver since
it cannot build with SPL.

This allows us to remove the hacks in config_uncmd_spl.h and
Makefile.uncmd_spl (eventually those files should be removed).

Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Remove unnecessary instances of DECLARE_GLOBAL_DATA_PTR

We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.

Signed-off-by: Tom Rini <trini@konsulko.com>

arm64: a37xx: pci: add support for aardvark pcie driver

This patch introduced the Aardvark PCIe driver based
driver model.
The PCIe driver is supposed to work in Root Complex
mode. It only supports X1 lane width.

Signed-off-by: Wilson Ding <dingwei@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38725
Reviewed-by: Victor Gu <xigu@marvell.com>
Reviewed-by: Hua Jing <jinghua@marvell.com>
Tested-by: Hua Jing <jinghua@marvell.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Ken Ma <make@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>

Merge tag 'v2022.01-rc4' into next

Prepare v2022.01-rc4

arm: mvebu: pci: Add me as co-maintainer and author of Marvell PCIe drivers

There is no maintainer entry for pci-aardvark.c. Add entry for
pci-aardvark.c and pci_mvebu.c with Pali and Stefan as maintainers.

Signed-off-by: Pali Rohár <pali@kernel.org>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Stefan Roese <sr@denx.de>

arm: a37xx: pci: Do not allow setting ROM BAR on PCI Bridge

PCI Bridge which represents aardvark PCIe Root Port has Expansion ROM Base
Address register at offset 0x30 but its meaning is different than PCI's
Expansion ROM BAR register. Only address format of register is same.

In reality, this device does not have any configurable PCI BARs. So ensure
that write operation into BARs (including Expansion ROM BAR) is noop and
registers always contain zero address which indicates that bars are
unsupported.

Fixes: cb056005dc67 ("arm: a37xx: pci: Add support for accessing PCI Bridge on root bus")
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Stefan Roese <sr@denx.de>