On 01/10/25 13:54, Oleksij Rempel wrote:
On Wed, Oct 01, 2025 at 01:40:56PM +0530, Bhanu Seshu Kumar Valluri wrote:
quoted
On 01/10/25 13:12, Oleksij Rempel wrote:
quoted
Hi,
On Wed, Oct 01, 2025 at 10:07:21AM +0530, Bhanu Seshu Kumar Valluri wrote:
quoted
On 01/10/25 06:09, Jakub Kicinski wrote:
quoted
On Tue, 30 Sep 2025 14:19:02 +0530 Bhanu Seshu Kumar Valluri wrote:
quoted
+ if (dev->chipid == ID_REV_CHIP_ID_7800_) {
+ int rc = lan78xx_write_reg(dev, HW_CFG, saved);
+ /* If USB fails, there is nothing to do */
+ if (rc < 0)
+ return rc;
+ }
+ return ret;
I don't think you need to add and handle rc here separately?
rc can only be <= so save the answer to ret and "fall thru"?
The fall thru path might have been reached with ret holding EEPROM read timeout
error status. So if ret is used instead of rc it might over write the ret with 0 when
lan78xx_write_reg returns success and timeout error status would be lost.
Ack, I see. It may happen if communication with EEPROM will fail. The same
would happen on write path too. Is it happened with real HW or it is
some USB emulation test? For me it is interesting why EEPROM is timed
out.
The sysbot's log with message "EEPROM read operation timeout" confirms that EEPROM read
timeout occurring. I tested the same condition on EVB-LAN7800LC by simulating
timeout during probe.
Do you simulating timeout during probe by modifying the code, or it is
real HW issue?
On my real hardware timeout didn't occur. So I simulated it once by modifying the code
to confirm the BUG. The BUG has occurred confirming syzbot finding.
Thanks.