Rpmsg channel for MICFIL can also be created through rpmsg name service
announcement. If this driver is probed, Cortex-A can access MICFIL
which is actually controlled by Cortex-M through rpmsg channel for
MICFIL. This driver also helps register ASoC platform device thus use
of PLATFORM_DEVID_AUTO macro in API can automatically create device for
each rpmsg channel.
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Shengjiu Wang <shengjiu.wang@gmail.com>
Link: https://lore.kernel.org/r/20220930064441.2548505-3-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add a string property to assign the rpmsg channel this sound card sits
on. This property can be omitted if there is only one sound card and it
sits on "rpmsg-audio-channel".
Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20220930064441.2548505-2-chancel.liu@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to load proper board configuration it needs to be looked up in
ACPI. Add board configuration for MAXIM 98927 codec present on
Chromebooks.
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20220930124538.354992-3-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Allow the WM8961 driver to be enabled independently now that it is
usable with devicetree.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221003032414.248326-4-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add support for devicetree to the WM8961 driver so it can be used with
modern DT-based kernels.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20221003032414.248326-3-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Create a simple DT schema for the existing Wolfson WM8961 driver so that
DT support can be added to the driver.
Signed-off-by: Doug Brown <doug@schmorgal.com>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221003032414.248326-2-doug@schmorgal.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Most of the device with QUP SPI adapter are actually using GPIO-s for
chip select.
However, this stopped working after ("spi: Retire legacy GPIO handling")
as it introduced a check on ->use_gpio_descriptors flag and since spi-qup
driver does not set the flag it meant that all of boards using GPIO-s and
with QUP adapter SPI devices stopped working.
So, to enable using GPIO-s again set ->use_gpio_descriptors to true and
populate ->max_native_cs.
Fixes: f48dc6b966 ("spi: Retire legacy GPIO handling")
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Cc: luka.perkov@sartura.hr
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20221006194819.1536932-1-robert.marko@sartura.hr
Signed-off-by: Mark Brown <broonie@kernel.org>
Add the infrared receiver and its associated pinctrl entry. Note that
there is an external pullup to VCC3V3_SYS.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-14-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3568 has two USB XHCI controllers. The USB 2.0 signals
are connected to a PHY providing one host-only port and one OTG port.
The USB 3.0 signals are connected to two USB3.0/PCIE/SATA combo PHY.
The ODROID M1 has 2 type A USB 3.0 connectors, with the USB 3.0 signals
connected to the two combo PHYs. For the USB 2.0 signals, one connector
is connected to the host-only PHY and uses the same power switch as the
USB 2.0 ports. The other connector has its own power switch and is
connected to the OTG PHY, which is also connected to a device only
micro-USB connector. The purpose of this micro-USB connector is for
firmware update using the Rockusb vendor specific USB class. Therefore
it does not make sense to enable this port on Linux, and the PHY is
forced to host mode.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-11-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Rockchip RK3568 has two USB OHCI/EHCI controllers connected to a PHY
providing one host-only port and one OTG port. On the ODROID-M1, they
are both used in host mode. The USB ports are powered by a DC/DC
converter providing 5V and named VCC5V0_SYS on the schematics, followed
by a power switch.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-10-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This enables the i2s0 controller and the hdmi-sound node on the
ODROID-M1.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-8-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
On the ODROID-M1, the I2S1 TDM controller is connected to the rk809
codec in I2S mode. It is used to provide a stereo headphones output and
a mono speaker output. A GPIO with an external pullup is used as an
headphone detection input.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-6-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Enable the Rockchip Serial Flash Controller for the ODROID-M1 and add
the corresponding SPI NOR flash entry. The SFC is used in dual I/O mode
and not quad I/O mode, as the FSPI_D2 pin is shared with the EMMC_RSTn
pin.
The partitions addresses and sizes are taken from the ODROID-M1
Partition Table page on the ODROID wiki.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-5-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
This patch is to add a device tree for new board Hardkernel ODROID-M1
based on Rockchip RK3568, includes basic peripherals -
uart/eMMC/uSD/i2c and on-board ethernet.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
[aurelien@aurel32.net: addressed issues from initial review]
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-3-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree binding for Hardkernel ODROID-M1 board based on RK3568
SoC.
Signed-off-by: Dongjin Kim <tobetter@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Tested-by: Dan Johansen <strit@manjaro.org>
Link: https://lore.kernel.org/r/20220930051246.391614-2-aurelien@aurel32.net
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The PX30-uQ7 (Ringneck) SoM is a µQseven-compatible (40mmx70mm, MXM-230
connector) system-on-module from Theobroma Systems[1], featuring the
Rockchip PX30.
It provides the following feature set:
* up to 4GB DDR4
* up to 128GB on-module eMMC (with 8-bit 1.8V interface)
* SD card (on a baseboard) via edge connector
* Fast Ethernet with on-module TI DP83825I PHY
* MIPI-DSI/LVDS
* MIPI-CSI
* USB
- 1x USB 2.0 dual-role
- 3x USB 2.0 host
* on-module STM32 Cortex-M0 companion controller, implementing:
- low-power RTC functionality (ISL1208 emulation)
- fan controller (AMC6821 emulation)
- USB<->CAN bridge controller
* on-module Espressif ESP32 for Bluetooth + 2.4GHz WiFi
* on-module NXP SE05x Secure Element
[1] https://www.theobroma-systems.com/som-product/px30-%C2%B5q7/
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Link: https://lore.kernel.org/r/20220930-upstream-ringneck-v2-1-6671694b6934@theobroma-systems.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Back in the description of commit e440e30e26 ("arm64: dts: qcom:
sc7180: Avoid glitching SPI CS at bootup on trogdor") we described a
problem that we were seeing on trogdor devices. I'll re-summarize here
but you can also re-read the original commit.
On trogdor devices, the BIOS is setting up the SPI chip select as:
- mux special function (SPI chip select)
- output enable
- output low (unused because we've muxed as special function)
In the kernel, however, we've moved away from using the chip select
line as special function. Since the kernel wants to fully control the
chip select it's far more efficient to treat the line as a GPIO rather
than sending packet-like commands to the GENI firmware every time we
want the line to toggle.
When we transition from how the BIOS had the pin configured to how the
kernel has the pin configured we end up glitching the line. That's
because we _first_ change the mux of the line and then later set its
output. This glitch is bad and can confuse the device on the other end
of the line.
The old commit e440e30e26 ("arm64: dts: qcom: sc7180: Avoid
glitching SPI CS at bootup on trogdor") fixed the glitch, though the
solution was far from elegant. It essentially did the thing that
everyone always hates: encoding a sequential program in device tree,
even if it's a simple one. It also, unfortunately, got broken by
commit b991f8c362 ("pinctrl: core: Handling pinmux and pinconf
separately"). After that commit we did all the muxing _first_ even
though the config (set the pin to output high) was listed first. :(
I looked at ideas for how to solve this more properly. My first
thought was to use the "init" pinctrl state. In theory the "init"
pinctrl state is supposed to be exactly for achieving glitch-free
transitions. My dream would have been for the "init" pinctrl to do
nothing at all. That would let us delay the automatic pin muxing until
the driver could set things up and call pinctrl_init_done(). In other
words, my dream was:
/* Request the GPIO; init it 1 (because DT says GPIO_ACTIVE_LOW) */
devm_gpiod_get_index(dev, "cs", GPIOD_OUT_LOW);
/* Output should be right, so we can remux, yay! */
pinctrl_init_done(dev);
Unfortunately, it didn't work out. The primary reason is that the MSM
GPIO driver implements gpio_request_enable(). As documented in
pinmux.h, that function automatically remuxes a line as a GPIO. ...and
it does this remuxing _before_ specifying the output of the pin. You
can see in gpiod_get_index() that we call gpiod_request() before
gpiod_configure_flags(). gpiod_request() isn't passed any flags so it
has no idea what the eventual output will be.
We could have debates about whether or not the automatic remuxing to
GPIO for the MSM pinctrl was a good idea or not, but at this point I
think there is a plethora of code that's relying on it and I certainly
wouldn't suggest changing it.
Alternatively, we could try to come up with a way to pass the initial
output state to gpio_request_enable() and plumb all that through. That
seems like it would be doable, but we'd have to plumb it through
several layers in the stack.
This patch implements yet another alternative. Here, we specifically
avoid glitching the first time a pin is muxed to GPIO function if the
direction of the pin is output. The idea is that we can read the state
of the pin before we set the mux and make sure that the re-mux won't
change the state.
NOTES:
- We only do this the first time since later swaps between mux states
might want to preserve the old output value. In other words, I
wouldn't want to break a driver that did:
gpiod_set_value(g, 1);
pinctrl_select_state(pinctrl, special_state);
pinctrl_select_default_state();
/* We should be driving 1 even if "special_state" made the pin 0 */
- It's safe to do this the first time since the driver _couldn't_ have
explicitly set a state. In order to even be able to control the GPIO
(at least using gpiod) we have to have requested it which would have
counted as the first mux.
- In theory, instead of keeping track of the first time a pin was set
as a GPIO we could enable the glitch-free behavior only when
msm_pinmux_request_gpio() is in the callchain. That works an enables
my "dream" implementation above where we use an "init" state to
solve this. However, it's nice not to have to do this. By handling
just the first transition to GPIO we can simply let the normal
"default" remuxing happen and we can be assured that there won't be
a glitch.
Before this change I could see the glitch reported on the EC console
when booting. It would say this when booting the kernel:
Unexpected state 1 in CSNRE ISR
After this change there is no error reported.
Note that I haven't reproduced the original problem described in
e440e30e26 ("arm64: dts: qcom: sc7180: Avoid glitching SPI CS at
bootup on trogdor") but I could believe it might happen in certain
timing conditions.
Fixes: b991f8c362 ("pinctrl: core: Handling pinmux and pinconf separately")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20221014103217.1.I656bb2c976ed626e5d37294eb252c1cf3be769dc@changeid
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
GPIOLIB and PINCTRL config options are required by all ARM32/ARM64/RISC-V
Renesas SoCs, so instead of selecting them under ARCH_RENESAS for each
architecture just explicitly select them under SOC_RENESAS config option
which will be visible for all the three architectures (if ARCH_RENESAS is
enabled).
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220919104606.96553-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
As serial communication requires a clock signal, the High Speed Serial
Communication Interfaces with FIFO (HSCIF) are clocked by a clock that
is not affected by Spread Spectrum or Fractional Multiplication.
Hence change the clock input for the HSCIF0 Baud Rate Generator internal
clock from the S0D3_PER clock to the SASYNCPERD1 clock (which has the
same clock rate), cfr. R-Car V4H Hardware User's Manual rev. 0.54.
Fixes: 987da486d8 ("arm64: dts: renesas: Add Renesas R8A779G0 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Link: https://lore.kernel.org/r/a5bd4148f92806f7c8e577d383370f810315f586.1665155947.git.geert+renesas@glider.be
Some laptops have been reported to wake up from s2idle when plugging
in the AC adapter or by closing the lid. This is a surprising
behavior that is further clarified by commit cb3e7d624c ("PM:
wakeup: Add extra debugging statement for multiple active IRQs").
With that commit in place the following interaction can be seen
when the lid is closed:
[ 28.946038] PM: suspend-to-idle
[ 28.946083] ACPI: EC: ACPI EC GPE status set
[ 28.946101] ACPI: PM: Rearming ACPI SCI for wakeup
[ 28.950152] Timekeeping suspended for 3.320 seconds
[ 28.950152] PM: Triggering wakeup from IRQ 9
[ 28.950152] ACPI: EC: ACPI EC GPE status set
[ 28.950152] ACPI: EC: ACPI EC GPE dispatched
[ 28.995057] ACPI: EC: ACPI EC work flushed
[ 28.995075] ACPI: PM: Rearming ACPI SCI for wakeup
[ 28.995131] PM: Triggering wakeup from IRQ 9
[ 28.995271] ACPI: EC: ACPI EC GPE status set
[ 28.995291] ACPI: EC: ACPI EC GPE dispatched
[ 29.098556] ACPI: EC: ACPI EC work flushed
[ 29.207020] ACPI: EC: ACPI EC work flushed
[ 29.207037] ACPI: PM: Rearming ACPI SCI for wakeup
[ 29.211095] Timekeeping suspended for 0.739 seconds
[ 29.211095] PM: Triggering wakeup from IRQ 9
[ 29.211079] PM: Triggering wakeup from IRQ 7
[ 29.211095] ACPI: PM: ACPI non-EC GPE wakeup
[ 29.211095] PM: resume from suspend-to-idle
* IRQ9 on this laptop is used for the ACPI SCI.
* IRQ7 on this laptop is used for the GPIO controller.
What has occurred is when the lid was closed the EC woke up the
SoC from it's deepest sleep state and the kernel's s2idle loop
processed all EC events. When it was finished processing EC events,
it checked for any other reasons to wake (break the s2idle loop).
The IRQ for the GPIO controller was active so the loop broke, and
then this IRQ was processed. This is not a kernel bug but it is
certainly a surprising behavior, and to better debug it we should
have a dynamic debugging message that we can enact to catch it.
Acked-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com>
Acked-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20221013134729.5592-2-mario.limonciello@amd.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The OF node in the GPIO library is deprecated and soon
will be removed.
GPIO library now accepts fwnode as a firmware node, so
switch the driver to use it.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://lore.kernel.org/r/20221010075615.43244-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
spi1 is available on the RZ/G2UL SMARC EVK carrier board (PMOD0), hence
moving the spi1 pinmux from SoM to carrier board. This is to keep
consistency with the other SMARC EVKs.
Also while moving the pinmux rename rspi1 to spi1 to be consistent with
other SMARC EVK DTSIs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220921082221.10599-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Move including the rzg2lc-smarc-som.dtsi from the carrier board
rzg2lc-smarc.dtsi to the actual RZ/G2LC SMARC EVK board dts
r9a07g044c2-smarc.dts. Also move the SW1 related macros along with
PMOD1_SER0 to board dts so that we have all the configuration options
in the same file.
This patch is to keep consistency with other SMARC EVKs (RZ/G2L, RZ/G2UL)
and it makes sense not include the SoM into the carrier board as we might
in future have a different carrier board with the same SoM.
Suggested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Link: https://lore.kernel.org/r/20220919092130.93074-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Without ->gpio_request_enable() and ->gpio_set_direction()
callbacks it's not possible to mux GPIO via standard GPIO
interfaces (like `gpioget` or `gpioset` tools in user space).
Implement those functions to fill the above mentioned gap.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221010125221.28275-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Adding persist state case to atmel_conf_pin_config_group_set() function.
After adding configuration support for userspace gpiod api, there was an
extra flag PIN_CONFIG_PERSIST_STATE that was not passed in before.
Based on other drivers like TI drivers, added a switch case and return
ENOTSUPP in that case.
Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20221007151647.98222-3-Ryan.Wanner@microchip.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Adding support for line bias flags that have been implented in gpio API.
There are functions in the gpiod library that can control line bias from
userspace this adds that functionality to this driver.
Adding .pin_config_set allows the driver's pin configuration to be
accessed from userspace. The general idea for this as been taken from
stm32, intel, and rockchip drivers that have userspace access for bias
flags.
Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com>
Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com> # on sama5d27 som1 ek
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Tested-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20221007151647.98222-2-Ryan.Wanner@microchip.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some mt7986 boards use uart rts/cts pins as gpio,
This patch allows to change rts/cts to gpio mode, but keep
rx/tx as UART function.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Link: https://lore.kernel.org/r/20221008164807.113590-1-linux@fw-web.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
SDIO tuple is only allocated for standard SDIO card, especially it causes
memory corruption issues when the non-standard SDIO card has removed, which
is because the card device's reference counter does not increase for it at
sdio_init_func(), but all SDIO card device reference counter gets decreased
at sdio_release_func().
Fixes: 6f51be3d37 ("sdio: allow non-standard SDIO cards")
Signed-off-by: Matthew Ma <mahongwei@zeku.com>
Reviewed-by: Weizhao Ouyang <ouyangweizhao@zeku.com>
Reviewed-by: John Wang <wangdayu@zeku.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221014034951.2300386-1-ouyangweizhao@zeku.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Enhanced Strobe (ES) does not work correctly on the ASUS 1100 series of
devices. Jasper Lake eMMCs (pci_id 8086:4dc4) are supposed to support
ES. There are also two system families under the series, thus this is
being scoped to the ASUS BIOS.
The failing ES prevents the installer from writing to disk. Falling back
to HS400 without ES fixes the issue.
Signed-off-by: Patrick Thompson <ptf@google.com>
Fixes: 315e3bd7ac ("mmc: sdhci-pci: Add support for Intel JSL")
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221013210017.3751025-1-ptf@google.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The core issues the warning "drop HS400 support since no 8-bit bus" when
one of the ESDHC_FLAG_HS400* flags is set on a non 8bit capable host. To
avoid this warning set these flags only on hosts that actually can do
8bit, i.e. have bus-width = <8> set in the device tree.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Fixes: 029e2476f9 ("mmc: sdhci-esdhc-imx: add HS400_ES support for i.MX8QXP")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20221013093248.2220802-1-s.hauer@pengutronix.de
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
To prevent any recovery work running after the queue cleanup cancel it.
Any recovery running post-cleanup dereferenced mq->card as NULL
and was not meaningful to begin with.
Cc: stable@vger.kernel.org
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/c865c0c9789d428494b67b820a78923e@hyperstone.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Before switching back to the right partition in mmc_blk_reset there used
to be a check if hw_reset was even supported. This return value
was removed, so there is no reason to check. Furthermore ensure
part_curr is not falsely set to a valid value on reset or
partition switch error.
As part of this change the code paths of mmc_blk_reset calls were checked
to ensure no commands are issued after a failed mmc_blk_reset directly
without going through the block layer.
Fixes: fefdd3c91e ("mmc: core: Drop superfluous validations in mmc_hw|sw_reset()")
Cc: stable@vger.kernel.org
Signed-off-by: Christian Loehle <cloehle@hyperstone.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Link: https://lore.kernel.org/r/e91be6199d04414a91e20611c81bfe1d@hyperstone.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
