netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Shannon Nelson <shannon.nelson@amd.com>
Cc: brett.creeley@amd.com, davem@davemloft.net,
	netdev@vger.kernel.org, kuba@kernel.org, drivers@pensando.io,
	leon@kernel.org
Subject: Re: [PATCH RFC v4 net-next 02/13] pds_core: add devcmd device interfaces
Date: Thu, 9 Mar 2023 10:29:33 +0100	[thread overview]
Message-ID: <ZAmm/bUs8FbWn+wp@nanopsycho> (raw)
In-Reply-To: <02b934ee-edd9-08f1-3571-5efe7687b546@amd.com>

Thu, Mar 09, 2023 at 03:05:13AM CET, shannon.nelson@amd.com wrote:
>On 3/8/23 1:37 AM, Jiri Pirko wrote:
>> Wed, Mar 08, 2023 at 06:12:59AM CET, shannon.nelson@amd.com wrote:

[..]


>> > +static int identity_show(struct seq_file *seq, void *v)
>> > +{
>> > +      struct pdsc *pdsc = seq->private;
>> > +      struct pds_core_dev_identity *ident;
>> > +      int vt;
>> > +
>> > +      ident = &pdsc->dev_ident;
>> > +
>> > +      seq_printf(seq, "asic_type:        0x%x\n", pdsc->dev_info.asic_type);
>> > +      seq_printf(seq, "asic_rev:         0x%x\n", pdsc->dev_info.asic_rev);
>> > +      seq_printf(seq, "serial_num:       %s\n", pdsc->dev_info.serial_num);
>> > +      seq_printf(seq, "fw_version:       %s\n", pdsc->dev_info.fw_version);
>> 
>> What is the exact reason of exposing this here and not trought well
>> defined devlink info interface?
>
>These do show up in devlink dev info eventually, but that isn't for another
>couple of patches.  This gives us info here for debugging the earlier patches
>if needed.

Implement it properly from the start and avoid these, please.


>
>> 
>> 
>> > +      seq_printf(seq, "fw_status:        0x%x\n",
>> > +                 ioread8(&pdsc->info_regs->fw_status));
>> > +      seq_printf(seq, "fw_heartbeat:     0x%x\n",
>> > +                 ioread32(&pdsc->info_regs->fw_heartbeat));
>> > +


[..]

>> > +static int pdsc_identify(struct pdsc *pdsc)
>> > +{
>> > +      struct pds_core_drv_identity drv = { 0 };
>> > +      size_t sz;
>> > +      int err;
>> > +
>> > +      drv.drv_type = cpu_to_le32(PDS_DRIVER_LINUX);
>> > +      drv.kernel_ver = cpu_to_le32(LINUX_VERSION_CODE);
>> > +      snprintf(drv.kernel_ver_str, sizeof(drv.kernel_ver_str),
>> > +               "%s %s", utsname()->release, utsname()->version);
>> > +      snprintf(drv.driver_ver_str, sizeof(drv.driver_ver_str),
>> > +               "%s %s", PDS_CORE_DRV_NAME, utsname()->release);
>> 
>> Why exactly are you doing this? Looks very wrong.
>
>This helps us when debugging on the DSC side - we can see which host driver
>is using the interface (PXE, Linux, etc).  This is modeled from what we have
>in our out-of-tree ionic driver interface, but I need to trim it down to be
>less snoopy.

Device should not care who is on the other side in my opinion. Jakub,
any thoughts?

>
>sln

  reply	other threads:[~2023-03-09  9:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08  5:12 [PATCH RFC v4 net-next 00/13] pds_core driver Shannon Nelson
2023-03-08  5:12 ` [PATCH RFC v4 net-next 01/13] pds_core: initial framework for pds_core PF driver Shannon Nelson
2023-03-08  5:12 ` [PATCH RFC v4 net-next 02/13] pds_core: add devcmd device interfaces Shannon Nelson
2023-03-08  9:37   ` Jiri Pirko
2023-03-09  2:05     ` Shannon Nelson
2023-03-09  9:29       ` Jiri Pirko [this message]
2023-03-09 22:25         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 03/13] pds_core: health timer and workqueue Shannon Nelson
2023-03-08  9:39   ` Jiri Pirko
2023-03-09  2:08     ` Shannon Nelson
2023-03-09  9:30       ` Jiri Pirko
2023-03-09 22:26         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 04/13] pds_core: set up device and adminq Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 05/13] pds_core: Add adminq processing and commands Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 06/13] pds_core: add FW update feature to devlink Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 07/13] pds_core: set up the VIF definitions and defaults Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 08/13] pds_core: add initial VF device handling Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 09/13] pds_core: add auxiliary_bus devices Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 10/13] pds_core: devlink params for enabling VIF support Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 11/13] pds_core: add the aux client API Shannon Nelson
2023-03-14 12:14   ` Leon Romanovsky
2023-03-14 16:53     ` Shannon Nelson
2023-03-15  8:21       ` Leon Romanovsky
2023-03-16  1:08         ` Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 12/13] pds_core: publish events to the clients Shannon Nelson
2023-03-08  5:13 ` [PATCH RFC v4 net-next 13/13] pds_core: Kconfig and pds_core.rst Shannon Nelson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZAmm/bUs8FbWn+wp@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=brett.creeley@amd.com \
    --cc=davem@davemloft.net \
    --cc=drivers@pensando.io \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shannon.nelson@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).