(Sorry if anything's a bit slow here. I don't really have time to write out full proposals myself.) On Fri, Oct 30, 2020 at 3:30 AM Tsuchiya Yuto <kitakar@xxxxxxxxx> wrote: > Let me know if splitting this patch like this works. 1) The first patch > is to add this module parameter but don't change the default behavior. That *could* be OK with me, although it's already been said that there are many people who dislike extra module parameters. I also don't see why this needs to be a module parameter at all. If you do #2 right, you don't really need this, as there are already several standard ways of doing this (e.g., via Kconfig, or via nl80211 on a per-device basis). > 2) The second patch is to change the parameter value depending on the > DMI matching or something so that it doesn't break the existing users. Point 2 sounds good, and this is the key point. Note that you can do point 2 without making it a module parameter. Just keep a flag in the driver-private structures. > But what I want to say here as well is that, if the firmware can be fixed, > we don't need a patch like this. Sure. That's also where we don't necessarily need more ways to control this from user space (e.g., module parameters), but just better detection of currently broken systems (in the driver). And if firmware ever gets fixed, we can undo the "broken device" detection. Brian
