Development Discussion (pinned)

[morrownr]

This issue is being established as a pinned issue for developers to discuss issues related to this repo, its future direction and various issues that may come up.

Current maintainers:

@Lucid-Duck
@Ashcal9669
@morrownr

We are seeking additional maintainers for this repo. Get involved.

This repo was established because we needed a good repo to test patches and explore ideas to improve the mt76 wireless drivers.

Hopefully this issue can serve as a fixed location to discuss development issues of interest.

@morrownr

[morrownr]

@Lucid-Duck

Since you added script check-driver.sh , I am thinking the following can be removed from script install-driver.sh ?

Please copy and post all displayed lines when reporting an issue!
Press Enter to continue...

What do you think?

I have started working on getting the word out about mt7927 needing testing. I am pointing users directly to your post that explains that they need to use a branch.

Different subject: A lot of these mt76 chips get paired with bluetooth chips. I'm pondering what it would take to add bbluetooth support to this repo so that we can test new vid/pids for bluetooth support. My mt7902 card uses a bluetooth vid/pid that is not in the kernel so I was thinking about this topic.

[Lucid-Duck]

Yes, drop the "copy and post all displayed lines / Press Enter" prompt -- predates check-driver.sh and blocks unattended installs. I'll send a PR that removes both lines and keeps the banner.

Glad mt7927 word is going out via #20. I'll keep that post updated as builds drift.

On Bluetooth: @morrownr, please, we had a nice thing going with good old Wi-Fi. Now you want to summon the eldritch Bluetooth gods? You know that Nietzsche quote "if you gaze long into an abyss, the abyss also gazes into you?" He was talking about Bluetooth…

Real answer: Let's do it. I'm game. A sibling bluetooth/ tree alongside mt76 -- btmtk + btusb pulled as _git variants the same way the mt76 modules are now, BT firmware mirrored alongside the WiFi firmware, and a companion install/check script harness. VID/PID adds still flow upstream-first to linux-bluetooth (and I can send the mt7902 one whenever you've got the lsusb output for it), but the OOT tree means users get the BT side working immediately on combo adapters where the kernel hasn't caught up. The maintenance burden is real but the BT subsystem is much smaller than mt76's surface and moves slowly enough to be tractable. I'll start scoping the tree this week.

[morrownr]

I'll send a PR that removes both lines and keeps the banner.

Merged. Thanks. Things are looking good. I will continue testing.

Glad mt7927 word is going out via #20. I'll keep that post updated as builds drift.

Good idea.

Now you want to summon the eldritch Bluetooth gods?

Okay, I am messing with the wireless gods. I get it. He he.

Let's do it. I'm game.

I think we should go through one cycle as wifi only to get the patch cycle down and then look at whether bluetooth can work. You are welcome to do some planning.

FYI: I am seeing interest in mt76 slowly increase. As word spreads, I think it can really become very useful to the community.

[Lucid-Duck]

Sounds good. I'll keep the WiFi cycle stable for now and start a low-key BT planning doc on the side so we have something to riff on when we're ready. Glad the install-driver.sh cleanup landed. Agreed on the mt76 interest curve, the issue traffic over the past few weeks tracks with what you're saying.

[morrownr]

I'm excited about this repo. I think it can help greatly with USB WiFi on Linux. Here is the current graph of unique cloners:

[morrownr]

@Lucid-Duck

Status report

The number of daily unique cloners was up to 30 as of two days ago. The trend is up. I continue to find places to mention this repo.

Today I updated firmware/LICENSE.mediatek and firmware/README.md. The license we had was dated and I think I made some improvements to firmware/README.md. Overall, the firmware directory appears to be in really good shape and we are still waiting on the drop of a new mt7927 bluetooth firmware file.

I discovered that the bluetooth support for the mt7902 chip requres patches to btusb.c and btmtk.c. Those patches evidently went into kernel 7.1. I use Ubuntu and their mainline to test mt7902 and the Ubuntu mainline is broken. I have other priorities so the issue of a new vid.pid can wait. Rome wasn't built in a day.

I am going to slowly start doing a detailed analysis of the scripts. Things seem to be working well.

I expect the patches that are approved for 7.2 will start flowing into openwrt/mt76 within the next two weeks. It will be good to work our way through the first round of updates.

If there is anything that you think that I should be looking at, let me know.

[morrownr]

@Lucid-Duck

I did some housekeeping in issues today.

I checked and Unique Clones is up to 152 over the last 2 weeks so interest is increasing.

I am working on cherry-picking new accepted patches.

[morrownr]

@Lucid-Duck

I think I learned a lesson about cherry-picking the new patches: go slow and...

do a quick compile after each patch to make sure things aren't broken. Thanks for the help on what was broken.

[morrownr]

@Lucid-Duck

Short message for you after you return.

Subject: Cherry Picking Patches for kernel 7.2

Felix main repo is:

https://github.com/nbd168/wireless/commits/mt76/drivers/net/wireless/mediatek/mt76

The repo we use to cherry pick is:

https://github.com/openwrt/mt76/commits/master/

My point: There seem to be around 11 patches in Felix' repo that are not in openwrt/mt76. Three of those patches are where you and Sean worked the txpower issue. My assumption is that Felix just came to a good place to pause but will merge the other patches in openwrt/mt76 before 7.2. This message is just to let you know that I am watching and will continue cherry picking once the additional patches are in openwrt/mt76.

Another issue that is related: in addition to the patches that we create, other devs will submit PRs. It goes without saying that we will need to review any PRs that are submitted but the issue of using branches needs to be considered. I lean toward merging them into main with the option of reverting. We can discuss this once you have time. No need to reply to this message for now.

[Lucid-Duck]

@morrownr caught up, two things:

Cherry-picks: same read as you. The 11 in Felix's tree that aren't in openwrt/mt76 yet check out, and the 3 txpower ones are Sean's cache txpower_cur rework that we're on. They're in Felix's tree already, just not down to openwrt (our source) yet. Plan's good: watch openwrt and pull them when they land.

Branches vs main: I'd split by risk rather than one rule:

• Upstream-accepted patches (our cherry-picks, or a PR backporting something already merged): straight to main, vetted and low-risk.
• Novel patches that aren't verified yet: a branch until they've got real evidence, then main. Same as we already do for mt7927.

The catch with main-with-revert as the blanket rule: a revert only helps if we catch the regression, and something unverified like the mt7925 PR in #18 (no stock-vs-patched A/B yet) could sit broken on main until someone trips over it. A branch keeps main trustworthy and testing opt-in until the numbers are in.

So the mt7925 PR goes to a branch until the numbers show up; routine stuff to main.

[morrownr]

@Lucid-Duck

The 11 in Felix's tree that aren't in openwrt/mt76 yet check out...

I saw that Felix sent the mt76 PR to Johannes earlier today so I checked again. It appears we actually have 21 new patches to cherry pick. I will start working on them this afternoon unless you see a reason to hold off.

Do you know if that mac80211 patch you were working on made it through Johannes?

Branches vs main: I'd split by risk rather than one rule:...

I'm good with this. I will handle the approved, low risk, patches and the rest are your call.