staging: ti dspbridge: enable driver building
in [Kernel]
|
Prev: Staging: memrar: fix coding style issues in memrar_handler.c
Next: linux-next: build failure after merge of the final tree (tip tree related)
From: Greg KH on 23 Jun 2010 18:50 On Wed, Jun 23, 2010 at 04:14:00PM +0300, Ohad Ben-Cohen wrote: > From: Omar Ramirez Luna <omar.ramirez(a)ti.com> > > Add Kconfig + Makefile for TI's DSP Bridge driver > and expose it to the staging menu. > > Signed-off-by: Omar Ramirez Luna <omar.ramirez(a)ti.com> > Signed-off-by: Kanigeri, Hari <h-kanigeri2(a)ti.com> > Signed-off-by: Ameya Palande <ameya.palande(a)nokia.com> > Signed-off-by: Guzman Lugo, Fernando <fernando.lugo(a)ti.com> > Signed-off-by: Hebbar, Shivananda <x0hebbar(a)ti.com> > Signed-off-by: Ramos Falcon, Ernesto <ernesto(a)ti.com> > Signed-off-by: Felipe Contreras <felipe.contreras(a)gmail.com> > Signed-off-by: Anna, Suman <s-anna(a)ti.com> > Signed-off-by: Gupta, Ramesh <grgupta(a)ti.com> > Signed-off-by: Gomez Castellanos, Ivan <ivan.gomez(a)ti.com> > Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko(a)nokia.com> > Signed-off-by: Armando Uribe De Leon <x0095078(a)ti.com> > Signed-off-by: Deepak Chitriki <deepak.chitriki(a)ti.com> > Signed-off-by: Menon, Nishanth <nm(a)ti.com> > Signed-off-by: Phil Carmody <ext-phil.2.carmody(a)nokia.com> > Signed-off-by: Ohad Ben-Cohen <ohad(a)wizery.com> > --- > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/tidspbridge/Kconfig | 88 ++++++++++++++++++++++++++++++++++ > drivers/staging/tidspbridge/Makefile | 34 +++++++++++++ > 4 files changed, 125 insertions(+), 0 deletions(-) > create mode 100644 drivers/staging/tidspbridge/Kconfig > create mode 100644 drivers/staging/tidspbridge/Makefile > > > diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig > index 3de4bca..c9e8215 100644 > --- a/drivers/staging/Kconfig > +++ b/drivers/staging/Kconfig > @@ -153,5 +153,9 @@ source "drivers/staging/easycap/Kconfig" > > source "drivers/staging/solo6x10/Kconfig" > > +source "drivers/staging/tidspbridge/Kconfig" > + > +source "drivers/staging/tidspbridge/Kconfig" > + > endif # !STAGING_EXCLUDE_BUILD > endif # STAGING > diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile > index b28d820..952b64e 100644 > --- a/drivers/staging/Makefile > +++ b/drivers/staging/Makefile > @@ -57,3 +57,4 @@ obj-$(CONFIG_TOUCHSCREEN_MRSTOUCH) += mrst-touchscreen/ > obj-$(CONFIG_MSM_STAGING) += msm/ > obj-$(CONFIG_EASYCAP) += easycap/ > obj-$(CONFIG_SOLO6X10) += solo6x10/ > +obj-$(CONFIG_TIDSPBRIDGE) += tidspbridge/ > diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig > new file mode 100644 > index 0000000..37fa2b1 > --- /dev/null > +++ b/drivers/staging/tidspbridge/Kconfig > @@ -0,0 +1,88 @@ > +# > +# DSP Bridge Driver Support > +# > + > +menuconfig TIDSPBRIDGE > + tristate "DSP Bridge driver" > + default n The default is always 'n' so you don't need this. Also, this enables the driver to be built on x86, which fails horribly, and I don't think is what you really want to have happen :) So I need some more Kconfig changes here, care to redo just this one patch? I've applied all the others and they will show up in linux-next tomorrow. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Contreras on 4 Jul 2010 07:00 On Thu, Jun 24, 2010 at 1:41 AM, Greg KH <greg(a)kroah.com> wrote: > The default is always 'n' so you don't need this. > > Also, this enables the driver to be built on x86, which fails horribly, > and I don't think is what you really want to have happen :) > > So I need some more Kconfig changes here, care to redo just this one > patch? I've applied all the others and they will show up in linux-next > tomorrow. I fixed all that stuff some time ago: http://article.gmane.org/gmane.linux.ports.arm.omap/36065 But the patches were ignored. I might rebase them if nobody beats me to it. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Omar Ramirez Luna on 6 Jul 2010 12:00 On 7/4/2010 5:53 AM, Felipe Contreras wrote: > On Thu, Jun 24, 2010 at 1:41 AM, Greg KH<greg(a)kroah.com> wrote: >> The default is always 'n' so you don't need this. >> >> Also, this enables the driver to be built on x86, which fails horribly, >> and I don't think is what you really want to have happen :) >> >> So I need some more Kconfig changes here, care to redo just this one >> patch? I've applied all the others and they will show up in linux-next >> tomorrow. > > I fixed all that stuff some time ago: > http://article.gmane.org/gmane.linux.ports.arm.omap/36065 > > But the patches were ignored. Patches were not ignored, discussion was held privately (you and me), patch 13 was not accepted because changing indentation doesn't deserve a copyright assignment (IMHO), at that point *you* wanted your patches not to be included if the last one wasn't merged in. - omar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Felipe Contreras on 7 Jul 2010 05:40 I'm removing many people from the Cc which I think don't care about this. Is this even the right place for discussing about it? On Tue, Jul 6, 2010 at 6:52 PM, Omar Ramirez Luna <omar.ramirez(a)ti.com> wrote: > On 7/4/2010 5:53 AM, Felipe Contreras wrote: >> On Thu, Jun 24, 2010 at 1:41 AM, Greg KH<greg(a)kroah.com> wrote: >>> So I need some more Kconfig changes here, care to redo just this one >>> patch? I've applied all the others and they will show up in linux-next >>> tomorrow. >> >> I fixed all that stuff some time ago: >> http://article.gmane.org/gmane.linux.ports.arm.omap/36065 >> >> But the patches were ignored. > > Patches were not ignored, discussion was held privately (you and me), That was for the deh reorganization. Not the Kconfig ones. Regarding the deh reorganization... > patch > 13 was not accepted because changing indentation doesn't deserve a copyright > assignment (IMHO), You didn't want to add a copyright without giving any valid reason, so you started a private thread. You never mentioned any rejection of the patches on any grounds, neither publicly, nor privately. If the patch series is only changing indentation then the lines removed would match the lines added, which is not the case. Take a look: 15 files changed, 184 insertions(+), 509 deletions(-) In my book removing 300 lines of code while keeping all the functionality is a good thing. Without even considering that the rest of the insertions are cleaning up the code. > at that point *you* wanted your patches not to be > included if the last one wasn't merged in. Not without the copyright update patch. Maybe you are forgetting that I made many changes before those patches. Here are some stats for ue_deh and mmu_fault: Me: 22 commits, 487 insertions(+), 742 deletions(-) Others: 60 commits, 394 insertions(+), 617 deletions(-) (I didn't count the automated camel case removal) 218 insertions(+), 209 deletions(-) And 'git blame' shows me on 70% of ue_deh (which doesn't take into consideration code removals which is the main thing I did). While the vast majority of the changes are cleanups (much needed); there are also functional changes, mostly fixing memory corruptions, both reproduced and theoretical. If somebody writes a piece of code that's 10,000 lines, and another person reorganizes the code to make it 1,000 lines; IMO the usefulness of the code relies on both person's contributions. Depending on whether you care about having something functional, or maintainability/readability; you might assign more value to one, or the other, but I think both are important. So. Would you care to give a reason why my contributions don't deserve a copyright? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ohad Ben-Cohen on 7 Jul 2010 06:20
On Wed, Jul 7, 2010 at 12:31 PM, Felipe Contreras <felipe.contreras(a)gmail.com> wrote: > On Tue, Jul 6, 2010 at 6:52 PM, Omar Ramirez Luna <omar.ramirez(a)ti.com> wrote: >> at that point *you* wanted your patches not to be >> included if the last one wasn't merged in. > > Not without the copyright update patch. .... > So. Would you care to give a reason why my contributions don't deserve > a copyright? Disclaimer: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. AFAICT, you get copyright for every kernel change you submit and is accepted. Even if you just contribute whitespace cleanups, you get the copyright to those cleanups (not to suggest this was the sole contribution here). The copyright assignment is per the actual git commit itself, obviously, and it doesn't apply for the rest of the code in those files you edited. There are some exceptions, but they are not applicable here: - Usually when you get paid for the work, the employer keeps the copyright of the patch, not the author. - There are some projects where you have to relinquish the copyright in order for the patch to be accepted. This is how FSF (Free Software Foundation) projects work (e.g. gcc), but not the Linux kernel (which is not a FSF project). As I mentioned, I don't think these exceptions apply in this case, and AFAICT, Felipe - you inherently get the copyright for the changes that your accepted patches introduce. So it all boils down to the semantic question whether to edit the header file, adding new copyright lines, or not. Felipe, I think your contributions are important and helpful, and I would personally be happy if you continue to do them. I personally don't think that adding an explicit copyright line to the header should be important, because you get your copyright anyway. The exact change, to which you get copyright on, is kept in the git history, and will not likely to go away. I think this is pretty satisfying, and as a result, you don't see people(/companies) changing copyright headers when they submit kernel patches that edit existing files. The only thing I am not sure about, and that may be a concern to TI, is whether adding a copyright line in the header might actually give copyright ownership for the complete file. If this is true, I can understand why TI might not be so keen in adding copyright owners to the file header, without explicitly specifying what is the copyright about (not to suggest any opinion of TI on the matter, I speak only for myself). Again: I am not a lawyer, and I speak only for myself in this post, and doesn't represent TI in anyway. Thanks, Ohad. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |