From: Jiri Pirko <jiri@resnulli.us>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vasundhara Volam <vasundhara-v.volam@broadcom.com>,
David Miller <davem@davemloft.net>,
Netdev <netdev@vger.kernel.org>, Jiri Pirko <jiri@mellanox.com>,
Michael Chan <michael.chan@broadcom.com>
Subject: Re: [PATCH net] devlink: Fix error handling in param and info_get dumpit cb
Date: Fri, 27 Sep 2019 15:08:32 +0200 [thread overview]
Message-ID: <20190927130832.GA2733@nanopsycho> (raw)
In-Reply-To: <20190927123129.GB25474@lunn.ch>
Fri, Sep 27, 2019 at 02:31:29PM CEST, andrew@lunn.ch wrote:
>On Fri, Sep 27, 2019 at 10:28:36AM +0530, Vasundhara Volam wrote:
>> On Thu, Sep 26, 2019 at 5:57 PM Andrew Lunn <andrew@lunn.ch> wrote:
>> >
>> > On Thu, Sep 26, 2019 at 03:05:54PM +0530, Vasundhara Volam wrote:
>> > > If any of the param or info_get op returns error, dumpit cb is
>> > > skipping to dump remaining params or info_get ops for all the
>> > > drivers.
>> > >
>> > > Instead skip only for the param/info_get op which returned error
>> > > and continue to dump remaining information, except if the return
>> > > code is EMSGSIZE.
>> >
>> > Hi Vasundhara
>> >
>> > How do we get to see something did fail? If it failed, it failed for a
>> > reason, and we want to know.
>> >
>> > What is your real use case here? What is failing, and why are you
>> > O.K. to skip this failure?
>> >
>> > Andrew
>> Hi Andrew,
>>
>> Thank you for looking into the patch.
>>
>> If any of the devlink parameter is returning error like EINVAL, then
>> current code is not displaying any further parameters for all the other
>> devices as well.
>>
>> In bnxt_en driver case, some of the parameters are not supported in
>> certain configurations like if the parameter is not part of the
>> NVM configuration, driver returns EINVAL error to the stack. And devlink is
>> skipping to display all the remaining parameters for that device and others
>> as well.
>>
>> I am trying to fix to skip only the error parameter and display the remaining
>> parameters.
>
>Hi Vasundhara
>
>Thanks for explaining your use case. It sounds sensible. But i would
>narrow this down.
>
>Make the driver return EOPNOTSUP, not EINVAL. And then in dump, only
>skip EOPNOTSUP. Any other errors cause the error to be returned, so we
>get to see them.
Agreed, that would be more reasonable.
>
> Andrew
next prev parent reply other threads:[~2019-09-27 13:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-26 9:35 [PATCH net] devlink: Fix error handling in param and info_get dumpit cb Vasundhara Volam
2019-09-26 12:27 ` Andrew Lunn
2019-09-27 4:58 ` Vasundhara Volam
2019-09-27 12:31 ` Andrew Lunn
2019-09-27 13:08 ` Jiri Pirko [this message]
2019-09-27 13:37 ` Vasundhara Volam
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=20190927130832.GA2733@nanopsycho \
--to=jiri@resnulli.us \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=jiri@mellanox.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=vasundhara-v.volam@broadcom.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).