From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 0/1] add support for enum module parameters
Date: Thu, 14 Apr 2022 16:29:49 +0200 [thread overview]
Message-ID: <Ylgv3U4HEtpk3sis@kroah.com> (raw)
In-Reply-To: <87a6cneoco.fsf@intel.com>
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
intel-gfx@lists.freedesktop.org,
Lucas De Marchi <lucas.demarchi@intel.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/1] add support for enum module parameters
Date: Thu, 14 Apr 2022 16:29:49 +0200 [thread overview]
Message-ID: <Ylgv3U4HEtpk3sis@kroah.com> (raw)
In-Reply-To: <87a6cneoco.fsf@intel.com>
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jani Nikula <jani.nikula@intel.com>
Cc: linux-kernel@vger.kernel.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org,
Andrew Morton <akpm@linux-foundation.org>,
Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [PATCH 0/1] add support for enum module parameters
Date: Thu, 14 Apr 2022 16:29:49 +0200 [thread overview]
Message-ID: <Ylgv3U4HEtpk3sis@kroah.com> (raw)
In-Reply-To: <87a6cneoco.fsf@intel.com>
On Thu, Apr 14, 2022 at 05:22:47PM +0300, Jani Nikula wrote:
> On Thu, 14 Apr 2022, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Apr 14, 2022 at 03:30:32PM +0300, Jani Nikula wrote:
> >> Hey, I've sent this before, ages ago, but haven't really followed
> >> through with it. I still think it would be useful for many scenarios
> >> where a plain number is a clumsy interface for a module param.
> >>
> >> Thoughts?
> >
> > We should not be adding new module parameters anyway (they operate on
> > code, not data/devices), so what would this be used for?
>
> I think it's just easier to use names than random values, and this also
> gives you range check on the input.
>
> I also keep telling people not to add new module parameters, but it's
> not like they're going away anytime soon.
Existing ones can not go away (or change), but we do not have to add new
ones.
> If there's a solution to being able to pass device specific debug
> parameters at probe time, I'm all ears. At least i915 has a bunch of
> things which can't really be changed after probe, when debugfs for the
> device is around. Module parameters aren't ideal, but debugfs doesn't
> work for this.
configfs?
next prev parent reply other threads:[~2022-04-14 14:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-14 12:30 [Intel-gfx] [PATCH 0/1] add support for enum module parameters Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 12:30 ` [Intel-gfx] [PATCH 1/1] module: add enum module parameter type to map names to values Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 12:30 ` Jani Nikula
2022-04-14 13:19 ` [Intel-gfx] [PATCH 0/1] add support for enum module parameters Greg Kroah-Hartman
2022-04-14 13:19 ` Greg Kroah-Hartman
2022-04-14 13:19 ` Greg Kroah-Hartman
2022-04-14 14:22 ` [Intel-gfx] " Jani Nikula
2022-04-14 14:22 ` Jani Nikula
2022-04-14 14:22 ` Jani Nikula
2022-04-14 14:29 ` Greg Kroah-Hartman [this message]
2022-04-14 14:29 ` Greg Kroah-Hartman
2022-04-14 14:29 ` Greg Kroah-Hartman
2022-04-20 5:13 ` [Intel-gfx] " Kalle Valo
2022-04-20 5:13 ` Kalle Valo
2022-04-20 5:13 ` Kalle Valo
2022-04-20 6:38 ` [Intel-gfx] " Greg Kroah-Hartman
2022-04-20 6:38 ` Greg Kroah-Hartman
2022-04-20 6:38 ` Greg Kroah-Hartman
2022-04-20 15:35 ` [Intel-gfx] " Ben Greear
2022-04-20 15:35 ` Ben Greear
2022-04-20 15:35 ` Ben Greear
2022-04-22 20:44 ` [Intel-gfx] " Jakub Kicinski
2022-04-22 20:44 ` Jakub Kicinski
2022-04-22 20:44 ` Jakub Kicinski
2022-04-14 13:59 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2022-04-14 13:59 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-04-14 14:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-04-14 16:49 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=Ylgv3U4HEtpk3sis@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.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.