RE: Two rtlwifi drivers?
> -Original Message- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Thursday, October 12, 2017 6:35 PM > To: Kalle Valo > Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick Joarder; > de...@driverdev.osuosl.org; linux-wirel...@vger.kernel.org; > kernel-janit...@vger.kernel.org > Subject: Re: Two rtlwifi drivers? > > On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote: > > > So what to do? Any ideas? What makes your life easier? You can just > > > ignore the staging tree, as it should not affect your portion of the > > > kernel at all, right? > > > > Yes, I automatically ignore anything staging related. But the problem is > > that we now have two drivers with the same name and people don't always > > remember to prefix the patch with "staging: ". So on a bad day I might > > accidentally apply a patch which was meant for your tree. Of course I > > immediately revert it as soon as I, or someone else, catches that but > > annoying still. > > It doesn't bother me if you apply staging patches, I can handle the > merge issues :) > > > I think we have two options here: > > > > 1) We set a deadline (like 12 months or something) for the > >drivers/staging/rtlwifi and after that you refuse to take any patches > >for it. Hopefully this makes it clear for everyone that this fork is > >just temporary. I think Larry is trying to do this, which is great. > > Fine with me, if Larry is ok with it. > > > 2) We move the whole rtlwifi driver to staging. A very bad option but > >still better than forking the drivers. > > Ick, I don't want that to have to happen, that would not be good for the > users of other devices that the "real" rtlwifi driver supports. > Hi Larry, Kalle and Gerg, This is Realtek engineer, PK. I appreciate your support to submit, review and merge patch. Since I'm a Linux newbie, I'll describe the situation of rtlwifi and need your suggestions. 1) New modules in rtlwifi We add two modules named phydm and halmac, when adding rtl8822be in staging. The phydm is BB/RF related module containing the parameters and APIs of BB/RF, and a dynamic mechanism to adapt to different field environment. The halmac consists of MAC APIs. The two modules are used by many OSs, so '#ifdef', CamelCase and so on are existing in original files. Hence, we convert them to Linux form by script, but it's not perfect. Do you have suggestion to deal with this problem? 2) The rtlwifi in staging In staging, the module phydm v13 contains bugs, so I want to upgrade to v21 (Realtek internal version number). This upgrade contains a big patch that the difference between v13 and v21, and there are 40+ patches to support this upgrade. I have three options, and I want to know which one is prefer. 2.1) apply 40+ patches to both staging and wireless tree, and apply the big patch to staging only. After reviewing, we move the module to wireless tree. 2.2) apply 40+ patches to wireless tree, and apply a single bigger patch containing 40+ patches and the big patch to staging. I think this can be seen as a new driver in staging. After reviewing, we move the module to wireless tree. 2.3) don't apply anything to staging. Just apply 40+ patches and add phydm v21 to wireless. 3) Coming drivers -- rtl8723de and rtl8821ce We're developing the two drivers, and rtl8723de and rtl8821ce will be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on rtl8822be that in staging now, so the line of code will be fewer. The new files will be a new IC folder and IC supported files of three modules that btcoexist, phydm and halmac. Could I submit them to wirless tree when they're ready? 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I plan to fix them after rtl8723de and rtl8821ce. Because the drivers are developing, the changes will make us hard to integrate. However, I don't have plan to process the magic numbers in the module phydm, because the most of BB/RF registers contain many functions. And it doesn't have a register name but a bit field name instead. Our BB team guys say the use of enumeration or defined name will be unreadable, and the name is meaningless for most people. Many Linux users ask Larry about the new drivers, and Realtek will provide drivers and try to submit them by myself. I hope the Linux users can yield the drivers as soon as I can. On the way, I'll attend netdev workshop in Korea, so we can meet there if you attend too. PK ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
答复: [PATCH] staging: rtsx: Add support for RTS5260
> On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote: > > On Fri, 13 Oct 2017, Greg KH wrote: > > > > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the definitions of some internal > > > > registers and workflow have to be modified and are different from > > > > its predecessors and OCP function is added for RTS5260. > > > > So we need this patch to ensure RTS5260 can work. > > > > > > > > Signed-off-by: Rui Feng > > > > > > Your from and signed-off-by name does not match :( > > > > > > > --- > > > > drivers/mfd/Makefile | 4 + > > > > drivers/mfd/rtsx_pcr.c| 127 ++- > > > > drivers/mfd/rtsx_pcr.h| 12 + > > > > drivers/staging/Kconfig | 2 + > > > > drivers/staging/rts5260/Kconfig | 6 + > > > > drivers/staging/rts5260/rts5260.c | 748 > > > > ++ > > > > drivers/staging/rts5260/rts5260.h | 45 +++ > > > > include/linux/mfd/rtsx_pci.h | 234 +++- > > > > > > I do not see a reason why this is a staging driver. Where is the > > > TODO file listing what needs to be done to get it out of staging? > > > Why can it not just go into the "real" part of the kernel? > > > > It's not a staging driver. Rui's focus appears to be to have this > > driver accepted into Mainline by hook or by crock. He's tried MFD, > > Misc and now Staging! > > Yeah, I've watched it too :) > > > Background: > > > > There are a number of drivers in this family which currently reside in > > MFD. These were accepted before my time. After a recent review I've > > made the decision that these aren't MFD drivers at all. > > > > MFD drivers are ones which aid in registering and setting up shared > > resources for sub-devices which reside on the same piece of silicon. > > This driver does basically none of that. Instead it *is* the (what we > > describe above as) sub-device. It does everything. > > I agree with your assessment. > > > In the absence of a subsystem which covers this type of device, I > > suggested Misk as a good location to place these drivers. > > What type of device is this thing? I can't seem to figure that out. If we > can > determine that, then we can find the proper place for it in the kernel. > > Rui, what does this hardware do? What is the interface between the > hardware and userspace that this driver is creating? > This driver is a pcie driver, it bridge mmc subsystem and memstick subsystem, and it does not deal with userspace. > thanks, > > greg k-h > > --Please consider the environment before printing this e-mail. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Two rtlwifi drivers?
Hi Just my two cents, :) Am 16.10.2017 um 04:41 schrieb Pkshih: > > >> -Original Message- >> From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >> Sent: Thursday, October 12, 2017 6:35 PM >> To: Kalle Valo >> Cc: Larry Finger; Dan Carpenter; Pkshih; 莊彥宣; Johannes Berg; Souptick >> Joarder; >> de...@driverdev.osuosl.org; linux-wirel...@vger.kernel.org; >> kernel-janit...@vger.kernel.org >> Subject: Re: Two rtlwifi drivers? >> >> On Thu, Oct 12, 2017 at 11:38:06AM +0300, Kalle Valo wrote: So what to do? Any ideas? What makes your life easier? You can just ignore the staging tree, as it should not affect your portion of the kernel at all, right? >>> >>> Yes, I automatically ignore anything staging related. But the problem is >>> that we now have two drivers with the same name and people don't always >>> remember to prefix the patch with "staging: ". So on a bad day I might >>> accidentally apply a patch which was meant for your tree. Of course I >>> immediately revert it as soon as I, or someone else, catches that but >>> annoying still. >> >> It doesn't bother me if you apply staging patches, I can handle the >> merge issues :) >> >>> I think we have two options here: >>> >>> 1) We set a deadline (like 12 months or something) for the >>>drivers/staging/rtlwifi and after that you refuse to take any patches >>>for it. Hopefully this makes it clear for everyone that this fork is >>>just temporary. I think Larry is trying to do this, which is great. >> >> Fine with me, if Larry is ok with it. >> >>> 2) We move the whole rtlwifi driver to staging. A very bad option but >>>still better than forking the drivers. >> >> Ick, I don't want that to have to happen, that would not be good for the >> users of other devices that the "real" rtlwifi driver supports. >> > > Hi Larry, Kalle and Gerg, > > This is Realtek engineer, PK. I appreciate your support to submit, review > and merge patch. Since I'm a Linux newbie, I'll describe the situation of > rtlwifi and need your suggestions. > > > 1) New modules in rtlwifi >We add two modules named phydm and halmac, when adding rtl8822be in >staging. The phydm is BB/RF related module containing the parameters >and APIs of BB/RF, and a dynamic mechanism to adapt to different >field environment. The halmac consists of MAC APIs. >The two modules are used by many OSs, so '#ifdef', CamelCase and >so on are existing in original files. Hence, we convert them to Linux >form by script, but it's not perfect. Do you have suggestion to deal >with this problem? > > > 2) The rtlwifi in staging >In staging, the module phydm v13 contains bugs, so I want to upgrade >to v21 (Realtek internal version number). This upgrade contains a >big patch that the difference between v13 and v21, and there are >40+ patches to support this upgrade. I have three options, and >I want to know which one is prefer. > > 2.1) apply 40+ patches to both staging and wireless tree, and apply > the big patch to staging only. After reviewing, we move the module > to wireless tree. > > 2.2) apply 40+ patches to wireless tree, and apply a single bigger > patch containing 40+ patches and the big patch to staging. I think > this can be seen as a new driver in staging. After reviewing, > we move the module to wireless tree. > > 2.3) don't apply anything to staging. Just apply 40+ patches and add > phydm v21 to wireless. > > > 3) Coming drivers -- rtl8723de and rtl8821ce >We're developing the two drivers, and rtl8723de and rtl8821ce will >be ready on 2017Q4 and 2018Q1 respectively. The drivers are based on >rtl8822be that in staging now, so the line of code will be fewer. >The new files will be a new IC folder and IC supported files of >three modules that btcoexist, phydm and halmac. Could I submit >them to wirless tree when they're ready? > > > 4) As Kalle mentioned, rtlwifi contains many magic numbers, and I >plan to fix them after rtl8723de and rtl8821ce. Because the drivers >are developing, the changes will make us hard to integrate. However, >I don't have plan to process the magic numbers in the module phydm, >because the most of BB/RF registers contain many functions. And >it doesn't have a register name but a bit field name instead. >Our BB team guys say the use of enumeration or defined name will >be unreadable, and the name is meaningless for most people. Experience with ath9k driver showed, that development was kind of balanced between two groups, QCA and Community (Other companies, researches, education and so on.). Saying: "you will not understand it any way" is nor really helpful :) Please don't repeat bad experience of Broadcom. > Many Linux users ask Larry about the new drivers, and Realtek will > provide drivers and try to submit them by myself. I hope the Linux > users can yield the drivers as soon as I c
