[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aVO3_32KT6HfOUAZ@ryzen>
Date: Tue, 30 Dec 2025 12:31:11 +0100
From: Niklas Cassel <cassel@...nel.org>
To: manivannan.sadhasivam@....qualcomm.com
Cc: Manivannan Sadhasivam <mani@...nel.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof WilczyĆski <kwilczynski@...nel.org>,
Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
Bartosz Golaszewski <brgl@...ev.pl>, linux-pci@...r.kernel.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
Chen-Yu Tsai <wens@...nel.org>,
Brian Norris <briannorris@...omium.org>,
Krishna Chaitanya Chundru <krishna.chundru@....qualcomm.com>,
Alex Elder <elder@...cstar.com>,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>,
Chen-Yu Tsai <wenst@...omium.org>
Subject: Re: [PATCH v3 0/7] PCI/pwrctrl: Major rework to integrate pwrctrl
devices with controller drivers
Hello Mani,
On Mon, Dec 29, 2025 at 10:56:51PM +0530, Manivannan Sadhasivam via B4 Relay wrote:
> **NOTE**: With this series, the controller driver may undergo multiple probe
> deferral if the pwrctrl driver was not available during the controller driver
> probe. This is pretty much required to avoid the resource allocation issue. I
> plan to replace probe deferral with blocking wait in the coming days.
It sounds like you want to base that upcoming series on top of this series.
Considering that we are only at -rc3, would it perhaps be a good idea to
wait for you to implement the blocking wait, so that it can be part of
this series, to avoid the additional code churn?
Kind regards,
Niklas
Powered by blists - more mailing lists