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

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

[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@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@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@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@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@11003000/rt5190a@64: Fixed dependency cycle(s) 
with /soc/i2c@11003000/rt5190a@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@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@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

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

[Frank Wunderlich (linux)]

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@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@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@51,eeprom@57) are shown on the 
main bus too.

root@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@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@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@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@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@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@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@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@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@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@11003000/rt5190a@64: Fixed dependency cycle(s) 
> with /soc/i2c@11003000/rt5190a@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@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@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

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

[Wolfram Sang]

> 
> 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".

Can you try enabling CONFIG_RESET_GPIO please? It is probably that this
driver is missing. The core relies on that driver for the fallback the
above patch makes use of. Sadly, I couldn't convince the reset
maintainers of a way to automatically select the driver for existing
users :(

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

[Frank Wunderlich (linux)]

Am 2025-11-02 13:45, schrieb Wolfram Sang:
> Can you try enabling CONFIG_RESET_GPIO please? It is probably that this
> driver is missing. The core relies on that driver for the fallback the
> above patch makes use of. Sadly, I couldn't convince the reset
> maintainers of a way to automatically select the driver for existing
> users :(

Thanks for pointing to this and indeed i had not enabled this. This is 
my fault and not
from reset maintainers as i have my own defconfig. Tested and my mux 
works now again.

Maybe this option should be enabled by default or when the i2c-mux is 
selected?

When moving from specific to a generic aproach (which makes sense) imho 
it should be
mentioned in commit description which option needed instead :)

btw. the Authors Email seems not working, got

<wojciech.siudy@nokia.com>: host
     nokia-com.mail.protection.outlook.com[52.101.73.24] said: 550 5.4.1
     Recipient address rejected: Access denied.

or maybe its inbox has a whitelist from which domains he can receive 
mails and my
domain is not added to it.

regards Frank

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

[Wolfram Sang]

> from reset maintainers as i have my own defconfig. Tested and my mux works
> now again.

Glad it works again!

> Maybe this option should be enabled by default or when the i2c-mux is
> selected?

That's what we were discussing. At least a warning will now get printed
to the logs when booting suggesting the above solution.

> When moving from specific to a generic aproach (which makes sense) imho it
> should be
> mentioned in commit description which option needed instead :)

We didn't realize this back then. Only when the first bug report came
in :/

> btw. the Authors Email seems not working, got

Yes, he quit Nokia meanwhile.

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

[AngeloGioacchino Del Regno]

Il 30/10/25 11:38, Frank Wunderlich (linux) ha scritto:
> 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@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@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@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?
> 

Did you check if there's any clock, or power rail, or power domain, that you are
missing in some node perhaps?

Could be that something is getting powered off temporarily and gifting you with
this "amazing" issue...

> root@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@11003000/rt5190a@64: Fixed dependency cycle(s) with /soc/ 
> i2c@11003000/rt5190a@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)
> 

That is something for which I can give you a clear answer....

> root@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@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

...Not strange at all...

> 
> 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 ).

...because on MediaTek, the I2C controllers are "kinda standalone" - meaning that
they work as long as they're powered up, with their main clock being either some
internal XO or the clk26m or a clock derived from that (it's bogus, as that is an
IP implementation detail that nobody has, if not MediaTek's HW engineering dept,
and it's not relevant anyway so we don't even need to really know if not for pure
curiosity).

The basic "unclocked" functionality of the I2C controller(s) in MediaTek SoCs is
XFER detection (not sure if they can do buffering as well while the AP-driven
clocks are off).

As a small side note: I think MediaTek are not the only ones doing that, but this
is an entirely different story and it's just for your own curiosity, in case.

The I2C clocks therefore are only enabling the CPU to perform read/write(/modify)
operations on the I2C Controller registers, which also include DMA transfers.

Speaking of DMA, is there really no support for apdma_sync in MT7988a? ;-)

> maybe some speed-calculation-issue?
> 

Could also be, but if it was that, and directly related to I2C, you'd get errors
during communication even when your PCA954X device actually gets probed, because
whatever calculation is ran, it's always going to be the same across reboots.

All that I'm saying here, though, ignores hardware issues. So, if you're using a
board that is not final, or a final board that has HW issues (not only as in your
own unit, but as a design mistake of some sort) it's a different story.

I am bringing up the HW question just because "better safe than sorry", but if
using something not final.. I'm mostly sure that you would've said that already
and tried with.. well, final hardware, before seeking for help here anyway :-)

Cheers!
Angelo

> 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

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

[Wolfram Sang]

> > Maybe this option should be enabled by default or when the i2c-mux is
> > selected?
> 
> That's what we were discussing. At least a warning will now get printed
> to the logs when booting suggesting the above solution.

FYI, all the commits leading to this breakage are reverted now. Sorry
for your troubles!

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

[AngeloGioacchino Del Regno]

Il 05/11/25 12:51, Wolfram Sang ha scritto:
> 
>>> Maybe this option should be enabled by default or when the i2c-mux is
>>> selected?
>>
>> That's what we were discussing. At least a warning will now get printed
>> to the logs when booting suggesting the above solution.
> 
> FYI, all the commits leading to this breakage are reverted now. Sorry
> for your troubles!
> 


Wow I replied to a very old email in the topic; Good (but not great) to know that
the issue was not in MediaTek specific drivers and nice to see that it's all been
resolved.

Cheers,
Angelo

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

[Frank Wunderlich]

Am 5. November 2025 12:51:23 MEZ schrieb Wolfram Sang <wsa+renesas@sang-engineering.com>:
>
>> > Maybe this option should be enabled by default or when the i2c-mux is
>> > selected?
>> 
>> That's what we were discussing. At least a warning will now get printed
>> to the logs when booting suggesting the above solution.
>
>FYI, all the commits leading to this breakage are reverted now. Sorry
>for your troubles!

Why? My issue was solved by adding GPIO_RESET... So it was fault on my side,sorry for bothering.

@angelo
yes it is a final board BPI-R4 v1.1.

Why sometimes it works i guess it is because uboot may previously initialize the device (and without reset working it may be stuck in wrong state).
I'm not sure if my current flashed version had the i2c and i2cmux support,but i got it working on that board because of the connected eeprom (read mac address via tlv_eeprom as macs do not have fixed macs via efuse afaik).

Thanks for help so far.

regards Frank

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

[AngeloGioacchino Del Regno]

Il 05/11/25 13:08, Frank Wunderlich ha scritto:
> Am 5. November 2025 12:51:23 MEZ schrieb Wolfram Sang <wsa+renesas@sang-engineering.com>:
>>
>>>> Maybe this option should be enabled by default or when the i2c-mux is
>>>> selected?
>>>
>>> That's what we were discussing. At least a warning will now get printed
>>> to the logs when booting suggesting the above solution.
>>
>> FYI, all the commits leading to this breakage are reverted now. Sorry
>> for your troubles!
> 
> Why? My issue was solved by adding GPIO_RESET... So it was fault on my side,sorry for bothering.
> 
> @angelo
> yes it is a final board BPI-R4 v1.1.
> 
> Why sometimes it works i guess it is because uboot may previously initialize the device (and without reset working it may be stuck in wrong state).

Heh, this is something that happens frequently.

> I'm not sure if my current flashed version had the i2c and i2cmux support,but i got it working on that board because of the connected eeprom (read mac address via tlv_eeprom as macs do not have fixed macs via efuse afaik).
> 
> Thanks for help so far.
> 

No worries, my pleasure (but I didn't do all that much anyway :P :P :P)

Cheers,
Angelo

> regards Frank