Hi Andre, > > any reason why we want this separated and being under host stack control > > in the first place. Should we not always enable LE if we can support it? > > What are the reason to run an LE capable BlueZ on an LE capable dongle > > and then not enable LE? > > > > I don't know the reason why, but today LE enabling is separated and is > under host control. There is an option in main.conf (EnableLE) to > enable/disable LE. > > AFAIK, the reason we want to disable LE is qualification tests only. Also, > since LE support is under development we may not wanna have LE enabled > by default (maybe this is another reason). for that I would have used a enable_le kernel module option since it should be all triggered by the kernel anyway. > > Maybe we should just have a generic kernel mgmt features enabling > > command. One thing that I do not wanna do is to just blindly make a copy > > of HCI commands for mgmt interface. The controller abstraction for the > > mgmt interface is suppose to have a feature list so we can check what > > the kernel supports and what not. > > > > We had a little discussion here and we came up with this idea of having > new parameter to the module (e. g. enable_le) to enable/disable LE. If > the module is loaded with enable_le=y we would enable LE host support. > Once LE support is stable enough, we have enable_le=y by default. > This approach we don't need a mgmt command. See above ;) I am open for discussion on how we might solve this in a bit more generic way on let this control by the user. Mainly for qualification testing and UPF testing. However we need a clear story for LE and SSP since both are host stack driven features. 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
