Before commit 0e30f47232 ("mtd: spi-nor: add support for DTR protocol"),
for all PP command, it only support 1-1-1 mode, no matter the tx setting
in dts. But after the upper commit, the logic change. It will choose
the best mode(fastest mode) which flash device and spi-nor host controller
both support.
Though the spi-nor device on imx6sx-sdb/imx6ul(l/z)-14x14-evk board
do not support PP-1-4-4/PP-1-1-4, but if tx is 4 in dts file, it will also
impact the read mode selection. For the spi-nor device on the upper mentioned
boards, they support read 1-4-4 mode and read 1-1-4 mode according to the
device internal sfdp register. But qspi host controller do not support
read 1-4-4 mode. so need to set the tx to 1, let the common code finally
select read 1-1-4 mode, PP-1-1-1 mode.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Fixes: 0e30f47232 ("mtd: spi-nor: add support for DTR protocol")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Commit 078fb7aa6a ("arm: dts: vexpress: Fix addressing issues with
'motherboard-bus' nodes") broke booting on a couple of 32-bit VExpress
boards. The problem is #address-cells size changed, but interrupt-map
was not updated. This results in the timer interrupt (and all the
other motherboard interrupts) not getting mapped.
As the 'interrupt-map' properties are all just duplicates across boards,
just move them into vexpress-v2m.dtsi and vexpress-v2m-rs1.dtsi.
Strictly speaking, 'interrupt-map' is dependent on the parent
interrupt controller, but it's not likely we'll ever have a different
parent than GICv2 on these old platforms. If there was one,
'interrupt-map' can still be overridden.
Link: https://lore.kernel.org/r/20210924214221.1877686-1-robh@kernel.org
Fixes: 078fb7aa6a ("arm: dts: vexpress: Fix addressing issues with 'motherboard-bus' nodes")
Cc: Guillaume Tucker <guillaume.tucker@collabora.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Reported-by: Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The core functions of string.c are those that may be implemented by
per-architecture functions, or overloaded by FORTIFY_SOURCE. As a
result, it needs to be built with __NO_FORTIFY. Without this, macros
will collide with function declarations. This was accidentally working
due to -ffreestanding (on some architectures). Make this deterministic
by explicitly setting __NO_FORTIFY and move all the helper functions
into string_helpers.c so that they gain the fortification coverage they
had been missing.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Andy Lavr <andy.lavr@gmail.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Commit bbc4d71d63 ("net: phy: realtek: fix rtl8211e rx/tx delay
config") sets the RX/TX delay according to the phy-mode property in the
device tree. For the A20-olinuxino-lime2 board this is "rgmii", which is the
wrong setting.
Following the example of a900cac375 ("ARM: dts: sun7i: a20: bananapro:
Fix ethernet phy-mode") the phy-mode is changed to "rgmii-id" which gets
the Ethernet working again on this board.
Signed-off-by: Bastien Roucariès <rouca@debian.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210916081721.237137-1-rouca@debian.org
Currently, it is no longer possible to retrieve a DHCP address
on the imx6qdl-pico board.
This issue has been exposed by commit f5d9aa79df ("ARM: imx6q:
remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs").
Fix it by describing the qca,clk-out-frequency property as suggested
by the commit above.
Fixes: 98670a0bb0 ("ARM: dts: imx6qdl: Add imx6qdl-pico support")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The micro-SD card doesn't feature a write-protect pin. Set the
corresponding property in the devicetree to handle this behavior
correctly and suppress driver warnings.
Signed-off-by: Yunus Bas <y.bas@phytec.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The MIC2025 switch input signal nEN is active low, describe it as such
in the DT. The previous change to this regulator polarity was incorrectly
influenced by broken quirks in gpiolib-of.c, which is now long fixed. So
fix this regulator polarity setting here once and for all.
Fixes: 3c3601cd6a ("ARM: dts: imx53: Update USB configuration on M53Menlo")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The panel already contains pinctrl-0 phandle, but it is missing
the default pinctrl-names property, so the pin configuration is
ignored. Fill in the missing pinctrl-names property, so the pin
configuration is applied.
Fixes: d81765d693 ("ARM: dts: imx53: Update LCD panel node on M53Menlo")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
- ranges property should be grouped by region, with no functional
changes. Otherwise, schema dtbs_check would report the following errors.
"linux-imx/arch/arm/boot/dts/imx6qp-vicutp.dt.yaml: pcie@1ffc000: ranges: 'oneOf' conditional failed, one must be fixed:
linux-imx/arch/arm/boot/dts/imx6qp-vicutp.dt.yaml: pcie@1ffc000: ranges: 'oneOf' conditional failed, one must be fixed:
[[2164260864, 0, 0, 33030144, 0, 65536, 2181038080, 0, 16777216, 16777216, 0, 15728640]] is not of type 'boolean'
True was expected
[[2164260864, 0, 0, 33030144, 0, 65536, 2181038080, 0, 16777216, 16777216, 0, 15728640]] is not of type 'null'
[2164260864, 0, 0, 33030144, 0, 65536, 2181038080, 0, 16777216, 16777216, 0, 15728640] is too long
From schema: linux-imx/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml"
- refer to commit 281f1f99cf ("PCI: dwc: Detect number of iATU windows").
The num-viewport is not required anymore, remove them totally.
- dt_binding_check complains "compatible: ['fsl,imx6qp-pcie', 'snps,dw-pcie']
is too long", remove "snps,dw-pcie" from the compatible string.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The following warning is seen when the SPI GPIO driver probes:
gpio-expander@0 enforce active low on chipselect handle
The reason for this warning is clearly explained in the comments inside
drivers/gpio/gpiolib-of.c:
* SPI children have active low chip selects
* by default. This can be specified negatively
* by just omitting "spi-cs-high" in the
* device node, or actively by tagging on
* GPIO_ACTIVE_LOW as flag in the device
* tree. If the line is simultaneously
* tagged as active low in the device tree
* and has the "spi-cs-high" set, we get a
* conflict and the "spi-cs-high" flag will
* take precedence.
To properly represent the SPI chipselect polarity, change it to active-low
when the "spi-cs-high" property is absent.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The conversion of the spi-imx driver to use GPIO descriptors
in commit 8cdcd8aeee ("spi: imx/fsl-lpspi: Convert to GPIO descriptors")
helped to detect the following SPI chipselect polarity mismatch on an
imx6q-sabresd for example:
[ 4.854337] m25p80@0 enforce active low on chipselect handle
Prior to the above commit, the chipselect polarity passed via cs-gpios
property was ignored and considered active-low.
The reason for such mismatch is clearly explained in the comments inside
drivers/gpio/gpiolib-of.c:
* SPI children have active low chip selects
* by default. This can be specified negatively
* by just omitting "spi-cs-high" in the
* device node, or actively by tagging on
* GPIO_ACTIVE_LOW as flag in the device
* tree. If the line is simultaneously
* tagged as active low in the device tree
* and has the "spi-cs-high" set, we get a
* conflict and the "spi-cs-high" flag will
* take precedence.
To properly represent the SPI chipselect polarity, change it to active-low
when the "spi-cs-high" property is absent.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The conversion of the spi-imx driver to use GPIO descriptors
in commit 8cdcd8aeee ("spi: imx/fsl-lpspi: Convert to GPIO descriptors")
helped to detect the following SPI chipselect polarity mismatch on an
imx6q-sabresd for example:
[ 4.854337] m25p80@0 enforce active low on chipselect handle
Prior to the above commit, the chipselect polarity passed via cs-gpios
property was ignored and considered active-low.
The reason for such mismatch is clearly explained in the comments inside
drivers/gpio/gpiolib-of.c:
* SPI children have active low chip selects
* by default. This can be specified negatively
* by just omitting "spi-cs-high" in the
* device node, or actively by tagging on
* GPIO_ACTIVE_LOW as flag in the device
* tree. If the line is simultaneously
* tagged as active low in the device tree
* and has the "spi-cs-high" set, we get a
* conflict and the "spi-cs-high" flag will
* take precedence.
To properly represent the SPI chipselect polarity, change it to active-low
when the "spi-cs-high" property is absent.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The conversion of the spi-imx driver to use GPIO descriptors
in commit 8cdcd8aeee ("spi: imx/fsl-lpspi: Convert to GPIO descriptors")
helped to detect the following SPI chipselect polarity mismatch on an
imx6q-sabresd for example:
[ 4.854337] m25p80@0 enforce active low on chipselect handle
Prior to the above commit, the chipselect polarity passed via cs-gpios
property was ignored and considered active-low.
The reason for such mismatch is clearly explained in the comments inside
drivers/gpio/gpiolib-of.c:
* SPI children have active low chip selects
* by default. This can be specified negatively
* by just omitting "spi-cs-high" in the
* device node, or actively by tagging on
* GPIO_ACTIVE_LOW as flag in the device
* tree. If the line is simultaneously
* tagged as active low in the device tree
* and has the "spi-cs-high" set, we get a
* conflict and the "spi-cs-high" flag will
* take precedence.
To properly represent the SPI chipselect polarity, change it to active-low
when the "spi-cs-high" property is absent.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Since the reg property was added to each channel node in commit
b86d3d21cd ("ARM: dts: imx6dl-yapp4: Add reg property to the lp5562
channel node") it is possible to skip unused channels.
Remove the actually unused white LED channel.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Since the LED multicolor framework support was added in commit
92a81562e6 ("leds: lp55xx: Add multicolor framework support to lp55xx")
LEDs on this platform stopped working.
Author of the framework attempted to accommodate this DT to the
framework in commit b86d3d21cd ("ARM: dts: imx6dl-yapp4: Add reg property
to the lp5562 channel node") but that is not sufficient. A color property
is now required even if the multicolor framework is not used, otherwise
the driver probe fails:
lp5562: probe of 1-0030 failed with error -22
Add the color property to fix this.
Fixes: 92a81562e6 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Cc: <stable@vger.kernel.org>
Cc: linux-leds@vger.kernel.org
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The MAC-Address of the MR32's sole ethernet port is
located in offset 0x66 of the attached AT24C64 eeprom.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
the switch identifies itself as a BCM53012 (rev 5)...
This patch has been tested & verified on OpenWrt's
snapshot with Linux 5.10 (didn't test any older kernels).
The MR32 is able to "talk to the network" as before with
OpenWrt's SWITCHDEV b53 driver.
| b53-srab-switch 18007000.ethernet-switch: found switch: BCM53012, rev 5
| libphy: dsa slave smi: probed
| b53-srab-switch 18007000.ethernet-switch poe (uninitialized):
| PHY [dsa-0.0:00] driver [Generic PHY] (irq=POLL)
| b53-srab-switch 18007000.ethernet-switch: Using legacy PHYLIB callbacks.
| Please migrate to PHYLINK!
| DSA: tree 0 setup
Reported-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
BCM53573 family SoC have Ethernet switch connected to the first Ethernet
controller (accessible over MDIO).
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The partitions on the eMMC will not even appear sometimes, in the
datasheet for the Samsung KLMxGxxE4x we find that the power-on time
for a 4GB eMMC of this type is 300 ms and nowadays the block stack
is so fast so we are stressing it, and we need to specify that we
need this delay in the device tree.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
With the conversion of rockchip,rk-timer.yaml the clock-names order
was set to "pclk", "timer", but nothing was fixed in the ARM dts section
of the mainline kernel, so the swap timer clock-names that don't fit.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/timer/rockchip,rk-timer.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210828102659.7348-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
After the conversion to YAML of the Operating Performance Points(OPP)
binding the operating-points property expects values in
a uint32-matrix with 2 items, so fix the notifications by adding
angle brackets.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v1.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210828091233.19992-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
After the conversion to YAML of the Operating Performance Points(OPP)
binding the operating-points-v2 property expects the nodename to have
the '^opp-table(-[a-z0-9]+)?$' format, so rename all Rockchip ARM dts
opp-table node names.
make ARCH=arm dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/opp/opp-v2.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210828094512.26862-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The MK808 has a button inside the cover for the boot loader to do
some action. Add the adc-keys node to the rk3066a-mk808.dts file.
The rk3066 has a higher maximum DC supply voltage for the analog part of
SAR-ADC VDDA_SARADC of 2.75V then other Rockchip SoCs.
For the "rockchip,saradc" node is a vref-supply property required,
so add a regulator for it as well.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210828092755.24560-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
