On Wed, Jan 11, 2017 at 09:20:54AM -0800, Tadeusz Struk wrote: > Hi Leon, > On 01/10/2017 11:12 PM, Leon Romanovsky wrote: > > Can't you recognize such device at the initialization phase? > > Yes, this is exactly what it does. It checks the device GUID > and reorders the ports during insmod. Why don't your firmware report the need to revert the ports? > > > This is definitely specific HW implementation bug/issue/limitation. > > Correct. As the commit message says this is to fix a HW issue. > > > > > I always had an impression that module parameters are rarely beneficial > > in upstream kernel for driver modules and adding them for new driver > > code should be explicitly prohibited in CodingStyle guide. > > > > You are adding new module parameter which will be with us forever to fix > > special HW bug/implementation in some legacy installations. It will be > > insane to add such thing to upstream kernel, errata and out-of-tree > > implementations are best places for such things. > > Agree, but the reality is that there are 5505 $(git grep module_param drivers/ | wc -l) > module parameters in the kernel already, and even mlx4 and mlx5 drivers use them. Regarding mlx4/mlx5, I'm not proud of that code and if it was dependent on me, I would remove it without thinking twice. Previous copy-paste can not be an excuse to add another module parameter. > I really considered every other possible solution, but module parameter is the > only possible way to do such things during insmod. This is another problem with the module parameters - assumption that everyone is running modules, but this is simply incorrect, most of my smoke tests are performed with monolithic kernel. > Thanks, > -- > Tadeusz
Attachment:
signature.asc
Description: PGP signature
