Hi, On Sun, Aug 3, 2025 at 10:48 PM manas gupta <manasgupta3131@xxxxxxxxx> wrote: > > hi all, > > I'm Manas, a GSoC 2025 contributor @BeagleBoard org working on the > project upstream wpanusb bcferial as part of my efforts I am aiming to > upstream these drivers to simplify on-going support. > > I'm writing to this list to introduce the project, share the progress > made so far, and respectfully ask for your guidance on the best path > forward for upstreaming the drivers. > > The drivers have had multiple functional gaps before they can be > upstreamed, over the past few weeks I have been working on quite a few > of them. > > To address the first major gap, I have spent the initial phase of the > project implementing the missing driver operations. The driver now has > functional implementations for: > set_txpower(), set_lbt(), set_cca_mode(), set_cca_ed_level(), > set_csma_params(), set_frame_retries(), set_promiscuous_mode(), > Enhanced parameter validation per IEEE 802.15.4 standard, Improved > error handling and debug logging and worked on the zephyr application. > Currently I am working on generic aspects which are hardcoded and > Dynamic device capabilities. > >Stefan's notes mentioned heavy work on management frames and scanning. Are there any new driver ops or architectural changes on the horizon that I should be aware of and plan for in this driver? > > I am eager to contribute and follow the best practices of the kernel > community. Any feedback on the work so far, patch submission > strategies and guidance would be incredibly valuable. > > Based on community feedback, I plan to: > 1. Address any architectural concerns raised SoftMAC vs HardMAC, look at timing critical "things". > 2. Implement suggested improvements make atusb more generic? > 3. Prepare formal patch series for submission just send patches marked as RFC. > 4. Coordinate hardware testing with BeagleConnect devices if its used a serial connection over usb? (You don't need to do that) maybe virtual dummy that can be connected with hwsim? > 5. Document any remaining limitations > Use documentation/ in the kernel source, but be warned we don't update them a lot... > I would greatly appreciate any guidance on: > - Code review and architectural feedback > - Upstreaming process and requirements Look in "documentation/". > - Testing strategies and requirements If you say you tested it and I don't have the hardware I need to trust you... however the mentioned above to have a way to connect it to hwsim it would be nice. We make a difference between HardMAC and SoftMAC. It depends how much MAC logic (especially MLME-ops are done on the firmware of the transceiver) although SoftMAC also does some MAC functionality that is necessarily to run on the firmware because of timing critical infrastructure, e.g. AACK/ARET handling. Given the fact that we support SoftMAC you probably want to have a SoftMAC firmware/driver. I think it is best to look at several SoftMAC transceivers, also on atusb, atusb is very specific to the current transceiver which is soldered on the transceiver stick. You should be able to make some "generic" layer on top to do something that your firmware supports the specific transceiver but the driver on the Linux side stays the same. Bluetooth has HCI which is part of their stack (one reason why it is successful) but wpan IEEE standard doesn't do such specification, you are on your own here to establish an open one which might others will follow or not. - Alex
