Support of rtl8723bs
Hi Jes, hello linux-wireless, I'd like to know more about the current progress of rtl8723bs support for Linux. Googling and reading the mailing list archives found an older vendor driver https://github.com/hadess/rtl8723bs plus patches at https://github.com/lwfinger/rtl8723bs which both aren't ready for Linux according to https://github.com/hadess/rtl8723bs/issues/96 According to https://github.com/hadess/rtl8723bs/issues/98 there is a newer vendor driver from Realtek at https://github.com/anthonywong/rtl8723bs which Anthony wants to get ready for inclusion to the Ubuntu kernel. But after reading https://marc.info/?l=linux-wireless&m=146902477024130&w=2 it appears that even that newer vendor driver isn't ready for Jes's work. Anyway, as an owner of such a device, I'd like to help somehow, and be it as a guinea pig to test on my hardware. The newer vendor driver crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8-rc sources. https://github.com/anthonywong/rtl8723bs/issues/1 Kind regards, Hanno
Re: Support of rtl8723bs
On Mon, 2016-09-12 at 11:20 +0200, Hanno Zulla wrote: > Hi Jes, > hello linux-wireless, > > I'd like to know more about the current progress of rtl8723bs support > for Linux. > > Googling and reading the mailing list archives found an older vendor > driver > https://github.com/hadess/rtl8723bs This is the canonical location. > plus patches at > https://github.com/lwfinger/rtl8723bs This is an old tree. > which both aren't ready for Linux according to > https://github.com/hadess/rtl8723bs/issues/96 > > According to > https://github.com/hadess/rtl8723bs/issues/98 > > there is a newer vendor driver from Realtek at > https://github.com/anthonywong/rtl8723bs > which Anthony wants to get ready for inclusion to the Ubuntu kernel. > > But after reading > https://marc.info/?l=linux-wireless&m=146902477024130&w=2 > it appears that even that newer vendor driver isn't ready for Jes's > work. The "hadess" driver above is an older vendor driver with 2 years of cleanups, and lots of code removal: 430 files changed, 81387 insertions(+), 254812 deletions(-) Anthony's repo is just a dump of a newer version of the driver. What would be useful would be to compare the newer vendor driver with the last time the "hadess" driver was rebased (a2e5bb366f6d6c19dcab6db47b68a944256e8228) and pick out bug fixes. Anyway, as an owner of such a device, I'd like to help somehow, and be > it as a guinea pig to test on my hardware. The newer vendor driver > crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8- > rc > sources. > https://github.com/anthonywong/rtl8723bs/issues/1 I really don't care about the vendor driver. There's no way to track changes other than through code dumps. Longer term, it seems likely that improving Jes' driver is the way to go. At least there's 170k less lines of code to read in the rtl8723bs driver to get things going. Cheers
Re: Support of rtl8723bs
On 12 September 2016 at 20:23, Bastien Nocera wrote: > > On Mon, 2016-09-12 at 11:20 +0200, Hanno Zulla wrote: > > Hi Jes, > > hello linux-wireless, > > > > I'd like to know more about the current progress of rtl8723bs support > > for Linux. > > > > Googling and reading the mailing list archives found an older vendor > > driver > > https://github.com/hadess/rtl8723bs > > This is the canonical location. > > > plus patches at > > https://github.com/lwfinger/rtl8723bs > > This is an old tree. > > > which both aren't ready for Linux according to > > https://github.com/hadess/rtl8723bs/issues/96 > > > > According to > > https://github.com/hadess/rtl8723bs/issues/98 > > > > there is a newer vendor driver from Realtek at > > https://github.com/anthonywong/rtl8723bs > > which Anthony wants to get ready for inclusion to the Ubuntu kernel. > > > > But after reading > > https://marc.info/?l=linux-wireless&m=146902477024130&w=2 > > it appears that even that newer vendor driver isn't ready for Jes's > > work. > > The "hadess" driver above is an older vendor driver with 2 years of > cleanups, and lots of code removal: > 430 files changed, 81387 insertions(+), 254812 deletions(-) > > Anthony's repo is just a dump of a newer version of the driver. Indeed, the code in my git repo is simply the driver source code extracted from what was provided by the vendor. It's pushed to github in the hope that it can help anyone who works on supporting this wifi device and can serve as a reference for future development. Cheers, Anthony > > > What would be useful would be to compare the newer vendor driver with > the last time the "hadess" driver was rebased > (a2e5bb366f6d6c19dcab6db47b68a944256e8228) and pick out bug fixes. > > Anyway, as an owner of such a device, I'd like to help somehow, and > be > > it as a guinea pig to test on my hardware. The newer vendor driver > > crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8- > > rc > > sources. > > https://github.com/anthonywong/rtl8723bs/issues/1 > > I really don't care about the vendor driver. There's no way to track > changes other than through code dumps. > > Longer term, it seems likely that improving Jes' driver is the way to > go. At least there's 170k less lines of code to read in the rtl8723bs > driver to get things going. > > Cheers
Re: Support of rtl8723bs
Bastien Nocera writes: > On Mon, 2016-09-12 at 11:20 +0200, Hanno Zulla wrote: >> Hi Jes, >> hello linux-wireless, >> it as a guinea pig to test on my hardware. The newer vendor driver >> crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8- >> rc >> sources. >> https://github.com/anthonywong/rtl8723bs/issues/1 > > I really don't care about the vendor driver. There's no way to track > changes other than through code dumps. > > Longer term, it seems likely that improving Jes' driver is the way to > go. At least there's 170k less lines of code to read in the rtl8723bs > driver to get things going. Longer term I think it makes sense to add SDIO support to rtl8xxxu. The differences between the USB version and the SDIO version are rather small. That said, I have quite a lot of things on my TODO list so it is going to take some time until I can look at this. It may make sense to pull a cleaned up version of the vendor driver into staging until then if there is a desperate need for it, but otherwise any help would be appreciated :) Jes
Re: Support of rtl8723bs
On 09/12/2016 09:47 AM, Jes Sorensen wrote: Bastien Nocera writes: On Mon, 2016-09-12 at 11:20 +0200, Hanno Zulla wrote: Hi Jes, hello linux-wireless, it as a guinea pig to test on my hardware. The newer vendor driver crashed on Ubuntu' 4.4 sources and doesn't compile yet on Ubuntu 4.8- rc sources. https://github.com/anthonywong/rtl8723bs/issues/1 I really don't care about the vendor driver. There's no way to track changes other than through code dumps. Longer term, it seems likely that improving Jes' driver is the way to go. At least there's 170k less lines of code to read in the rtl8723bs driver to get things going. Longer term I think it makes sense to add SDIO support to rtl8xxxu. The differences between the USB version and the SDIO version are rather small. That said, I have quite a lot of things on my TODO list so it is going to take some time until I can look at this. It may make sense to pull a cleaned up version of the vendor driver into staging until then if there is a desperate need for it, but otherwise any help would be appreciated :) I agree with Jes that adding support for SDIO in rtl8xxxu would be a useful step. If anyone wants to help, that would be the place to start. I disagree that this driver should be dumped into staging. If one reads the various issues associated with the GitHub repo, you will see that this driver has severe problems that are unlikely to be fixed with a cleanup. The latest report is that the driver causes the loss of clock interrupts, which is not surprising given the sorry state of locking in the driver. Complicating matters is that no one outside Realtek ever sees the details of any commit. At intervals, they make a dump of their current code and release it. The differences between two such releases amounts to many thousands of lines, and finding any changes due to bug fixes is a "needle in the haystack" problem. Larry
Re: Support of rtl8723bs
Hi, > Longer term I think it makes sense to add SDIO support to rtl8xxxu. The > differences between the USB version and the SDIO version are rather > small. This is beyond my expertise, sadly. Is there a good blueprint / example of a previous case where a USB driver had SDIO support added that one might learn from? Kind regards, Hanno
Re: Support of rtl8723bs
On Mon, 2016-09-12 at 17:48 +0200, Hanno Zulla wrote: > Hi, > > > Longer term I think it makes sense to add SDIO support to rtl8xxxu. > > The > > differences between the USB version and the SDIO version are rather > > small. > > > This is beyond my expertise, sadly. > > Is there a good blueprint / example of a previous case where a USB > driver had SDIO support added that one might learn from? I don't know on top of my head, sorry. Best look in the kernel sources directly.
Re: Support of rtl8723bs
Bastien Nocera writes: > On Mon, 2016-09-12 at 17:48 +0200, Hanno Zulla wrote: >> Hi, >> >> > Longer term I think it makes sense to add SDIO support to rtl8xxxu. >> > The >> > differences between the USB version and the SDIO version are rather >> > small. >> >> >> This is beyond my expertise, sadly. >> >> Is there a good blueprint / example of a previous case where a USB >> driver had SDIO support added that one might learn from? > > I don't know on top of my head, sorry. Best look in the kernel sources > directly. The issues I am aware of is to start out changing the register access macros into function pointers and stick them all into the fileops structure. Provide a set of SDIO ones to match the USB ones. Then you will need some code to detect the device, as that part will obviously be different from the USB device detection. I know there are a few issues to look out for in the hw register init files to look out for too, that does some special casing for SDIO, but that should be limited. I am happy to point someone in the right direction on that when they get to that. Cheers, Jes
Re: Support of rtl8723bs
Hi, > The issues I am aware of is to start out changing the register access > macros into function pointers and stick them all into the fileops > structure. Provide a set of SDIO ones to match the USB ones. Then you > will need some code to detect the device, as that part will obviously be > different from the USB device detection. > > I know there are a few issues to look out for in the hw register init > files to look out for too, that does some special casing for SDIO, but > that should be limited. I am happy to point someone in the right > direction on that when they get to that. I had a brief look into the sources of other drivers implementing SDIO, but not being a kernel-dev, this is out of my league. If you decide to reprioritize your TODO-List in favour of adding SDIO sooner, I'll be gladly testing this for you on my hardware (and buy you a beer). Kind regards, Hanno
Re: Support of rtl8723bs
On 09/13/2016 02:47 AM, Hanno Zulla wrote: Hi, The issues I am aware of is to start out changing the register access macros into function pointers and stick them all into the fileops structure. Provide a set of SDIO ones to match the USB ones. Then you will need some code to detect the device, as that part will obviously be different from the USB device detection. I know there are a few issues to look out for in the hw register init files to look out for too, that does some special casing for SDIO, but that should be limited. I am happy to point someone in the right direction on that when they get to that. I had a brief look into the sources of other drivers implementing SDIO, but not being a kernel-dev, this is out of my league. If you decide to reprioritize your TODO-List in favour of adding SDIO sooner, I'll be gladly testing this for you on my hardware (and buy you a beer). I received a CherryTrail z8300 device yesterday with RTL8723BS wifi and BT. I have started making the changes that Jes suggested. Once I get something running, I will post patches here for review, and I will also make them available in Bastien's repo. I make no promises on when anything will be available. Larry
Re: Support of rtl8723bs
Hi, it was exciting to see https://marc.info/?l=linux-wireless&m=148735587909056&w=2 So please forgive me for asking about the current state of things. Kind regards, Hanno
Re: Support of rtl8723bs
On 03/29/2017 05:20 AM, Hanno Zulla wrote: Hi, it was exciting to see https://marc.info/?l=linux-wireless&m=148735587909056&w=2 So please forgive me for asking about the current state of things. I cannot divulge any details at present, but there are plans to submit a staging driver for the RTL8723BS card. Larry
Re: Support of rtl8723bs
Hi, has there been any progress on the rtl8723bs / sdio issue? There were no updates to this mailing list or the usual git repositories since this was last discussed, unless I missed the proper place to look for this. I'm sorry that I can't be more helpful with actual development, but am eager to help with testing this device. Thank you, Hanno
Re: Support of rtl8723bs
Hanno Zulla writes: > Hi, > > has there been any progress on the rtl8723bs / sdio issue? > > There were no updates to this mailing list or the usual git repositories > since this was last discussed, unless I missed the proper place to look > for this. > > I'm sorry that I can't be more helpful with actual development, but am > eager to help with testing this device. > > Thank you, > Hanno Hanno, The 8723bs project is currently in idle mode, I haven't had time to spend time on it for the last couple of months. Cheers, Jes
Re: Support of rtl8723bs
On 01/16/2017 07:25 AM, Jes Sorensen wrote: Hanno Zulla writes: Hi, has there been any progress on the rtl8723bs / sdio issue? There were no updates to this mailing list or the usual git repositories since this was last discussed, unless I missed the proper place to look for this. I'm sorry that I can't be more helpful with actual development, but am eager to help with testing this device. Thank you, Hanno Hanno, The 8723bs project is currently in idle mode, I haven't had time to spend time on it for the last couple of months. I have also been busy. Larry