SPDX: Convert all of our single license tags to Linux Kernel styleWhen U-Boot started using SPDX tags we were among the early adopters andthere weren't a lot of other examples to borrow from. So
SPDX: Convert all of our single license tags to Linux Kernel styleWhen U-Boot started using SPDX tags we were among the early adopters andthere weren't a lot of other examples to borrow from. So we picked thearea of the file that usually had a full license text and replaced itwith an appropriate SPDX-License-Identifier: entry. Since then, theLinux Kernel has adopted SPDX tags and they place it as the very firstline in a file (except where shebangs are used, then it's second line)and with slightly different comment styles than us.In part due to community overlap, in part due to better tag visibilityand in part for other minor reasons, switch over to that style.This commit changes all instances where we have a single declaredlicense in the tag as both the before and after are identical in tagcontents. There's also a few places where I found we did not have a tagand have introduced one.Signed-off-by: Tom Rini <trini@konsulko.com>
show more ...
omap3: Drop CONFIG_OMAP3_EVM, switch to CONFIG_TARGET_OMAP3_EVM when neededWe make use of CONFIG_OMAP3_EVM today to know when to do a specifictweak in MUSB. This can be tested on via CONFIG_TARGE
omap3: Drop CONFIG_OMAP3_EVM, switch to CONFIG_TARGET_OMAP3_EVM when neededWe make use of CONFIG_OMAP3_EVM today to know when to do a specifictweak in MUSB. This can be tested on via CONFIG_TARGET_OMAP3_EVMinstead, so switch there so we can drop the now unused symbolCONFIG_OMAP3_EVM. In investigating what to do about the symbol usage wesee that the cairo board defines the same function, but never called it(as it does not define CONFIG_OMAP3_EVM) and was just returning anyhow,so drop that function from that board.Cc: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr>Cc: Marek Vasut <marex@denx.de>Signed-off-by: Tom Rini <trini@konsulko.com>
mmc: replace CONFIG_GENERIC_MMC with CONFIG_MMCNow CONFIG_GENERIC_MMC and CONFIG_MMC match for all defconfig.We do not need two options for the same feature. Deprecate theformer.This commit wa
mmc: replace CONFIG_GENERIC_MMC with CONFIG_MMCNow CONFIG_GENERIC_MMC and CONFIG_MMC match for all defconfig.We do not need two options for the same feature. Deprecate theformer.This commit was generated with the sed script 's/GENERIC_MMC/MMC/'and manual fixup of drivers/mmc/Kconfig.Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
ti: boot: Register the MMC controllers in SPL in the same way as in u-bootTo keep a consistent MMC device mapping in SPL and in u-boot, let'sregister the MMC controllers the same way in u-boot and
ti: boot: Register the MMC controllers in SPL in the same way as in u-bootTo keep a consistent MMC device mapping in SPL and in u-boot, let'sregister the MMC controllers the same way in u-boot and in the SPL.In terms of boot time, it doesn't hurt to register more controllers thanneeded because the MMC device is initialized only prior being accessed forthe first time.Having the same device mapping in SPL and u-boot allows us to use theenvironment in SPL whatever the MMC boot device.Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
arm: Note vendor-required status of certain MACH_TYPE valuesIn the cases of some boards, a MACH_TYPE number is used which is eithernot registered upstream or worse (for functionality) is re-using
arm: Note vendor-required status of certain MACH_TYPE valuesIn the cases of some boards, a MACH_TYPE number is used which is eithernot registered upstream or worse (for functionality) is re-using thenumber of a different (or reference) platform instead. Make sure wehave a comment in these cases.Cc: Albert ARIBAUD <albert.aribaud@3adev.fr>Cc: Walter Schweizer <swwa@users.sourceforge.net>Cc: Stefan Roese <sr@denx.de>Cc: Fabio Estevam <fabio.estevam@nxp.com>Signed-off-by: Tom Rini <trini@konsulko.com>Acked-by: Stefan Roese <sr@denx.de>
serial, ns16550: bugfix: ns16550 fifo not enabledcommit: 65f83802b7a5b "serial: 16550: Add getfcr accessor"breaks u-boot commandline working with long commandssending to the board.Since the abo
serial, ns16550: bugfix: ns16550 fifo not enabledcommit: 65f83802b7a5b "serial: 16550: Add getfcr accessor"breaks u-boot commandline working with long commandssending to the board.Since the above patch, you have to setup the fcr register.For board/archs which enable OF_PLATDATA, the new fieldfcr in struct ns16550_platdata is not filled with adefault value ...This leads in not setting up the uarts fifo, which endsin problems, when you send long commands to u-bootscommandline.Detected this issue with automated tbot tests on am335xbased shc board.The error does not popup, if you type commands. You needto copy&paste a long command to u-boots commandshell(or send a long command with tbot)Possible boards/plattforms with problems:./arch/arm/cpu/arm926ejs/lpc32xx/devices.c./arch/arm/mach-tegra/board.c./board/overo/overo.c./board/quipos/cairo/cairo.c./board/logicpd/omap3som/omap3logic.c./board/logicpd/zoom1/zoom1.c./board/timll/devkit8000/devkit8000.c./board/lg/sniper/sniper.c./board/ti/beagle/beagle.c./drivers/serial/serial_rockchip.cSigned-off-by: Heiko Schocher <hs@denx.de>Signed-off-by: Ladislav Michl <ladis@linux-mips.org>Tested-by: Adam Ford <aford173@gmail.com>Reviewed-by: Tom Rini <trini@konsulko.com>
ARM: Various: Future-proof serial platdataA few boards still use ns16550_platdata structures, but assume the structureis going to be in a specific order. By explicitly naming each entry,this shou
ARM: Various: Future-proof serial platdataA few boards still use ns16550_platdata structures, but assume the structureis going to be in a specific order. By explicitly naming each entry,this should also help 'future-proof' in the event the structure changes.Tested on the Logic PD Torpedo + Wireless.I only changed a handful of devices that used the same syntax as the Logicboard. Appologies if I missed one or stepped on toes. Thanks to Derald Woodsand Alexander Graf.Signed-off-by: Adam Ford <aford173@gmail.com>V6: Add fix to arch/arm/cpu/armv7/am33xx/board.cV5: Add fix to arch/arm/cpu/arm926ejs/lpc32xx/devices.cV4: Fix subject headingV3: Remove reg_offset out in all the structs. It was reverted out, and and ifit did exist, it would get initialized to 0 by default.V2: I hastily copy-pasted the boards without looking at the UART number.This addresses 3 boards that use UART3 and not UART1.Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>Reviewed-by: Simon Glass <sjg@chromium.org>
ns16550: unify serial_omapUnify serial_omap, and use the generic binding.Signed-off-by: Thomas Chou <thomas@wytron.com.tw>Reviewed-by: Tom Rini <trini@konsulko.com>Acked-by: Simon Glass <sjg@ch
ns16550: unify serial_omapUnify serial_omap, and use the generic binding.Signed-off-by: Thomas Chou <thomas@wytron.com.tw>Reviewed-by: Tom Rini <trini@konsulko.com>Acked-by: Simon Glass <sjg@chromium.org>
cairo: add missing MAINTAINERS fileThis removes the following two warnings from buildman: WARNING: no status info for 'cairo' WARNING: no maintainers for 'cairo'Signed-off-by: Albert ARIBAUD (
cairo: add missing MAINTAINERS fileThis removes the following two warnings from buildman: WARNING: no status info for 'cairo' WARNING: no maintainers for 'cairo'Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
omap3: add support for QUIPOS Cairo board.This patch extends OMAP3 support for AM/DM37xx andintroduces the AM3703-based Quipos Cairo board.Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3
omap3: add support for QUIPOS Cairo board.This patch extends OMAP3 support for AM/DM37xx andintroduces the AM3703-based Quipos Cairo board.Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>Reviewed-by: Simon Glass <sjg@chromium.org>