Hi Ilia, > > > This param allows role switch request while accepting a new acl > > > connection. This is an enhancement to l2cap L2CAP_LM role switching > > > capability which allows requesting role switch without modification > > > to the application code. It was observed that operating as a master > > > of piconet (as oposed to scatternet config) is beneficial when > > > qos (flow_spec) guarantees are requested. > > > > <snip> > > > > > module_param(enable_le, bool, 0444); > > > MODULE_PARM_DESC(enable_le, "Enable LE support"); > > > +module_param(force_acl_master, bool, 0644); > > > +MODULE_PARM_DESC(force_acl_master, "Always try to switch to master > > role on ACL link"); > > > > using kernel module parameters is not an acceptable API/ABI for this. > It is not API/ABI, it is a way to configure a system without modifying > application code and it’s as useful as the other Bluetooth module > params. no, we use kernel parameters to on purpose not enable features that have not passed qualification yet. We do not use it for general purpose configuration. And btw. what is wrong with the setting lm to master via hciconfig? That said, I am pretty much against general purpose setting that are not really bound to any specific service/profile. The sum of profiles should define a proper policy and not some magic global setting. Otherwise you easily run into dead-lock scenarios. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
