> I also saw the high temperature issue on 5.6 when charging sometimes - I guess
> you know already from your previous bq work but "60°" just means too hot to
> charge as there is no exact readout. This also resulted in a "HOT" print from
> the driver.

Yes, there are only three levels: too cold, of, too hot. And these are mapped
to -10°C, 22.5°C and 60°C.

But the battery wasn't charging (battery is full) and after a reboot it did read
out correctly. So it was a driver glitch. And I never had that with the old driver.

I remember that these bits reporting NTC temperature are not easy to be handled
correctly by the driver so the rework may have changed something subtle.


I have seen this on the old driver on 5.6.y.  I will see if I can reproduce again on the old driver and get a register dump and some other information.  Re-examining the logic in the restructure patches, the reporting in the NTC fields looks ok.  So there may be something in the configuration of the chip causing these NTC bits to be set.  Have you dumped the registers when you reproduce this issue to see if the actual values are as expected?
 
>> I have started a little to test your patches on top of v5.8-rc7 (including
>> also David's patches so that the Panel is working again).
>> There was a missing comma - easy to fix for compilation.

Yes I noticed that, sorry.  Something broke in my submission.
 
>> Basically the driver seems to work, but OTG doesn't. It does not even try to
>> switch power on, although DWC3 detects it.
>>
>> Unplugging the OTG cable once did lead to:
>>
>> root@letux:~# [  397.149733] ------------[ cut here ]------------
>> [  397.154707] WARNING: CPU: 0 PID: 37 at drivers/regulator/core.c:2603
>> _regulator_disable+0x3c/0x168
>> [  397.170413] unbalanced disables for otg_path

This is interesting.  I don't have a device handy to test OTG, so this is probably why I didn't catch this.  I'll try and get a device to test OTG mode with.
 
>> And once the temperature report was 60°C.
>>
>> So I think there is something wrong with interrupts / status change detection.
>> Just a note: I have tested on an older Pyra prototype with tca6424 and there,
>> IRQs are definitively broken. So we must poll the status bits.

Also interesting, I'll need to investigate what broke with the interrupts.  My original driver rewrite behaved quite well on 4.19.