- 19 Jun, 2023 9 commits
-
-
Linus Walleij authored
These four lines clearing, masking and resetting the state of the busy detect state machine is repeated five times in the code so break this out to a small helper so things are easier to read. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230405-pl180-busydetect-fix-v7-9-69a7164f2a61@linaro.orgSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Linus Walleij authored
As is custom, use a big switch statement to transition between the edges of the state machine inside the ux500 ->busy_complete callback. Signed-off-by:
-
Linus Walleij authored
Return true if and only if we reached the state MMCI_BUSY_DONE in the ux500 ->busy_complete() callback. Signed-off-by:
-
Linus Walleij authored
This makes the ux500 ->busy_complete() callback re-read the status register 10 times while waiting for the busy signal to assert in the status register. If this does not happen, we bail out regarding the command completed already, i.e. before we managed to start to check the busy status. There is a comment in the code about this, let's just implement it to be certain that we can catch this glitch if it happens. Signed-off-by:
-
Linus Walleij authored
This refactors the ->busy_complete() callback currently only used by Ux500 and STM32 to handle busy detection on hardware where one and the same IRQ is fired whether we get a start or an end signal on busy detect. The code is currently using the cached status from the command IRQ in ->busy_status as a state to select what to do next: if this state is non-zero we are waiting for IRQs and if it is zero we treat the state as the starting point for a busy detect wait cycle. Make this explicit by creating a state machine where the ->busy_complete callback moves between three states. The Ux500 busy detect code currently assumes this order: we enable the busy detect IRQ, get a busy start IRQ, then a busy end IRQ, and then we clear and mask this IRQ and proceed. We insert debug prints for unexpected states. This works as before on most cards, however on a problematic card that is not working with busy detect, and which I have been debugging, the following happens a lot: [ 3.380554] mmci-pl18x 80005000.mmc: no busy signalling in time [ 3.387420] mmci-pl18x 80005000.mmc: no busy signalling in time [ 3.394561] mmci-pl18x 80005000.mmc: lost busy status when waiting for busy start IRQ This probably means that the busy detect start IRQ has already occurred when we start executing the ->busy_complete() callbacks, and the busy detect end IRQ is counted as the start IRQ, and this is what is causing the card to not be detected properly. Signed-off-by: -
Linus Walleij authored
The busy detect callback for Ux500 checks for an error in the status in the first if() clause. The only practical reason is that if an error occurs, the if()-clause is not executed, and the code falls through to the last if()-clause if (host->busy_status) which will clear and disable the irq. Make this explicit instead: it is easier to read. Signed-off-by:
-
Linus Walleij authored
Some interesting flags can arrive while we are waiting for the first busy detect IRQ so OR then onto the stashed flags so they are not missed. Signed-off-by:
-
Linus Walleij authored
This does two things: firsr replace the hard-to-read long if-expression: if (!host->busy_status && !(status & err_msk) && (readl(base + MMCISTATUS) & host->variant->busy_detect_flag)) { With the more readable: if (!host->busy_status && !(status & err_msk)) { status = readl(base + MMCISTATUS); if (status & host->variant->busy_detect_flag) { Second notice that the re-read MMCISTATUS register is now stored into the status variable, using logic OR because what if something else changed too? While we are at it, explain what the function is doing. Signed-off-by: -
Linus Walleij authored
If we are starting a command which can generate a busy response, then clear the variable host->busy_status if the variant is using a ->busy_complete callback. We are lucky that the member is zero by default and hopefully always gets cleared in the ->busy_complete callback even on errors, but it's just fragile so make sure it is always initialized to zero. Signed-off-by:
-
- 15 Jun, 2023 2 commits
-
-
Ulf Hansson authored
Merge the mmc fixes for v6.4-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.5. Signed-off-by: -
Yann Gautier authored
The feedback clock is used only for SDR104 & HS200 modes, and when delay block is used (frequency is higher than 50 MHz). The tuning procedure is then only required for those modes. Skip the procedure for other modes. The setting of this feedback clock is done just after enabling delay block, and before configuring it. Signed-off-by:
Yann Gautier <yann.gautier@foss.st.com> Signed-off-by:
Christophe Kerello <christophe.kerello@foss.st.com> Link: https://lore.kernel.org/r/20230613150148.429828-1-yann.gautier@foss.st.comSigned-off-by:
-
- 14 Jun, 2023 1 commit
-
-
Martin Hundebøll authored
The call to mmc_request_done() can schedule, so it must not be called from irq context. Wake the irq thread if it needs to be called, and let its existing logic do its work. Fixes the following kernel bug, which appears when running an RT patched kernel on the AmLogic Meson AXG A113X SoC: [ 11.111407] BUG: scheduling while atomic: kworker/0:1H/75/0x00010001 [ 11.111438] Modules linked in: [ 11.111451] CPU: 0 PID: 75 Comm: kworker/0:1H Not tainted 6.4.0-rc3-rt2-rtx-00081-gfd07f41ed6b4-dirty #1 [ 11.111461] Hardware name: RTX AXG A113X Linux Platform Board (DT) [ 11.111469] Workqueue: kblockd blk_mq_run_work_fn [ 11.111492] Call trace: [ 11.111497] dump_backtrace+0xac/0xe8 [ 11.111510] show_stack+0x18/0x28 [ 11.111518] dump_stack_lvl+0x48/0x60 [ 11.111530] dump_stack+0x18/0x24 [ 11.111537] __schedule_bug+0x4c/0x68 [ 11.111548] __schedule+0x80/0x574 [ 11.111558] schedule_loop+0x2c/0x50 [ 11.111567] schedule_rtlock+0x14/0x20 [ 11.111576] rtlock_slowlock_locked+0x468/0x730 [ 11.111587] rt_spin_lock+0x40/0x64 [ 11.111596] __wake_up_common_lock+0x5c/0xc4 [ 11.111610] __wake_up+0x18/0x24 [ 11.111620] mmc_blk_mq_req_done+0x68/0x138 [ 11.111633] mmc_request_done+0x104/0x118 [ 11.111644] meson_mmc_request_done+0x38/0x48 [ 11.111654] meson_mmc_irq+0x128/0x1f0 [ 11.111663] __handle_irq_event_percpu+0x70/0x114 [ 11.111674] handle_irq_event_percpu+0x18/0x4c [ 11.111683] handle_irq_event+0x80/0xb8 [ 11.111691] handle_fasteoi_irq+0xa4/0x120 [ 11.111704] handle_irq_desc+0x20/0x38 [ 11.111712] generic_handle_domain_irq+0x1c/0x28 [ 11.111721] gic_handle_irq+0x8c/0xa8 [ 11.111735] call_on_irq_stack+0x24/0x4c [ 11.111746] do_interrupt_handler+0x88/0x94 [ 11.111757] el1_interrupt+0x34/0x64 [ 11.111769] el1h_64_irq_handler+0x18/0x24 [ 11.111779] el1h_64_irq+0x64/0x68 [ 11.111786] __add_wait_queue+0x0/0x4c [ 11.111795] mmc_blk_rw_wait+0x84/0x118 [ 11.111804] mmc_blk_mq_issue_rq+0x5c4/0x654 [ 11.111814] mmc_mq_queue_rq+0x194/0x214 [ 11.111822] blk_mq_dispatch_rq_list+0x3ac/0x528 [ 11.111834] __blk_mq_sched_dispatch_requests+0x340/0x4d0 [ 11.111847] blk_mq_sched_dispatch_requests+0x38/0x70 [ 11.111858] blk_mq_run_work_fn+0x3c/0x70 [ 11.111865] process_one_work+0x17c/0x1f0 [ 11.111876] worker_thread+0x1d4/0x26c [ 11.111885] kthread+0xe4/0xf4 [ 11.111894] ret_from_fork+0x10/0x20 Fixes: 51c5d844 ("MMC: meson: initial support for GX platforms") Cc: stable@vger.kernel.org Signed-off-by:
Martin Hundebøll <martin@geanix.com> Link: https://lore.kernel.org/r/20230607082713.517157-1-martin@geanix.comSigned-off-by:
-
- 13 Jun, 2023 4 commits
-
-
Christophe Kerello authored
The way that the timeout is currently calculated could lead to a u64 timeout value in mmci_start_command(). This value is then cast in a u32 register that leads to mmc erase failed issue with some SD cards. Fixes: 8266c585 ("mmc: mmci: add hardware busy timeout feature") Signed-off-by:
-
Dennis Zhou authored
When using dm-verity with a data partition on an emmc device, dm-verity races with the initialization of the (e)MMC/SD cards. This is because the card detection procedure is being managed from a workqueue, rather than synchronously from the mmc host's ->probe() routine. To allow the card detect to be synchronous, let's simply skip using the workqueue at the first initialization attempt from mmc_start_host(). Signed-off-by:
Dennis Zhou <dennis@kernel.org> Link: https://lore.kernel.org/r/ZCTOMVjW+pnZVGsQ@snowbird [Ulf: Re-wrote the commit message to clarify the change] Signed-off-by:
-
Ulf Hansson authored
All mmc host drivers should have the asynchronous probe option enabled, but it seems like we failed to set it for mmci, so let's do that now. Fixes: 21b2cec6 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4") Signed-off-by:
-
Ulf Hansson authored
Merge the mmc fixes for v6.4-rc[n] into the next branch, to allow them to get tested together with the new mmc changes that are targeted for v6.5. Signed-off-by:
-
- 12 Jun, 2023 20 commits
-
-
Stephan Gerhold authored
While SDHCI claims to support 64-bit DMA on MSM8916 it does not seem to be properly functional. It is not immediately obvious because SDHCI is usually used with IOMMU bypassed on this SoC, and all physical memory has 32-bit addresses. But when trying to enable the IOMMU it quickly fails with an error such as the following: arm-smmu 1e00000.iommu: Unhandled context fault: fsr=0x402, iova=0xfffff200, fsynr=0xe0000, cbfrsynra=0x140, cb=3 mmc1: ADMA error: 0x02000000 mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00002e02 mmc1: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000000 mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013 mmc1: sdhci: Present: 0x03f80206 | Host ctl: 0x00000019 mmc1: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x00000007 mmc1: sdhci: Timeout: 0x0000000a | Int stat: 0x00000001 mmc1: sdhci: Int enab: 0x03ff900b | Sig enab: 0x03ff100b mmc1: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 mmc1: sdhci: Caps: 0x322dc8b2 | Caps_1: 0x00008007 mmc1: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000 mmc1: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x5b590000 mmc1: sdhci: Resp[2]: 0xe6487f80 | Resp[3]: 0x0a404094 mmc1: sdhci: Host ctl2: 0x00000008 mmc1: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0x0000000ffffff224 mmc1: sdhci_msm: ----------- VENDOR REGISTER DUMP ----------- mmc1: sdhci_msm: DLL sts: 0x00000000 | DLL cfg: 0x60006400 | DLL cfg2: 0x00000000 mmc1: sdhci_msm: DLL cfg3: 0x00000000 | DLL usr ctl: 0x00000000 | DDR cfg: 0x00000000 mmc1: sdhci_msm: Vndr func: 0x00018a9c | Vndr func2 : 0xf88018a8 Vndr func3: 0x00000000 mmc1: sdhci: ============================================ mmc1: sdhci: fffffffff200: DMA 0x0000ffffffffe100, LEN 0x0008, Attr=0x21 mmc1: sdhci: fffffffff20c: DMA 0x0000000000000000, LEN 0x0000, Attr=0x03 Looking closely it's obvious that only the 32-bit part of the address (0xfffff200) arrives at the SMMU, the higher 16-bit (0xffff...) get lost somewhere. This might not be a limitation of the SDHCI itself but perhaps the bus/interconnect it is connected to, or even the connection to the SMMU. Work around this by setting SDHCI_QUIRK2_BROKEN_64_BIT_DMA to avoid using 64-bit addresses. Signed-off-by:Stephan Gerhold <stephan@gerhold.net> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230518-msm8916-64bit-v1-1-5694b0f35211@gerhold.netSigned-off-by:
-
Abel Vesa authored
Now that there is a new dedicated ICE driver, drop the sdhci-msm ICE implementation and use the new ICE api provided by the Qualcomm soc driver ice. The platforms that already have ICE support will use the API as library since there will not be a devicetree node, but instead they have reg range. In this case, the of_qcom_ice_get will return an ICE instance created for the consumer's device. But if there are platforms that do not have ice reg in the consumer devicetree node and instead provide a dedicated ICE devicetree node, theof_qcom_ice_get will look up the device based on qcom,ice property and will get the ICE instance registered by the probe function of the ice driver. The ICE clock is now handle by the new driver. This is done by enabling it on the creation of the ICE instance and then enabling/disabling it on SDCC runtime resume/suspend. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Acked-by:
-
Stefan Wahren authored
Convert the DT binding document for bcm2835-sdhost from .txt to YAML. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20230604121223.9625-9-stefan.wahren@i2se.comSigned-off-by:
-
Victor Shih authored
Add support SD Express card for GL9767. The workflow of the SD Express card in GL9767 is as below. 1. GL9767 operates in SD mode and set MMC_CAP2_SD_EXP flag. 2. If card is inserted, Host send CMD8 to ask the capabilities of the card. 3. If the card has PCIe capability, then init_sd_express() will be invoked. 4. If the card has been put in write protect state then the SD features supported by SD mode but not supported by PCIe mode, therefore GL9767 switch to SD mode. 5. If the card has not been put in write protect state then GL9767 switch from SD mode to PCIe/NVMe mode and mmc driver handover control to NVMe driver. 6. If card is removed, GL9767 will return to SD mode. Signed-off-by:
Ben Chuang <ben.chuang@genesyslogic.com.tw> Signed-off-by:
Victor Shih <victor.shih@genesyslogic.com.tw> Acked-by:
-
Victor Shih authored
Add new definition for VDD2 - UHS2 or PCIe/NVMe. Signed-off-by:
-
Victor Shih authored
Set GL9767 SDR104's clock to 205MHz and enable SSC feature depend on register 0x888 BIT(1). Signed-off-by:
-
Victor Shih authored
Add support for the GL9767 chipset. GL9767 supports SD3 mode likes UHS-I SDR50, SDR104. Enable MSI interrupt for GL9767. Some platform do not support PCI INTx and devices can not work without interrupt. Signed-off-by:
-
Wenbin Mei authored
CQHCI_SSC1 indicates to CQE the polling period to use when using periodic SEND_QUEUE_STATUS(CMD13) polling. Since MSDC CQE uses msdc_hclk as ITCFVAL, so driver should use hclk frequency to get the actual time. The default value 0x1000 that corresponds to 150us for MediaTek SoCs, let's decrease it to 0x40 that corresponds to 2.35us, which can improve the performance of some eMMC devices. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Wenbin Mei <wenbin.mei@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by:
Alexandre Mergnat <amergnat@baylibre.com> Link: https://lore.kernel.org/r/20230609101355.5220-2-wenbin.mei@mediatek.comSigned-off-by:
-
Komal Bajaj authored
Document the compatible for SDHCI on QDU1000 and QRU1000 SoCs. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Reviewed-by:
Bhupesh Sharma <bhupesh.sharma@linaro.org> Signed-off-by:
Komal Bajaj <quic_kbajaj@quicinc.com> Link: https://lore.kernel.org/r/20230601111128.19562-2-quic_kbajaj@quicinc.comSigned-off-by:
-
Christian Loehle authored
SPI doesn't have the usual PROG path we can check for error bits after moving back to TRAN. Instead it holds the line LOW until completion. We can then check if the card shows any errors or is in IDLE state, indicating the line is no longer LOW because the card was reset. Signed-off-by:
Christian Loehle <cloehle@hyperstone.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/55920f880c9742f486f64aa44e25508e@hyperstone.comSigned-off-by:
-
Chevron Li authored
Bayhub SD host has hardware limitation: 1.The upper 32bit address is inhibited to be written at SD Host Register [03E][13]=0 (32bits addressing) mode, is admitted to be written only at SD Host Register [03E][13]=1 (64bits addressing) mode. 2.Because of above item#1, need to configure SD Host Register [03E][13] to 1(64bits addressing mode) before set 64bit ADMA system address's higher 32bits SD Host Register [05F~05C] if 64 bits addressing mode is used. The hardware limitation is reasonable for below reasons: 1.Normal flow should set DMA working mode first, then do DMA-transfer-related configuration, such as system address. 2.The hardware limitation may avoid the software to configure wrong higher 32bit address at 32bits addressing mode although it is redundant. The change that set 32bits/64bits addressing mode before set ADMA address, has no side-effect to other host IPs for below reason: The setting order is reasonable and standard: DMA Mode setting first and then DMA address setting. It meets all DMA setting sequence. Signed-off-by:
Chevron Li <chevron.li@bayhubtech.com> Acked-by:
-
Yeqi Fu authored
The error checks in mmc_blk_add_debugfs() and mmc_blk_remove_debugfs() are extraneous. Therefore, this patch removes all error checks from both functions. Additionally, mmc_blk_add_debugfs() has been changed to return void instead of an integer value that was never used. This simplifies the function and improves its clarity. Signed-off-by:
Yeqi Fu <asuk4.q@gmail.com> Acked-by:
-
Arnd Bergmann authored
There are no other files referencing this function, apparently it was left global to avoid an 'unused function' warning when the only caller is left out. With a 'W=1' build, it causes a 'missing prototype' warning though: drivers/memstick/host/r592.c:47:13: error: no previous prototype for 'memstick_debug_get_tpc_name' [-Werror=missing-prototypes] Annotate the function as 'static __maybe_unused' to avoid both problems. Fixes: 92634125 ("memstick: add driver for Ricoh R5C592 card reader") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20230516202714.560929-1-arnd@kernel.orgSigned-off-by:
-
Douglas Anderson authored
When I boot a kukui-kodama board, I see an ugly warning in my kernel log: mtk-msdc 11240000.mmc: error -ENXIO: IRQ sdio_wakeup not found It's pretty normal not to have an "sdio_wakeup" IRQ defined. In fact, no device trees in mainline seem to have it. Let's use the platform_get_irq_byname_optional() to avoid the error message. Fixes: 527f36f5 ("mmc: mediatek: add support for SDIO eint wakup IRQ") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Brugger <matthias.bgg@gmail.com> Link: https://lore.kernel.org/r/20230510064434.1.I935404c5396e6bf952e99bb7ffb744c6f7fd430b@changeidSigned-off-by:
-
Simon Horman authored
Rather than casting mmc_free_host to an incompatible function type, provide a trivial wrapper with the correct signature for the use-case. Reported by clang-16 with W=1: .../meson-mx-sdhc-mmc.c:791:38: error: cast from 'void (*)(struct mmc_host *)' to 'void (*)(void *)' converts to incompatible function type [-Werror,-Wcast-function-type-strict] ret = devm_add_action_or_reset(dev, (void(*)(void *))mmc_free_host, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/device.h:265:38: note: expanded from macro 'devm_add_action_or_reset' __devm_add_action_or_reset(release, action, data, #action) ^~~~~~ The same approach is taken in litex_mmc.c with the function litex_mmc_free_host_wrapper(). There may be scope for consolidation. No functional change intended. Compile tested only. Signed-off-by:Simon Horman <horms@kernel.org> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20230510-mmc-sdhci-msm-function-cast-v1-1-5ae634b24fbd@kernel.orgSigned-off-by:
-
Florian Fainelli authored
If the device is not read-only, then we will be printing an empty whitespace before the newline, fix that. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20230509194455.1791890-1-f.fainelli@gmail.comSigned-off-by:
-
Bjorn Andersson authored
Add compatible for the SDHCI block found in SC8280XP. Signed-off-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Stanislav Jakubek authored
Convert Broadcom Kona family SDHCI controller bindings to DT schema. Changes during conversion: - also mark reg and interrupts as required - drop deprecated compatible (it's been deprecated for ~10 years) Signed-off-by:
Stanislav Jakubek <stano.jakubek@gmail.com> Acked-by:
-
Uwe Kleine-König authored
dw_mci_pltfm_remove() returned zero unconditionally. Make it return void instead which makes its semantics a bit clearer. Convert the drivers that use this function as .remove() callback to .remove_new() which has the right prototype. This helps getting rid of the platform_driver's remove callback that returns an int (which is error prone). The other users didn't check the return value anyhow. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230505221506.1247424-1-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Mantas Pucka authored
IPQ6018 has a sdhci-msm compatible MMC controller. Add the appropriate compatible to the documentation. Signed-off-by:
Mantas Pucka <mantas@8devices.com> Acked-by:
-
- 11 Jun, 2023 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Borislav Petkov: - Set up the kernel CS earlier in the boot process in case EFI boots the kernel after bypassing the decompressor and the CS descriptor used ends up being the EFI one which is not mapped in the identity page table, leading to early SEV/SNP guest communication exceptions resulting in the guest crashing * tag 'x86_urgent_for_v6.4_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/head/64: Switch to KERNEL_CS as soon as new GDT is installed
-
git://git.samba.org/ksmbdLinus Torvalds authored
Pull smb server fixes from Steve French: "Five smb3 server fixes, all also for stable: - Fix four slab out of bounds warnings: improve checks for protocol id, and for small packet length, and for create context parsing, and for negotiate context parsing - Fix for incorrect dereferencing POSIX ACLs" * tag '6.4-rc5-smb3-server-fixes' of git://git.samba.org/ksmbd: ksmbd: validate smb request protocol id ksmbd: check the validation of pdu_size in ksmbd_conn_handler_loop ksmbd: fix posix_acls and acls dereferencing possible ERR_PTR() ksmbd: fix out-of-bound read in parse_lease_state() ksmbd: fix out-of-bound read in deassemble_neg_contexts()
-
- 10 Jun, 2023 1 commit
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Biggest news is that Andi Shyti steps in for maintaining the controller drivers. Thank you very much! Other than that, one new driver maintainer and the rest is usual driver bugfixes. at24 has a Kconfig dependecy fix" * tag 'i2c-for-6.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: Add entries for Renesas RZ/V2M I2C driver eeprom: at24: also select REGMAP i2c: sprd: Delete i2c adapter in .remove's error path i2c: mv64xxx: Fix reading invalid status value in atomic mode i2c: designware: fix idx_write_cnt in read loop i2c: mchp-pci1xxxx: Avoid cast to incompatible function type i2c: img-scb: Fix spelling mistake "innacurate" -> "inaccurate" MAINTAINERS: Add myself as I2C host drivers maintainer
-
