Staging: dt3155: Cleanup memory mapped i/o access
in [Kernel]
|
Prev: [PATCH v2.1 3/4] IPVS: make FTP work with full NAT support
Next: Staging: dream: pmem: code style fixes
From: Greg KH on 3 May 2010 17:40 On Mon, May 03, 2010 at 03:15:42PM -0500, H Hartley Sweeten wrote: > On Monday, May 03, 2010 12:00 PM, Greg KH wrote: > > On Sun, May 02, 2010 at 01:00:41PM -0500, H Hartley Sweeten wrote: > >> The macros ReadMReg and WriteMReg are really just private versions of > >> the kernel's readl and writel functions. Use the kernel's functions > >> instead. And since ioremap returns a (void __iomem *) not a (u8 *), > >> change all the uses of dt3155_lbase to reflect this. > >> > >> While here, make dt3155_lbase static since it is only used in the > >> dt3155_drv.c file. Also, remove the global variable dt3155_bbase > >> since it is not used anywhere in the code. > >> > >> Where is makes sense, create a local 'mmio' variable instead of using > >> dt3155_lbase[minor] to make the code more readable. > >> > >> This change also affects the {Read|Write}I2C functions so they are > >> also modified as needed. > >> > >> Signed-off-by: H Hartley Sweeten <hsweeten(a)visionengravers.com> > >> Cc: Scott Smedley <ss(a)aao.gov.au> > > > > Odd, but no, this still does not apply. I get the following errors: > > patching file drivers/staging/dt3155/dt3155_drv.c > > Hunk #1 succeeded at 75 (offset 11 lines). > > Hunk #2 FAILED at 115. > > Hunk #3 succeeded at 150 (offset 8 lines). > > Hunk #4 succeeded at 184 (offset 8 lines). > > Hunk #5 succeeded at 201 (offset 8 lines). > > Hunk #6 succeeded at 216 (offset 8 lines). > > Hunk #7 succeeded at 227 with fuzz 2 (offset 8 lines). > > Hunk #8 succeeded at 247 with fuzz 2 (offset 8 lines). > > Hunk #9 FAILED at 257. > > Hunk #10 succeeded at 273 with fuzz 2 (offset 8 lines). > > Hunk #11 succeeded at 290 (offset 8 lines). > > Hunk #12 succeeded at 326 with fuzz 2 (offset 8 lines). > > Hunk #13 FAILED at 395. > > Hunk #14 succeeded at 418 with fuzz 2 (offset 8 lines). > > Hunk #15 succeeded at 435 (offset 8 lines). > > Hunk #16 FAILED at 438. > > Hunk #17 FAILED at 456. > > Hunk #18 FAILED at 471. > > Hunk #19 succeeded at 501 (offset 8 lines). > > Hunk #20 succeeded at 510 (offset 8 lines). > > Hunk #21 succeeded at 699 (offset 8 lines). > > Hunk #22 succeeded at 727 (offset 8 lines). > > Hunk #23 succeeded at 929 with fuzz 1 (offset 8 lines). > > Hunk #24 succeeded at 1054 with fuzz 2 (offset 8 lines). > > 6 out of 24 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_drv.c.rej > > patching file drivers/staging/dt3155/dt3155_drv.h > > patching file drivers/staging/dt3155/dt3155_io.c > > Hunk #2 FAILED at 77. > > Hunk #3 FAILED at 103. > > Hunk #4 FAILED at 119. > > Hunk #5 FAILED at 134. > > Hunk #6 FAILED at 151. > > 5 out of 6 hunks FAILED -- saving rejects to file drivers/staging/dt3155/dt3155_io.c.rej > > patching file drivers/staging/dt3155/dt3155_io.h > > Reversed (or previously applied) patch detected! Assume -R? [n] > > Apply anyway? [n] > > Skipping patch. > > 2 out of 2 hunks ignored -- saving rejects to file drivers/staging/dt3155/dt3155_io.h.rej > > > > > > Did you rebase this on the latest linux-next tree? > > I did. And I just re-did is again against next-20100503 and it generated the same patch. Wierd. > But, I just noticed this: > > $ git log drivers/staging/dt3155 > commit 3c59b4691587b8977cc77ecf07985758a2ba0d97 > Merge: 7f1e428 bed46a8 > Author: Stephen Rothwell <sfr(a)canb.auug.org.au> > Date: Mon May 3 14:17:49 2010 +1000 > > Merge remote branch 'staging-next/staging-next' > > Conflicts: > drivers/staging/arlan/arlan-main.c > drivers/staging/comedi/drivers/cb_das16_cs.c > drivers/staging/cx25821/cx25821-alsa.c > drivers/staging/dt3155/dt3155_drv.c > drivers/staging/netwave/netwave_cs.c > > Could the next tree be out of sync with your tree? Hm, some other tree might be doing something in those files. But the fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought it was a revert, makes me suspect that you did it against something else. If you make this against my staging-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git using the staging-next branch, does that make the patch different? Let me know if you need help doing that. 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: H Hartley Sweeten on 3 May 2010 18:30 On Monday, May 03, 2010 2:18 PM, Greg KH wrote: >>> Did you rebase this on the latest linux-next tree? >> >> I did. And I just re-did is again against next-20100503 and it generated >> the same patch. > > Wierd. > >> But, I just noticed this: >> >> $ git log drivers/staging/dt3155 >> commit 3c59b4691587b8977cc77ecf07985758a2ba0d97 >> Merge: 7f1e428 bed46a8 >> Author: Stephen Rothwell <sfr(a)canb.auug.org.au> >> Date: Mon May 3 14:17:49 2010 +1000 >> >> Merge remote branch 'staging-next/staging-next' >> >> Conflicts: >> drivers/staging/arlan/arlan-main.c >> drivers/staging/comedi/drivers/cb_das16_cs.c >> drivers/staging/cx25821/cx25821-alsa.c >> drivers/staging/dt3155/dt3155_drv.c >> drivers/staging/netwave/netwave_cs.c >> >> Could the next tree be out of sync with your tree? > > Hm, some other tree might be doing something in those files. But the > fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought > it was a revert, makes me suspect that you did it against something > else. I just looked at the Next/merge.log file for next-20100503. $ git merge origin/master .... drivers/staging/dt3155/dt3155_drv.c | 4 +- .... $ git merge staging-next/staging-next .... Resolved 'drivers/staging/dt3155/dt3155_drv.c' using previous resolution. .... Auto-merging drivers/staging/dt3155/dt3155_drv.c CONFLICT (content): Merge conflict in drivers/staging/dt3155/dt3155_drv.c .... $ git diff -M --stat --summary HEAD^.. .... drivers/staging/dt3155/allocator.c | 16 +- drivers/staging/dt3155/allocator.h | 4 +- drivers/staging/dt3155/dt3155.h | 44 +- drivers/staging/dt3155/dt3155_drv.c | 380 +- drivers/staging/dt3155/dt3155_io.c | 24 +- drivers/staging/dt3155/dt3155_isr.c | 297 +- drivers/staging/dt3155/dt3155_isr.h | 2 +- .... Not sure if that helps... > > If you make this against my staging-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git > using the staging-next branch, does that make the patch different? > > Let me know if you need help doing that. I just tried pulling that tree and got: $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git fatal: Not a git repository (or any of the parent directories): .git So, yes I need help doing that ;-) Regards, Hartley-- 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: H Hartley Sweeten on 3 May 2010 18:50 On Monday, May 03, 2010 2:18 PM, Greg KH wrote: >>> Did you rebase this on the latest linux-next tree? >> >> I did. And I just re-did is again against next-20100503 and it generated the same patch. > > Wierd. > >> But, I just noticed this: >> >> $ git log drivers/staging/dt3155 >> commit 3c59b4691587b8977cc77ecf07985758a2ba0d97 >> Merge: 7f1e428 bed46a8 >> Author: Stephen Rothwell <sfr(a)canb.auug.org.au> >> Date: Mon May 3 14:17:49 2010 +1000 >> >> Merge remote branch 'staging-next/staging-next' >> >> Conflicts: >> drivers/staging/arlan/arlan-main.c >> drivers/staging/comedi/drivers/cb_das16_cs.c >> drivers/staging/cx25821/cx25821-alsa.c >> drivers/staging/dt3155/dt3155_drv.c >> drivers/staging/netwave/netwave_cs.c >> >> Could the next tree be out of sync with your tree? > > Hm, some other tree might be doing something in those files. But the > fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought > it was a revert, makes me suspect that you did it against something > else. > > If you make this against my staging-next tree at > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git > U sing the staging-next branch, does that make the patch different? Ok. Pulled your staging-next (thanks Joe). It's way different from linux-next and matches Linus' tree exactly. It's missing all of your "Drop the "_s"..." and "The typedef is not needed." patches. Of course I could be on the wrong branch for your staging-next tree. The only branches listed are: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master Regards, Hartley-- 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: H Hartley Sweeten on 3 May 2010 19:40 On Monday, May 03, 2010 3:45 PM, H Hartley Sweeten wrote: >>> Could the next tree be out of sync with your tree? >> >> Hm, some other tree might be doing something in those files. But the >> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought >> it was a revert, makes me suspect that you did it against something >> else. >> >> If you make this against my staging-next tree at >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git >> Using the staging-next branch, does that make the patch different? > > Ok. Pulled your staging-next (thanks Joe). > > It's way different from linux-next and matches Linus' tree exactly. It's > missing all of your "Drop the "_s"..." and "The typedef is not needed." > patches. > > Of course I could be on the wrong branch for your staging-next tree. The > only branches listed are: > > $ git branch -a > * master > remotes/origin/HEAD -> origin/master > remotes/origin/master It appears these are the patches missing in your staging-next tree that do exist in the linux-next tree: Staging: dt3155: remove "inline" usage Staging: dt3155: rename dt3155_fbuffer_s Staging: dt3155: rename dt3155_config_s Staging: dt3155: rename dt3155_read_t Staging: dt3155: rename dt3155_status_t Staging: dt3155: remove frame_info_t Staging: dt3155: remove TRUE/FALSE Staging: dt3155: remove #ifdef Staging: dt3155: allocator.c: sparse cleanups Staging: dt3155: fix parentheses and bracket spacing style issues Staging: dt3155: fix coding style issue in dt3155_isr.c Staging: dt3155: fix wait_ibsyclr function Staging: remove unused #include <linux/version.h> The first one that exists in both is: Staging: dt3155: fix 50Hz configuration Could the others be in a staging-stable branch? Regards, Hartley-- 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: Greg KH on 3 May 2010 19:50 On Mon, May 03, 2010 at 06:33:08PM -0500, H Hartley Sweeten wrote: > On Monday, May 03, 2010 3:45 PM, H Hartley Sweeten wrote: > >>> Could the next tree be out of sync with your tree? > >> > >> Hm, some other tree might be doing something in those files. But the > >> fact that the drivers/staging/dt3155/dt3155_io.h was so wrong it thought > >> it was a revert, makes me suspect that you did it against something > >> else. > >> > >> If you make this against my staging-next tree at > >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-next-2.6.git > >> Using the staging-next branch, does that make the patch different? > > > > Ok. Pulled your staging-next (thanks Joe). > > > > It's way different from linux-next and matches Linus' tree exactly. It's > > missing all of your "Drop the "_s"..." and "The typedef is not needed." > > patches. > > > > Of course I could be on the wrong branch for your staging-next tree. The > > only branches listed are: > > > > $ git branch -a > > * master > > remotes/origin/HEAD -> origin/master > > remotes/origin/master > > It appears these are the patches missing in your staging-next tree that do > exist in the linux-next tree: > > Staging: dt3155: remove "inline" usage > Staging: dt3155: rename dt3155_fbuffer_s > Staging: dt3155: rename dt3155_config_s > Staging: dt3155: rename dt3155_read_t > Staging: dt3155: rename dt3155_status_t > Staging: dt3155: remove frame_info_t > Staging: dt3155: remove TRUE/FALSE > Staging: dt3155: remove #ifdef > Staging: dt3155: allocator.c: sparse cleanups > Staging: dt3155: fix parentheses and bracket spacing style issues > Staging: dt3155: fix coding style issue in dt3155_isr.c > Staging: dt3155: fix wait_ibsyclr function > Staging: remove unused #include <linux/version.h> No, wait, I see these in my staging-next tree here. Some of them I wrote :) Are you sure you are cloning my tree properly? confused, 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/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: [PATCH v2.1 3/4] IPVS: make FTP work with full NAT support Next: Staging: dream: pmem: code style fixes |