Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 2/2] usb: bdc: Fix a resource leak in the error handling
 path of 'bdc_probe()'
To:     Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
        alcooperx@gmail.com, balbi@kernel.org, gregkh@linuxfoundation.org
Cc:     linux-usb@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com,
        linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
References: <0c5910979f39225d5d8fe68c9ab1c147c68ddee1.1629314734.git.christophe.jaillet@wanadoo.fr>
 <f8a4a6897deb0c8cb2e576580790303550f15fcd.1629314734.git.christophe.jaillet@wanadoo.fr>
From:   Florian Fainelli <f.fainelli@gmail.com>
Message-ID: <c56617ff-5d74-9b07-4bcc-25f3dd2aca64@gmail.com>
Date:   Fri, 20 Aug 2021 22:03:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <f8a4a6897deb0c8cb2e576580790303550f15fcd.1629314734.git.christophe.jaillet@wanadoo.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 8/18/2021 9:32 PM, Christophe JAILLET wrote:
> If an error occurs after a successful 'clk_prepare_enable()' call, it must
> be undone by a corresponding 'clk_disable_unprepare()' call.
> This call is already present in the remove function.
> 
> Add this call in the error handling path and reorder the code so that the
> 'clk_prepare_enable()' call happens later in the function.
> The goal is to have as much managed resources functions as possible
> before the 'clk_prepare_enable()' call in order to keep the error handling
> path simple.
> 
> While at it, remove the now unneeded 'clk' variable.
> 
> Fixes: c87dca047849 ("usb: bdc: Add clock enable for new chips with a separate BDC clock")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>

> ---
> Review with care.
> I don't like shuffling code like that because of possible side effect.
> Moving the code related to this clk looks fine to me, but who knows...

There are no register accesses until bdc_phy_init() gets called, so this 
looks fine to me. Al knows this code better than I do though, so it 
would be better to wait for his Acked-by tag.
-- 
Florian