I saw some new 2.0 tags for your repositories! I’m probably just jumping the gun here but any plan to release the 2.0 patches for MM rpi-linux repo or would the 1.17.X version of the kernel work with the 2.0 version of the other repos?
There was a minor issue when pushing these up the other day. Should be resolved now 
(An announcement will be going out tomorrow)
2 Likes
I also noticed the openwrt fork for the HaLowLinks have been updated from 23.05 up to 24.10, but that they still point to the 1.17.x drivers, is that right? Do you know roughly how long it will be before the 2.x drivers land there too?
That’s correct for the 2.12.6 release of OpenWrt.
The next OpenWrt release is in flight. Will be going out on GitHub shortly.
2 Likes
Sounds good, thanks a lot!
Another question regarding the 2.0.x driver releases:
With the split of repositories for the mm6108 and mm8108 how do you expect us to support firmware images supporting both devices? This makes things difficult for your users.
There are differences between the morse_driver repos and the hostap repos. The morse-firmware releases are on the same gitsha which makes sense as firmware files are per chip.
Can the drivers be named differently and have different chip bindings so as to coexist on the same rootfs? I know in my case we have a SDIO based mm6108 and a USB based mm8108 device so I’ll look at renaming the drivers to a chip level name and building the older for SDIO only and the newer for USB only but this doesn’t help hostap which does have a few differences between the released versions.
I’m probably not the right person to comment @tharvey, but yes, exactly how to manage this is a topic of internal discussion
The rationale for the split is to separate the MM6108 and MM8108 release cycles, as they have different testing processes. As you point out, this is a bit annoying since they use the ‘same’ driver and support packages with some subtle changes.
In practice, it’s likely to be safe to smoosh the hostapd releases together, but they haven’t been through our validation cycle, so it’s at your own risk. If you’re feeling very risky you can even trying smooshing the drivers together (more likely to cause an issue).
@james.haggerty , perhaps a better question to ask then is for you to lay out your schedule for mainline submission of your driver and your path to up-streaming your patches to hostap. I would have thought you would have at least sent a driver to the linux-wireless mailing list by this point in time.
The mainline effort should be treated separately to the existing driver release cycles. We expect a long development cycle on the upstream driver before it would serve as a functional replacement for customers wanting the majority of features.
That said, updates:
-
The upstream driver was accepted into linux-wireless yesterday. See git.kernel.org
-
As per driver submission guidelines, the upstream driver required a large number of features to be gutted to limit review surface area. At this stage, AP + STA only in US channels. Also MM8108 only - the split in the drivers had to happen for upstream as well.
-
hostap patches are currently an RFC waiting for comment: hostap - patchwork
-
We have to rework a license for the firmware binaries to land into linux-firmware.
-
A non-trivial amount of work is required to expand the regulatory support of Linux for S1G, which we are investigating now.
@james.haggerty , that is great news! Congratulations to your team - it’s no small effort to get a wireless driver upstream!
Regarding the driver split: Looking at the drivers it seems you didn’t change the USB product ID between chips - does the bcdDevice at least differ or anything else you can use one of the other USB_DEVICE_* macros to bind to?
It looks to me like the mm8108 releases of hostapd/wpa_supplicant/morse_cli will work fine on the mm6108 - is that true?
MM6108 doesn’t support USB, so I’m not sure what you’re referring to re the USB product id.
Re using the MM6108/MM8108 releases on the ‘other’ chip, to clarify what I was saying before:
- they’re currently built off the same codebase internally
- BUT the point at which the release is forked may be different, and the subsequent patch releases will pull in different commits
- they are tested and validated independently
However, there should be nothing (at the moment) in any of the packages (including morse_driver) which is incompatible/wrong, it’s just that they just haven’t been tested with the other chip and may contain obvious/subtle bugs. This is why if you wanted to subsequently remerge these packages by pulling any missing commits from one to the other it should work, but we can offer no guarantees. i.e. it’s on you to test that the behaviour meets your requirements.
NB the only thing that could completely break is if the firmware version is incompatible with the driver (e.g. you may have this if you use the mm6108 driver with mm8108 and the mm8108 firmware had a subsequent version bump). There is a compatibility check on load, so this should be obvious, and could be resolved by pulling the necessary commits across.
BTW, you should be congratulating Arien not me 
(he’s our open source/community person, and he’s made this happen - I’m just a company random who likes posting on forums, probably because I’m nostalgic for my lost youth)
@james.haggerty, thanks for the explanation. I spent more time looking at diffs and indeed there are only a couple of things the mm6108 driver has that would need to be merged back to the mm8108 driver for my needs.
However, an easier path for me looks to be to just change the mm6108 driver name so the two can co-exist as we only use mm8108 for usb and mm6108 for sdio. That leaves me with a rather simple patch to only the mm6108 driver that is very portable for newer releases.
@ajudge congrats to you and your team getting the mm81xx driver upstream!