Thanks to this thread, I checked my bluetooth and it said that there is no bt hardware. After loading the new firmware, bt showed up. So far, both work simultaneously. Great!
I tried to load them all and found that the version shown in dmesg is a total mess:
To keep an overview I symlinked on my L5 the version shown in dmesg (as “FW Version”) to the file I downloaded from the repo.
The two files named as versions 1.2.1
, 1.2.20
make the module show in dmesg the exact same “FW Version” and it’s not possible to flash one on the other. To switch between them it’s necessary to flash a third firmware first and then flash the other of the two mentioned.
BTW: where do I find the original repos with the software? I looked around and found:
- https://github.com/SiliconLabs/RS911X-nLink-OSD - but this seems to lead to a modules named rsi_91x_* and not redpine_91x
- https://www.silabs.com/documents/login/software/RS9116N%20n-link%20OSD%20Driver%20Release.zip - it’s not possible to get this without an account
- https://siliconlabs.force.com/SL_CommunitiesLogin?ec=302&startURL=%2Fs%2Flicense-agreement%3FName%3DRS9116.NB0.NL.GENR.LNX - also not accessible without an account and labled ‘Linux Proprietary Driver’
Yeap all is mess : (
- dmesg it has to be showing the combo-version of the firmware/driver, otherwise people will confused.
This is it. We have renamed the module when importing to our tree.
Just curious: do you remember the reason?
The reason is simple - there’s already a module with this name in mainline kernel (an old driver that Redpine appears to have abandoned). Eventually we would like to drop the out-of-tree driver and use the mainline one, but it needs some improvements before this could happen.
Hi @angus.ainslie the new Redpine driver version GNU.LNX.OSD.2.5.1.11 it already shipped on current kernel version or it was stopped shipping to L5.?
kernel5.18.7: dmesg still is showing:
[ 465.897234] redpine_91x: Driver Version : GNU.LNX.OSD.2.0.0.0024
We can’t ship the new Silicon Labs (redpine) driver until they fix this
Thanks you angus.ainslie
The last couple of weeks I’ve had a problem with wifi tethering. I’ve used it extensively for 6 months before that and have almost never had a problem, but probably after an upgrade a few weeks to a month ago I started getting restarts. I start tethering and after a while the wifi module seems to go offline since it’s not even displayed in the settings. After another while it comes back on again and I have to re-enable the tethering. Sometimes this happens several times in a row before it becomes “stable”. Did anyone else experience these problems? Could it be a glitch with my HKS?
Commented on the issue and hit the thumbs-up button.
Maybe someone likes to join in up-voting or giving her/his point of view on this issue?
Good initiative. I’ve upvoted your comment now.
It looks to me like the issue is that the macros claim GPL compatibility, but the source code claims a different license which does not seem compatible with the GPL (see 5.1.3 of https://www.silabs.com/about-us/legal/master-software-license-agreement ).
The licensor of this software is Silicon Laboratories Inc. Your use of this
software is governed by the terms of Silicon Labs Master Software License
Agreement (MSLA) available at
www.silabs.com/about-us/legal/master-software-license-agreement. This
software is distributed to you in Source Code format and is governed by the
sections of the MSLA applicable to Source Code.
Angus Ainslie can’t simply change the copyright and license. The only thing he can do is change the macros which declare GPL compatibility … so as to no longer assert compatibility. If that is done, AFAICT the only thing Purism can do is to revert to a previous GPL-compatible version (or convince Silicon Labs to change their license [fat chance!]. Edit: Given Section 7 of the MSLA it is possible that Silicon Labs might provide a clarification.).
And, for others who are not aware: Silicon Labs is the new owner of RedPine.
This all is more or LEDs obvious.
What I do not understand - if you’re right - why couldn’t SiliconLabs simply put the software again under GPL if they own all the rights? Could they theoretically or not? If not, why?
If their intended move has been to take a competitor and its open source software off the market to secure their market share and shut down the development of an open source stack they could just tell us.
They could. But why would they?
I’m not sure why you want to view the world as agents making tactical anti-competitive decisions in regard to FOSS. Most HW companies aren’t giving FOSS a second thought because it is such a small market.
Well, there are many answers to this, one for instance is that then they will probably get more help from the community. Anyways they just changed the license to GPL in the latest commit.
Yes, I think I see this behavior as well. And maybe others as well. I described here from a user perspective how it impacts me, and what I do to work around it.
Hope that it also will be mainlined now that there are no licensing issues.