* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir [not found] <1349400892-25315-1-git-send-email-xiong@qca.qualcomm.com> @ 2012-10-08 22:25 ` Luis R. Rodriguez [not found] ` <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Luis R. Rodriguez @ 2012-10-08 22:25 UTC (permalink / raw) To: xiong Cc: mcgrof, backports, nic-devel, Ren Cloud, Greg Kroah-Hartman, linux-kernel, netdev, linux-wireless, qca_vkondrat On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote: > From: xiong <xiong@qca.qualcomm.com> > > 1. support new device id (0x10A0/0x10A1). > 2. add DEBUG_FS interface for diag/swoi functions. > > Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com> > Signed-off-by: xiong <xiong@qca.qualcomm.com> Xiong, -- Vladimir, just a heads up -- this applies to you as well for the 802.11ad wil6210 driver -- Greg, some review on your preference on this would be appreciated The original alx crap patch was added into compat-wireless on the linux-3.5.y branch. Its been two kernel releases and alx is not yet upstream and users can only get alx via compat-drivers (technically compat-wireless as that was pre v3.7). v3.7 would be the *third* release in which this would happen... This is unfair to users and consumers of the Linux kernel and derails expectations and our arrangements for Linux kernel development. I realize that the goal was to get alx upstream ASAP but regardless of what the reason is, its not yet upstream. If you cannot work on alx on a timely manner to get upstream then please submit the driver to the staging area of the Linux kernel that Greg maintains so that other developers who may be able to help can submit patches to help you. Under staging your driver should be accepted so long as it compiles. I will update the documentation for crap/ patches for compat-drivers to make it clear now that crap/ patches can be used for adding components / pieces of code not yet ready for upstream but as far as full new drivers are concerned you only get one kernel release cycle for it to linger on crap/ under compat-drivers, if you haven't addressed upstreaming yet then it should go to drivers/staging/. That is crap/ should only be used as a shortcut because users exist that can use the driver but you *do* have a team properly resourced to address upstreaming properly in a timely manner. Linus should soon release v3.7-rc1 and new drivers are allowed to be merged during the RC cycles, as such my recommendation is instead of getting users to consume alx only through compat-drivers you now submit alx into staging to Greg in hopes that we can get it into v3.7-rcX some time, and at that time we can remove the crap/ patch from compat-drivers. Users should be able to consume new drivers through kernel.org and compat-drivers should only provide the framework for backporting and also categorizing quick fixes. It should not be used for ongoing updates for new drivers that users need. We must draw the line with crap/ patches somewhere. I'll then take this patch for now but do expect you to get alx into either staging or proper upstream for the v3.7-rcX. I welcome feedback from other folks on the proposed arrangement for crap/ patches for compat-drivers. https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers/additional-patches#crap_patches Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir [not found] ` <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2012-10-09 0:42 ` Greg Kroah-Hartman 2012-10-09 1:14 ` Luis R. Rodriguez 2012-10-09 1:24 ` Huang, Xiong 1 sibling, 1 reply; 5+ messages in thread From: Greg Kroah-Hartman @ 2012-10-09 0:42 UTC (permalink / raw) To: Luis R. Rodriguez Cc: xiong-A+ZNKFmMK5xy9aJCnZT0Uw, mcgrof-DgEjT+Ai2ygdnm+yROfE0A, backports-u79uwXL29TY76Z2rM5mHXA, nic-devel-zC7DfRvBq/JWk0Htik3J/w, Ren Cloud, linux-kernel-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA, linux-wireless, qca_vkondrat-A+ZNKFmMK5xy9aJCnZT0Uw On Mon, Oct 08, 2012 at 03:25:08PM -0700, Luis R. Rodriguez wrote: > On Thu, Oct 4, 2012 at 6:34 PM, <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> wrote: > > From: xiong <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> > > > > 1. support new device id (0x10A0/0x10A1). > > 2. add DEBUG_FS interface for diag/swoi functions. > > > > Signed-off-by: Ren Cloud <cjren-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> > > Signed-off-by: xiong <xiong-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org> > > Xiong, > > -- Vladimir, just a heads up -- this applies to you as well for the > 802.11ad wil6210 driver > -- Greg, some review on your preference on this would be appreciated Preference on what? I've never seen this driver before, why wasn't it submitted to be in the staging tree in the first place? > The original alx crap patch was added into compat-wireless on the > linux-3.5.y branch. What is "crap patch"? And is this the old driver with the dubios history keeping it from ever being merged anywhere, or is this something new? > Its been two kernel releases and alx is not yet > upstream and users can only get alx via compat-drivers (technically > compat-wireless as that was pre v3.7). v3.7 would be the *third* > release in which this would happen... This is unfair to users and > consumers of the Linux kernel and derails expectations and our > arrangements for Linux kernel development. I realize that the goal was > to get alx upstream ASAP but regardless of what the reason is, its not > yet upstream. If you cannot work on alx on a timely manner to get > upstream then please submit the driver to the staging area of the > Linux kernel that Greg maintains so that other developers who may be > able to help can submit patches to help you. Under staging your driver > should be accepted so long as it compiles. > > I will update the documentation for crap/ patches for compat-drivers > to make it clear now that crap/ patches can be used for adding > components / pieces of code not yet ready for upstream but as far as > full new drivers are concerned you only get one kernel release cycle > for it to linger on crap/ under compat-drivers, if you haven't > addressed upstreaming yet then it should go to drivers/staging/. That > is crap/ should only be used as a shortcut because users exist that > can use the driver but you *do* have a team properly resourced to > address upstreaming properly in a timely manner. Why do you even need crap/ at all? What is keeping drivers like this (if it isn't the legally dubious driver) from being merged into staging today? And if it is the legally dubious driver, well, you had better not be taking it in your tree either... confused, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir 2012-10-09 0:42 ` Greg Kroah-Hartman @ 2012-10-09 1:14 ` Luis R. Rodriguez 0 siblings, 0 replies; 5+ messages in thread From: Luis R. Rodriguez @ 2012-10-09 1:14 UTC (permalink / raw) To: Greg Kroah-Hartman Cc: xiong, mcgrof, backports, nic-devel, Ren Cloud, linux-kernel, netdev, linux-wireless, qca_vkondrat On Mon, Oct 8, 2012 at 5:42 PM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > On Mon, Oct 08, 2012 at 03:25:08PM -0700, Luis R. Rodriguez wrote: >> On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote: >> > From: xiong <xiong@qca.qualcomm.com> >> > >> > 1. support new device id (0x10A0/0x10A1). >> > 2. add DEBUG_FS interface for diag/swoi functions. >> > >> > Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com> >> > Signed-off-by: xiong <xiong@qca.qualcomm.com> >> >> Xiong, >> >> -- Vladimir, just a heads up -- this applies to you as well for the >> 802.11ad wil6210 driver >> -- Greg, some review on your preference on this would be appreciated > > Preference on what? I've never seen this driver before, why wasn't it > submitted to be in the staging tree in the first place? Because the goal was to jump straight to proper upstream and this was expected to happen rather easily. >> The original alx crap patch was added into compat-wireless on the >> linux-3.5.y branch. > > What is "crap patch"? And is this the old driver with the dubios > history keeping it from ever being merged anywhere, or is this something > new? The driver never had any legal dubious issues. The issues with the alx driver were purely technical. >> Its been two kernel releases and alx is not yet >> upstream and users can only get alx via compat-drivers (technically >> compat-wireless as that was pre v3.7). v3.7 would be the *third* >> release in which this would happen... This is unfair to users and >> consumers of the Linux kernel and derails expectations and our >> arrangements for Linux kernel development. I realize that the goal was >> to get alx upstream ASAP but regardless of what the reason is, its not >> yet upstream. If you cannot work on alx on a timely manner to get >> upstream then please submit the driver to the staging area of the >> Linux kernel that Greg maintains so that other developers who may be >> able to help can submit patches to help you. Under staging your driver >> should be accepted so long as it compiles. >> >> I will update the documentation for crap/ patches for compat-drivers >> to make it clear now that crap/ patches can be used for adding >> components / pieces of code not yet ready for upstream but as far as >> full new drivers are concerned you only get one kernel release cycle >> for it to linger on crap/ under compat-drivers, if you haven't >> addressed upstreaming yet then it should go to drivers/staging/. That >> is crap/ should only be used as a shortcut because users exist that >> can use the driver but you *do* have a team properly resourced to >> address upstreaming properly in a timely manner. > > Why do you even need crap/ at all? What is keeping drivers like this > (if it isn't the legally dubious driver) from being merged into staging > today? And if it is the legally dubious driver, well, you had better > not be taking it in your tree either... crap/ was invented for patches to existing code that people wrote that they for whatever reason did not think would ever get upstream but yet they *needed* to support for customer deliveries. Consider a feature that won't be acceptable but yet a customer *needs* today. In such case we know the developer should post it as it will get rejected. The developer may also know that they have to adjust the code to meet upstream criteria, and they might do that in 1 or 2 future kernel releases. Without having a mechanism to allow these type of patches folks go on a forking bandwagon and at times creates a slippery slope to never go back upstream. crap/ then was used later for alx as a full driver rather than drivers/staging/ given that the developers believed they could address upstream concerns within a release cycle and they needed a release ASAP. The alx driver needed to be changed to remove atl1c device support as per review and only support new generation devices. It was a lot easier for the developers to address that internally rather than working on drivers/staging. In the end alx is still not upstream as more technical issues have have not yet been addressed. I'm considering perhaps just not allowing full drivers through crap/ on compat-drivers and simply having developers bite the bullet and have to go through staging if they really need a release ASAP and are not yet ready for upstream. At this point I am revisiting the policy of when / if to allow drivers at all through crap/ and that's what I was asking for review for. Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH] compat-drivers: update ethernet driver alx in crap dir [not found] ` <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-10-09 0:42 ` Greg Kroah-Hartman @ 2012-10-09 1:24 ` Huang, Xiong 2012-10-16 15:37 ` Luis R. Rodriguez 1 sibling, 1 reply; 5+ messages in thread From: Huang, Xiong @ 2012-10-09 1:24 UTC (permalink / raw) To: Luis R. Rodriguez Cc: mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, backports-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, nic-devel, Ren, Cloud, Greg Kroah-Hartman, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-wireless, qca_vkondrat Hi Luis I'm refining the code, I try my best to make it upstream ASAP. Thanks ! -Xiong > -----Original Message----- > From: mcgrof@gmail.com [mailto:mcgrof@gmail.com] On Behalf Of Luis R. > Rodriguez > Sent: Tuesday, October 09, 2012 6:25 > To: Huang, Xiong > Cc: mcgrof@kernel.org; backports@vger.kernel.org; nic-devel; Ren, Cloud; > Greg Kroah-Hartman; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; > linux-wireless; qca_vkondrat > Subject: Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir > > On Thu, Oct 4, 2012 at 6:34 PM, <xiong@qca.qualcomm.com> wrote: > > From: xiong <xiong@qca.qualcomm.com> > > > > 1. support new device id (0x10A0/0x10A1). > > 2. add DEBUG_FS interface for diag/swoi functions. > > > > Signed-off-by: Ren Cloud <cjren@qca.qualcomm.com> > > Signed-off-by: xiong <xiong@qca.qualcomm.com> > > Xiong, > > -- Vladimir, just a heads up -- this applies to you as well for the 802.11ad > wil6210 driver > -- Greg, some review on your preference on this would be appreciated > > The original alx crap patch was added into compat-wireless on the linux-3.5.y > branch. Its been two kernel releases and alx is not yet upstream and users can > only get alx via compat-drivers (technically compat-wireless as that was pre > v3.7). v3.7 would be the *third* release in which this would happen... This is > unfair to users and consumers of the Linux kernel and derails expectations and > our arrangements for Linux kernel development. I realize that the goal was to > get alx upstream ASAP but regardless of what the reason is, its not yet > upstream. If you cannot work on alx on a timely manner to get upstream then > please submit the driver to the staging area of the Linux kernel that Greg > maintains so that other developers who may be able to help can submit > patches to help you. Under staging your driver should be accepted so long as it > compiles. > > I will update the documentation for crap/ patches for compat-drivers to make > it clear now that crap/ patches can be used for adding components / pieces of > code not yet ready for upstream but as far as full new drivers are concerned > you only get one kernel release cycle for it to linger on crap/ under compat- > drivers, if you haven't addressed upstreaming yet then it should go to > drivers/staging/. That is crap/ should only be used as a shortcut because users > exist that can use the driver but you *do* have a team properly resourced to > address upstreaming properly in a timely manner. > > Linus should soon release v3.7-rc1 and new drivers are allowed to be merged > during the RC cycles, as such my recommendation is instead of getting users to > consume alx only through compat-drivers you now submit alx into staging to > Greg in hopes that we can get it into v3.7-rcX some time, and at that time we > can remove the crap/ patch from compat-drivers. > > Users should be able to consume new drivers through kernel.org and compat- > drivers should only provide the framework for backporting and also > categorizing quick fixes. It should not be used for ongoing updates for new > drivers that users need. > > We must draw the line with crap/ patches somewhere. > > I'll then take this patch for now but do expect you to get alx into either staging > or proper upstream for the v3.7-rcX. I welcome feedback from other folks on > the proposed arrangement for crap/ patches for compat-drivers. > > https://backports.wiki.kernel.org/index.php/Documentation/compat- > drivers/additional-patches#crap_patches > > Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] compat-drivers: update ethernet driver alx in crap dir 2012-10-09 1:24 ` Huang, Xiong @ 2012-10-16 15:37 ` Luis R. Rodriguez 0 siblings, 0 replies; 5+ messages in thread From: Luis R. Rodriguez @ 2012-10-16 15:37 UTC (permalink / raw) To: Huang, Xiong Cc: mcgrof@kernel.org, backports@vger.kernel.org, nic-devel, Ren, Cloud, Greg Kroah-Hartman, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-wireless, qca_vkondrat On Mon, Oct 8, 2012 at 6:24 PM, Huang, Xiong <xiong@qca.qualcomm.com> wrote: > Hi Luis > > I'm refining the code, I try my best to make it upstream ASAP. Thanks ! Ok great thanks, in that case I'm going to make it policy moving forward to simply not take in full drivers at all into compat-drivers regardless of the situation. If a driver is desired to be made available, whatever the situation may be, it must now go upstream directly onto drivers/staging or drivers/ proper somewhere. Xiong, Vlad, I'm going to then nuke the current drivers there from the v3.7-rc1 release, if you want those drivers to be part of the compat-drivers-3.7 releases you will have to submit your driver upstream into proper or staging. The additional patches then will be for components already upstream. Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-16 15:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1349400892-25315-1-git-send-email-xiong@qca.qualcomm.com>
2012-10-08 22:25 ` [PATCH] compat-drivers: update ethernet driver alx in crap dir Luis R. Rodriguez
[not found] ` <CAB=NE6VotAu-cugsn4==3TPX0OGPEFtdn1J+5+Rd_YfLcg9YDQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-09 0:42 ` Greg Kroah-Hartman
2012-10-09 1:14 ` Luis R. Rodriguez
2012-10-09 1:24 ` Huang, Xiong
2012-10-16 15:37 ` Luis R. Rodriguez
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox