| Message ID | 20220610123627.1339985-1-cezary.rojewski@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Intel: haswell and broadwell boards update | expand |
On 2022-06-10 2:36 PM, Cezary Rojewski wrote: > A number of patches improving overall quality and readability of > haswell.c and broadwell.c source files found in sound/soc/intel/boards. > Both files are first renamed and only then actual changes are being > incrementally added. The respective names are: hsw_rt5640 and bdw_rt286 > to match the pattern found in more recent boards. > > Most patches bring no functional change - the more impactful patches at > are placed the end: > > Refactor of suspend/resume flow for the bdw_rt286 board by dropping > dev->remove() in favour of card->remove() and adjust jack handling to > reduce code size slightly by implementing card_set_jack(). > > The last patch is removing of FE DAI ops. Given the existence of > platform FE DAI capabilities (either static declaration or through > topology file), this code is redundant. Hello, While this patchset reorganizes and rewords code of two boards in question, module (kernel module) names are unchanged. Currently those two are: - snd_soc_sst_haswell.ko - snd_soc_sst_broadwell.ko My question is: Is it viable to reword these two? Both modules accept no custom parameters, perhaps *dyndbg* is the only possibility so the impact is reduced. Regards, Czarek
On 6/10/22 12:33, Cezary Rojewski wrote: > On 2022-06-10 2:36 PM, Cezary Rojewski wrote: >> A number of patches improving overall quality and readability of >> haswell.c and broadwell.c source files found in sound/soc/intel/boards. >> Both files are first renamed and only then actual changes are being >> incrementally added. The respective names are: hsw_rt5640 and bdw_rt286 >> to match the pattern found in more recent boards. >> >> Most patches bring no functional change - the more impactful patches at >> are placed the end: >> >> Refactor of suspend/resume flow for the bdw_rt286 board by dropping >> dev->remove() in favour of card->remove() and adjust jack handling to >> reduce code size slightly by implementing card_set_jack(). >> >> The last patch is removing of FE DAI ops. Given the existence of >> platform FE DAI capabilities (either static declaration or through >> topology file), this code is redundant. > > > Hello, > > While this patchset reorganizes and rewords code of two boards in > question, module (kernel module) names are unchanged. Currently those > two are: > > - snd_soc_sst_haswell.ko > - snd_soc_sst_broadwell.ko > > My question is: Is it viable to reword these two? > > Both modules accept no custom parameters, perhaps *dyndbg* is the only > possibility so the impact is reduced. Thanks for asking the question. I have no objection to the driver name change and haswell is not used in commercial products outside of Intel. You have a point that most of the machine driver module names make limited sense in hindsight, but it's better to leave them as is. Changing them will increase confusion IMHO. We have scripts to remove/re-insert modules and every time we add a name change we break the test suite. This happened when we changed all the PCI names, it wasn't pretty. See e.g. all the 'obsolete' references in those scripts to keep them working across kernel versions. https://github.com/thesofproject/sof-test/blob/main/tools/kmod/sof_remove.sh#L134 we also enable dyndbg with /etc/modprobe.d/sof-dyndbg.conf deployed on test devices, if we change module names it gives everyone involved in CI/testing more work. And last if you Google a bit you'll see references in a couple of wikis and bug reports to modprobe snd-soc-sst-broadwell, so if you change the module name you make the information obsolete.
On 2022-06-10 8:48 PM, Pierre-Louis Bossart wrote: > On 6/10/22 12:33, Cezary Rojewski wrote: ... >> Hello, >> >> While this patchset reorganizes and rewords code of two boards in >> question, module (kernel module) names are unchanged. Currently those >> two are: >> >> - snd_soc_sst_haswell.ko >> - snd_soc_sst_broadwell.ko >> >> My question is: Is it viable to reword these two? >> >> Both modules accept no custom parameters, perhaps *dyndbg* is the only >> possibility so the impact is reduced. > > Thanks for asking the question. > > I have no objection to the driver name change and haswell is not used in > commercial products outside of Intel. (save #1) > You have a point that most of the machine driver module names make > limited sense in hindsight, but it's better to leave them as is. > Changing them will increase confusion IMHO. (save #2) > We have scripts to remove/re-insert modules and every time we add a name > change we break the test suite. This happened when we changed all the > PCI names, it wasn't pretty. See e.g. all the 'obsolete' references in > those scripts to keep them working across kernel versions. > > https://github.com/thesofproject/sof-test/blob/main/tools/kmod/sof_remove.sh#L134 > > we also enable dyndbg with /etc/modprobe.d/sof-dyndbg.conf deployed on > test devices, if we change module names it gives everyone involved in > CI/testing more work. > > And last if you Google a bit you'll see references in a couple of wikis > and bug reports to modprobe snd-soc-sst-broadwell, so if you change the > module name you make the information obsolete. Hello, Very much appreciate the input. I admit that at first #1 made me think it's OK to change the name for the two but the later portion of the message (#2 and onward) made me think otherwise. Decided to not that change part of current series in v2, will send module renames as separate two patches either today or later this week - if snd_soc_sst_broadwell rename is not welcome, it won't get merged. Regards, Czarek