[PATCH] drm/dp: Fix Write_Status_Update_Request AUX request format

[Lin, Wayne]

[Public]

> -----Original Message-----
> From: Jani Nikula <jani.nikula at intel.com>
> Sent: Thursday, May 8, 2025 4:19 PM
> To: Lin, Wayne <Wayne.Lin at amd.com>; dri-devel at lists.freedesktop.org
> Cc: ville.syrjala at linux.intel.com; Limonciello, Mario <Mario.Limonciello at amd.com>;
> Wentland, Harry <Harry.Wentland at amd.com>; Lin, Wayne
> <Wayne.Lin at amd.com>; stable at vger.kernel.org
> Subject: Re: [PATCH] drm/dp: Fix Write_Status_Update_Request AUX request
> format
>
> On Sun, 27 Apr 2025, Wayne Lin <Wayne.Lin at amd.com> wrote:
> > +                   /*
> > +                    * When I2C write firstly get defer and get ack after
> > +                    * retries by wirte_status_update, we have to return
> > +                    * all data bytes get transferred instead of 0.
> > +                    */
>
> My brain gives me syntax and parse error here. ;)

Appreciate for the feedback, Jani.
Could you elaborate more on your concerns please?

Since Write_Status_Update_Request is address only request. Data length
is 0. When I2C write request completes, reply for
Write_Status_Update_Request from DPRx will be ACK only (i.e. data
length is 0).

Is your concern about returning 0 from aux->transfer?
My thoughts is drm_dp_i2c_do_msg() is designed to handle I2C-Over-Aux
reply data, and aux->transfer() is handling hw specific manipulation and
return transferred bytes. For Write_Status_Update_Request request itself,
nothing new to be transferred. I think drm_dp_i2c_do_msg() should be
responsible for determining the correct transferred data bytes under this
case. Or do you expect aux->transfer to memorize the data length of
write request?

Thanks!
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel
--
Wayne Lin