[Public] > -----Original Message----- > From: Jani Nikula <jani.nik...@intel.com> > Sent: Thursday, May 8, 2025 4:19 PM > To: Lin, Wayne <wayne....@amd.com>; dri-devel@lists.freedesktop.org > Cc: ville.syrj...@linux.intel.com; Limonciello, Mario > <mario.limoncie...@amd.com>; > Wentland, Harry <harry.wentl...@amd.com>; Lin, Wayne > <wayne....@amd.com>; sta...@vger.kernel.org > Subject: Re: [PATCH] drm/dp: Fix Write_Status_Update_Request AUX request > format > > On Sun, 27 Apr 2025, Wayne Lin <wayne....@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
