* [PATCH] ufs: qcom: Fix confusing cleanup.h syntax
@ 2025-12-08 2:08 Krzysztof Kozlowski
2025-12-08 5:16 ` Manivannan Sadhasivam
2025-12-09 3:11 ` Martin K. Petersen
0 siblings, 2 replies; 4+ messages in thread
From: Krzysztof Kozlowski @ 2025-12-08 2:08 UTC (permalink / raw)
To: Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
linux-arm-msm, linux-scsi, linux-kernel
Cc: Krzysztof Kozlowski
Initializing automatic __free variables to NULL without need (e.g.
branches with different allocations), followed by actual allocation is
in contrary to explicit coding rules guiding cleanup.h:
"Given that the "__free(...) = NULL" pattern for variables defined at
the top of the function poses this potential interdependency problem the
recommendation is to always define and assign variables in one statement
and not group variable definitions at the top of the function when
__free() is used."
Code does not have a bug, but is less readable and uses discouraged
coding practice, so fix that by moving declaration to the place of
assignment.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
drivers/ufs/host/ufs-qcom.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
index 8d119b3223cb..8ebee0cc5313 100644
--- a/drivers/ufs/host/ufs-qcom.c
+++ b/drivers/ufs/host/ufs-qcom.c
@@ -1769,10 +1769,9 @@ static void ufs_qcom_dump_testbus(struct ufs_hba *hba)
{
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
int i, j, nminor = 0, testbus_len = 0;
- u32 *testbus __free(kfree) = NULL;
char *prefix;
- testbus = kmalloc_array(256, sizeof(u32), GFP_KERNEL);
+ u32 *testbus __free(kfree) = kmalloc_array(256, sizeof(u32), GFP_KERNEL);
if (!testbus)
return;
@@ -1794,13 +1793,12 @@ static void ufs_qcom_dump_testbus(struct ufs_hba *hba)
static int ufs_qcom_dump_regs(struct ufs_hba *hba, size_t offset, size_t len,
const char *prefix, void __iomem *base)
{
- u32 *regs __free(kfree) = NULL;
size_t pos;
if (offset % 4 != 0 || len % 4 != 0)
return -EINVAL;
- regs = kzalloc(len, GFP_ATOMIC);
+ u32 *regs __free(kfree) = kzalloc(len, GFP_ATOMIC);
if (!regs)
return -ENOMEM;
--
2.51.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] ufs: qcom: Fix confusing cleanup.h syntax
2025-12-08 2:08 [PATCH] ufs: qcom: Fix confusing cleanup.h syntax Krzysztof Kozlowski
@ 2025-12-08 5:16 ` Manivannan Sadhasivam
2025-12-08 7:09 ` Krzysztof Kozlowski
2025-12-09 3:11 ` Martin K. Petersen
1 sibling, 1 reply; 4+ messages in thread
From: Manivannan Sadhasivam @ 2025-12-08 5:16 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: James E.J. Bottomley, Martin K. Petersen, linux-arm-msm,
linux-scsi, linux-kernel
On Mon, Dec 08, 2025 at 03:08:08AM +0100, Krzysztof Kozlowski wrote:
> Initializing automatic __free variables to NULL without need (e.g.
> branches with different allocations), followed by actual allocation is
> in contrary to explicit coding rules guiding cleanup.h:
>
> "Given that the "__free(...) = NULL" pattern for variables defined at
> the top of the function poses this potential interdependency problem the
> recommendation is to always define and assign variables in one statement
> and not group variable definitions at the top of the function when
> __free() is used."
>
> Code does not have a bug, but is less readable and uses discouraged
> coding practice, so fix that by moving declaration to the place of
> assignment.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Thanks. On the side note, I would recommend adding this check to checkpatch to
warn people in the first place.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/ufs/host/ufs-qcom.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 8d119b3223cb..8ebee0cc5313 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -1769,10 +1769,9 @@ static void ufs_qcom_dump_testbus(struct ufs_hba *hba)
> {
> struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> int i, j, nminor = 0, testbus_len = 0;
> - u32 *testbus __free(kfree) = NULL;
> char *prefix;
>
> - testbus = kmalloc_array(256, sizeof(u32), GFP_KERNEL);
> + u32 *testbus __free(kfree) = kmalloc_array(256, sizeof(u32), GFP_KERNEL);
> if (!testbus)
> return;
>
> @@ -1794,13 +1793,12 @@ static void ufs_qcom_dump_testbus(struct ufs_hba *hba)
> static int ufs_qcom_dump_regs(struct ufs_hba *hba, size_t offset, size_t len,
> const char *prefix, void __iomem *base)
> {
> - u32 *regs __free(kfree) = NULL;
> size_t pos;
>
> if (offset % 4 != 0 || len % 4 != 0)
> return -EINVAL;
>
> - regs = kzalloc(len, GFP_ATOMIC);
> + u32 *regs __free(kfree) = kzalloc(len, GFP_ATOMIC);
> if (!regs)
> return -ENOMEM;
>
> --
> 2.51.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] ufs: qcom: Fix confusing cleanup.h syntax
2025-12-08 5:16 ` Manivannan Sadhasivam
@ 2025-12-08 7:09 ` Krzysztof Kozlowski
0 siblings, 0 replies; 4+ messages in thread
From: Krzysztof Kozlowski @ 2025-12-08 7:09 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: James E.J. Bottomley, Martin K. Petersen, linux-arm-msm,
linux-scsi, linux-kernel
On 08/12/2025 06:16, Manivannan Sadhasivam wrote:
> On Mon, Dec 08, 2025 at 03:08:08AM +0100, Krzysztof Kozlowski wrote:
>> Initializing automatic __free variables to NULL without need (e.g.
>> branches with different allocations), followed by actual allocation is
>> in contrary to explicit coding rules guiding cleanup.h:
>>
>> "Given that the "__free(...) = NULL" pattern for variables defined at
>> the top of the function poses this potential interdependency problem the
>> recommendation is to always define and assign variables in one statement
>> and not group variable definitions at the top of the function when
>> __free() is used."
>>
>> Code does not have a bug, but is less readable and uses discouraged
>> coding practice, so fix that by moving declaration to the place of
>> assignment.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Thanks. On the side note, I would recommend adding this check to checkpatch to
> warn people in the first place.
>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
That could be too many false positives. =NULL initialization is correct
and valid in certain cases. Just should not be the default/standard.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] ufs: qcom: Fix confusing cleanup.h syntax
2025-12-08 2:08 [PATCH] ufs: qcom: Fix confusing cleanup.h syntax Krzysztof Kozlowski
2025-12-08 5:16 ` Manivannan Sadhasivam
@ 2025-12-09 3:11 ` Martin K. Petersen
1 sibling, 0 replies; 4+ messages in thread
From: Martin K. Petersen @ 2025-12-09 3:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Manivannan Sadhasivam, James E.J. Bottomley, Martin K. Petersen,
linux-arm-msm, linux-scsi, linux-kernel
Krzysztof,
> Initializing automatic __free variables to NULL without need (e.g.
> branches with different allocations), followed by actual allocation is
> in contrary to explicit coding rules guiding cleanup.h:
Applied to 6.19/scsi-staging, thanks!
--
Martin K. Petersen
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-12-09 3:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-08 2:08 [PATCH] ufs: qcom: Fix confusing cleanup.h syntax Krzysztof Kozlowski
2025-12-08 5:16 ` Manivannan Sadhasivam
2025-12-08 7:09 ` Krzysztof Kozlowski
2025-12-09 3:11 ` Martin K. Petersen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox