[PATCH v2 1/2] mtd: rawnand: qcom: Fix clock sequencing in qcom_nandc_probe()

[Bryan O'Donoghue]

On 06/01/2022 17:44, Greg KH wrote:
> On Thu, Jan 06, 2022 at 05:24:27PM +0000, Bryan O'Donoghue wrote:
>> On 03/01/2022 05:51, Manivannan Sadhasivam wrote:
>>> On Mon, Jan 03, 2022 at 03:03:15AM +0000, Bryan O'Donoghue wrote:
>>>> Interacting with a NAND chip on an IPQ6018 I found that the qcomsmem NAND
>>>> partition parser was returning -EPROBE_DEFER waiting for the main smem
>>>> driver to load.
>>>>
>>>> This caused the board to reset. Playing about with the probe() function
>>>> shows that the problem lies in the core clock being switched off before the
>>>> nandc_unalloc() routine has completed.
>>>>
>>>> If we look at how qcom_nandc_remove() tears down allocated resources we see
>>>> the expected order is
>>>>
>>>> qcom_nandc_unalloc(nandc);
>>>>
>>>> clk_disable_unprepare(nandc->aon_clk);
>>>> clk_disable_unprepare(nandc->core_clk);
>>>>
>>>> dma_unmap_resource(&pdev->dev, nandc->base_dma, resource_size(res),
>>>> 		   DMA_BIDIRECTIONAL, 0);
>>>>
>>>> Tweaking probe() to both bring up and tear-down in that order removes the
>>>> reset if we end up deferring elsewhere.
>>>>
>>>> Fixes: c76b78d8ec05 ("mtd: nand: Qualcomm NAND controller driver")
>>>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue at linaro.org>
>>>
>>> Reviewed-by: Manivannan Sadhasivam <mani at kernel.org>
>>>
>>> Can you please CC stable list for backporting?
>>>
>>> Thanks,
>>> Mani
>>>
>>
>> NP.
>>
>> + cc stable
>>
>> FWIW I believe Greg's scripts will pick up on Fixes: tags automatically
> 
> No, that is NOT the way to ensure that a patch will get picked up, that
> is a "this might eventually get there".
> 
> Please read:
>      https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> for how to do this properly.
> 
> thanks,
> 
> greg k-h
> 

Good to know

I've just been using Fixes: for the most part

Thanks

---
bod