Re: [PATCH net-next 8/9] net: hns3: cleanup some print format warning

From: tanhuazhong
Date: Thu Oct 31 2019 - 21:18:09 EST




On 2019/10/31 19:53, Joe Perches wrote:
On Thu, 2019-10-31 at 19:23 +0800, Huazhong Tan wrote:
From: Guojia Liao <liaoguojia@xxxxxxxxxx>

Using '%d' for printing type unsigned int or '%u' for
type int would cause static tools to give false warnings,
so this patch cleanups this warning by using the suitable
format specifier of the type of variable.

BTW, modifies the type of some variables and macro to
synchronize with their usage.

What tool is this?

Sorry, it is my mistake, as confirmed, this patch is
advised by internal code review.


I think this static warning is excessive as macro
defines with a small positive number are common


yes, it seems ok.
The reason we do this modification is that
printing resp_data_len with '%u' and printing
HCLGE_MBX_MAX_RESP_DATA_SIZE with '%d' seems a little odd.

if (resp_data_len > HCLGE_MBX_MAX_RESP_DATA_SIZE) {
dev_err(&hdev->pdev->dev,
- "PF fail to gen resp to VF len %d exceeds max len %d\n",
+ "PF fail to gen resp to VF len %u exceeds max len %u\n",
resp_data_len,
HCLGE_MBX_MAX_RESP_DATA_SIZE);

Thanks for your suggestion.

diff --git a/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
[]
@@ -72,7 +72,7 @@ enum hclge_mbx_vlan_cfg_subcode {
};
#define HCLGE_MBX_MAX_MSG_SIZE 16
-#define HCLGE_MBX_MAX_RESP_DATA_SIZE 8
+#define HCLGE_MBX_MAX_RESP_DATA_SIZE 8U
#define HCLGE_MBX_RING_MAP_BASIC_MSG_NUM 3
#define HCLGE_MBX_RING_NODE_VARIABLE_NUM 3

like this one

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
[]
@@ -57,68 +57,68 @@ static int hns3_dbg_queue_info(struct hnae3_handle *h,
HNS3_RING_RX_RING_BASEADDR_H_REG);
base_add_l = readl_relaxed(ring->tqp->io_base +
HNS3_RING_RX_RING_BASEADDR_L_REG);
- dev_info(&h->pdev->dev, "RX(%d) BASE ADD: 0x%08x%08x\n", i,
+ dev_info(&h->pdev->dev, "RX(%u) BASE ADD: 0x%08x%08x\n", i,

so using %d is correct enough.



.