[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220613204435.GD28636-robh@kernel.org>
Date: Mon, 13 Jun 2022 14:44:35 -0600
From: Rob Herring <robh@...nel.org>
To: Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Jingoo Han <jingoohan1@...il.com>,
Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
Krzysztof WilczyĆski <kw@...ux.com>,
Serge Semin <fancer.lancer@...il.com>,
Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
Frank Li <Frank.Li@....com>,
Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 16/18] PCI: dwc-plat: Simplify the probe method return
value handling
On Fri, Jun 10, 2022 at 11:25:32AM +0300, Serge Semin wrote:
> The whole switch-case-logic implemented in the DWC PCIe RC/EP probe
> procedure doesn't seem well thought through. First of all the ret variable
> is unused in the EP-case and is only partly involved in the RC-case of the
> switch-case statement, which unnecessary complicates the code. Secondly
> the probe method will return zero if an unknown mode is detected. That is
> improbable situation since the OF-device data is initialized only with
> valid modes, but such code is still wrong at least from maintainability
> point of view. So let's convert the switch-case part of the probe function
> to being more coherent. We suggest to use the local ret variable to
> preserve the status of the case-clauses and return its value from the
> probe procedure after the work is done.
>
> Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> ---
> drivers/pci/controller/dwc/pcie-designware-plat.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
Reviewed-by: Rob Herring <robh@...nel.org>
Powered by blists - more mailing lists