| Age | Commit message (Collapse) | Author |
|---|
|
Per xHCI spec chapter 6.2.2 table 6-7, as input, software shall
initialize the dev_state field to '0'. Though this does not seem
to cause any issue with most xHC implementations, let's do this
to conform with the spec.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Tested-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
|
|
If a USB 3.0 hub is plugged into the root port of the xHC, the xHCI
driver will issue a 'Configure Endpoint' command to the xHC for it
to update its internal data structure for this hub device. The hub
attributes are in the slot context so we need tell xHC to update the
slot context by setting the add context flags of the input control
context to only cover the slot context.
At present the add context flags is or'ed with the slot context bit,
but it should really be accurately set to the slot context, as the
variable that holds the value of the add context flags comes from
whatever was set in the last command execution, which may contain
additional contexts that 'Configure Endpoint' command should not
touch. Some xHC implementations like x86 don't complain such, but
it was observed on Renesas RCar Gen3 platform that the RCar xHC
complains with a 'TRB error' completion codes as the response.
Reported-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Tested-by: Marek Vasut <marek.vasut@gmail.com>
Tested-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
|
|
During the execution of xhci_deregister xHCI registers are accessed. If
the clock is already deactivated when xhci_deregister is called this can
lead to undefined behavior. Change the order to deregister the device
before deactivating the clock.
Signed-off-by: Matthias Blankertz <matthias.blankertz@cetitec.com>
|
|
|
|
|
|
ftsmc020_init is not used anymore.
So it can be removed.
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>
|
|
The compatible string of ftsdc010_mci.c is different from
the mmc driver in Linux Kernel. Modify it for consistency.
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>
|
|
Fix warnings as below when compile in 64-bit.
warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>
|
|
Fix warning as below when compile in 64-bit.
warning: format '%u' expects argument of type
'unsigned int', but argument 6 has type 'size_t
{aka long unsigned int}
Signed-off-by: Rick Chen <rick@andestech.com>
Signed-off-by: Rick Chen <rickchen36@gmail.com>
Cc: Greentime Hu <green.hu@gmail.com>
|
|
Mvebu AHCI is AHCI driver which uses SCSI under the hood.
This patch adjusts AHCI setup to support SCSI by creating
a SCSI device as a child. Since the functions of creating
SCSI device need the kconfig option DM_SCSI, so let
AHCI_MVEBU select DM_SCSI.
Signed-off-by: Ken Ma <make@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
This workaround was added for A8040/7040 A0.
A8040/7040 A0 is no longer supported so this workaround
can be removed.
Signed-off-by: David Sniatkiwicz <davidsn@marvell.com>
Signed-off-by: Ken Ma <make@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
Currently mvebu sata driver is in arch/arm/mach_mvebu directory, this
patch moves it to drivers/ata directory with renaming "sata.c" to
"ahci_mvebu.c" which is aligned to Linux.
New ahci driver's kconfig option is added as AHCI_MVEBU which selects
SCSI_AHCI and is based on AHCI.
Signed-off-by: Ken Ma <make@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
When the pin control driver selects SD/eMMC function for
a pin group, there is additional configuration to be done
for this case - switch the PHY to work with SDHCI interface.
This patch adds the missing functionality into the pin
control driver.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Evan Wang <xswang@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
For pinctrl driver of mvebu, the compatible strings
supported are defined differently from Linux version.
The patch aligned the compatible string with
Linux 4.17-rc4.
Signed-off-by: Evan Wang <xswang@marvell.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
|
|
Add ID for the Macronix MX25U25635F flash.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
|
|
Add ID for the Winbond W25Q256 flash.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
|
|
SDMMC_CMD_CPSMEN bit is wrongly check and set in
SDMMC_ARG register instead of SDMMC_CMD register.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
|
|
Add support of fuse command (read/write/program/sense)
on bank 0 to access to BSEC SAFMEM (4096 OTP bits).
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
|
|
Add possibility to update the serial parity used.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
|
|
Rename USART_ISR_FLAG_xxx bits to USART_ISR_xxx bits and
USART_ICR_OREF to USART_ICR_ORECF in order to match datasheets.
Sort defines by descendant order.
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add support for early debug printf, before the availability of
driver model and device tree support.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
- adds reading FMC swap setting from DTB to SDRAM driver
- sets FMC swap for stm32f429-disco board
- changes ram start address to 0x90000000
Signed-off-by: Radoslaw Pietrzyk <radoslaw.pietrzyk@gmail.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
|
|
Serial port configuration was missing from previous implementation.
It only worked because it was preconfigured by LK.
This patch configures the uart for 115200 8N1.
It also configures the pin mux for uart pins using DT bindings.
Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
|
|
The uart is already initialized prior to relocation,
reinitialization after relocation is unnecessary.
Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Failure to set the clocks will causes data abort exception when
trying to write to AHB uart registers.
This patch ensures that we don't touch these registers if clock
setting failed.
Signed-off-by: Ramon Fried <ramon.fried@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Currently, if we happen to allocate an address requiring 64 bits to a
device only supporting 32-bit BARs, the address eventually gets silently
truncated to 32 bits. Avoid this by adding a new flag to
pciauto_region_allocate() to bail out in such situations.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
All of the debug output from this file is squished to one line. Fix
it.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Currently, qemu_arm_defconfig and qemu_arm64_defconfig only work with
the 'highmem=off' parameter passed to QEMU's virt machine. The reason is
that when 'highmem' is not disabled, QEMU appends 64-bit a memory
resource to the PCI controller's regions property in DT in addition to
the 32-bit PCI memory window in low memory. And the current DT parsing
code picks the last (thus the 64-bit one) memory resource, whose address
eventually gets silently truncated to 32 bits because
CONFIG_SYS_PCI_64BIT is not set, which obviously causes PCI to break.
Avoid this problem by ignoring memory regions whose addresses are above
the 32-bit boundary when CONFIG_SYS_PCI_64BIT is not set.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This driver can emulate all the basic functionalities of a TPMv2.x
chip and should behave like them during regular testing.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
On some designs, the reset line could not be connected to the SoC reset
line, in this case, request the GPIO and ensure the chip gets reset.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Add the tpm2_tis_spi driver that should support any TPMv2 compliant
(SPI) module.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Choice between v1 and v2 compliant functions is done with the
configuration.
Create the various files that will receive TPMv2-only code on the same
scheme as for the TPMv1 code.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
There are no changes in this commit but a new organization of the code
as follow.
* cmd/ directory:
> move existing code from cmd/tpm.c in cmd/tpm-common.c
> move specific code in cmd/tpm-v1.c
> create a specific header file with generic definitions for
commands only called cmd/tpm-user-utils.h
* lib/ directory:
> move existing code from lib/tpm.c in lib/tpm-common.c
> move specific code in lib/tpm-v1.c
> create a specific header file with generic definitions for
the library itself called lib/tpm-utils.h
* include/ directory:
> move existing code from include/tpm.h in include/tpm-common.h
> move specific code in include/tpm-v1.h
Code designated as 'common' is compiled if TPM are used. Code designated
as 'specific' is compiled only if the right specification has been
selected.
All files include tpm-common.h.
Files in cmd/ include tpm-user-utils.h.
Files in lib/ include tpm-utils.h.
Depending on the specification, files may include either (not both)
tpm-v1.h or tpm-v2.h.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Fix a few more cases of tpm.h -> tpm-v1.h, some Kconfig logic]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
Because both major revisions are not compatible at all, let's make them
mutually exclusive in Kconfig. This way we will be sure, when using a
command or a library function that it is supported by the right
revision.
Current drivers are currently prefixed by "tpm_", we will prefix TPMv2.x
files by "tpm2_" to make the distinction without moving everything.
The Kconfig menu about TPM drivers is now divided into two sections, one
for each specification. Compliant drivers with one specification will
only show up if this specification _only_ has been selected, otherwise a
comment is displayed.
Once a driver is selected by the user, it selects automatically a
boolean value, that is needed in order to activate the TPM commands.
Selecting the TPM commands will automatically select the right
command/library files.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
[trini: Rework deps as TPM_V1 and TPM_V2 depend on TPM,
drop TPM_DRIVER_SELECTED]
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
TPM are shipped with a few read-only register from which we can retrieve
for instance:
- vendor ID
- product ID
- revision ID
Product and vendor ID share the same register and are already referenced
in the tpm_chip structure. Add the revision ID entry which is missing.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Add support for DEBUG_UART on ARC devboards
This required us to do 2 things:
1) Insert a call to debug_uart_init() in early boot code
2) Convert serial_arc to Kconfig
Once both items above are done we just patched defconfigs.
|
|
Patch queue for rpi - 2018-05-24
Some minor fixes for the Raspberry Pi:
- Fix SD writes on new sdhost controller
- Sanitize default load addresses, allowing for better payload placement
|
|
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
One step closer to completely Kconfig-driven target configuration in
U-Boot :)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
|
|
Last user of this driver went away in May 2017 in commit
eb5ba3aefdf0f6c ("i2c: Drop use of CONFIG_I2C_HARD").
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Acked-by: Heiko Schocher <hs@denx.de>
|
|
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
Acked-by: Heiko Schocher <hs@denx.de>
|
|
Last user of this driver went away in June 2015 in commit
d928664f4101e24 ("powerpc: 74xx_7xx: remove 74xx_7xx cpu support")
Signed-off-by: Tuomas Tynkkynen <tuomas@tuxera.com>
|
|
dm_warn is too noisy, replace with dev_dbg for less noise.
Based on original work by Wenyou Yang
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
|
|
Convert CONFIG_SUPPORT_EMMC_RPMB to Kconfig. Split the command handling
from the underlying support and expose this through CMD_MMC_RPMB.
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
|
|
The bcm2835 sdhost driver has a problem with "write multiple" commands.
It seems to boil down to the fact that the controller dislikes its FIFO
to get drained at the end of a block when a write multiple blocks command
is in flight.
The easy fix is to simply get rid of all the IRQ driven logic and make
the driver push as much data into the FIFO as it can. That way we never
drain and we never run into the problem.
Reported-by: Jan Leonhardt <jan@cyberdesigner.net>
Signed-off-by: Alexander Graf <agraf@suse.de>
|
|
Since 'commit f82290afc847 ("mtd: ubi: Fix worker handling")',
when booting from NAND, on a fresh NAND just after being flashed (and
only in this case), we got the following log:
ubi0: default fastmap pool size: 200
ubi0: default fastmap WL pool size: 100
ubi0: attaching mtd2
ubi0: scanning is finished
ubi0 error: ubi_update_fastmap: could not find any anchor PEB
ubi0 error: ubi_update_fastmap: could not find any anchor PEB
ubi0 error: ubi_wl_get_peb: Unable to get a free PEB from user WL pool
ubi0 error: autoresize: cannot auto-resize volume 1
UBI error: cannot attach mtd2UBI error: cannot initialize UBI, error
-28UBI init error 28
After analysis, in ubi_wl_init(), when performing schedule_erase(),
thread_enabled flag is not yet set to 1, which forbids ubi_do_worker()
to execute pending works.
This has to effect to not populate ubi->free with free physical
eraseblocks.
Following Richard Weinberger's advice, this patch has been
backported from kernel tree :
'commit 1cb8f9776c7d ("ubi: fastmap: Implement produce_free_peb()")'
Tested-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Acked-by: Heiko Schocher <hs@denx.de>
|
|
Signed-off-by: Tom Rini <trini@konsulko.com>
|
|
|
|
|
|
|
