Re: [PATCH] platform/x86: int3472: add HP Spectre handshake delay

Hans de Goede <[email protected]>
Newsgroups org.kernel.vger.platform-driver-x86,org.kernel.vger.linux-kernel,org.kernel.vger.linux-media
Message-ID <[email protected]>
Hi Alexander,

On 18-Aug-26 12:43, Hans de Goede wrote:
> Hi,
> 
> On 16-Aug-26 22:42, James Alexander wrote:
>> The OVTI08F4 sensor on an HP Spectre x360 14-eu0xxx failed to read its
>> chip ID with error -121 when the existing 45 ms handshake delay was used.
>> Increasing the delay to 150 ms allowed the sensor to probe.
>>
>> Keep the existing delay for other OVTI08F4 systems. Add a reusable
>> handshake-delay field to the discrete-device quirks and set it only for the
>> affected HP Spectre family through DMI matching.
>>
>> Compile-tested against Linux base fd923b32d761. Hardware-tested with the
>> full patch set across 25 consecutive reboots on the affected laptop running
>> Ubuntu 7.0.0-29-generic; the sensor probed successfully on every boot.
>>
>> Signed-off-by: James Alexander <[email protected]>
> 
> Thank you for your patch.
> 
> There have been more reports about the 45 ms not being enough of a delay,
> but IIRC I never got around to bumping the delay because even with
> a bigger delay on the laptop in question the probe would still fail
> approx. every 1 out of 10 boots and we got stuck on debugging that.
> 
> And then I dropped the bal on this, sorry.
> 
> See:
> https://bugzilla.redhat.com/show_bug.cgi?id=2333331

Funny after re-reading that bug I see you are one of the reporters
of it, again sorry for dropping the ball on this.

> https://bugzilla.redhat.com/show_bug.cgi?id=2333647

And this is more or less the same thing, but here the sensor is
a hi556. So it looks like the fix is to simply boost the handshake
pin default delay to 200 ms instead of having a model / device
specific quirk, dropping the existing OVTI08F4 quirk.

I'll go and prepare a patch for this and submit it upstream myself.

Regards,

Hans
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.