drivers: espi: ite: Receive vwire level without checking the valid bit

[yimjiajun]

If the valid bit is set to '0', the corresponding virtual wire will retain its previous value and will not be updated by the current virtual wire packet.

The virtual wire value will be reset to its default by an eSPI reset. Therefore, this commit skips the check for the valid bit when receiving the level.

When a similar index with a single event valid is sent in a separate packet, the previous valid bit will be cleared. However, since it was previously valid, at the moment it will appear as non-valid and return '0' as a non-valid value.

Thus, we return the level directly without checking the valid bit, as the virtual wire will reset to its default value upon an eSPI reset.

[MaureenHelm]

@Dino-Li @GTLin08 @fabiobaltieri please take a look

[Dino-Li]

If the valid bit is set to '0', the corresponding virtual wire will retain its previous value and will not be updated by the current virtual wire packet.

The virtual wire value will be reset to its default by an eSPI reset. Therefore, this commit skips the check for the valid bit when receiving the level.

When a similar index with a single event valid is sent in a separate packet, the previous valid bit will be cleared. However, since it was previously valid, at the moment it will appear as non-valid and return '0' as a non-valid value.

Thus, we return the level directly without checking the valid bit, as the virtual wire will reset to its default value upon an eSPI reset.

Is this symptom only seen on a specific platform? I'm curious why we need to think the level of VW signal is valid when its valid bit is set to invalid?

[albertofloyd]

@yimjiajun This is probably not the best approach to solve the issue you are facing.
Ignoring the valid bit status (valid_mask) feels wrong (per eSPI spec), valid bit should be always checked, otherwise how can we distinguish between the bit that is updated and the ones that are unchanged.

Perhaps the problem is that the rest of bits in same index should be untouched.

@Dino-Li does the HW keeps track of valid bit once is set and reset only during eSPI reset.
If not maybe need to account this for the driver

[yimjiajun]

For the diagram shown, the value needs to retain the previous state when the valid bit is not set to 1.

For example, if the same index 2 is used, and three separate virtual packets (SLP_Sx) are sent:

•	Initially, the value is 0x70 with bits 2-0 set to zero.
•	The first packet received is 0x11.
•	Then, the second packet received is 0x23 (with bit 1 set).
•	Finally, the third packet is 0x47 (with bit 2 set).

All three virtual packets conform to the specification, with the valid bit set individually for each packet while preserving the previous state.

However, during the last instance, only one valid bit is set. If the function API is used to read this, it may return a zero for the other valid bits that were not raised, even though those bits were previously determined to be valid based on prior packets.

[Dino-Li]

@yimjiajun there is PR merged: #81096

[Dino-Li]

@yimjiajun can we close this PR?

[yimjiajun]

@yimjiajun can we close this PR?

sure, no problem.

[Dino-Li]

Fixed by this PR:
#81096