During hardware validation it was noticed that the clock isn't
continuously enabled when there is no link. This is because the 125MHz
clock is derived from the internal PLL which seems to go into some kind
of power-down mode every once in a while. The LS1028A expects a contiuous
clock. Thus enable the PLL all the time.

Also, the RGMII pad voltage is wrong, it was configured to 2.5V (that is
the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO
regulator.

This fix is for the freescale/fsl-ls1028a-kontron-sl28-var1.dts.

Fixes: 64285609 ("arm64: dts: freescale: sl28: add variant 1")
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

During hardware validation it was noticed that the clock isn't
continuously enabled when there is no link. This is because the 125MHz
clock is derived from the internal PLL which seems to go into some kind
of power-down mode every once in a while. The LS1028A expects a contiuous
clock. Thus enable the PLL all the time.

Also, the RGMII pad voltage is wrong. It was configured to 2.5V (that is
the VDDH regulator). The correct voltage is 1.8V, i.e. the VDDIO
regulator.

This fix is for the freescale/fsl-ls1028a-kontron-sl28-var4.dts.

Fixes: 815364d0 ("arm64: dts: freescale: add Kontron sl28 support")
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

As this is a fixed regulator on the board there was no harm in the wrong
voltage being specified, apart from a confusing reporting to userspace.

Fixes: 4a13b3be ("arm64: dts: imx: add Zii Ultra board support")
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

When adding the sound support a second instance of the GEN_3V3 regulator was
added by accident. Remove it and point the consumers to the first instance.

Fixes: 663a5b5e ("arm64: dts: zii-ultra: add sound support")
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

While enabling EDAC support for the LS1028A it was discovered that the
memory node has a wrong endianness setting as well as a wrong interrupt
assignment. Fix both.

This was tested on a sl28 board. To force ECC errors, you can use the
error injection supported by the controller in hardware (with
CONFIG_EDAC_DEBUG enabled):

 # enable error injection
 $ echo 0x100 > /sys/devices/system/edac/mc/mc0/inject_ctrl
 # flip lowest bit of the data
 $ echo 0x1 > /sys/devices/system/edac/mc/mc0/inject_data_lo

Fixes: 8897f325 ("arm64: dts: Add support for NXP LS1028A SoC")
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NShawn Guo <shawnguo@kernel.org>

Interrupt routers are memory mapped peripherals, that are organized
in our dts bus hierarchy to closely represents the actual hardware
behavior.

However, without explicitly calling out the reg property, using
2021.03+ dt-schema package, this exposes the following problem with
dtbs_check:

/arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000:
interrupt-controller0: {'type': 'object'} is not allowed for
{'compatible': ['ti,sci-intr'], .....

Even though we don't use interrupt router directly via memory mapped
registers and have to use it via the system controller, the hardware
block is memory mapped, so describe the base address in device tree.

This is a valid, comprehensive description of hardware and permitted
by the existing ti,sci-intr schema.
Reviewed-by: NTero Kristo <kristo@kernel.org>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210511194821.13919-1-nm@ti.com

Instead of using empty ranges property, lets map explicitly the address
range that is mapped onto the dma / navigator subsystems (navss/dmss).

This is also exposed via the dtbs_check with dt-schema newer than
2021.03 version by throwing out following:
arch/arm64/boot/dts/ti/k3-am654-base-board.dt.yaml: bus@100000: main-navss:
{'type': 'object'} is not allowed for
{'compatible': ['simple-mfd'], '#address-cells': [[2]], .....

This has already been correctly done for J7200, however was missed for
other k3 SoCs. Fix that oversight.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTero Kristo <kristo@kernel.org>
Acked-by: NVignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20210510145429.8752-1-nm@ti.com

Lets rename the node name of TI-SCI node to be system-controller as it
is a better standardized name for the function that TI-SCI plays in the
SoC.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-5-nm@ti.com

The DMSC node does'nt require any of "#address-cells", "#size-cells"
or "ranges" property as the child nodes are representations of SoC's
system controller itself, so align it with the bindings.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-4-nm@ti.com

Lets add the TISCI debug region to TI-SCI region in line with TI-SCI
documentation[1]. While at it, lets rename the node to indicate the
address usage.

[1] http://downloads.ti.com/tisci/esd/latest/4_trace/trace.htmlSigned-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-3-nm@ti.com

We currently use clocks as the node name for the node representing
TI-SCI clock nodes. This is better renamed to being clock-controller
as that is a better representative of the system controller function
as a clock controller for the SoC.
Signed-off-by: NNishanth Menon <nm@ti.com>
Reviewed-by: NTero Kristo <kristo@kernel.org>
Link: https://lore.kernel.org/r/20210510145033.7426-2-nm@ti.com

Traffic through main NAVSS interconnect is coherent wrt ARM caches on
J7200 SoC.  Add missing dma-coherent property to main_navss node.

Also add dma-ranges to be consistent with mcu_navss node
and with AM65/J721e main_navss and mcu_navss nodes.

Fixes: d361ed88 ("arm64: dts: ti: Add support for J7200 SoC")
Signed-off-by: NVignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210510180601.19458-1-vigneshr@ti.com

AM654 EVM boards are not shipped with OV5640 sensor module, it is a
separate purchase. OV5640 module is also just one of the possible
sensors or capture boards you can connect.

However, for some reason, OV5640 has been added to the board dts file,
making it cumbersome to use other sensors.

Remove the OV5640 from the dts file so that it is easy to use other
sensors via DT overlays.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Acked-by: NPratyush Yadav <p.yadav@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210423083120.73476-1-tomi.valkeinen@ideasonboard.com

The port@0 is a mandatory port, add or move the declaration to the CSI-2
nodes top declared in dtsi files instead of depending on dts files
adding them when describing the external connection.

This fixes validation warnings for DTB outputs that do not connect all
CSI-2 receivers to transmitters and thus declaring all port@0 nodes in
dts files.
Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20210421150221.3202955-3-niklas.soderlund+renesas@ragnatech.seSigned-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>

Fix the DTS schema by explicitly stating that the input is port@0. This
fixes a schema validation error but has no runtime effect as the default
port number is 0 if not specified.
Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20210421150221.3202955-2-niklas.soderlund+renesas@ragnatech.seSigned-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>

Rockchip DWMAC glue driver uses the phy node (phy-handle)
reset specifier, and not a "mac-phy" reset specifier.

Remove it.
Signed-off-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NDavid Wu <david.wu@rock-chips.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A test with the command below gives this error:

/arch/arm64/boot/dts/rockchip/rk3368-evb-act8846.dt.yaml:
pwm@ff680030: clock-names: ['pwm'] is too short

Devices with only one PWM clock use it to both to derive the functional
clock for the device and as the bus clock. The driver does not need
"clock-names" to get a handle, so remove them all.

make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml
Signed-off-by: NJohan Jonker <jbx6244@gmail.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NThierry Reding <thierry.reding@gmail.com>

UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have
the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY
pins.

After the commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx
delay config"), the delays are working correctly, however, "rgmii" means
no delay and the phy doesn't work. So need to set the phy-mode to
"rgmii-id" to show that RX/TX delays are enabled.

Fixes: c73730ee ("arm64: dts: uniphier: add AVE ethernet node")
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Take a pass at cleaning up a bunch of warnings
from 'make dtbs_check' that have crept in.
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210421204833.18523-1-khilman@baylibre.com'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Commit 941432d0 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

This was based on the observation that the Pine64-LTS has as "push-push"
SD card socket, and that the schematic mentions the card detect GPIO.

After having received two reports about failing SD card access with that
patch, some more research and polls on that subject revealed that there
are at least two different versions of the Pine64-LTS out there:
- On some boards (including mine) the card detect pin is "stuck" at
  high, regardless of an microSD card being inserted or not.
- On other boards the card-detect is working, but is active-high, by
  virtue of an explicit inverter circuit, as shown in the schematic.

To cover all versions of the board out there, and don't take any chances,
let's revert the introduction of the active-low CD GPIO, but let's use
the broken-cd property for the Pine64-LTS this time. That should avoid
regressions and should work for everyone, even allowing SD card changes
now.
The SOPine card detect has proven to be working, so let's keep that
GPIO in place.

Fixes: 941432d0 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
Reported-by: NMichael Weiser <michael.weiser@gmx.de>
Reported-by: NDaniel Kulesz <kuleszdl@posteo.org>
Suggested-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Tested-by: NMichael Weiser <michael.weiser@gmx.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210414104740.31497-1-andre.przywara@arm.com

Add a node describing the address in the SoC memory space for the IERB.
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Update iommu property in lpass cpu node for supporting
simultaneous playback on headset and speaker.
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NV Sujith Kumar Reddy <vsujithk@codeaurora.org>
Signed-off-by: NSrinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20210406163330.11996-1-srivasam@codeaurora.orgSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Match what's downstream for this board.
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Ajit Pandey <ajitp@codeaurora.org>
Cc: Judy Hsiao <judyhsiao@chromium.org>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315133924.v2.2.If218189eff613a6c48ba12d75fad992377d8f181@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This was present downstream. Add upstream too. NOTE: upstream I
managed to get some sort of halfway state and got one pinctrl entry in
the coachz-r1 device tree. Remove that as part of this since it's now
in the dtsi.
Reviewed-by: NMatthias Kaehlcke <mka@chromium.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Ajit Pandey <ajitp@codeaurora.org>
Cc: Judy Hsiao <judyhsiao@chromium.org>
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315133924.v2.1.I601a051cad7cfd0923e55b69ef7e5748910a6096@changeidSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

Fix unit names to make dtbs_check happy.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-2-matthias.bgg@kernel.org
Link: https://lore.kernel.org/r/20210416143923.23406-3-matthias.bgg@kernel.org'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Fix unit names to make dtbs_check happy.
Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210414144643.17435-1-matthias.bgg@kernel.org
Link: https://lore.kernel.org/r/20210416143923.23406-2-matthias.bgg@kernel.org'
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.
Suggested-by: NArnd Bergmann <arnd@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-7-heiko@sntech.de

As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.
Suggested-by: NArnd Bergmann <arnd@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-6-heiko@sntech.de

As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.
Suggested-by: NArnd Bergmann <arnd@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-5-heiko@sntech.de

As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.
Suggested-by: NArnd Bergmann <arnd@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-4-heiko@sntech.de

As suggested by Arnd Bergmann, the newly added mmc aliases
should be board specific, so move them from the general dtsi
to the individual boards.

For the Engicam-boards this means a split as the core
boards contains the emmc while the commit baseboard handles
sdmmc and sdio.
Suggested-by: NArnd Bergmann <arnd@kernel.org>
Signed-off-by: NHeiko Stuebner <heiko.stuebner@theobroma-systems.com>
Link: https://lore.kernel.org/r/20210324122235.1059292-3-heiko@sntech.de

Change my e-mail address to kabel@kernel.org, and fix my name in
non-code parts (add diacritical mark).

Link: https://lkml.kernel.org/r/20210325171123.28093-2-kabel@kernel.orgSigned-off-by: NMarek Behún <kabel@kernel.org>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jassi Brar <jassisinghbrar@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The top-level node doesn't provide any clocks, the subnode provides a
single clock with of_clk_hw_simple_get.
Signed-off-by: NJonathan Marek <jonathan@marek.ca>
Link: https://lore.kernel.org/r/20201123143705.14277-1-jonathan@marek.caSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

The ARM Cortex-A53 CPU cores and QGIC2 interrupt controller
(an implementation of the ARM GIC 2.0 specification) used in MSM8916
support virtualization, e.g. for KVM on Linux. However, so far it was
not possible to make use of this functionality, because Qualcomm's
proprietary "hyp" firmware blocks the EL2 mode of the CPU and only
allows booting Linux in EL1.

However, on devices without (firmware) secure boot there is no need
to rely on all of Qualcomm's firmware. The "hyp" firmware on MSM8916
seems simple enough that it can be replaced with an open-source
alternative created only based on trial and error - with some similar
EL2/EL1 initialization code adapted from Linux and U-Boot.

qhypstub [1] is such an open-source firmware for MSM8916 that
can be used as drop-in replacement for Qualcomm's "hyp" firmware.
It does not implement any hypervisor functionality.
Instead, it allows booting Linux/KVM (or other hypervisors) in EL2.

With Linux booting in EL2, KVM seems to be working just fine on MSM8916.
However, so far it is not possible to make use of the virtualization
features in the GICv2. To use KVM's VGICv2 code, the QGIC2 device tree
node needs additional resources (according to binding documentation):

  - The CPU interface region (second reg) must be at least 8 KiB large
    to access the GICC_DIR register (mapped at 0x1000 offset)
  - Virtual control/CPU interface register base and size
  - Hypervisor maintenance interrupt

Fortunately, the public APQ8016E TRM [2] provides the required information:

  - The CPU interface region (at 0x0B002000) actually has a size of 8 KiB
  - Virtual control/CPU interface register is at 0x0B001000/0x0B004000
  - Hypervisor maintenance interrupt is "PPI #0"
      Note: This is a bit strange since almost all other ARM SoCs use
            GIC_PPI 9 for this. However, I have verified that this is
            indeed the interrupt that fires when bits are set in GICH_HCR.

Add the additional resources to the QGIC2 device tree node in msm8916.dtsi.
There is no functional difference when Linux is started in EL1 since the
additional resources are ignored in that case.

With these changes (and qhypstub), KVM seems to be fully working on
the DragonBoard 410c (apq8016-sbc) and BQ Aquaris X5 (longcheer-l8910).

[1]: https://github.com/msm8916-mainline/qhypstub
[2]: https://developer.qualcomm.com/download/sd410/snapdragon-410e-technical-reference-manual.pdfAcked-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NStephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210407163648.4708-1-stephan@gerhold.netSigned-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>

This currently supports:

* SMP (via spin-tables)
* AIC IRQs
* Serial (with earlycon)
* Framebuffer

A number of properties are dynamic, and based on system firmware
decisions that vary from version to version. These are expected
to be filled in by the loader.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NHector Martin <marcan@marcan.st>

Add GPIO line-name identifiers to the ODROID N2/N2+ common dtsi.
Signed-off-by: NHyeonki Hong <hhk7734@gmail.com>
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20210407042609.9736-4-christianshewitt@gmail.com

Add the meson saradc node to the ODROID N2/N2+ common dtsi.
Signed-off-by: NHyeonki Hong <hhk7734@gmail.com>
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20210407042609.9736-3-christianshewitt@gmail.com

Remove an extra tab from the ext_mdio node in the ODROID N2/N2+ common
dtsi file.
Signed-off-by: NChristian Hewitt <christianshewitt@gmail.com>
Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com>
Reviewed-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: NKevin Hilman <khilman@baylibre.com>
Link: https://lore.kernel.org/r/20210407042609.9736-2-christianshewitt@gmail.com

Although every Beelink GS1 seems to have external 32768 Hz oscillator,
it works only on one from four tested. There are more reports of RTC
issues elsewhere, like Armbian forum.

One Beelink GS1 owner read RTC osc status register on Android which
shipped with the box. Reported value indicated problems with external
oscillator.

In order to fix RTC and related issues (HDMI-CEC and suspend/resume with
Crust) on all boards, switch to internal oscillator.

Fixes: 32507b86 ("arm64: dts: allwinner: h6: Move ext. oscillator to board DTs")
Signed-off-by: NJernej Skrabec <jernej.skrabec@siol.net>
Tested-by: NClément Péron <peron.clem@gmail.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210330184218.279738-1-jernej.skrabec@siol.net

Commit 941432d0 ("arm64: dts: allwinner: Drop non-removable from
SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module,
along the way with the Pine64-LTS, which share the same base .dtsi.

However while both boards indeed have a working CD GPIO on PF6, the
polarity is different: the SOPine modules uses a "push-pull" socket,
which has an active-high switch, while the Pine64-LTS use the more
traditional push-push socket and the common active-low switch.

Fix the polarity in the sopine.dtsi, and overwrite it in the LTS
board .dts, to make the SD card work again on systems using SOPine
modules.

Fixes: 941432d0 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card")
Reported-by: NAshley <contact@victorianfox.com>
Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210316144219.5973-1-andre.przywara@arm.com