[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c0de40c-7bf3-4d98-9d25-9b4f36a91e0b@huawei.com>
Date: Thu, 24 Oct 2024 22:06:14 +0800
From: Jijie Shao <shaojijie@...wei.com>
To: Andrew Lunn <andrew@...n.ch>
CC: <shaojijie@...wei.com>, <davem@...emloft.net>, <edumazet@...gle.com>,
<kuba@...nel.org>, <pabeni@...hat.com>, <andrew+netdev@...n.ch>,
<horms@...nel.org>, <shenjian15@...wei.com>, <wangpeiyang1@...wei.com>,
<liuyonglong@...wei.com>, <chenhao418@...wei.com>, <sudongming1@...wei.com>,
<xujunsheng@...wei.com>, <shiyongbang@...wei.com>, <libaihan@...wei.com>,
<jonathan.cameron@...wei.com>, <shameerali.kolothum.thodi@...wei.com>,
<salil.mehta@...wei.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 2/7] net: hibmcge: Add debugfs supported in this
module
on 2024/10/24 20:05, Andrew Lunn wrote:
>>>> + seq_printf(s, "mdio frequency: %u\n", specs->mdio_frequency);
>>> Is this interesting? Are you clocking it greater than 2.5MHz?
>> MDIO controller supports 1MHz, 2.5MHz, 12.5MHz, and 25MHz
>> Of course, we chose and tested 2.5M in actual work, but this can be modified.
> How? What API are you using it allow it to be modified? Why cannot you
> get the value using the same API?
This frequency cannot be modified dynamically.
There are some specification registers that store some initialization configuration parameters
written by the BMC, such as the default MAC address and hardware FIFO size and mdio frequency.
When the device is in prob, the driver reads the related configuration information and
initializes the device based on the configuration.
>
>> We requested three interrupts: "tx", "rx", "err"
>> The err interrupt is a summary interrupt. We distinguish different errors
>> based on the status register and mask.
>>
>> With "cat /proc/interrupts | grep hibmcge",
>> we can't distinguish the detailed cause of the error,
>> so we added this file to debugfs.
>>
>> the following effects are achieved:
>> [root@...alhost sjj]# cat /sys/kernel/debug/hibmcge/0000\:83\:00.1/irq_info
>> RX : is enabled: true, print: false, count: 2
>> TX : is enabled: true, print: false, count: 0
>> MAC_MII_FIFO_ERR : is enabled: false, print: true, count: 0
>> MAC_PCS_RX_FIFO_ERR : is enabled: false, print: true, count: 0
>> MAC_PCS_TX_FIFO_ERR : is enabled: false, print: true, count: 0
>> MAC_APP_RX_FIFO_ERR : is enabled: false, print: true, count: 0
>> MAC_APP_TX_FIFO_ERR : is enabled: false, print: true, count: 0
>> SRAM_PARITY_ERR : is enabled: true, print: true, count: 0
>> TX_AHB_ERR : is enabled: true, print: true, count: 0
>> RX_BUF_AVL : is enabled: true, print: false, count: 0
>> REL_BUF_ERR : is enabled: true, print: true, count: 0
>> TXCFG_AVL : is enabled: true, print: false, count: 0
>> TX_DROP : is enabled: true, print: false, count: 0
>> RX_DROP : is enabled: true, print: false, count: 0
>> RX_AHB_ERR : is enabled: true, print: true, count: 0
>> MAC_FIFO_ERR : is enabled: true, print: false, count: 0
>> RBREQ_ERR : is enabled: true, print: false, count: 0
>> WE_ERR : is enabled: true, print: false, count: 0
>>
>>
>> The irq framework of hibmcge driver also includes tx/rx interrupts.
>> Therefore, these interrupts are not distinguished separately in debugfs.
> Please make this a patch of its own, and include this in the commit
> message.
>
> Ideally you need to show there is no standard API for what you want to
> put into debugfs, because if there is a standard API, you don't need
> debugfs...
Because standard API don't meet my needs, I added detailed interrupt information to debugfs.
I'll add a detailed description to the commit message of v2.
>
>>>> +static int hbg_dbg_nic_state(struct seq_file *s, void *unused)
>>>> +{
>>>> + struct net_device *netdev = dev_get_drvdata(s->private);
>>>> + struct hbg_priv *priv = netdev_priv(netdev);
>>>> +
>>>> + seq_printf(s, "event handling state: %s\n",
>>>> + hbg_get_bool_str(test_bit(HBG_NIC_STATE_EVENT_HANDLING,
>>>> + &priv->state)));
>>>> +
>>>> + seq_printf(s, "tx timeout cnt: %llu\n", priv->stats.tx_timeout_cnt);
>>> Don't you have this via ethtool -S ?
>> Although tx_timeout_cnt is a statistical item, it is not displayed in the ethtool -S.
> Why?
>
> Andrew
This was decided by our internal discussion before,
and we'll revisit it, and move it to ethtool -S in the next version if it's okay with us.
Thanks,
Jijie Shao
Powered by blists - more mailing lists