summaryrefslogtreecommitdiffstats
path: root/net/bridge/br_mdb.c
diff options
context:
space:
mode:
authorDouglas Anderson <dianders@chromium.org>2023-03-13 11:18:19 -0700
committerMark Brown <broonie@kernel.org>2023-03-14 13:30:50 +0000
commit691c1fcda5351ed98a44610b7dccc0e3ee920020 (patch)
treee6cb08dff723beefc49d7856420253782ea99bc4 /net/bridge/br_mdb.c
parent38cc873cb1cf27965dacbbc5957a7a8aee89679c (diff)
downloadlinux-stable-691c1fcda5351ed98a44610b7dccc0e3ee920020.tar.gz
linux-stable-691c1fcda5351ed98a44610b7dccc0e3ee920020.tar.bz2
linux-stable-691c1fcda5351ed98a44610b7dccc0e3ee920020.zip
regulator: core: Shorten off-on-delay-us for always-on/boot-on by time since booted
This is very close to a straight revert of commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"). We've identified that patch as causing a boot speed regression on sc7180-trogdor boards. While boot speed certainly isn't more important than making sure that power sequencing is correct, looking closely at the original change it doesn't seem to have been fully justified. It mentions "cycling issues" without describing exactly what the issues were. That means it's possible that the cycling issues were really a problem that should be fixed in a different way. Let's take a careful look at how we should handle regulators that have an off-on-delay and that are boot-on or always-on. Linux currently doesn't have any way to identify whether a GPIO regulator was already on when the kernel booted. That means that when the kernel boots we probe a regulator, see that it wants boot-on / always-on we, and then turn the regulator on. We could be in one of two cases when we do this: a) The regulator might have been left on by the bootloader and we're ensuring that it stays on. b) The regulator might have been left off by the bootloader and we're just now turning it on. For case a) we definitely don't need any sort of delay. For case b) we _might_ need some delay in case the bootloader turned the regulator off _right_ before booting the kernel. To get the proper delay for case b) then we can just assume a `last_off` of 0, which is what it gets initialized to by default. As per above, we can't tell whether we're in case a) or case b) so we'll assume the longer delay (case b). This basically puts the code to how it was before commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"). However, we add one important change: we make sure that the delay is actually honored if `last_off` is 0. Though the original "cycling issues" cited were vague, I'm hopeful that this important extra change will be enough to fix the issues that the initial commit mentioned. With this fix, I've confined that on a sc7180-trogdor board the delay at boot goes down from 500 ms to ~250 ms. That's not as good as the 0 ms that we had prior to commit 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators"), but it's probably safer because we don't know if the bootloader turned the regulator off right before booting. One note is that it's possible that we could be in a state that's not a) or b) if there are other issues in the kernel. The only one I can think of is related to pinctrl. If the pinctrl driver being used on a board isn't careful about avoiding glitches when setting up a pin then it's possible that setting up a pin could cause the regulator to "turn off" briefly immediately before the regulator probes. If this is indeed causing problems then the pinctrl driver should be fixed, perhaps in a similar way to what was done in commit d21f4b7ffc22 ("pinctrl: qcom: Avoid glitching lines when we first mux to output") Fixes: 218320fec294 ("regulator: core: Fix off-on-delay-us for always-on/boot-on regulators") Cc: Christian Kohlschütter <christian@kohlschutter.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20230313111806.1.I2eaad872be0932a805c239a7c7a102233fb0b03b@changeid Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'net/bridge/br_mdb.c')
0 files changed, 0 insertions, 0 deletions