> -----Original Message----- > From: Hillf Danton <hdanton@xxxxxxxx> > Sent: Wednesday, February 15, 2023 7:54 AM > > On Tue, 14 Feb 2023 12:40:12 +0000 Wentong Wu <wentong.wu@xxxxxxxxx> > > > -----Original Message----- > > > From: Hillf Danton <hdanton@xxxxxxxx> > > > Sent: Tuesday, February 14, 2023 4:36 PM > > >=20 > > > On Tue, 14 Feb 2023 06:25:35 +0000 Wentong Wu <wentong.wu@xxxxxxxxx> > > > > > > > > This allows new command(e.g. 'get status' command to check current > > > > firmware=3D > > > > status) to be downloaded to firmware for debugging purpose in > > > > case no resp=3D onse for current command though I have never saw this > happen. > > > > =3D20 > > >=20 > > > Thanks for your specification. > > >=20 > > > Another question, is it likely for the wakeup to come after reinit > > >becaus= > > e of for > > > instance timeout on the waiter side? > > > > Thanks, first I want to clarify why we have timeout here, in case > > firmware = stuck somehow or IVSC device is removed suddenly, calling > > thread can't be w= akeup if wait forever here. > > Fair enough on the waiter side. > > > > And firmware gets high priority to handle command and response, also > > there = is timeout mechanism inside firmware, I think there will be > > some problem wi= th firmware if driver gets command response after 5s > > which will be captured= by driver code(if (csi->cmd_response.cmd_id > > !=3D cmd->cmd_id)) but I have = never saw this happen. > > The problem with firmware could be emulated by directly skipping the wait for > completion and returning ETIMEDOUT, in order to see what will happen if > wakeup comes later than timeout. Thanks, but what do you mean "emulated"?
