On Mon, Nov 30, 2020 at 12:10:07PM +0000, Lorenzo Pieralisi wrote: > On Mon, Nov 09, 2020 at 10:49:35PM +0530, Vidya Sagar wrote: > > Currently the driver checks for error value of different APIs during the > > uninitialization sequence. It just returns from there if there is any error > > observed for one of those calls. Comparatively it is better to continue the > > uninitialization sequence irrespective of whether some of them are > > returning error. That way, it is more closer to complete uninitialization. > > Hi Vidya, Thierry, > > I can apply this series (dropping patches as suggested by Thierry), > before though I wanted to ask you if this patch is really an > improvement, it is hard to understand why skipping some error > codes is OK for device correct operations to continue, maybe it > is worth describing why some of those failures aren't really > fatal. > > Please let me know, thanks. As explained in the commit message, the idea is to continue tearing down even if things fail somewhere in the middle, because that ensures that the hardware gets as close to an "uninitialized" state as possible. If for example the first reset assert were to fail, then none of the PHYs get disabled, the regulator stays on and the clocks stays on, all of which can continue draining power after the controller has already been torn down. So yes, I think this is an improvement. It's unclear to me what you're asking for, though. Would you rather have a comment somewhere near the tegra_pcie_unconfig_controller() function that states the same thing as the commit message? Thierry
Attachment:
signature.asc
Description: PGP signature
