lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 10 Jan 2019 22:59:44 +0000
From:   Sowjanya Komatineni <>
To:     Thierry Reding <>
CC:     Jonathan Hunter <>,
        Mantravadi Karthik <>,
        Shardar Mohammed <>,
        Timo Alho <>,
        "" <>,
        "" <>,
        "" <>
Subject: RE: [PATCH V1] i2c: tegra: Add Bus Clear Master Support

>> @@ -636,6 +649,9 @@ static irqreturn_t tegra_i2c_isr(int irq, void *dev_id)
>>  		goto err;
>>  	}
>> +	if (i2c_dev->hw->has_bus_clr_support && (status & I2C_INT_BUS_CLR_DONE))
>> +		goto err;
>> +
>This looks odd. If we support bus clear and the BUS_CLR_DONE interrupt is set, shouldn't we still process all other potential interrupts? Or was this meant to be inversed:
>	if (!i2c_dev->hw->supports_bus_clear && (status & I2C_INT_BUS_CLR_DONE)

Bus clear mechanism is to recover master from I2C Bus hang when I2C master loses bus arbitration due to some slave devices pulling SDA LOW continuously for some unknown reason.
Master performs bus clear operation and once bus clear is done successfully, I2C_INT_BUS_CLR_DONE is set in interrupt status. 
During this time, no other interrupts will be received as it is already in the process of recovering from bus hang thru this bus clear operation. 
So transaction during the bus hang obviously is failure transaction. But master tries to recover from bus hang so transaction can be re-tried and communication with other slaves on that bus and further happen.


Powered by blists - more mailing lists