This is needed for BTRFS.

Signed-off-by: Marek Behun <marek.behun@nic.cz>

 create mode 100644 lib/crc32c.c

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

Ignore these generated files during the build of dtc.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Add UniPhier platform specific glue layer to support USB3 Host mode
on Synopsys DWC3 IP.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Marek Vasut <marex@denx.de>

The stored 'blk' value is overwritten to 'size / 512' before it can
be used in usb_stor_set_max_xfer_blk(). This is not what we want.
In fact, when 'size' exceeds the upper limit (USHRT_MAX * 512), we
should simply assign 'size' to the upper limit.

Reported-by: Coverity (CID: 167250)
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Update the codes to conform with xHCI spec chapter 6.2.3.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Per xHCI spec, 'Error Count' should be set to 0 for isoch endpoints.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

The 'Max Burst Size' indicates to the xHC the maximum number of
consecutive USB transactions that should be executed per scheduling
opportunity. This is a “zero-based” value, where 0 to 15 represents
burst sizes of 1 to 16, but at present this is always set to zero.
Let's program the required value according to real needs.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

USB endpoint reports the period between consecutive requests to send
or receive data as bInverval in its endpoint descriptor. So far this
is ignored by xHCI driver and the 'Interval' field in xHC's endpoint
context is always programmed to zero which means 1ms for low speed
or full speed , or 125us for high speed or super speed. We should
honor the interval by getting it from endpoint descriptor.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

USB 3.0 hubs report bit[5] in the port status change response as BH
reset. The hub shall set the C_BH_PORT_RESET field for this port.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

During usb_hub_port_connect_change(), a port reset set feature
request is issued to the port, and later a port reset clear feature
is done to the same port before the function returns. However at
the end of usb_scan_port(), we attempt to clear port reset again
on a cached port status change variable, which should not be done.

Adjust the call to clear port reset to right before the call to
usb_hub_port_connect_change().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

In xhci_check_maxpacket(), the control endpoint 0 max packet size
is wrongly taken from the interface's endpoint descriptor. However
the default endpoint 0 does not come with an endpoint descriptor
hence is not included in the interface structure. Change to use
epmaxpacketin[0] instead.

The other bug in this routine is that when setting max packet size
to the xHC endpoint 0 context, it does not clear its previous value
at all before programming a new one.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

For xHCI it is not possible to read a device descriptor before it
has been assigned an address. That's why usb_setup_descriptor()
was called with 'do_read' being false. But we really need try to
read the device descriptor before starting any real communication
with the default control endpoint.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Full speed device endpoint 0 can have 8/16/32/64 bMaxPacketSize0.
Other speed devices report fixed value per USB spec. So it only
makes sense if we send a get device descriptor with 64 bytes to
full speed devices.

While we are here, update the comment block to be within 80 cols.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

xHCI uses normal TRBs for both bulk and interrupt. This adds the
missing interrupt transfer support to xHCI so that devices like
USB keyboard that uses interrupt transfer can work.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Normal endpoint descriptor size is 7, but for audio extension it is
9. Handle that correctly when parsing endpoint descriptor.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

At present xHCI driver assumes LS/FS devices are attached directly
to a HS hub. If they are connected to a LS/FS hub, the driver will
fail to perform the USB enumeration process on such devices.

This is fixed by looking from the device itself all the way up to
the HS hub where the TT that serves the device is located.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Now that we have changed to remove all devices under the root hub in
usb_stop(), and corrected the USB emulator select logic, it makes no
sense to do various tests based on 'usb tree' output since the order
of devices is no longer fixed. Remove these USB test cases related
to 'usb tree'.

For the USB remove test, ideally we should remove an emulator device
node from the device tree, but this is so far not working. Change to
test the 'usb stop' only.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

With the root hub unbinding in usb_stop(), there is no need to do
a Sandbox-specific reset operation. usb_emul_reset() is no longer
used anywhere, drop it.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

With the root hub unbinding in usb_stop(), there is no need to do
a blk uclass specific unbind operation.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

At present we only do device_remove() during usb stop. The DM API
device_remove() only marks the device state as inactivated, but
still keeps its USB topology (eg: parent, children, etc) in the DM
device structure. There is no issue if we only start USB subsystem
once and never stop it. But a big issue occurs when we do 'usb stop'
and 'usb start' multiple times.

Strange things may be observed with current implementation, like:
- the enumeration may report only 1 mass storage device is detected,
  but the total number of USB devices is correct.
- USB keyboard does not work anymore after a bunch of 'usb reset'
  even if 'usb tree' shows it is correctly identified.
- read/write flash drive via 'fatload usb' may complain "Bad device"

In fact, every time when USB host controller starts the enumeration
process, it takes random time for each USB port to show up online,
hence each USB device may appear in a different order from previous
enumeration, and gets assigned to a totally different USB address.
As a result, we end up using a stale USB topology in the DM device
structure which still reflects the previous enumeration result, and
it may create an exact same DM device name like generic_bus_0_dev_7
that is already in the DM device structure. And since the DM device
structure is there, there is no device_bind() call to bind driver to
the device during current enumeration process, eventually creating
an inconsistent software representation of the hardware topology, a
non-working USB subsystem.

The fix is to clear the unused USB topology in the usb_stop(), by
calling device_unbind() on each controller's root hub device, and
the unbinding will unbind all of its children automatically.

For Sandbox, we need scan the device tree each time when we start
the USB stack, in order to re-create the emulated USB devices and
bind drivers for them before we actually do the driver probe.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

At present the usb hub emulator always reports its downstream port
speed as full speed. Actually it is high speed for sandbox-flash,
and low speed for sandbox-keyb. We can determine the device speed
by checking its device descriptor bcdUSB field, and do the proper
hub port status report based on that.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

This can be useful outside of the sandbox usb emulation uclass
driver. Expose it as a public API with a proper prefix (usb_emul_).

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Current emulator select logic in usb_emul_find_devnum() is to test
the USB address. The USB address of the device being enumerated is
initialized to zero at the beginning of the enumeration process in
usb_setup_device(). At this point, the saved USB address in the
platform data has not been assigned to any valid USB address either.
This means: the logic will select an emulator device according to
its sequence of declaring order in the device tree. Take test.dts
for example, flash-stick@0 will be selected before flash-stick@1.
But unfortunately such logic is wrong.

In fact USB devices show up in a random order during the enumeration
which means usb_emul_find_devnum() may be called on port 3 for keyb@3
before on port 0 for flash-stick@0.

To fix this, we introduce a new emulator uclass specific platdata
to store the USB device's port number on its parent hub, and update
the logic to test the port number instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

At present 'usb tree' shows that the root hub on the Sandbox USB
controller is at full speed. But its device descriptor says it's
USB 2.0, so let's report it as a high speed device.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

There is no such a parameter called 'bus'.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

This parameter is never used.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Patch queue for efi - 2017-10-01

Lots of new things this time. High level highlights are:

  - Shim support (to boot Fedora)
  - Initial set of unit tests
  - Preparations to support UEFI Shell

With Makefiles testing for $(SPL_TPL_)SYSRESET, we need TPL_SYSRESET
for do_reset() in TPL for Rockchip SoCs.

References: 87c16d49 "drivers: spl: consistently use the $(SPL_TPL_)
macro"

Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Falcon mode, is updating DDR dt node configuration through
spl_fixup_fdt() so add appropriate DDR base and size through
dram_init_banksize.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

The RK3399-Q7 requires DM regulator support in SPL, so we can use the
regulator framework to reenable the eMMC and SPI, if these had been
turned of by the BIOS_DISABLE signal.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The Makefile already tests for SPL_DM_REGULATOR_FIXED, but Kconfig
does not provide it.  This adds SPL_DM_REGULATOR_FIXED to Kconfig.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The (Qseven) BIOS_DISABLE signal on the RK3399-Q7 (Puma) keeps the
eMMC and SPI in reset initially and we need to write a GPIO to turn
them on before continuing the boot-up.

This adds the DTS entries for the additional regulator and makes
pinctrl and gpio3 available during SPL.  It also adds a hook to the
spl_board_init() to ensure that the regulator gets probed and enabled.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The original initialisation code for board_init() was largely lifted
from the code on the EVB.  However, the RK3399-Q7 can do with a much
more concise init sequence.

This cleans up the board_init() by updating it to the essentials for
the RK3399-Q7 and getting rid of the accumulated cruft.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

In the general case, we want to continue booting the full U-Boot
(contained in a discoverable FIT image) from the same device the SPL
stage was loaded from.  This prepends the 'same-as-spl' specifier to
our configurable boot-order to make this the default behaviour.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

To support the new "same-as-spl" specifier in the boot-order on the
RK3399, this implements the chip-specific mapping from the information
obtainable from the BROM to a OF path name.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

It is often desirable to configure the spl-boot-order (i.e. the order
that SPL probes devices to find the FIT image containing a full U-Boot)
such that it contains 'the same device the SPL stage was booted from'
early on.  To support this, we introduce the 'same-as-spl' specifier
for the spl-boot-order property.

This commit adds:
 - documentation for the new board_spl_was_booted_from() function that
   individual SoCs/boards should provide, if they can determine where
   the SPL was booted from
 - implements the new board_spl_was_booted_from() stub function
 - adds support for handling the 'same-as-spl' specifier and calling
   into the per-SoC/per-board support code.

This also updates the documentation for the 'u-boot,spl-boot-order'
property.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

In the expectation that the spl-boot-order code will eventually
gain use outside of mach-rockchip: let's add documentation on the
spl_node_to_boot_device() function, which is likely to become a
publicly exported function.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>