| Message ID | 20220414123033.654198-1-jani.nikula@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | add support for enum module parameters | expand |
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? thanks, greg k-h
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. 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. BR, Jani.
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?
+ linux-wireless, netdev Jani Nikula <jani.nikula@intel.com> writes: > 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. > > 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. Wireless drivers would also desperately need to pass device specific parameters at (or before) probe time. And not only debug parameters but also configuration parameters, for example firmware memory allocations schemes (optimise for features vs number of clients etc) and whatnot. Any ideas how to implement that? Is there any prior work for anything like this? This is pretty hard limiting usability of upstream wireless drivers and I really want to find a proper solution.
On Wed, Apr 20, 2022 at 08:13:47AM +0300, Kalle Valo wrote: > + linux-wireless, netdev > > Jani Nikula <jani.nikula@intel.com> writes: > > > 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. > > > > 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. > > Wireless drivers would also desperately need to pass device specific > parameters at (or before) probe time. And not only debug parameters but > also configuration parameters, for example firmware memory allocations > schemes (optimise for features vs number of clients etc) and whatnot. > > Any ideas how to implement that? Is there any prior work for anything > like this? This is pretty hard limiting usability of upstream wireless > drivers and I really want to find a proper solution. Again, configfs? That should be what that subsystem was designed for... thanks, greg k-h
On 4/19/22 10:13 PM, Kalle Valo wrote: > + linux-wireless, netdev > > Jani Nikula <jani.nikula@intel.com> writes: > >> 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. >> >> 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. > > Wireless drivers would also desperately need to pass device specific > parameters at (or before) probe time. And not only debug parameters but > also configuration parameters, for example firmware memory allocations > schemes (optimise for features vs number of clients etc) and whatnot. > > Any ideas how to implement that? Is there any prior work for anything > like this? This is pretty hard limiting usability of upstream wireless > drivers and I really want to find a proper solution. I used a 'fwcfg' file that is loaded during ath10k initialization, from same general location as the firmware. Name is with pci-id or other unique identifier like board files sometimes are named, and you get per radio configuration at device load time. I'm sure I posted a patch on this some years ago, but I can point you to my current tree if you prefer. Thanks, Ben
On Wed, 20 Apr 2022 08:13:47 +0300 Kalle Valo wrote: > Wireless drivers would also desperately need to pass device specific > parameters at (or before) probe time. And not only debug parameters but > also configuration parameters, for example firmware memory allocations > schemes (optimise for features vs number of clients etc) and whatnot. > > Any ideas how to implement that? Is there any prior work for anything > like this? This is pretty hard limiting usability of upstream wireless > drivers and I really want to find a proper solution. In netdev we have devlink which is used for all sort of device configuration. devlink-resource sounds like what you need, but it'd have to be extended to support configuration which requires reload/re-probe. Currently only devlink-params support that but params were a mistake so don't use that.