From: Jakub Kicinski <kuba@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Lixue Liang <lianglixuehao@126.com>,
anthony.l.nguyen@intel.com, linux-kernel@vger.kernel.org,
jesse.brandeburg@intel.com, davem@davemloft.net,
edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org,
lianglixue@greatwall.com.cn,
Alexander H Duyck <alexander.duyck@gmail.com>
Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one
Date: Wed, 14 Dec 2022 12:50:16 -0800 [thread overview]
Message-ID: <20221214125016.5a23c32a@kernel.org> (raw)
In-Reply-To: <Y5obql8TVeYEsRw8@unreal>
On Wed, 14 Dec 2022 20:53:30 +0200 Leon Romanovsky wrote:
> On Wed, Dec 14, 2022 at 08:51:06AM -0800, Jakub Kicinski wrote:
> > On Wed, 14 Dec 2022 09:22:13 +0200 Leon Romanovsky wrote:
> > > NAK to any module driver parameter. If it is applicable to all drivers,
> > > please find a way to configure it to more user-friendly. If it is not,
> > > try to do the same as other drivers do.
> >
> > I think this one may be fine. Configuration which has to be set before
> > device probing can't really be per-device.
>
> This configuration can be different between multiple devices
> which use same igb module. Module parameters doesn't allow such
> separation.
Configuration of the device, sure, but this module param is more of
a system policy. BTW the name of the param is not great, we're allowing
the use of random address, not an invalid address.
> Also, as a user, I despise random module parameters which I need
> to set after every HW update/replacement.
Agreed, IIUC the concern was alerting users to incorrect EEPROM values.
I thought falling back to a random address was relatively common, but
I haven't done the research.
next prev parent reply other threads:[~2022-12-14 20:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 7:47 [PATCH v7] igb: Assign random MAC address instead of fail in case of invalid one Lixue Liang
2022-12-13 19:22 ` Tony Nguyen
2022-12-14 7:22 ` Leon Romanovsky
2022-12-14 10:02 ` 梁礼学
2022-12-14 16:51 ` Jakub Kicinski
2022-12-14 18:53 ` Leon Romanovsky
2022-12-14 20:50 ` Jakub Kicinski [this message]
2022-12-14 21:43 ` Heiner Kallweit
2022-12-14 23:17 ` Alexander Duyck
2022-12-15 3:24 ` 梁礼学
2022-12-15 15:49 ` Alexander H Duyck
2022-12-19 18:25 ` Jacob Keller
2022-12-18 8:41 ` Leon Romanovsky
2022-12-19 15:30 ` Alexander Duyck
2022-12-28 9:15 ` Leon Romanovsky
2022-12-30 16:17 ` Andrew Lunn
-- strict thread matches above, loose matches on Subject: below --
2022-12-14 1:12 Lixue Liang
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=20221214125016.5a23c32a@kernel.org \
--to=kuba@kernel.org \
--cc=alexander.duyck@gmail.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jesse.brandeburg@intel.com \
--cc=leon@kernel.org \
--cc=lianglixue@greatwall.com.cn \
--cc=lianglixuehao@126.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.