Use __maybe_unused which should avoid the Coverity error.
Reported-by: Coverity (CID: 134900)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Close the file earlier to hopefully fix a Coverity error.
Reported-by: Coverity (CID: 134901)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Using short doesn't save anything and is confusing when the width and height
variables are ulong.
This may fix Coverity CID134902 but I doubt it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
All paths should share the same return.
Reported-by: Coverity (CID:134903)
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
This fixes the following error when building microblaze-generic:
net/eth-uclass.c: In function 'eth_post_probe':
net/eth-uclass.c:466:18: error: 'gd' undeclared (first use in this function)
ops->start += gd->reloc_off;
Fixes: db9391e1 ("net: Move driver-model code into its own file")
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Correct spelling of "U-Boot" shall be used in all written text
(documentation, comments in source files etc.).
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
Set up the debug UART early if enabled, so that it is ready to use.
Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Acked-by: Chin Liang See <clsee@altera.com>
Now that we have converted all x86 codes to DM PCI, drop pci_type1.c
which is only built for legacy PCI. Also per checkpatch.pl warning,
DEFINE_PCI_DEVICE_TABLE is now deprecated so drop that too.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that all x86 codes have been converted to use proper DM PCI APIs,
it's time to disable the legacy compatible layer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
When CONFIG_DM_PCI_COMPAT is not on, there is only a forward declaration
for pci_write_config32(). Add other missing ones.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This board uses RTL8169 which is a driver model ethernet driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that the RTL8169 driver warning is fixed we can drop this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It does not build if without CONFIG_DM_PCI_COMPAT. For now we just
disable it, until some day we add USB support to EFI application.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Move some #undef from efi-x86.h to efi-x86_defconfig as these are
already Kconfig options.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
There are still two places in Quark's MRC codes that use the generic
legacy PCI APIs, but as we are phasing out these legacy APIs, switch
to use Quark's own PCI config routines.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that we have converted all x86 codes to use DM PCI APIs,
drop those legacy ones.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Drop legacy PCI APIs usage in pci_assign_irqs() as well.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Use pci_[read|write]_config intead of x86_pci_[read|write]_config.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
With recent DM PCI changes to vesa_fb driver, external graphics
card does not work any more. This is because: after setting the
function disable bit, IGD and SDVO devices will disappear in the
PCI configuration space. This however creates an inconsistent state
from a driver model PCI controller point of view, as these two PCI
devices are still attached to its parent's child device list as
maintained by the driver model. Some driver model PCI APIs like
dm_pci_find_class() used in the vesa_fb driver, are referring to
the list to speed up the finding process instead of re-enumerating
the whole PCI bus, so it gets the stale cached data which is wrong.
To fix this, manually remove these two devices.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Once we get udevice of IGD and SDVO, we can use its udevice to
access PCI configuration space with dm_pci_write_config32().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
So far disable_igd() does not have any return value, but we may need
that in the future.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Now that we have irq router's udevice passed as a parameter, it's
time to start using the DM PCI API instead of those legacy ones.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
At present irq_router is declared as a static struct irq_router in
arch/x86/cpu/irq.c. Since it's a driver control block, it makes sense
to move it to a per driver priv. Adjust existing APIs to accept an
additional parameter of irq_router's udevice.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
There is no need to parse PCH's <reg> property as we have already
a DM PCI API dm_pci_get_bdf() that can handle this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
IOBASE is now obtained from PCH driver, drop this <io-base> property.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
asm/arch/gpio.h is not needed anymore as we get the GPIO base from
PCH driver.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
At present this GPIO driver still uses the legacy PCI API. Now that
we have proper PCH drivers we can use those to obtain the information
we need. While the device tree has nodes for the GPIO peripheral it is
not in the right place. It should be on the PCI bus as a sub-peripheral
of the PCH device.
Update the device tree files to show the GPIO controller within the PCH,
so that PCI access works as expected. This also adds '#address-cells'
and '#size-cells' to the PCH node.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
IO_BASE is only seen on PCH9 device, implement the get_io_base op.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
On some newer chipset (eg: BayTrail), there is an IO base address
register on the PCH device which configures the base address of a
memory-mapped I/O controller.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Implement get_gpio_base op for bd82x6x, pch7 and pch9 drivers.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
x86 GPIO registers are accessed via I/O port whose base address is
configured in a PCI configuration register on the PCH device. Add
an op get_gpio_base to get the GPIO base address from PCH.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Spell out 'sbase' to 'spi_base' so that it looks clearer.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
pch_get_version op was only used by the ich spi controller driver,
and does not really provide a good identification of pch controller
so far, since we see plenty of Intel PCH chipsets and one differs
from another a lot, which is not simply either a PCHV_7 or PCHV_9.
Now that ich spi controller driver was updated to not get such info
from pch, the pch_get_version op is useless now.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Unprotecting SPI flash is now handled in the SPI controller driver,
via a call to the PCH driver. Drop the ad-hoc version.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Unprotecting SPI flash is now handled in the SPI controller driver,
via a call to the PCH driver. Drop the ad-hoc version.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The ICH SPI controller supports two variants, one of which is ICH7
compatible and the other is ICH9 compatible. Change 'pch_version'
to 'ich_version' to better match its original name.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Tested-by: Simon Glass <sjg@chromium.org>
At present ich spi driver gets the controller version information via
pch, but this can be simply retrieved via spi node's compatible string.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Tested-by: Simon Glass <sjg@chromium.org>
This cleans up the ich spi driver a little bit:
- Remove struct ich_spi_slave that is not referenced anywhere
- Remove ending period in some comments
- Move struct ich_spi_platdata and struct ich_spi_priv to ich.h
- Add #ifndef _ICH_H_ .. in ich.h
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Without this CONFIG_BOOTDELAY, autobooting does not work at all. As
autoboot_command() from common/* will not get called. So lets define
CONFIG_BOOTDELAY, so that auto-booting works on x86.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Miao Yan <yanmiaobest@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Tested-by: Miao Yan <yanmiaobest@gmail.com>
Acked-by: Bin Meng <bmeng.cn@gmail.com>
The x86 build target "efi-x86" has no TEXT_BASE configured. And with the
introduction of CONFIG_BOOTDELAY for x86, this function is now called
for this board as well. Resulting in compile errors for this target.
Without TEXT_BASE it makes no sense to fill these values. So lets only
configure the env variable if TEXT_BASE is defined.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Apparently, the logic for the FPGA global bit is not universal between Gen5
and Gen10 devices is not the same. Disabling this bit, while applicable to
Gen10 devices, will break FPGA programming on Gen5 devices.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
In current high speed fastboot, fs_ep_in.wMaxPacketSize is configured 64 bytes
as default, as a result, it failed to match the size at initialization stage in
usb controller.
Actually, hardware can support less than or equal to 512 bytes in high speed mode,
so I changed the condition from '!=' to '>' to fix this issue.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Tested-by: Steve Rae <srae@broadcom.com>
Implement board_mmc_get_env_dev for the boards.
Following is examples:
SD1/SD2/SD3: return devno;
SD2/SD3: return devno - 1;
SD2/SD4: if (devno == 2), return dev - 2; return dev - 1;
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Implement mmc_get_env_dev, devno can be got from smbr1 of SRC.
Introduce a weak function board_mmc_get_env_dev, different
boards can implement it according to different sdhc controllers
that used by the board.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Move mmc_get_env_devno to soc.c and rename to mmc_get_env_dev to
match the one in common/env_mmc.c.
Introduce a weak function board_mmc_get_env_dev. Different
boards can implement this according to sdhc controller which
is used by the board.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Cc: Stefano Babic <sbabic@denx.de>
Simon Glass
Bin Meng
Thomas Chou
Stefan Roese
Tom Rini
Dinh Nguyen
Frank Wang
Peng Fan