On Wed, Dec 04, 2024 at 09:45:11PM +0800, Pin-yen Lin wrote: > On Wed, Dec 4, 2024 at 10:04 AM Brian Norris <briannorris@xxxxxxxxxxxx> wrote: > > > > > > Can you try testing (and gather timing numbers) when > > > > suspending soon after initiating scans? It's hard to judge what the > > > > lower limit of this timeout should really be without any numbers, just > > > > like it's hard to judge whether your 10 second watchdog is reasonable. > > > > > > Pin-yen: is this something you could gather? > > I tried entering suspend right after wifi scans, and the time spent in > mwifiex_enable_hs() is always around 100ms. It seems initiating > suspend does not increase the execution time for mwifiex_enable_hs(), > so I think the driver is capable of interrupting a scan. Thanks! At some level, there are things we can only verify by experimentation, since we don't have firmware source code. This seems fine to me then. > > > > Also, for the record, since we might have to field regression reports > > > > for other systems: what hardware (chip variant, FW version) are you > > > > seeing problems on? > > > > > > Pin-yen: I'm assuming you'll provide this. > > From the debugfs entry: > > driver_name = "mwifiex" > driver_version = mwifiex 1.0 (15.68.19.p54) > verext = w8897o-B0, RF87XX, FP68, 15.68.19.p54 > > The compatible string of the DT is "marvell,sd8897". Thanks. I think it'd be good to see this info in the commit message, but otherwise you can carry my: Acked-by: Brian Norris <briannorris@xxxxxxxxxxxx> It'd be extra nice to see that you successfully use this patch in your own releases, but I don't think that's a requirement for upstream. And anyway, the upstream RC cycle is pretty long. Brian
