On 2021-07-19 4:24 a.m., Lazar, Lijo
wrote:
On 7/14/2021 11:28 PM, Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before
On 7/14/2021 11:28 PM, Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
On 2021-07-16 4:29 p.m., Alex Deucher
wrote:
On Wed, Jul 14, 2021 at 1:58 PM Luben Tuikov wrote:
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
On Wed, Jul 14, 2021 at 1:58 PM Luben Tuikov wrote:
>
> This fixes a bug which if we probe a non-existing
> I2C device, and the SMU returns 0xFF, from then on
> we can never communicate with the SMU, because the
> code before this patch reads and interprets 0xFF
> as a terminal error, and thus we
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
into register 90 to clear the status (and
