On Wed, 2022-11-30 at 18:43 +0100, Greg Kroah-Hartman wrote: > On Wed, Nov 30, 2022 at 09:20:28AM -0500, Rodrigo Vivi wrote: > > On Wed, Nov 16, 2022 at 02:47:33PM +0200, Alexander Usyskin wrote: > > > When driver wakes up the firmware from the low power state, > > > it is sending a memory ready message. > > > The send is done via synchronous/blocking function to ensure > > > that firmware is in ready state. However, in case of firmware > > > undergoing reset send might be block forever. > > > To address this issue a timeout is added to blocking > > > write command on the internal bus. > > > > > > Introduce the __mei_cl_send_timeout function to use instead of > > > __mei_cl_send in cases where timeout is required. > > > The mei_cl_write has only two callers and there is no need to > > > split > > > it into two functions. > > > > > > V2: address review comments: > > > - split __mei_cl_send and __mei_cl_send_timeout > > > - add units to timeout KDoc > > > - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro > > > > > > V3: - split the state fix into separate patch > > > - document define unit > > > - expand timeout KDoc > > > > These 2 patches looks good to me now. > > > > Greg, whenever you review it, please let me know if it is > > okay to me to push these through the drm-fixes, or if you > > prefer these to the mei branches. > > These have been in my tree for over a week now, sorry. No one told > me > not to take them... > > {sigh}
no worries at all. The important thing is that the users will get the fix. We can keep them in our topic/core-for-CI while our branches are out- of-sync. Thanks a lot, Rodrigo. > > greg k-h