Hi Pavan, > On Wed, Nov 17, 2010 at 6:32 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: >>> drivers/staging/ti-st/Kconfig | 10 + >>> drivers/staging/ti-st/Makefile | 2 + >>> drivers/staging/ti-st/fmdrv.h | 259 ++++ >>> drivers/staging/ti-st/fmdrv_common.c | 2141 ++++++++++++++++++++++++++++++++++ >>> drivers/staging/ti-st/fmdrv_common.h | 458 ++++++++ >>> drivers/staging/ti-st/fmdrv_rx.c | 979 ++++++++++++++++ >>> drivers/staging/ti-st/fmdrv_rx.h | 59 + >>> drivers/staging/ti-st/fmdrv_tx.c | 461 ++++++++ >>> drivers/staging/ti-st/fmdrv_tx.h | 37 + >>> drivers/staging/ti-st/fmdrv_v4l2.c | 757 ++++++++++++ >>> drivers/staging/ti-st/fmdrv_v4l2.h | 32 + >>> 11 files changed, 5195 insertions(+), 0 deletions(-) >> >> Usually when a driver is added to staging, it should also have a TODO >> file specifying what needs to be done before the driver can be taken >> out of staging (at least as far as the author knows of today). >> >> It helps keeping track of the open issues in the driver, which is good >> for everyone - the author, the random contributor/observer, and >> probably even the staging maintainer. >> >> Can you please add such a TODO file ? ... > Thanks Ohad, for the comments, We do have an internal TODO. > In terms of functionality we have stuff like TX RDS which already has > few CIDs in the extended controls. > extend V4L2 for complete-scan, add in stop search during hw_seek .. etc... You need to understand and list the reasons why this driver cannot go directly to mainline; missing functionality is usually not the culprit. > But I just wanted to ask whether this is good enough to be staged. > Because as we begin to implement and add in the items in TODO - the > patch set will keep continuing to grow. > > So Hans, Mauro, What do you think ? > It would be real helpful - if this can be staged, it is becoming > difficult to maintain for us. Greg has mentioned that staging acceptance rules are: 1. Code compiles 2. Is self sustained (does not touch code out of staging) 3. Has a clear roadmap out of staging (that TODO file) 4. Is maintained But I really think you should always prefer to upstream your code directly to mainline. Submit the code, have it reviewed by the relevant maintainers and upstream developers, and fix it appropriately until it is accepted. Only if you feel (/know) it would take substantial cleanup/redesign efforts until it is accepted upstream, then staging is indeed the way to go. But then you should know what gates it from upstream merger, and focus on that (rather than on adding functionality) until it is taken out of staging. IMHO adding functionality will just make it harder for you to take it out of staging eventually. Usually the opposite road is taken: first get a minimal driver accepted upstream, and then gradually add the missing functionality. Good luck, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
