Hi Andrew, Apologies for the late reply. On Thu, Jan 18, 2018 at 7:53 AM Andrew Worsley <amworsley@xxxxxxxxx> wrote: > > On 8 December 2017 at 09:15, Andrew Worsley <amworsley@xxxxxxxxx> wrote: > > Thanks. I regularly see the warning my patch prints out on boot up as then > > there is a big pull of random data from the TPM. > > Just an update on this bug - I did a i2c capture with pulseview on > a boot that included this issue. > > > On 8 Dec 2017 12:30 am, "Harini Katakam" <harinikatakamlinux@xxxxxxxxx> > > wrote: > >> > >> Hi Wolfram and Andrew, > >> > >> On Thu, Dec 7, 2017 at 4:19 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: > >> > > >> >> > I attach a patch of the changes to the i2c driver showing my debug in > >> >> > this driver. > >> >> > As I said I am happy to send more verbose bug output - I have about > >> >> > 36 > >> >> > odd runs with 9 occurences of the bug. > >> >> > Once it happen twice in the one run > >> >> > > >> >> > I include the crashing line from the runs where the bug occured (I > >> >> > added more diagnostics as the runs progressed): > >> >> > >> >> I'll check with out HW team as well and check your flow to > >> >> see if we can reproduce it; will also check if the existing errata > >> >> has larger scope. > >> >> I'll let you know if we require further assistance with debug > >> >> next week. > >> > > >> > Any news here? > >> > >> Sorry for the delay. > >> I've checked the known errata and confirmed that it wont > >> affect this use case. And we haven't been able to hit this > >> issue on our HW (with eeprom slave devices). > >> I will add my colleague looking into this further to debug. > >> > >> Regards, > >> Harini > > I suspect a well behaved i2c slave may never show the issue. But the > i2c cadence doesn't handle bad slaves safely > so I suggest that length check is needed to avoid buffer kernel > crashes due to mis-behaving i2c hardware. > > I got a board that this issue was *very* bad to the point that the > TPM_RANDOM requests repeatedly returned the same data and so were > failing the sanity tests. So I captured the i2c transactions using > pulseview and very bad behaviour from the TPM. The problem disappears > at 100KHz and very reliably occurs at 400k on this individual board so > I believe this TPM is failing to keep up with the i2c clock and > screwying everything up. > > What I am concerned about is that the i2c-cadence driver is almost > always carrying on and returning data with out errors. > I agree we should attempt to fix this could you resend the patch removing the debug. thanks and Regards, Shubhrajyoti
