[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YzVflom04uK0gojn@hovoldconsulting.com>
Date: Thu, 29 Sep 2022 11:04:22 +0200
From: Johan Hovold <johan@...nel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Johan Hovold <johan+linaro@...nel.org>,
Vinod Koul <vkoul@...nel.org>, Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Kishon Vijay Abraham I <kishon@...com>,
linux-arm-msm@...r.kernel.org, linux-phy@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/13] phy: qcom-qmp-pcie: clean up power-down handling
On Thu, Sep 29, 2022 at 10:30:20AM +0300, Dmitry Baryshkov wrote:
> On 29/09/2022 10:25, Johan Hovold wrote:
> > On Wed, Sep 28, 2022 at 10:15:46PM +0300, Dmitry Baryshkov wrote:
> >> On 28/09/2022 18:28, Johan Hovold wrote:
> >>> Always define the POWER_DOWN_CONTROL register instead of falling back to
> >>> the v2 offset during power on and power off.
> >>>
> >>> Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> >>> ---
> >>> drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 20 ++++++--------------
> >>> 1 file changed, 6 insertions(+), 14 deletions(-)
> >>>
> >>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> >>> index eea66c24cf7e..47cdb9ed80cd 100644
> >>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> >>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> >>> @@ -90,12 +90,14 @@ static const unsigned int pciephy_regs_layout[QPHY_LAYOUT_SIZE] = {
> >>> [QPHY_SW_RESET] = 0x00,
> >>> [QPHY_START_CTRL] = 0x08,
> >>> [QPHY_PCS_STATUS] = 0x174,
> >>> + [QPHY_PCS_POWER_DOWN_CONTROL] = 0x04,
> >>> };
> >>
> >> Without symbolic names it's not obvious that 0x04 (and thus this
> >> regs_layout) can be used for v2 and v3, but not for v4.
> >
> > It's no less obvious than it was when we were falling back to the v2
> > define when it wasn't in the table.
>
> Yes, that's without doubts. Anyway, I've sent my view on the regs
> layouts standing on top of your six patches from this series. Could you
> please take a glance?
Sure, but I don't think doing that separate change should be a blocker
for this series. Especially since you run into issues like it not
always being clear which version of the IP is being used (IPQ).
I'd rather respin this series and drop the two patches that merged the
two redundant layout structs.
Then you can work on further clean ups on top for 6.2 since that's going
to require some more careful review and thought.
Johan
Powered by blists - more mailing lists