i2c issues in 6.18 on R4, but not r4pro (both mt7988 with i2c-mux on i2c2)

Frank Wunderlich (linux) linux at fw-web.de
Sun Nov 2 03:39:19 PST 2025


Hi,

it seems that is caused by these 2 commits:

94c296776403 2025-06-03 i2c: muxes: pca954x: Reset if (de)select fails 
Wojciech Siudy 
690de2902dca 2025-06-03 i2c: muxes: pca954x: Use reset controller only 
Wojciech Siudy 

I'm sure that i had tested with them already reverted, but maybe 
powercycle was not complete.
Git bisect pointed also to "i2c: muxes: pca954x: Use reset controller 
only".

Added Author in To. Maybe he can tell where the gpio-reset should happen 
in i2c core (have not found any recent commit which takes the 
reset-gpios) like stated in the commit

commit 690de2902dca98aec96de004428c020ca902f047
Author: Wojciech Siudy <wojciech.siudy at nokia.com>
Date:   Tue Jun 3 14:47:20 2025 +0200

     i2c: muxes: pca954x: Use reset controller only

     Fallback to legacy reset-gpios is no more needed, because the 
framework
     can use reset-gpios properity now as well.

my dts-config:

	pca9545: i2c-mux at 70 {
		compatible = "nxp,pca9545";
		reg = <0x70>;
		reset-gpios = <&pio 5 GPIO_ACTIVE_LOW>;

i'm unsure what devices are shown in the i2cdetect output, as there 
should not be any on same bus, only behind the mux (rtc, eeprom and 
sfp).

[    1.637174] pca954x 2-0070: supply vdd not found, using dummy 
regulator
[    1.675701] i2c i2c-2: Added multiplexed i2c bus 3
[    1.680597] i2c i2c-2: Added multiplexed i2c bus 4
[    1.685472] i2c i2c-2: Added multiplexed i2c bus 5
[    1.690344] i2c i2c-2: Added multiplexed i2c bus 6
[    1.695137] pca954x 2-0070: registered 4 multiplexed busses for I2C 
switch pca9545

looks like devices from channel 0 (rtc at 51,eeprom at 57) are shown on the 
main bus too.

root at bpi-r4-v11:~
# i2cdetect -y 2
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root at bpi-r4-v11:~
# i2cdetect -y 3
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root at bpi-r4-v11:~
# i2cdetect -y 4
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root at bpi-r4-v11:~
# i2cdetect -y 5
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root at bpi-r4-v11:~
# i2cdetect -y 6
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: UU -- -- -- -- -- -- --
root at bpi-r4-v11:~

regards Frank

Am 2025-10-30 11:38, schrieb Frank Wunderlich (linux):
> Hi
> 
> sorry for html-mail, my main email-provider (GMX) sent it as html (have 
> enabled text-mail as default in settings) when using web-mailer.
> 
> i've noticed i2c-issues (i2c2) on mt7988 BPI-R4 with 6.18. On most 
> bootups the i2c-mux is not detected.
>  
> root at bpi-r4-v11:~
> # i2cdetect -y  2
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:                         -- -- -- -- -- -- -- -- 
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 70: -- -- -- -- -- -- -- --
>  
> i2c-probe is completed successful (no errors and debugs shown before 
> final "return 0;")
>  
> sometimes the mux came up with same kernel-binary, and i see also other 
> devices on same i2c bus, but mostly all devices are not shown when i 
> use i2cdetect on the bus.
>  
> root at bpi-r4-v11:~
> # i2cdetect -y  2
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:                         -- -- -- -- -- -- -- -- 
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 50: -- UU -- -- -- -- -- UU -- -- -- -- -- -- -- -- 
> 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
> 70: UU -- -- -- -- -- -- --                         
> root at bpi-r4-v11:~
> # [   58.594846] sfp sfp1: failed to read EEPROM: -ENXIO
>  
> 6.17 seems ok (have not seen the issue there yet).
>  
> i looked through many commits, reverted some for clock (my own, lauras 
> clk_gate,...), pinctrl and the i2c-mux (some reset-related) itself but 
> nothing helped.
>  
> One strange thing is that i have noticed no issues on bpi-r4pro which 
> uses same SoC, same config and should use same drivers and 
> configuration via dt.
> Only diference was the reset for the mux itself in dts as far as i 
> see....so tried to disable it to have it nearly same as on r4pro 
> without any effect.
>  
> Maybe you have any idea how i can nail it down?
>  
> root at bpi-r4-v11:~
> # dmesg | grep -i 'sfp\|i2c'
> [    0.000000] Machine model: Banana Pi BPI-R4 (2x SFP+)
> [    1.600387] i2c_dev: i2c /dev entries driver
> [    1.605291] /soc/i2c at 11003000/rt5190a at 64: Fixed dependency cycle(s) 
> with /soc/i2c at 11003000/rt5190a at 64/regulators/buck1 #i2c0 seems not 
> affected
> [   12.685157] platform sfp1: deferred probe pending: (reason unknown)
> [   12.691440] platform sfp2: deferred probe pending: (reason unknown)
>  
> # dmesg | grep -i 'err\|fail\|clk'
> ... #nothing related to i2c or clk
> [    1.623805] pca954x 2-0070: probe failed
> ....
>  
> wondered why i2c-clocks are always disabled when i look into the 
> clk_summary (also when i2c was working)
> 
> root at bpi-r4-v11:~
> # cat /sys/kernel/debug/clk/clk_summary | grep -i -B2 INFRA_I2C_BCK
>              infra_usb_sys           0       0        0       
>  125000000   0          0     50000      N               deviceless     
>            
>           i2c_sel                    0       1        0       
>  125000000   0          0     50000      N            deviceless       
>             
>              infra_i2c_bck           0       3        0       
>  125000000   0          0     50000      N               11005000.i2c   
>            
> root at bpi-r4-v11:~
> 
> but looking at the driver the clocks are disabled on probe which looks 
> strange to me
>  
> https://elixir.bootlin.com/linux/v6.18-rc1/source/drivers/i2c/busses/i2c-mt65xx.c#L1477
>  
> i guess it is some kind of timing issue where clocks are still disabled 
> but not reenabled in mtk_i2c_transfer, but
> my debug in this function shows that is called and ret=0 after the 
> bulk_enable (and of course flooding console :p ).
> maybe some speed-calculation-issue?
>  
> what i had tried to revert (also my own non-mainline like "convert 
> invalid GATE to MUX"), so they seem not the rootcause:
>  
> d51e7cfca3fe 2025-09-25 i2c: mt65xx: convert set_speed function to void 
> Wolfram Sang 
> b49218365280 2025-09-06 i2c: mediatek: fix potential incorrect use of 
> I2C_MASTER_WRRD Leilk.Liu 
> 614b1c3cbfb0 2025-06-12 i2c: use inclusive callbacks in struct 
> i2c_algorithm Wolfram Sang
>  
> c90fa5493f7a 2025-07-31 i2c: mux: pca9541: Use I2C adapter timeout 
> value for arbitration timeout Manikanta Guntupalli 
> 94c296776403 2025-06-03 i2c: muxes: pca954x: Reset if (de)select fails 
> Wojciech Siudy 
> 690de2902dca 2025-06-03 i2c: muxes: pca954x: Use reset controller only 
> Wojciech Siudy 
>  
> e504d3bdb3d0 2025-09-15 clk: mediatek: clk-gate: Add ops for gates with 
> HW voter Laura Nao 
> 8ceff24a754a 2025-09-15 clk: mediatek: clk-gate: Refactor 
> mtk_clk_register_gate to use mtk_gate struct Laura Nao
>  
> bd6f4a91401f 2025-09-02 pinctrl: mediatek: moore: replace struct 
> function_desc with struct pinfunction Bartosz Golaszewski 
> 7a24f1f5b214 2025-09-02 pinctrl: mediatek: mt7988: use 
> PINCTRL_PIN_FUNCTION() Bartosz Golaszewski
>  
> regards Frank



More information about the Linux-mediatek mailing list