Hi Larry, >>>>> We want to share some information between wifi driver and bt driver, what rules do you recommend for the following situation ? >>>>> 1. at system startup, bluetooth driver want to read some information (eg antenna settings) that generated by wifi , shall we use files or /proc/ information? >>>>> 2. when user is using Bluetooth, bt driver may notify wifi driver to perform better, shall we use socket to communication? >>>> >>>> this is the Bluetooth subsystem communicating with the WiFi subsystem (cfg80211) and vice versa, then this is happening inside the kernel. I do not see any need to even try to go via userspace at all. So neither /proc and no sockets for this. >>> >>> I agree. But can we give more specific advice on how to do this inside >>> the kernel? >>> i.e. should they create a new driver under drivers/misc which exposes >>> a shared API via EXPORT_SYMBOL? >> >> I was actually thinking about creating a rfres subsystem where each radio subsystem can register their antenna and channel information. That why WiFi does not depend on Bluetooth or that Bluetooth depend on WiFi. This cross dependency is something I like to avoid. >> >> And with rfres subsystem in place, each subsystem could also register for notification and adapt its radio usage if possible. Keep in mind that we support multiple Bluetooth and WiFi cards in the system. So this all needs to be fully generic. >> >>> The other option for Realtek to consider is to do this in >>> hardware/firmware. I already saw that the btcoexist driver knows >>> exactly when the wifi and BT start and finish scanning, so there is >>> clearly already an information-passing mechanism between the two >>> interfaces. I wonder if an updated firmware could extend that to >>> include the new information that you wish to additionally transfer. >> >> That is another option and a lot of companies have chosen to do this. If this is a card that has WiFi and Bluetooth on the same hardware, then normally an internal bus exists for communicating coexistence information out-of-band. That is what we are expecting in a lot of cases to happen when looking at platforms. >> >> Of course rfres will be hardly do a better job then the internal communication between the WiFi and Bluetooth parts on the same chip. It can only help when the two pieces are independent or when you have more than one of each installed. > > I do not know much about the internal structure of the Realtek devices, and I have no idea if the two parts can communicate over an internal bus. For that reason, I have added Shaofu, the lead engineer on the PCIe wifi driver. > > Is there a time frame for rfres? Although it might not do a better job in all cases, its generality will be useful. there is no timeframe on rfres. It is something we clearly want, but I have not yet started working on it. 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
