Hi Larry, >>> I'm adding bluetooth list to the discussion. Full patch is available >>> here: >>> >>> https://patchwork.kernel.org/patch/5712591/
<snip> >>> So the wireless driver communicates with the bluetooth driver (which is >>> not in upstream) via a localhost UDP connection? >> >> I think the first order of business should be to get the Bluetooth driver >> upstream. Until that has happened this is all kinda pointless discussion. > > I agree with this; however, the last time I tried to submit a BT driver for > Realtek, I was told that this driver should use some (as yet included) > feature. I have watched the driver development, and if that feature was ever > included, it was in a form that I did not recognize. I'm sorry that this is > vague, but this happened a long time ago. if the Bluetooth side is running over USB, then it should be driven from the existing btusb.ko module with a vendor specific ->setup() callback. However nothing materialized that I could merge it. >>> I know there's a general need for something similar like this, but it >>> needs to properly discussed and designed. >> >> This is just insane. Clear NAK. >> >> Two kernel modules will not use UDP ports over the loopback interface to >> communicate with each other. > > I will work on combining the latest BT drivers from Realtek with btusb to see > if I can achieve a patch that will both work with the Realtek hardware, and > get approval from the reviewers. > > What would be an approved method of communicating between two kernel modules? > Is there some example in the kernel that I could study? We need a btcoex subsystem that both WiFi and Bluetooth can register to and communicate with. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
