Message ID | 20230714130214.14552-1-johan+linaro@kernel.org |
---|---|
Headers | show |
Series | serial: qcom-geni: fix opp vote on shutdown | expand |
On Fri, Jul 14, 2023 at 04:29:08PM +0200, Konrad Dybcio wrote: > On 14.07.2023 15:02, Johan Hovold wrote: > > The operating-performance-point vote needs to be dropped when shutting > > down the port to avoid wasting power by keeping resources like power > > domains in an unnecessarily high performance state (e.g. when a UART > > connected Bluetooth controller is not in use). > > > > Fixes: a5819b548af0 ("tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state") > > Cc: stable@vger.kernel.org # 5.9 > > Cc: Rajendra Nayak <quic_rjendra@quicinc.com> > > Cc: Matthias Kaehlcke <mka@chromium.org> > > Signed-off-by: Johan Hovold <johan+linaro@kernel.org> > > --- > I don't know a whole lot about this subsystem, but the PM call has > a pointer to uport which already contains this clock rate.. Is it > zeroed out by the core before we reach it, which would prevent us > from reusing it? No, but this driver has other issues and I couldn't be arsed fixing them before addressing this bug. Specifically that uartclk variable can currently be set by userspace... I'll fix that up next week. Johan
On 14.07.2023 17:08, Johan Hovold wrote: > On Fri, Jul 14, 2023 at 04:29:08PM +0200, Konrad Dybcio wrote: >> On 14.07.2023 15:02, Johan Hovold wrote: >>> The operating-performance-point vote needs to be dropped when shutting >>> down the port to avoid wasting power by keeping resources like power >>> domains in an unnecessarily high performance state (e.g. when a UART >>> connected Bluetooth controller is not in use). >>> >>> Fixes: a5819b548af0 ("tty: serial: qcom_geni_serial: Use OPP API to set clk/perf state") >>> Cc: stable@vger.kernel.org # 5.9 >>> Cc: Rajendra Nayak <quic_rjendra@quicinc.com> >>> Cc: Matthias Kaehlcke <mka@chromium.org> >>> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> >>> --- >> I don't know a whole lot about this subsystem, but the PM call has >> a pointer to uport which already contains this clock rate.. Is it >> zeroed out by the core before we reach it, which would prevent us >> from reusing it? > > No, but this driver has other issues and I couldn't be arsed fixing them > before addressing this bug. > > Specifically that uartclk variable can currently be set by userspace... > > I'll fix that up next week. OK sounds good Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad > > Johan