Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Improve the DTS files by removing all the leading "0x" and zeros to fix the
following dtc warnings:
Warning (unit_address_format): Node /XXX unit name should not have
leading "0x"
and
Warning (unit_address_format): Node /XXX unit name should not have
leading 0s
Converted using the following command:
$ find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec \
sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" \
-e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
For simplicity, two sed expressions were used to solve each warnings
separately.
To make the regex expression more robust a few other issues were resolved,
namely setting unit-address to lower case, and adding a whitespace before
the the opening curly brace:
https://elinux.org/Device_Tree_Linux#Linux_conventions
This will solve as a side effect warning:
Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format
error, expected "<lower>"
This is a follow up to commit 4c9847b737 ("dt-bindings: Remove leading
0x from bindings notation")
Reported-by: David Daney <ddaney@caviumnetworks.com>
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This commit moves common OMAP3-EVM processor module device tree data
to a separate include file. This will allow for 'omap3-evm.dts' to use
device tree data that is unique to the OMAP3530 version of the
processor module, while making use of the work already done for the
'omap3-evm-37xx.dts'.
Signed-off-by: Derald D. Woods <woods.technical@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Looks like nobody bothered to configure USB host for 37xx-evm
when we converted things to device tree, so let's add it. This
is similar to beagleboard configuration with few extra quirks
to configure the port. And as with beagleboard, OHCI won't work
because there is no USB LS/FS PHY. A HS USB hub is needed to use
devices like keyboard and mice.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This patch fixes the following DTC warnings:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The padconf register WAKEUP_EN is now handled in a generic way using
Linux wakeirqs where pinctrl-single toggles the WAKEUP_EN bit when
a wakeirq is enabled or disabled.
At least omap5 gets confused if the WAKEUP_EN bit is set and the pin
is not claimed as a wakeirq. The end result is that wakeirqs don't
work properly as there is nothing handling the wakeirq.
So let's just remove the WAKEUP_EN usage from dts files.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.
The GPMC node will provide an interrupt controller for the
NAND IRQs.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Use the pinmux IOPAD macros to define the register absolute physical
address instead of the offset from the padconf base address. This
makes the DTS easier to read since matches the addresses listed in
the Technical Reference Manual.
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Some omaps are producing imprecise external aborts because we are
wrongly trying to init SRAM for device tree based booting. Only
omap3 is still using the legacy SRAM code, so we need to make it
omap3 specific. Otherwise we can get errors like this on at least
dm814x:
Unhandled fault: imprecise external abort (0xc06) at 0xc08b156c
...
(omap_rev) from [<c08b12e0>] (omap_sram_init+0xf8/0x3e0)
(omap_sram_init) from [<c08aca0c>] (omap_sdrc_init+0x10/0xb0)
(omap_sdrc_init) from [<c08b581c>] (pdata_quirks_init+0x18/0x44)
(pdata_quirks_init) from [<c08b5478>] (omap_generic_init+0x10/0x1c)
(omap_generic_init) from [<c08a57e0>] (customize_machine+0x1c/0x40)
(customize_machine) from [<c00098a4>] (do_one_initcall+0x80/0x1dc)
(do_one_initcall) from [<c08a2ec4>] (kernel_init_freeable+0x218/0x2e8)
(kernel_init_freeable) from [<c063a554>] (kernel_init+0x8/0xec)
(kernel_init) from [<c000f890>] (ret_from_fork+0x14/0x24)
Let's fix the issue by making sure omap_sdrc_init only gets called for
omap3. To do that, we need to have compatible "ti,omap3" in the dts
files. And let's also use "ti,omap3630" instead of "ti,omap36xx" like
we're supposed to.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Looks like we have some GPMC NAND timings missing device
width. This fixes "gpmc_cs_program_settings: invalid width 0!"
errors during boot.
Signed-off-by: Tony Lindgren <tony@atomide.com>
The GPMC binding is obviously very confusing as the values
are all over the place. People seem to confuse the GPMC partition
size for the chip select, and the device IO size within the GPMC
partition easily.
The ranges entry contains the GPMC partition size. And the
reg entry contains the size of the IO registers of the
device connected to the GPMC.
Let's fix the issue according to the following table:
Device GPMC partition size Device IO size
connected in the ranges entry in the reg entry
NAND 0x01000000 (16MB) 4
16550 0x01000000 (16MB) 8
smc91x 0x01000000 (16MB) 0xf
smc911x 0x01000000 (16MB) 0xff
OneNAND 0x01000000 (16MB) 0x20000 (128KB)
16MB NOR 0x01000000 (16MB) 0x01000000 (16MB)
32MB NOR 0x02000000 (32MB) 0x02000000 (32MB)
64MB NOR 0x04000000 (64MB) 0x04000000 (64MB)
128MB NOR 0x08000000 (128MB) 0x08000000 (128MB)
256MB NOR 0x10000000 (256MB) 0x10000000 (256MB)
Let's also add comments to the fixed entries while at it.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add OMAP DT data:
* omap5 display subsystem
* display data for omap5 uEVM board
* am43xx display subsystem
* display data for am43xx ePOS and GP boards (LCD only)
* display data for GTA04 board
* display data for overo board
* display data for duovero-parlor board
* display data for omap3 evm and ldp boards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTlbIaAAoJEPo9qoy8lh71zKsP/2RuWCEKuyZ8acg5a58y98eD
aguogxUjxKURoqA2FtrH1qAokYnqds9KHcB8GtOtYL+5Q8GMhGsk4YS/++twyCBm
9JOq/2FBdbTKi8mkGmURRJQjWwd+BJyeOQb/F54jif+akEmw3oL4SNL3YaTitQqT
Yhg+QZa7djwBBCSGy2sHygnrYlEVJiz9gjdMye0kdPEPmg1LKZny0HJZgMkndsCH
oEs836pY78SiWGpFjz5Jsk4zjitPJOLwa7/RdL27s+OWyJb/RMxc4SDdL6de5H+u
L2GSOe3vxG+0lrTslosRM3qJwIQGKWbYqOEXMDFdDKANS24QbQYw5NCFwUCfeCCy
Rxlw9ntr7v/iPyQ3t8oMoNG9Xm0o4gvet8LIbj/33mqFMAESnnbi6GmujmlA9S9p
x6DAasBN2LAf6eQhshE7W/6XiEnDH2cVLXVGQwj6yiuhPp/GblGhHIh1MTHA41Vi
A/AN/svDsPjkzhZyMETRljSpdHwQXf+vIYSeipSQFW0poBQ7o5bLUuli/VB21kbi
UNDhegCNrTKjqxVZL4DI7/E8JYdwGjKKfmbgiGWOjyu8Jd3/0KAhZA6JIv0DeAyN
ankSfioyEleXFm4iPC+dN7dZPWTb3SudCndEwbmjVR3VDKjBeiy60HGyxBJ4/uWm
9FkkdQfnRfNHYYXHJi1R
=/UHU
-----END PGP SIGNATURE-----
Merge tag 'fbdev-omap-dt-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux
Pull OMAP DT fbdev updates from Tomi Valkeinen:
"Here are display related device tree data changes for OMAP. They are
based on an already merged branch to satisfy the dependencies for the
dts file changes.
Add OMAP DT data:
- omap5 display subsystem
- display data for omap5 uEVM board
- am43xx display subsystem
- display data for am43xx ePOS and GP boards (LCD only)
- display data for GTA04 board
- display data for overo board
- display data for duovero-parlor board
- display data for omap3 evm and ldp boards"
* tag 'fbdev-omap-dt-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
ARM: omap5.dtsi: Add audio related parameters to hdmi node
ARM: omap4.dtsi: Add audio related parametes to hdmi node
ARM: dts: duovero-parlor: Add HDMI output
ARM: dts: overo: Add support for 3.5'' LCD output
ARM: dts: overo: Add support for 4.3'' LCD output
ARM: dts: overo: Add support for DVI output
ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
ARM: dts: omap3-gta04: Add display support
ARM: dts: omap5-uevm.dts: add display nodes
ARM: dts: omap5-uevm.dts: add tca6424a
ARM: dts: omap5.dtsi: add DSS nodes
ARM: dts: am43x-epos-evm: add LCD data
ARM: dts: am437x-gp-evm: add LCD data
ARM: dts: am4372.dtsi: add DSS information
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
We've had deeper idle states working on omaps for few years now,
but only in the legacy mode. When booted with device tree, the
wake-up events did not have a chance to work until commit
3e6cee1786 (pinctrl: single: Add support for wake-up interrupts)
that recently got merged. In addition to that we also needed commit
79d9701559 (of/irq: create interrupts-extended property) and
9ec36cafe4 (of/irq: do irq resolution in platform_get_irq) that
are now also merged.
So let's fix the wake-up events for some selected omaps so devices
booted in device tree mode won't just hang if deeper power states
are enabled, and so systems can wake up from suspend to the serial
port event.
Note that there's no longer need to specify the wake-up bit in
the pinctrl settings, the request_irq on the wake-up pin takes
care of that.
Cc: devicetree@vger.kernel.org
Cc: "Benoît Cousson" <bcousson@baylibre.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
[tony@atomide.com: updated comments, added board LDP]
Signed-off-by: Tony Lindgren <tony@atomide.com>
I've tested the serial, MMC, smsc911x, wl12xx, and off-idle support
with the pinctrl patches, so it probably works better than the
board-*.c files ever did. Also the board-omap3evm.c file is broken
for the DSS, and has been for a while. Patches are welcome to fix
it in this .dts file, let's just drop the board-*.c file for this.
Note that off-idle currently requires doing request_irq() on the
wake-up pin from pinctrl-single IRQ domain until we can handle
that in some Linux generic way.
[tony@atomide.com: updated for make dtbs build fix]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Alexander A. Klimov