Message ID | 20181119211845.23168-1-salil.mehta@huawei.com |
---|---|
Headers | show |
Series | net: hns3: Adds support of debugfs to HNS3 driver | expand |
> From: Jakub Kicinski [mailto:jakub.kicinski@netronome.com] > Sent: Monday, November 19, 2018 10:30 PM > To: Salil Mehta <salil.mehta@huawei.com> > Cc: davem@davemloft.net; Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; > lipeng (Y) <lipeng321@huawei.com>; mehta.salil@opnsrc.net; > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm > <linuxarm@huawei.com> > Subject: Re: [PATCH net-next 0/8] net: hns3: Adds support of debugfs to > HNS3 driver > > On Mon, 19 Nov 2018 21:18:37 +0000, Salil Mehta wrote: > > This patchset adds support of debugfs to the HNS3 driver. > > > > Support has been added to query info related to below items: > > 1. Queue related > > 2. Flow Director > > 3. TC config > > 4. Transmit Module/Scheduler > > 5. QoS pause > > 6. QoS buffer > > 7. QoS prio map > > Please provide a more informative cover letter. > > From a short glance it looks like you add a single debugfs file, which > can be written to, and upon that write the driver will dump stuff into > kernel logs. That is correct. Do you foresee any problem with it or are we doing something which is objectionable? Salil.
On Wed, 21 Nov 2018 18:06:19 +0000, Salil Mehta wrote: > > From: Jakub Kicinski [mailto:jakub.kicinski@netronome.com] > > Sent: Monday, November 19, 2018 10:30 PM > > To: Salil Mehta <salil.mehta@huawei.com> > > Cc: davem@davemloft.net; Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>; > > lipeng (Y) <lipeng321@huawei.com>; mehta.salil@opnsrc.net; > > netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Linuxarm > > <linuxarm@huawei.com> > > Subject: Re: [PATCH net-next 0/8] net: hns3: Adds support of debugfs to > > HNS3 driver > > > > On Mon, 19 Nov 2018 21:18:37 +0000, Salil Mehta wrote: > > > This patchset adds support of debugfs to the HNS3 driver. > > > > > > Support has been added to query info related to below items: > > > 1. Queue related > > > 2. Flow Director > > > 3. TC config > > > 4. Transmit Module/Scheduler > > > 5. QoS pause > > > 6. QoS buffer > > > 7. QoS prio map > > > > Please provide a more informative cover letter. > > > > From a short glance it looks like you add a single debugfs file, which > > can be written to, and upon that write the driver will dump stuff into > > kernel logs. > > That is correct. Do you foresee any problem with it or are we doing something > which is objectionable? Its fine with me, but I think not everyone reading the list will read the code so a few extra words and adding one of the examples from the patches to the cover letter could help people understand the changes.