Re: [PATCH] usb: typec: fusb302: Drop unacknowledged Get_Source_Cap_Extended

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

On Tue, Nov 10, 2026 at 10:48:46AM +0400, Alexey Charkov wrote:
> On Fri, Nov 6, 2026 at 4:39 PM Heikki Krogerus
> <heikki.krogerus@linux.intel.com> wrote:
> >
> > On Mon, Nov 02, 2026 at 05:09:05PM +0400, Alexey Charkov wrote:
> > > The chip mistakes Get_Source_Cap_Extended for a GoodCRC, as it apparently
> > > decodes only the low four bits of the message type. As a result, it sends
> > > no GoodCRC for it, but still queues it in the RX FIFO. The partner never
> > > sees the message as delivered due to no GoodCRC, so it retries and then
> > > sends a Soft_Reset. When FUSB302 receives the Soft_Reset, it finally
> > > raises its interrupt, at which point TCPM sees Get_Source_Cap_Extended in
> > > the RX FIFO instead of the Soft_Reset it just received, and answers it
> > > Not_Supported, which is not a valid reply to Soft_Reset, so the partner
> > > escalates to a hard reset instead of getting a chance to gracefully handle
> > > a lost Get_Source_Cap_Extended.
> > >
> > > Discard Get_Source_Cap_Extended, which FUSB302 can never properly receive
> > > due to its inability to automatically GoodCRC it, and answering it from
> > > the host within the protocol specified 250us window without so much as an
> > > interrupt cannot be made to work.
> > >
> > > This way the TCPM view of the PD exchange at least matches what the
> > > partner saw on the wire. This lets the TCPM complete a PD negotiation over
> > > the FUSB302 with e.g. an Apple Studio Display, which otherwise always ends
> > > in hard resets.
> > >
> > > Signed-off-by: Alexey Charkov <alchark@flipper.net>
> >
> > Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> 
> Thanks for acking it Heikki, but let's please hold off applying this
> patch. My colleagues have done broader testing with Apple hardware.
> While this patch prevents hard reset loops and lets TCPM negotiate a
> PD contract, it can't yet complete Alt Modes negotiation in PD 3.0.
> 
> I've done another attempt locally to send GoodCRC from the driver
> instead of discarding Get_Source_Cap_Extended altogether. It lands
> wildly out of spec timing wise (close to 2ms vs. the spec-prescribed
> 250us to start transmitting GoodCRC on the wire). However, it works by
> sheer luck because the partner waits up to 1ms for a GoodCRC and
> retries the message with the same ID up to 3 times, so the first
> GoodCRC lands in the window of the second or third retry and gets
> accepted. Everyone is happy, and the negotiation completes just fine.
> 
> It's a bit more invasive for the driver, though (as can be expected),
> and relies heavily on the bus speed being at least 400 kHz (FUSB302
> can do up to 1 MHz) and not a single extra I2C transaction being added
> in the timing-critical path before the GoodCRC goes out. I'll send it
> for review separately, and if it proves palatable, it will supersede
> this patch.

Okay, thanks for the explanation.

-- 
heikki