Problems encountered by i2c-mux-pca954x drivers
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- c
- Domain
- embedded-iot, operating-systems
Research direction
Start with drivers/i2c/muxes/i2c-mux-pca954x.c and trace the idle-state handling and channel-close path. Check how the driver detects a failed close and how PCA9548 reset is represented there. Done means channels default to disconnected and a failed close resets the PCA9548 so a faulty optical module is isolated.
Written by the indexing model from the issue text.
Description
Code Path：drivers/i2c/muxes/i2c-mux-pca954x.c
Issue 1：After accessing the peripherals under PCA9548, the PCA9548 channel is not closed. One I2C controller of our product is connected to multiple PCA9548s, and each PCA9548 channel is connected to an optical module (address is 0x50). After accessing the device under PCA9548, the channel is not closed, and I2C address conflicts will occur, resulting in access exceptions.
Issue 2：After connecting the faulty optical module with SCL and GND short-circuited, and then opening the PCA9548 channel where the optical module is located. SCL is pulled to a low voltage level, causing the entire I2C controller to not work properly, and all I2C peripherals under the entire controller to be inaccessible and cannot be recovered (the fault scope has expanded)
Regarding this issue, our solution is:
Issue1：By default, idle_state is MUX_IDLE_AS_IS (that is, after accessing the devices under PCA9548, maintaining the original state without closing the channels). The default idle_state can only be changed by using the device tree, and X86 products do not support device trees. At present, we decided to directly modify the driver code and change the default idle_state status to MUX_IDLE_DISCONNECT
Issue2：Add the PCA9548 reset logic to the PCA9548 closed channel logic. If the PCA9548 channel fails to be closed, perform a PCA9548 reset (after the PCA9548 reset, all channels are closed) to isolate the faulty device.
- Dominant language
- Shell
- Stars
- 72
- Forks
- 237
- Avg merge
- 7d 19h
- Merged PRs (30d)
- 8
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sonic-net/sonic-linux-kernel
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
sonic-net/sonic-linux-kernel#531 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
sonic-net/sonic-linux-kernel#367 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sonic-net/sonic-linux-kernel#347 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
sonic-net/sonic-linux-kernel#346 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
sonic-net/sonic-linux-kernel#345 · 1 comment · 1 reaction ·
All issues in sonic-net/sonic-linux-kernel
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
danielmiessler/LifeOS#2218 ·
-
docs(agents): strengthen the no-backslash-escaped-backticks rule with an issue-creation example Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
technical-debt
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
ll7/robot_sf_ll7#9560 ·
-
package-update
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
oSoWoSo/vOid_Community_repOsitory#148 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100