[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/27/2012 06:56 AM, Daniel Vetter wrote: > On Fri, Oct 26, 2012 at 10:57 PM, Justin P. Mattock > wrote: >> >> :~/drm> git clone git://people.freedesktop.org/~danvet/drm >> Cloning into 'drm'... >> remote: Counting objects: 2728390, done. >> remote: Compressing objects: 100% (418606/418606), done. >> remote: Total 2728390 (delta 2293727), reused 2717443 (delta 2282880) >> Receiving objects: 100% (2728390/2728390), 637.95 MiB | 599 KiB/s, done. >> Resolving deltas: 100% (2293727/2293727), done. >> warning: remote HEAD refers to nonexistent ref, unable to checkout. >> >> >> so now I have to go on a witch hunt for 600MB's in my system. > > $ git checkout origin/ilk-wa-pile cool thanks..(not so good at git over here). > > ... and you have the right branch checked out. No need for pitchforks > and witch hunts ;-) > -Daniel > alright.. putting the pitchfork away for now. Justin P. Mattock
Re: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/27/2012 06:56 AM, Daniel Vetter wrote: On Fri, Oct 26, 2012 at 10:57 PM, Justin P. Mattock justinmatt...@gmail.com wrote: :~/drm git clone git://people.freedesktop.org/~danvet/drm Cloning into 'drm'... remote: Counting objects: 2728390, done. remote: Compressing objects: 100% (418606/418606), done. remote: Total 2728390 (delta 2293727), reused 2717443 (delta 2282880) Receiving objects: 100% (2728390/2728390), 637.95 MiB | 599 KiB/s, done. Resolving deltas: 100% (2293727/2293727), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. so now I have to go on a witch hunt for 600MB's in my system. $ git checkout origin/ilk-wa-pile cool thanks..(not so good at git over here). ... and you have the right branch checked out. No need for pitchforks and witch hunts ;-) -Daniel alright.. putting the pitchfork away for now. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/26/2012 01:05 AM, Daniel Vetter wrote: > On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock > wrote: >>> >>> No worries, it is another ILK hang similar to the ones reported earlier >>> - it just seems the ring stops advancing. Hopefully it is a missing w/a >>> from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile >>> -Chris >>> >> >> well if this means building libdrm etc.. then thats not a problem, more time >> consuming if anything. perhaps an *.rpm that I can test to see? > > It's not libdrm, the above is just a kernel git tree with a bunch of > ironlake workarounds. > -Daniel > nice.. :~/drm> git clone git://people.freedesktop.org/~danvet/drm Cloning into 'drm'... remote: Counting objects: 2728390, done. remote: Compressing objects: 100% (418606/418606), done. remote: Total 2728390 (delta 2293727), reused 2717443 (delta 2282880) Receiving objects: 100% (2728390/2728390), 637.95 MiB | 599 KiB/s, done. Resolving deltas: 100% (2293727/2293727), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. so now I have to go on a witch hunt for 600MB's in my system. Justin P. Mattock
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/26/2012 01:05 AM, Daniel Vetter wrote: > On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock > wrote: >>> >>> No worries, it is another ILK hang similar to the ones reported earlier >>> - it just seems the ring stops advancing. Hopefully it is a missing w/a >>> from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile >>> -Chris >>> >> >> well if this means building libdrm etc.. then thats not a problem, more time >> consuming if anything. perhaps an *.rpm that I can test to see? > > It's not libdrm, the above is just a kernel git tree with a bunch of > ironlake workarounds. > -Daniel > hmm.. then in that case maybe I should pull and run that kernel to see if the crash occurs, before bisecting(if anything). will do once I get time to download. Justin P. Mattock
Re: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/26/2012 01:05 AM, Daniel Vetter wrote: On Fri, Oct 26, 2012 at 6:43 AM, Justin P. Mattock justinmatt...@gmail.com wrote: No worries, it is another ILK hang similar to the ones reported earlier - it just seems the ring stops advancing. Hopefully it is a missing w/a from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile -Chris well if this means building libdrm etc.. then thats not a problem, more time consuming if anything. perhaps an *.rpm that I can test to see? It's not libdrm, the above is just a kernel git tree with a bunch of ironlake workarounds. -Daniel hmm.. then in that case maybe I should pull and run that kernel to see if the crash occurs, before bisecting(if anything). will do once I get time to download. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On 10/25/2012 01:47 AM, Chris Wilson wrote: > On Thu, 25 Oct 2012 10:16:08 +0200, Daniel Vetter wrote: >> On Thu, Oct 25, 2012 at 7:22 AM, Justin P. Mattock >> wrote: >>> >>> here is a link to the file..: intel_error_decode >>> http://www.filefactory.com/file/22bypyjhs4mx >> >> I haven't figured out how to access this thing. Can you please file a >> bug report on bugs.freedesktop.org and attach it there? Oops.. I filed with the kernel. maybe can just add a cc's https://bugzilla.kernel.org/show_bug.cgi?id=49571 > > No worries, it is another ILK hang similar to the ones reported earlier > - it just seems the ring stops advancing. Hopefully it is a missing w/a > from http://cgit.freedesktop.org/~danvet/drm/log/?h=ilk-wa-pile > -Chris > well if this means building libdrm etc.. then thats not a problem, more time consuming if anything. perhaps an *.rpm that I can test to see? Justin P. Mattock
Re: [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote: This is happening both with MAINLINE and NEXT. basically system is running fine, then under load system becomes really sluggish and unresponsive. I was able to get dmesg of the error..: [ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP [ 7745.007736] wlan0: associate with 68:7f:74:b8:05:82 (try 1/3) [ 7745.011456] wlan0: RX AssocResp from 68:7f:74:b8:05:82 (capab=0x411 status=0 aid=5) [ 7745.011529] wlan0: associated [ 8120.812482] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8120.812642] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 8122.328682] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8122.328845] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [ 8122.328850] [drm:i915_reset] *ERROR* Failed to reset chip. full log is here: http://fpaste.org/7xH8/ as for good kernels from what I remember 3.6.0-rc1. I can try a bisect on this once I get the time. or if anybody has a patch I can test. Can you please rehand your machine, and then grab the i915_error_state from debugfs? That contains the gpu hang dump we need to diagnose things. And the bisect would obviously be awesome. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch took a bit to trigger, but finally fired off. here is a link to the file..: intel_error_decode http://www.filefactory.com/file/22bypyjhs4mx the file was to large to send to the list.. let me know if you need more info with this. also if anybody has any ideas to trigger this would be appreciated so the bisect can be more precise. right now dont even think its worth it, due to not being able to trigger the crash causing the bisect to go astray and pointing to a wrong commit(which has happened in the past) but then again you never know. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > > On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote: > > This is happening both with MAINLINE and NEXT. > > > > basically system is running fine, then under load system becomes > > really sluggish and unresponsive. I was able to get dmesg of the > > error..: > > > > [ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is > > not supported by the AP > > [ 7745.007736] wlan0: associate with 68:7f:74:b8:05:82 (try 1/3) > > [ 7745.011456] wlan0: RX AssocResp from 68:7f:74:b8:05:82 > > (capab=0x411 status=0 aid=5) > > [ 7745.011529] wlan0: associated > > [ 8120.812482] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 8120.812642] [drm] capturing error event; look for more > > information in /debug/dri/0/i915_error_state > > [ 8122.328682] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 8122.328845] [drm:i915_reset] *ERROR* GPU hanging too fast, > > declaring wedged! > > [ 8122.328850] [drm:i915_reset] *ERROR* Failed to reset chip. > > > > full log is here: http://fpaste.org/7xH8/ > > > > as for good kernels from what I remember 3.6.0-rc1. I can try a > > bisect on this once I get the time. or if anybody has a patch I can > > test. > > Can you please rehand your machine, and then grab the i915_error_state > from debugfs? That contains the gpu hang dump we need to diagnose things. > > And the bisect would obviously be awesome. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch took a bit to trigger, but finally fired off. here is a link to the file..: intel_error_decode http://www.filefactory.com/file/22bypyjhs4mx the file was to large to send to the list.. let me know if you need more info with this. also if anybody has any ideas to trigger this would be appreciated so the bisect can be more precise. right now dont even think its worth it, due to not being able to trigger the crash causing the bisect to go astray and pointing to a wrong commit(which has happened in the past) but then again you never know. Justin P. Mattock
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
This is happening both with MAINLINE and NEXT. basically system is running fine, then under load system becomes really sluggish and unresponsive. I was able to get dmesg of the error..: [ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP [ 7745.007736] wlan0: associate with 68:7f:74:b8:05:82 (try 1/3) [ 7745.011456] wlan0: RX AssocResp from 68:7f:74:b8:05:82 (capab=0x411 status=0 aid=5) [ 7745.011529] wlan0: associated [ 8120.812482] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8120.812642] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 8122.328682] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8122.328845] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [ 8122.328850] [drm:i915_reset] *ERROR* Failed to reset chip. full log is here: http://fpaste.org/7xH8/ as for good kernels from what I remember 3.6.0-rc1. I can try a bisect on this once I get the time. or if anybody has a patch I can test. Justin P. Mattock
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
This is happening both with MAINLINE and NEXT. basically system is running fine, then under load system becomes really sluggish and unresponsive. I was able to get dmesg of the error..: [ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is not supported by the AP [ 7745.007736] wlan0: associate with 68:7f:74:b8:05:82 (try 1/3) [ 7745.011456] wlan0: RX AssocResp from 68:7f:74:b8:05:82 (capab=0x411 status=0 aid=5) [ 7745.011529] wlan0: associated [ 8120.812482] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8120.812642] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state [ 8122.328682] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung [ 8122.328845] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged! [ 8122.328850] [drm:i915_reset] *ERROR* Failed to reset chip. full log is here: http://fpaste.org/7xH8/ as for good kernels from what I remember 3.6.0-rc1. I can try a bisect on this once I get the time. or if anybody has a patch I can test. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3]drivers:video:aty:radeon_base Fix typo occationally to occasionally
The below patch fixes a typo occationally to occasionally.
Signed-off-by: Justin P. Mattock
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
drivers/video/aty/radeon_base.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index cf0638c..a883902 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -888,7 +888,7 @@ static void radeon_set_pll(struct drm_crtc *crtc, struct
drm_display_mode *mode)
}
if (rdev->flags & RADEON_IS_MOBILITY) {
- /* A temporal workaround for the occational blanking on
certain laptop panels.
+ /* A temporal workaround for the occasional blanking on
certain laptop panels.
This appears to related to the PLL divider registers
(fail to lock?).
It occurs even when all dividers are the same with
their old settings.
In this case we really don't need to fiddle with PLL
registers.
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
index 3c1e13e..32f8cf6 100644
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -1248,7 +1248,7 @@ static void radeon_write_pll_regs(struct radeonfb_info
*rinfo, struct radeon_reg
/* Workaround from XFree */
if (rinfo->is_mobility) {
- /* A temporal workaround for the occational blanking on certain
laptop
+ /* A temporal workaround for the occasional blanking on certain
laptop
* panels. This appears to related to the PLL divider registers
* (fail to lock?). It occurs even when all dividers are the
same
* with their old settings. In this case we really don't need to
--
1.6.5.2.180.gc5b3e
[BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
With the current HEAD Im getting screen flickering really bad to point where it looks like the screen is damaged and/or half plugged-in etc.. the bisect pointed to here: commit 619efb105924d8cafa0c1dd9389e9ab506f5425d doing a git revert 619efb10592 gets the screen working properly again. I havent looked much through the code to see if I can fix this. for the time being I'll revert this on my machine with the current, until later on. lspci -vv shows my card info(let me know if you need anymore) 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] (prog-if 00 [VGA controller]) Subsystem: Apple Computer Inc. MacBook Pro Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: radeon Kernel modules: radeon Justin P. Mattock
[BISECTED] commit 619efb1059 makes the MacBookPro2,2 screen flicker like its broken or half plugged in
With the current HEAD Im getting screen flickering really bad to point where it looks like the screen is damaged and/or half plugged-in etc.. the bisect pointed to here: commit 619efb105924d8cafa0c1dd9389e9ab506f5425d doing a git revert 619efb10592 gets the screen working properly again. I havent looked much through the code to see if I can fix this. for the time being I'll revert this on my machine with the current, until later on. lspci -vv shows my card info(let me know if you need anymore) 01:00.0 VGA compatible controller: ATI Technologies Inc M56P [Radeon Mobility X1600] (prog-if 00 [VGA controller]) Subsystem: Apple Computer Inc. MacBook Pro Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 256 bytes Interrupt: pin A routed to IRQ 42 Region 0: Memory at 4000 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at 5030 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 5032 [disabled] [size=128K] Capabilities: access denied Kernel driver in use: radeon Kernel modules: radeon Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v5]update broken web addresses in the kernel.
On 09/28/2010 12:35 AM, Finn Thain wrote:
>
> On Tue, 28 Sep 2010, Justin P. Mattock wrote:
>
>> o.k... I'll make the changes to the arch patch, and combine the two, and
>> send it to jiri..
>
> Why?
>
> My advice is don't do it unless you want to waste reviewers' time.
>
>> as for the names and signed offs is what is below fine or do I need to
>> change some of them?
>
> If you combine patch 1 and patch 2 and submit that as patch 3, you will
> likely have to CC patch 3 to everyone to whom you sent patch 1 plus
> everyone to whom you sent patch 2. You must also change any "acked-by" to
> "Cc", since patch 3 is new.
>
> Keep the same CC list since Jiri is already on it ("trivial at kernel.org").
>
> Finn
>
alright.. so it will be two patches then..(not the best at the CC etc..
thing) cool... and thanks again for reviewing this for me..(back
breaking work, but somebodies _gots_ to do it..)
Justin P. Mattock
[RFC v5]update broken web addresses in the kernel.
o.k... I'll make the changes to the arch patch, and combine the two, and send it to jiri.. as for the names and signed offs is what is below fine or do I need to change some of them? > > Looks good to me. > > Finn > > > On Mon, 27 Sep 2010, Justin P. Mattock wrote: > >> Below is an updated patch to fix broken web addresses in the kernel. >> Please let me know if I missed anything, and I'll go back and fix it. >> and lastly Thanks for all the help with this... >> >> Signed-off-by: Justin P. Mattock >> Cc: Maciej W. Rozycki >> Cc: Geert Uytterhoeven >> Cc: Finn Thain >> Cc: Randy Dunlap >> Cc: Matt Turner >> Cc: Dimitry Torokhov >> Cc: Mike Frysinger >> Acked-by: Ben Pfaff >> Acked-by: Hans J. Koch >> >> --- >> drivers/ata/pata_it821x.c |4 ++-- >> drivers/atm/Kconfig |2 +- >> drivers/char/agp/Kconfig|2 +- >> drivers/char/agp/i460-agp.c |2 +- >> drivers/char/apm-emulation.c|4 ++-- >> drivers/char/ipmi/ipmi_bt_sm.c |2 +- >> drivers/char/ipmi/ipmi_si_intf.c|3 +-- >> drivers/char/n_r3964.c |1 - >> drivers/char/pcmcia/Kconfig |4 ++-- >> drivers/char/tpm/Kconfig|2 +- >> drivers/char/tpm/tpm_infineon.c |2 +- >> drivers/edac/edac_device_sysfs.c|2 +- >> drivers/edac/i82443bxgx_edac.c |2 +- >> drivers/firmware/Kconfig|4 ++-- >> drivers/firmware/edd.c |2 +- >> drivers/firmware/pcdp.h |4 ++-- >> drivers/gpu/drm/drm_modes.c |2 +- >> drivers/hwmon/adm1025.c |2 +- >> drivers/hwmon/adm1026.c |2 +- >> drivers/hwmon/f75375s.c |4 ++-- >> drivers/hwmon/g760a.c |2 +- >> drivers/hwmon/hwmon-vid.c |2 +- >> drivers/ide/hpt366.c|2 +- >> drivers/ide/ht6560b.c |1 - >> drivers/infiniband/Kconfig |4 ++-- >> drivers/infiniband/hw/cxgb3/Kconfig |2 +- >> drivers/infiniband/hw/cxgb4/Kconfig |2 +- >> drivers/infiniband/ulp/iser/Kconfig |2 +- >> drivers/input/joystick/gamecon.c|3 +-- >> drivers/input/misc/cm109.c |2 +- >> drivers/input/mouse/Kconfig |1 + >> drivers/input/mouse/touchkit_ps2.c |4 ++-- >> drivers/input/touchscreen/mk712.c |2 +- >> drivers/isdn/i4l/isdn_audio.c |2 +- >> drivers/macintosh/therm_adt746x.c |6 +++--- >> drivers/media/IR/keymaps/rc-manli.c |1 - >> drivers/media/dvb/ttpci/av7110.c| 10 ++ >> drivers/media/dvb/ttpci/av7110_av.c |2 +- >> drivers/media/dvb/ttpci/av7110_ca.c |2 +- >> drivers/media/dvb/ttpci/av7110_hw.c |2 +- >> drivers/media/dvb/ttpci/av7110_v4l.c|2 +- >> drivers/media/dvb/ttpci/budget-av.c |2 +- >> drivers/media/dvb/ttpci/budget-ci.c |2 +- >> drivers/media/dvb/ttpci/budget-core.c |2 +- >> drivers/media/dvb/ttpci/budget-patch.c |2 +- >> drivers/media/dvb/ttpci/budget.c|2 +- >> drivers/media/radio/radio-maxiradio.c |2 +- >> drivers/media/radio/radio-typhoon.c |2 -- >> drivers/media/video/Kconfig |2 +- >> drivers/media/video/cafe_ccic.c |2 +- >> drivers/media/video/cx18/cx18-cards.c |2 +- >> drivers/media/video/cx23885/cx23885-417.c |2 +- >> drivers/media/video/cx88/cx88-blackbird.c |2 +- >> drivers/media/video/ivtv/ivtv-cards.c |2 +- >> drivers/media/video/mxb.c |2 +- >> drivers/media/video/sn9c102/sn9c102_pas202bcb.c |1 - >> drivers/misc/Kconfig|4 ++-- >> drivers/mtd/chips/cfi_cmdset_0002.c |4 ++-- >> drivers/mtd/devices/lart.c |2 +- >> drivers/mtd/ftl.c
Re: [RFC v4]update broken web addresses in the kernel.
On 09/27/2010 07:59 PM, Finn Thain wrote: On Sun, 26 Sep 2010, Justin P. Mattock wrote: diff --git a/drivers/char/apm-emulation.c b/drivers/char/apm-emulation.c index 033e150..d7d9a78 100644 --- a/drivers/char/apm-emulation.c +++ b/drivers/char/apm-emulation.c @@ -8,7 +8,7 @@ * (APM) BIOS Interface Specification, Revision 1.2, February 1996. * * [This document is available from Microsoft at: - *http://www.microsoft.com/hwdev/busbios/amp_12.htm] + *http://www.microsoft.com/whdc/archive/amp_12.mspx] */ Can we lose the brackets? #includelinux/module.h #includelinux/poll.h diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 280c9b5..b2bd5fb 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -73,8 +73,8 @@ config EFI_PCDP on how the driver discovers devices. You must also enable the appropriate drivers (serial, VGA, etc.) - - Seehttp://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf + See [DIG64_HCDPv20_042804.pdf] available from What are the square brackets for? + http://www.dig64.org/specifications/ config DELL_RBU tristate BIOS update support for DELL systems via sysfs diff --git a/drivers/firmware/pcdp.h b/drivers/firmware/pcdp.h index ce910d6..777d928 100644 --- a/drivers/firmware/pcdp.h +++ b/drivers/firmware/pcdp.h @@ -1,8 +1,8 @@ /* * Definitions for PCDP-defined console devices * - * v1.0a: http://www.dig64.org/specifications/DIG64_HCDPv10a_01.pdf - * v2.0: http://www.dig64.org/specifications/DIG64_PCDPv20.pdf + * For [v1.0a: DIG64_HCDPv10a_01.pdf] [v2.0: DIG64_PCDPv20.pdf] For DIG64_HCDPv10a_01.pdf and DIG64_PCDPv20.pdf (v10.a and v2.0 resp.), + * Please seehttp://www.dig64.org/specifications/ please seehttp://www.dig64.org/specifications/ * * (c) Copyright 2002, 2004 Hewlett-Packard Development Company, L.P. *Khalid Azizkhalid.a...@hp.com diff --git a/drivers/gpu/drm/README.drm b/drivers/gpu/drm/README.drm index b5b3327..bf29068 100644 --- a/drivers/gpu/drm/README.drm +++ b/drivers/gpu/drm/README.drm @@ -28,7 +28,7 @@ ways: Documentation on the DRI is available from: http://dri.freedesktop.org/wiki/Documentation http://sourceforge.net/project/showfiles.php?group_id=387 -http://dri.sourceforge.net/doc/ +http://dri.sourceforge.net/doc/DRIuserguide.html http://dri.freedesktop.org/wiki/Documentation For specific information about kernel-level support, see: diff --git a/drivers/input/mouse/touchkit_ps2.c b/drivers/input/mouse/touchkit_ps2.c index 88121c5..e74753e 100644 --- a/drivers/input/mouse/touchkit_ps2.c +++ b/drivers/input/mouse/touchkit_ps2.c @@ -22,7 +22,7 @@ * Based upon touchkitusb.c * * Vendor documentation is available in support section of: - * http://www.egalax.com.tw/ + * http://home.eeti.com.tw/web20/drivers/Software%20Programming%20Guide_v2.0.pdf The comment text needs to be fixed also. */ #includelinux/kernel.h diff --git a/drivers/media/dvb/frontends/mt312.c b/drivers/media/dvb/frontends/mt312.c index 472907d..08023f1 100644 --- a/drivers/media/dvb/frontends/mt312.c +++ b/drivers/media/dvb/frontends/mt312.c @@ -20,8 +20,9 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. References: -http://products.zarlink.com/product_profiles/MT312.htm -http://products.zarlink.com/product_profiles/SL1935.htm +http://www.zarlink.com/zarlink/hs/71.htm +http://www.chipcatalog.com/Zarlink/MT312.htm +http://www.chipcatalog.com/Zarlink/SL1935.htm There's no need for links to chipcatalog.com. As I said in the previous review, we have search engines for finding datasheets. Besides, the old links are in the web archive (complete with PDFs) so there's no need to remove them. */ #includelinux/delay.h diff --git a/drivers/media/dvb/frontends/mt312.h b/drivers/media/dvb/frontends/mt312.h index 29e3bb5..6d32e3f 100644 --- a/drivers/media/dvb/frontends/mt312.h +++ b/drivers/media/dvb/frontends/mt312.h @@ -19,8 +19,9 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. References: -http://products.zarlink.com/product_profiles/MT312.htm -http://products.zarlink.com/product_profiles/SL1935.htm +http://www.zarlink.com/zarlink/hs/71.htm +http://www.chipcatalog.com/Zarlink/MT312.htm +http://www.chipcatalog.com/Zarlink/SL1935.htm Same here. */ #ifndef MT312_H --- a/drivers/media/video/gspca/gspca.c +++ b/drivers/media/video/gspca/gspca.c @@ -2338,7 +2338,7 @@ EXPORT_SYMBOL(gspca_resume); /* auto gain and exposure algorithm based on the knee algorithm described here: http://ytse.tricolour.net/docs/LowLightOptimization.html - + http://81.209.78.62:8080/docs/LowLightOptimization.html This is in the web archive. Returns 0 if no changes were made, 1 if the gain and or exposure settings where changed. */ int gspca_auto_gain_n_exposure(struct
Re: [RFC v4]update broken web addresses in the kernel.
On 09/27/2010 09:15 PM, Finn Thain wrote: On Mon, 27 Sep 2010, Justin P. Mattock wrote: alright.. I'll redu this... remove the brackets, and fix up the rest.. one note is: http://dri.freedesktop.org/wiki/Documentation this address is already there.. Right you are. probably best to just leave the sourceforge address and use the webarchive and/or if theirs a proper address for the sourceforge dri.. I didn't find a sensible address for the sourceforge stuff now that indexes are turned off for /doc/. I agree, best just to leave it as is, since it is in the archive. Finn Justin P. Mattock alright... resent, hopefully I didnt miss any of them... eyes are going out of whack over here.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5]update broken web addresses in the kernel.
On 09/28/2010 12:35 AM, Finn Thain wrote: On Tue, 28 Sep 2010, Justin P. Mattock wrote: o.k... I'll make the changes to the arch patch, and combine the two, and send it to jiri.. Why? My advice is don't do it unless you want to waste reviewers' time. as for the names and signed offs is what is below fine or do I need to change some of them? If you combine patch 1 and patch 2 and submit that as patch 3, you will likely have to CC patch 3 to everyone to whom you sent patch 1 plus everyone to whom you sent patch 2. You must also change any acked-by to Cc, since patch 3 is new. Keep the same CC list since Jiri is already on it (triv...@kernel.org). Finn alright.. so it will be two patches then..(not the best at the CC etc.. thing) cool... and thanks again for reviewing this for me..(back breaking work, but somebodies _gots_ to do it..) Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4]update broken web addresses in the kernel.
On 09/27/2010 09:15 PM, Finn Thain wrote: > > On Mon, 27 Sep 2010, Justin P. Mattock wrote: > >> alright.. I'll redu this... remove the brackets, and fix up the rest.. >> one note is: >> http://dri.freedesktop.org/wiki/Documentation >> this address is already there.. > > Right you are. > >> probably best to just leave the sourceforge >> address and use the webarchive and/or if theirs a >> proper address for the sourceforge dri.. > > I didn't find a sensible address for the sourceforge stuff now that > indexes are turned off for /doc/. > > I agree, best just to leave it as is, since it is in the archive. > > Finn > >> >> Justin P. Mattock >> >> > alright... resent, hopefully I didnt miss any of them... eyes are going out of whack over here.. Justin P. Mattock
[RFC v5]update broken web addresses in the kernel.
Below is an updated patch to fix broken web addresses in the kernel. Please let me know if I missed anything, and I'll go back and fix it. and lastly Thanks for all the help with this... Signed-off-by: Justin P. Mattock Cc: Maciej W. Rozycki Cc: Geert Uytterhoeven Cc: Finn Thain Cc: Randy Dunlap Cc: Matt Turner Cc: Dimitry Torokhov Cc: Mike Frysinger Acked-by: Ben Pfaff Acked-by: Hans J. Koch --- drivers/ata/pata_it821x.c |4 ++-- drivers/atm/Kconfig |2 +- drivers/char/agp/Kconfig|2 +- drivers/char/agp/i460-agp.c |2 +- drivers/char/apm-emulation.c|4 ++-- drivers/char/ipmi/ipmi_bt_sm.c |2 +- drivers/char/ipmi/ipmi_si_intf.c|3 +-- drivers/char/n_r3964.c |1 - drivers/char/pcmcia/Kconfig |4 ++-- drivers/char/tpm/Kconfig|2 +- drivers/char/tpm/tpm_infineon.c |2 +- drivers/edac/edac_device_sysfs.c|2 +- drivers/edac/i82443bxgx_edac.c |2 +- drivers/firmware/Kconfig|4 ++-- drivers/firmware/edd.c |2 +- drivers/firmware/pcdp.h |4 ++-- drivers/gpu/drm/drm_modes.c |2 +- drivers/hwmon/adm1025.c |2 +- drivers/hwmon/adm1026.c |2 +- drivers/hwmon/f75375s.c |4 ++-- drivers/hwmon/g760a.c |2 +- drivers/hwmon/hwmon-vid.c |2 +- drivers/ide/hpt366.c|2 +- drivers/ide/ht6560b.c |1 - drivers/infiniband/Kconfig |4 ++-- drivers/infiniband/hw/cxgb3/Kconfig |2 +- drivers/infiniband/hw/cxgb4/Kconfig |2 +- drivers/infiniband/ulp/iser/Kconfig |2 +- drivers/input/joystick/gamecon.c|3 +-- drivers/input/misc/cm109.c |2 +- drivers/input/mouse/Kconfig |1 + drivers/input/mouse/touchkit_ps2.c |4 ++-- drivers/input/touchscreen/mk712.c |2 +- drivers/isdn/i4l/isdn_audio.c |2 +- drivers/macintosh/therm_adt746x.c |6 +++--- drivers/media/IR/keymaps/rc-manli.c |1 - drivers/media/dvb/ttpci/av7110.c| 10 ++ drivers/media/dvb/ttpci/av7110_av.c |2 +- drivers/media/dvb/ttpci/av7110_ca.c |2 +- drivers/media/dvb/ttpci/av7110_hw.c |2 +- drivers/media/dvb/ttpci/av7110_v4l.c|2 +- drivers/media/dvb/ttpci/budget-av.c |2 +- drivers/media/dvb/ttpci/budget-ci.c |2 +- drivers/media/dvb/ttpci/budget-core.c |2 +- drivers/media/dvb/ttpci/budget-patch.c |2 +- drivers/media/dvb/ttpci/budget.c|2 +- drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-typhoon.c |2 -- drivers/media/video/Kconfig |2 +- drivers/media/video/cafe_ccic.c |2 +- drivers/media/video/cx18/cx18-cards.c |2 +- drivers/media/video/cx23885/cx23885-417.c |2 +- drivers/media/video/cx88/cx88-blackbird.c |2 +- drivers/media/video/ivtv/ivtv-cards.c |2 +- drivers/media/video/mxb.c |2 +- drivers/media/video/sn9c102/sn9c102_pas202bcb.c |1 - drivers/misc/Kconfig|4 ++-- drivers/mtd/chips/cfi_cmdset_0002.c |4 ++-- drivers/mtd/devices/lart.c |2 +- drivers/mtd/ftl.c |2 +- drivers/mtd/maps/Kconfig|4 ++-- drivers/mtd/nand/cafe_nand.c|2 +- drivers/net/Kconfig | 21 ++--- drivers/net/appletalk/Kconfig |2 +- drivers/net/atp.c |2 +- drivers/net/epic100.c |4 ++-- drivers/net/hamradio/Kconfig|2 +- drivers/net/ibmlana.c |2 +- drivers/net/irda/donauboe.h |2 +- drivers/net/pci-skeleton.c |2 +- drivers/net/pcmcia/3c574_cs.c |2 +- drivers/net/sc92031.c |2 +- drivers/net/tlan.c |2 +- drivers/net/tokenring/tms380tr.c|2 +- drivers/net/tulip/Kconfig |2 +- drivers/net/usb/plusb.c |2 +- drivers/net/wan/Kconfig
[RFC v4]update broken web addresses in the kernel.
On 09/27/2010 07:59 PM, Finn Thain wrote: > > On Sun, 26 Sep 2010, Justin P. Mattock wrote: > >> diff --git a/drivers/char/apm-emulation.c b/drivers/char/apm-emulation.c >> index 033e150..d7d9a78 100644 >> --- a/drivers/char/apm-emulation.c >> +++ b/drivers/char/apm-emulation.c >> @@ -8,7 +8,7 @@ >>* (APM) BIOS Interface Specification, Revision 1.2, February 1996. >>* >>* [This document is available from Microsoft at: >> - *http://www.microsoft.com/hwdev/busbios/amp_12.htm] >> + *http://www.microsoft.com/whdc/archive/amp_12.mspx] >>*/ > > > Can we lose the brackets? > > >> #include >> #include > >> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig >> index 280c9b5..b2bd5fb 100644 >> --- a/drivers/firmware/Kconfig >> +++ b/drivers/firmware/Kconfig >> @@ -73,8 +73,8 @@ config EFI_PCDP >>on how the driver discovers devices. >> >>You must also enable the appropriate drivers (serial, VGA, etc.) >> - >> - See<http://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf> >> + See [DIG64_HCDPv20_042804.pdf] available from > > > What are the square brackets for? > > >> +<http://www.dig64.org/specifications/> >> >> config DELL_RBU >> tristate "BIOS update support for DELL systems via sysfs" > >> diff --git a/drivers/firmware/pcdp.h b/drivers/firmware/pcdp.h >> index ce910d6..777d928 100644 >> --- a/drivers/firmware/pcdp.h >> +++ b/drivers/firmware/pcdp.h >> @@ -1,8 +1,8 @@ >> /* >>* Definitions for PCDP-defined console devices >>* >> - * v1.0a: http://www.dig64.org/specifications/DIG64_HCDPv10a_01.pdf >> - * v2.0: http://www.dig64.org/specifications/DIG64_PCDPv20.pdf >> + * For [v1.0a: DIG64_HCDPv10a_01.pdf] [v2.0: DIG64_PCDPv20.pdf] > > > For DIG64_HCDPv10a_01.pdf and DIG64_PCDPv20.pdf (v10.a and v2.0 resp.), > > >> + * Please see<http://www.dig64.org/specifications/> > > > please see<http://www.dig64.org/specifications/> > > >>* >>* (c) Copyright 2002, 2004 Hewlett-Packard Development Company, L.P. >>* Khalid Aziz >> diff --git a/drivers/gpu/drm/README.drm b/drivers/gpu/drm/README.drm >> index b5b3327..bf29068 100644 >> --- a/drivers/gpu/drm/README.drm >> +++ b/drivers/gpu/drm/README.drm >> @@ -28,7 +28,7 @@ ways: >> Documentation on the DRI is available from: >> http://dri.freedesktop.org/wiki/Documentation >> http://sourceforge.net/project/showfiles.php?group_id=387 >> -http://dri.sourceforge.net/doc/ >> +http://dri.sourceforge.net/doc/DRIuserguide.html > > > http://dri.freedesktop.org/wiki/Documentation > > >> >> For specific information about kernel-level support, see: >> > >> diff --git a/drivers/input/mouse/touchkit_ps2.c >> b/drivers/input/mouse/touchkit_ps2.c >> index 88121c5..e74753e 100644 >> --- a/drivers/input/mouse/touchkit_ps2.c >> +++ b/drivers/input/mouse/touchkit_ps2.c >> @@ -22,7 +22,7 @@ >>* Based upon touchkitusb.c >>* >>* Vendor documentation is available in support section of: >> - * http://www.egalax.com.tw/ >> + * >> http://home.eeti.com.tw/web20/drivers/Software%20Programming%20Guide_v2.0.pdf > > > The comment text needs to be fixed also. > > >>*/ >> >> #include > >> diff --git a/drivers/media/dvb/frontends/mt312.c >> b/drivers/media/dvb/frontends/mt312.c >> index 472907d..08023f1 100644 >> --- a/drivers/media/dvb/frontends/mt312.c >> +++ b/drivers/media/dvb/frontends/mt312.c >> @@ -20,8 +20,9 @@ >> Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. >> >> References: >> -http://products.zarlink.com/product_profiles/MT312.htm >> -http://products.zarlink.com/product_profiles/SL1935.htm >> +http://www.zarlink.com/zarlink/hs/71.htm >> +http://www.chipcatalog.com/Zarlink/MT312.htm >> +http://www.chipcatalog.com/Zarlink/SL1935.htm > > > There's no need for links to chipcatalog.com. As I said in the previous > review, we have search engines for finding datasheets. Besides, the old > links are in the web archive (complete with PDFs) so there's no need to > remove them. > > >> */ >> >> #include >> diff --git a/drivers/media/dvb/frontends/mt312.h >> b/drivers/media/dvb/frontends/mt312.h >> index 29e3bb5..6d32e3f 100644 >> --- a/drivers/media/dvb/frontends/mt312.h >> +++ b/dri
[RFC v4]update broken web addresses in the kernel.
On 09/27/2010 06:37 PM, Finn Thain wrote: > > On Mon, 27 Sep 2010, Justin P. Mattock wrote: > >> On 09/27/2010 09:03 AM, Joe Perches wrote: >>> On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote: >>>> On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: >>>>> Below is an updated patch from the original fixing broken web >>>>> addresses in the kernel. Thanks for all the help and info on this >>>>> to everybody.. Hopefully I didnt miss any of them(if so let me >>>>> know, and I'll resend). >>>> Changing a URL for a relocated page is one thing, but removing links >>>> isn't necessarily a great idea. Even if the site is technically >>>> gone, it may be possible to find information e.g through the >>>> Internet Archive Wayback Machine. >>> >>> Perhaps it'd be better to scrape the contents of the various web >>> pages, collect them somewhere like wiki.kernel.org and encourage >>> others to put new contributions in that site. > > The copyright problem aside, this might be a good idea for material not > already archived but I don't think it makes sense to start a new > archive when archive.org (or other) has the information. > > And which version(s) do you scrape? I discussed some problems with > changing URLs in another thread: http://lkml.org/lkml/2010/9/22/22 > > Anyway, without knowing what future archive(s) would be available or > relevant to any given URL in the future, I think the best we might do is a > "Retrieved on -MM-DD" qualification for new URLs. > >> >> >> yeah I think somebody was saying something about having a separate file, >> with all the web addresses in them or something...In any case, up to you >> guys.. > > I don't see how moving the addresses would help. > And would it not make the information harder to find? > > Finn > depends on how the setup is.. I was thinking of having some kind of letter/number scheme i.e. (A-13) in the comment, then in the file with all the addresses under article "A" 13th address down you would have the web address.(but keep in mind that's just speculation..) Justin P. Mattock
[RFC v4]update broken web addresses in the kernel.
On 09/27/2010 09:03 AM, Joe Perches wrote: > On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote: >> On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: >>> Below is an updated patch from the original fixing broken web addresses in >>> the kernel. >>> Thanks for all the help and info on this to everybody.. >>> Hopefully I didnt miss any of them(if so let me know, and I'll resend). >> Changing a URL for a relocated page is one thing, but removing links >> isn't necessarily a great idea. Even if the site is technically >> gone, it may be possible to find information e.g through the Internet >> Archive Wayback Machine. > > Perhaps it'd be better to scrape the contents of the various > web pages, collect them somewhere like wiki.kernel.org and > encourage others to put new contributions in that site. > > > > yeah I think somebody was saying something about having a separate file, with all the web addresses in them or something...In any case, up to you guys.. Justin P. Mattock
[RFC v4]update broken web addresses in the kernel.
On 09/27/2010 08:10 AM, John W. Linville wrote: > On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: >> Below is an updated patch from the original fixing broken web addresses in >> the kernel. >> Thanks for all the help and info on this to everybody.. >> Hopefully I didnt miss any of them(if so let me know, and I'll resend). > > Changing a URL for a relocated page is one thing, but removing links > isn't necessarily a great idea. Even if the site is technically > gone, it may be possible to find information e.g through the Internet > Archive Wayback Machine. > >> diff --git a/drivers/net/wireless/orinoco/main.c >> b/drivers/net/wireless/orinoco/main.c >> index e8e2d0f..ba10b07 100644 >> --- a/drivers/net/wireless/orinoco/main.c >> +++ b/drivers/net/wireless/orinoco/main.c >> @@ -17,7 +17,6 @@ >>* >>* Portions based on wvlan_cs.c 1.0.6, Copyright Andreas Neuhaus>* AT fasta.fh-dortmund.de> >> - * http://www.stud.fh-dortmund.de/~andy/wvlan/ >>* >>* The contents of this file are subject to the Mozilla Public License >>* Version 1.1 (the "License"); you may not use this file except in > > http://web.archive.org/web/20070716051348/http://www.stud.fh-dortmund.de/~andy/wvlan/ > most of the urls that are not removed that are still broken work with the wayback machine..(from what I remember this one would give me a server error(reason for removing), but it doesn't look so). Thanks for this, I'll change that up. Justin P. Mattock
Re: [RFC 1/3 v3]update web addresses in the kernel
alright(going to top post because of how long this is). I will go and make the changes and resend it out... On 09/26/2010 02:43 AM, Finn Thain wrote: Hi Justin, Some comments on your latest patch follow. On Fri, 24 Sep 2010, Justin P. Mattock wrote: --- a/drivers/ata/pata_it821x.c +++ b/drivers/ata/pata_it821x.c @@ -16,7 +16,7 @@ * Based in part on the ITE vendor provided SCSI driver. * * Documentation available from - * http://www.ite.com.tw/pc/IT8212F_V04.pdf + * http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3ID=5,91 The existence of the pdf could be useful information when one needs to locate a copy. I think the filename needs to be retained. * Some other documents are NDA. * * The ITE8212 isn't exactly a standard IDE controller. It has two diff --git a/drivers/edac/i82443bxgx_edac.c b/drivers/edac/i82443bxgx_edac.c index a2fa1fe..adb6574 100644 --- a/drivers/edac/i82443bxgx_edac.c +++ b/drivers/edac/i82443bxgx_edac.c @@ -12,7 +12,7 @@ * 440GX fix by Jason Uhlenkottjuhle...@akamai.com. * * Written with reference to 82443BX Host Bridge Datasheet: - * http://www.intel.com/design/chipsets/440/documentation.htm + * http://ark.intel.com/Product.aspx?id=27151 That's the wrong document. It refers to processor number 440 not the *440 chipsets. Google offers this link: http://download.intel.com/design/chipsets/datashts/29063301.pdf * references to this document given in []. * * This module doesn't support the 440LX, but it may be possible to diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 280c9b5..aec5691 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -74,7 +74,8 @@ config EFI_PCDP You must also enable the appropriate drivers (serial, VGA, etc.) - Seehttp://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf + See DIG64_HCDPv20_042804.pdf available from + http://www.dig64.org/specifications/ Can you do the same for IT8212F_V04.pdf above? config DELL_RBU tristate BIOS update support for DELL systems via sysfs diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 949326d..f3e9d45 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -76,7 +76,7 @@ EXPORT_SYMBOL(drm_mode_debug_printmodeline); * according to the hdisplay, vdisplay, vrefresh. * It is based from the VESA(TM) Coordinated Video Timing Generator by * Graham Loveridge April 9, 2003 available at - * http://www.vesa.org/public/CVT/CVTd6r1.xls + * http://www.elo.utfsm.cl/~elo212/docs/CVTd6r1.xls * * And it is copied from xf86CVTmode in xserver/hw/xfree86/modes/xf86cvt.c. * What I have done is to translate it by using integer calculation. /* * Keymap for ATCom AU-100 - * http://www.atcom.cn/En_products_AU100.html + * http://www.atcom.cn/products.html * http://www.packetizer.com/products/au100/ * http://www.voip-info.org/wiki/view/AU-100 * diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig index c714ca2..5e98430 100644 --- a/drivers/input/mouse/Kconfig +++ b/drivers/input/mouse/Kconfig @@ -27,10 +27,7 @@ config MOUSE_PS2 Synaptics, ALPS or Elantech TouchPad users might be interested in a specialized Xorg/XFree86 driver at: - http://w1.894.telia.com/~u89404340/touchpad/index.html - and a new version of GPM at: - http://www.geocities.com/dt_or/gpm/gpm.html This one is in the web archive so it might be a good idea to keep the URL? - to take advantage of the advanced features of the touchpad. + http://xorg.freedesktop.org/archive/individual/driver/ If unsure, say Y. diff --git a/drivers/media/video/cx23885/cx23885-417.c b/drivers/media/video/cx23885/cx23885-417.c index abd64e8..43eea3a 100644 --- a/drivers/media/video/cx23885/cx23885-417.c +++ b/drivers/media/video/cx23885/cx23885-417.c @@ -7,7 +7,7 @@ *(c) 2008 Steven Tothst...@linuxtv.org * - CX23885/7/8 support * - * Includes parts from the ivtv driver( http://ivtv.sourceforge.net/), + * Includes parts from the ivtv driver(http://sourceforge.net/projects/ivtv/), How about, + * Includes parts from the ivtv driverhttp://sourceforge.net/projects/ivtv/ * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by diff --git a/drivers/media/video/cx88/cx88-blackbird.c b/drivers/media/video/cx88/cx88-blackbird.c index e46e1ce..821766e 100644 --- a/drivers/media/video/cx88/cx88-blackbird.c +++ b/drivers/media/video/cx88/cx88-blackbird.c @@ -9,7 +9,7 @@ *(c) 2005-2006 Mauro Carvalho Chehabmche...@infradead.org *- video_ioctl2 conversion * - * Includes parts from the ivtv driver( http://ivtv.sourceforge.net/), + * Includes parts from the ivtv driver(http://sourceforge.net/projects/ivtv
Re: [RFC v4]update broken web addresses in the kernel.
On 09/27/2010 08:10 AM, John W. Linville wrote: On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: Below is an updated patch from the original fixing broken web addresses in the kernel. Thanks for all the help and info on this to everybody.. Hopefully I didnt miss any of them(if so let me know, and I'll resend). Changing a URL for a relocated page is one thing, but removing links isn't necessarily a great idea. Even if the site is technically gone, it may be possible to find information e.g through the Internet Archive Wayback Machine. diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c index e8e2d0f..ba10b07 100644 --- a/drivers/net/wireless/orinoco/main.c +++ b/drivers/net/wireless/orinoco/main.c @@ -17,7 +17,6 @@ * * Portions based on wvlan_cs.c 1.0.6, Copyright Andreas Neuhausandy * AT fasta.fh-dortmund.de - * http://www.stud.fh-dortmund.de/~andy/wvlan/ * * The contents of this file are subject to the Mozilla Public License * Version 1.1 (the License); you may not use this file except in http://web.archive.org/web/20070716051348/http://www.stud.fh-dortmund.de/~andy/wvlan/ most of the urls that are not removed that are still broken work with the wayback machine..(from what I remember this one would give me a server error(reason for removing), but it doesn't look so). Thanks for this, I'll change that up. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4]update broken web addresses in the kernel.
On 09/27/2010 09:03 AM, Joe Perches wrote: On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote: On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: Below is an updated patch from the original fixing broken web addresses in the kernel. Thanks for all the help and info on this to everybody.. Hopefully I didnt miss any of them(if so let me know, and I'll resend). Changing a URL for a relocated page is one thing, but removing links isn't necessarily a great idea. Even if the site is technically gone, it may be possible to find information e.g through the Internet Archive Wayback Machine. Perhaps it'd be better to scrape the contents of the various web pages, collect them somewhere like wiki.kernel.org and encourage others to put new contributions in that site. yeah I think somebody was saying something about having a separate file, with all the web addresses in them or something...In any case, up to you guys.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v4]update broken web addresses in the kernel.
On 09/27/2010 06:37 PM, Finn Thain wrote: On Mon, 27 Sep 2010, Justin P. Mattock wrote: On 09/27/2010 09:03 AM, Joe Perches wrote: On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote: On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote: Below is an updated patch from the original fixing broken web addresses in the kernel. Thanks for all the help and info on this to everybody.. Hopefully I didnt miss any of them(if so let me know, and I'll resend). Changing a URL for a relocated page is one thing, but removing links isn't necessarily a great idea. Even if the site is technically gone, it may be possible to find information e.g through the Internet Archive Wayback Machine. Perhaps it'd be better to scrape the contents of the various web pages, collect them somewhere like wiki.kernel.org and encourage others to put new contributions in that site. The copyright problem aside, this might be a good idea for material not already archived but I don't think it makes sense to start a new archive when archive.org (or other) has the information. And which version(s) do you scrape? I discussed some problems with changing URLs in another thread: http://lkml.org/lkml/2010/9/22/22 Anyway, without knowing what future archive(s) would be available or relevant to any given URL in the future, I think the best we might do is a Retrieved on -MM-DD qualification for new URLs. yeah I think somebody was saying something about having a separate file, with all the web addresses in them or something...In any case, up to you guys.. I don't see how moving the addresses would help. And would it not make the information harder to find? Finn depends on how the setup is.. I was thinking of having some kind of letter/number scheme i.e. (A-13) in the comment, then in the file with all the addresses under article A 13th address down you would have the web address.(but keep in mind that's just speculation..) Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v4]update broken web addresses in the kernel.
Below is an updated patch from the original fixing broken web addresses in the kernel. Thanks for all the help and info on this to everybody.. Hopefully I didnt miss any of them(if so let me know, and I'll resend). Signed-off-by: Justin P. Mattock Cc: Maciej W. Rozycki Cc: Geert Uytterhoeven Cc: Finn Thain Cc: Randy Dunlap Cc: Matt Turner Cc: Dimitry Torokhov Cc: Mike Frysinger Acked-by: Ben Pfaff Acked-by: Hans J. Koch --- drivers/ata/pata_it821x.c |4 ++-- drivers/atm/Kconfig |2 +- drivers/char/agp/Kconfig|2 +- drivers/char/agp/i460-agp.c |2 +- drivers/char/apm-emulation.c|2 +- drivers/char/ipmi/ipmi_bt_sm.c |2 +- drivers/char/ipmi/ipmi_si_intf.c|3 +-- drivers/char/n_r3964.c |1 - drivers/char/pcmcia/Kconfig |4 ++-- drivers/char/tpm/Kconfig|2 +- drivers/char/tpm/tpm_infineon.c |2 +- drivers/edac/edac_device_sysfs.c|2 +- drivers/edac/i82443bxgx_edac.c |2 +- drivers/firmware/Kconfig|4 ++-- drivers/firmware/edd.c |2 +- drivers/firmware/pcdp.h |4 ++-- drivers/gpu/drm/README.drm |2 +- drivers/gpu/drm/drm_modes.c |2 +- drivers/hwmon/adm1025.c |2 +- drivers/hwmon/adm1026.c |2 +- drivers/hwmon/f75375s.c |4 ++-- drivers/hwmon/g760a.c |2 +- drivers/hwmon/hwmon-vid.c |2 +- drivers/ide/hpt366.c|2 +- drivers/ide/ht6560b.c |1 - drivers/infiniband/Kconfig |4 ++-- drivers/infiniband/hw/cxgb3/Kconfig |2 +- drivers/infiniband/hw/cxgb4/Kconfig |2 +- drivers/infiniband/ulp/iser/Kconfig |2 +- drivers/input/joystick/gamecon.c|3 +-- drivers/input/misc/cm109.c |2 +- drivers/input/mouse/Kconfig |1 + drivers/input/mouse/touchkit_ps2.c |2 +- drivers/input/touchscreen/mk712.c |4 ++-- drivers/isdn/i4l/isdn_audio.c |2 +- drivers/macintosh/therm_adt746x.c |6 +++--- drivers/media/IR/keymaps/rc-manli.c |1 - drivers/media/dvb/frontends/mt312.c |5 +++-- drivers/media/dvb/frontends/mt312.h |5 +++-- drivers/media/dvb/ttpci/av7110.c| 10 ++ drivers/media/dvb/ttpci/av7110_av.c |2 +- drivers/media/dvb/ttpci/av7110_ca.c |2 +- drivers/media/dvb/ttpci/av7110_hw.c |2 +- drivers/media/dvb/ttpci/av7110_v4l.c|2 +- drivers/media/dvb/ttpci/budget-av.c |2 +- drivers/media/dvb/ttpci/budget-ci.c |2 +- drivers/media/dvb/ttpci/budget-core.c |2 +- drivers/media/dvb/ttpci/budget-patch.c |2 +- drivers/media/dvb/ttpci/budget.c|2 +- drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-typhoon.c |2 -- drivers/media/video/Kconfig |2 +- drivers/media/video/cafe_ccic.c |2 +- drivers/media/video/cx18/cx18-cards.c |2 +- drivers/media/video/cx23885/cx23885-417.c |2 +- drivers/media/video/cx88/cx88-blackbird.c |2 +- drivers/media/video/gspca/gspca.c |2 +- drivers/media/video/ivtv/ivtv-cards.c |2 +- drivers/media/video/mxb.c |2 +- drivers/media/video/sn9c102/sn9c102_pas202bcb.c |1 - drivers/misc/Kconfig|4 ++-- drivers/mtd/chips/cfi_cmdset_0002.c |4 ++-- drivers/mtd/devices/lart.c |2 +- drivers/mtd/ftl.c |2 +- drivers/mtd/maps/Kconfig|7 +++ drivers/mtd/maps/dilnetpc.c |3 +-- drivers/mtd/nand/cafe_nand.c|2 +- drivers/net/Kconfig | 21 ++--- drivers/net/appletalk/Kconfig |2 +- drivers/net/atp.c |2 +- drivers/net/epic100.c |4 ++-- drivers/net/hamachi.c |3 --- drivers/net/hamradio/Kconfig|2 +- drivers/net/ibmlana.c |2 +- drivers/net/irda/donauboe.h |2 +- drivers/net/pci-skeleton.c |2 +- drivers/net
[RFC 1/3 v3]update web addresses in the kernel
alright(going to top post because of how long this is). I will go and make the changes and resend it out... On 09/26/2010 02:43 AM, Finn Thain wrote: > > Hi Justin, > > Some comments on your latest patch follow. > > > On Fri, 24 Sep 2010, Justin P. Mattock wrote: > >> --- a/drivers/ata/pata_it821x.c >> +++ b/drivers/ata/pata_it821x.c >> @@ -16,7 +16,7 @@ >>* Based in part on the ITE vendor provided SCSI driver. >>* >>* Documentation available from >> - * http://www.ite.com.tw/pc/IT8212F_V04.pdf >> + * http://www.ite.com.tw/EN/products_more.aspx?CategoryID=3=5,91 > > The existence of the pdf could be useful information when one needs to > locate a copy. I think the filename needs to be retained. > > > >>* Some other documents are NDA. >>* >>* The ITE8212 isn't exactly a standard IDE controller. It has two > >> diff --git a/drivers/edac/i82443bxgx_edac.c b/drivers/edac/i82443bxgx_edac.c >> index a2fa1fe..adb6574 100644 >> --- a/drivers/edac/i82443bxgx_edac.c >> +++ b/drivers/edac/i82443bxgx_edac.c >> @@ -12,7 +12,7 @@ >>* 440GX fix by Jason Uhlenkott. >>* >>* Written with reference to 82443BX Host Bridge Datasheet: >> - * http://www.intel.com/design/chipsets/440/documentation.htm >> + * http://ark.intel.com/Product.aspx?id=27151 > > That's the wrong document. It refers to processor number 440 not the *440 > chipsets. > > Google offers this link: > http://download.intel.com/design/chipsets/datashts/29063301.pdf > > >>* references to this document given in []. >>* >>* This module doesn't support the 440LX, but it may be possible to >> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig >> index 280c9b5..aec5691 100644 >> --- a/drivers/firmware/Kconfig >> +++ b/drivers/firmware/Kconfig >> @@ -74,7 +74,8 @@ config EFI_PCDP >> >>You must also enable the appropriate drivers (serial, VGA, etc.) >> >> - See<http://www.dig64.org/specifications/DIG64_HCDPv20_042804.pdf> >> + See DIG64_HCDPv20_042804.pdf available from >> +<http://www.dig64.org/specifications/> > > Can you do the same for IT8212F_V04.pdf above? > > >> >> config DELL_RBU >> tristate "BIOS update support for DELL systems via sysfs" > >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c >> index 949326d..f3e9d45 100644 >> --- a/drivers/gpu/drm/drm_modes.c >> +++ b/drivers/gpu/drm/drm_modes.c >> @@ -76,7 +76,7 @@ EXPORT_SYMBOL(drm_mode_debug_printmodeline); >>* according to the hdisplay, vdisplay, vrefresh. >>* It is based from the VESA(TM) Coordinated Video Timing Generator by >>* Graham Loveridge April 9, 2003 available at >> - * http://www.vesa.org/public/CVT/CVTd6r1.xls >> + * http://www.elo.utfsm.cl/~elo212/docs/CVTd6r1.xls >>* >>* And it is copied from xf86CVTmode in xserver/hw/xfree86/modes/xf86cvt.c. >>* What I have done is to translate it by using integer calculation. > >> /* >>* Keymap for ATCom AU-100 >> - * http://www.atcom.cn/En_products_AU100.html >> + * http://www.atcom.cn/products.html >>* http://www.packetizer.com/products/au100/ >>* http://www.voip-info.org/wiki/view/AU-100 >>* >> diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig >> index c714ca2..5e98430 100644 >> --- a/drivers/input/mouse/Kconfig >> +++ b/drivers/input/mouse/Kconfig >> @@ -27,10 +27,7 @@ config MOUSE_PS2 >> >>Synaptics, ALPS or Elantech TouchPad users might be interested >>in a specialized Xorg/XFree86 driver at: >> -<http://w1.894.telia.com/~u89404340/touchpad/index.html> >> - and a new version of GPM at: >> -<http://www.geocities.com/dt_or/gpm/gpm.html> > > > This one is in the web archive so it might be a good idea to keep the URL? > > >> - to take advantage of the advanced features of the touchpad. >> +<http://xorg.freedesktop.org/archive/individual/driver/> >> >> If unsure, say Y. >> > >> diff --git a/drivers/media/video/cx23885/cx23885-417.c >> b/drivers/media/video/cx23885/cx23885-417.c >> index abd64e8..43eea3a 100644 >> --- a/drivers/media/video/cx23885/cx23885-417.c >> +++ b/drivers/media/video/cx23885/cx23885-417.c >> @@ -7,7 +7,7 @@ >>*(c) 2008 Steven Toth >>* - CX23885/7/8 support >>* >> - * Includes parts from the ivtv driver( http://ivtv.s
[RFC 2/3 v3]update web addresses in stagging
On 09/25/2010 01:47 PM, Matthew Dharm wrote: > On Fri, Sep 24, 2010 at 05:51:56PM -0700, Justin P. Mattock wrote: >> On 09/24/2010 05:34 PM, Greg KH wrote: >>> On Fri, Sep 24, 2010 at 05:08:56PM -0700, Justin P. Mattock wrote: >>>> The below patch, is a simple fix to a broken web address not using a >>>> period in it's >>>> name. I'll leave this up to you guys if you want to use it... >>>> >>>> Signed-off-by: Justin P. Mattock >>> >>> I'll queue it up, thanks. >>> >>> Oh, it's "staging", not "stagging" as you have up there in the Subject: >>> :) >>> >>> thanks, >>> >>> greg k-h >>> >> >> shoot... and I actually changed it from staging to stagging thinking >> that was correct..(duh).. >> >> Anyways alright.. I'll exclude this one if the other sets get finalized. > > One random suggestion: Perhaps you should include a date here? i.e. "URL > blah blah blah (as of Sept 2010)" > > That way, people have some idea how much they can trust that URL without > having to dig into the kernel history to see when it was last changed. > > Matt > well.. as it stand right now doing grep -Re "http" in all the directories(minus COPYING/MAINTAINERS) gave me a little over 2000 addresses to check(not so bad, only a few days worth of checking(finding the broken address is time consuming)).. so I could go back and do this for all of them except the webarchive addresses that are broken(maybe put a tag on them saying use_webarchive or something). then there is the question of how much more bloated will the kernel get with such a thing(I'm guessing not much, but then again you never know). Justin P. Mattock
[RFC 2/3 v3]update web addresses in stagging
On 09/24/2010 05:34 PM, Greg KH wrote: > On Fri, Sep 24, 2010 at 05:08:56PM -0700, Justin P. Mattock wrote: >> The below patch, is a simple fix to a broken web address not using a period >> in it's >> name. I'll leave this up to you guys if you want to use it... >> >> Signed-off-by: Justin P. Mattock > > I'll queue it up, thanks. > > Oh, it's "staging", not "stagging" as you have up there in the Subject: > :) > > thanks, > > greg k-h > shoot... and I actually changed it from staging to stagging thinking that was correct..(duh).. Anyways alright.. I'll exclude this one if the other sets get finalized. Justin P. Mattock
[RFC 3/3 v3]update broken web addresses archive dot org
Below is just a patch showing all the archive.org in the kernel so far. up to you if you guys want to use this.. Signed-off-by: Justin P. Mattock --- drivers/block/Kconfig |2 +- drivers/edac/i82975x_edac.c |2 +- drivers/hwmon/hwmon-vid.c |6 +++--- drivers/input/misc/cm109.c|4 ++-- drivers/media/IR/keymaps/rc-rc5-tv.c |2 +- drivers/media/dvb/pluto2/pluto2.c |2 +- drivers/media/radio/Kconfig |4 ++-- drivers/media/radio/radio-aztech.c|2 +- drivers/media/video/bt8xx/bttv-cards.c|2 +- drivers/media/video/pwc/philips.txt |2 +- drivers/mtd/maps/Kconfig |6 +++--- drivers/mtd/maps/pismo.c |2 +- drivers/mtd/maps/sc520cdp.c |2 +- drivers/net/8139too.c |2 +- drivers/net/Kconfig | 18 +- drivers/net/acenic.c |2 +- drivers/net/fealnx.c |2 +- drivers/net/hamachi.c |4 +++- drivers/net/lne390.c |4 ++-- drivers/net/natsemi.c |9 - drivers/net/pci-skeleton.c|4 ++-- drivers/net/starfire.c|7 +++ drivers/net/sundance.c|6 +++--- drivers/net/tokenring/Kconfig |2 +- drivers/net/wan/Kconfig | 12 ++-- drivers/net/wan/cosa.c|3 ++- drivers/net/wan/farsync.c |4 ++-- drivers/net/wan/sbni.c|2 +- drivers/net/wireless/ath/ath5k/reg.h |2 +- drivers/net/wireless/hostap/hostap_cs.c |2 +- drivers/parport/Kconfig |4 ++-- drivers/scsi/arm/Kconfig |2 +- drivers/scsi/ibmmca.c |4 ++-- drivers/serial/altera_uart.c |2 +- drivers/serial/sn_console.c |2 +- drivers/staging/comedi/drivers/c6xdigio.c |4 ++-- drivers/staging/comedi/drivers/pcl711.c |2 +- drivers/staging/go7007/go7007.txt |8 drivers/usb/serial/cypress_m8.c |2 +- drivers/usb/storage/unusual_devs.h|2 +- drivers/video/macfb.c |2 +- drivers/video/s3fb.c |2 +- drivers/video/svgalib.c |2 +- drivers/video/vt8623fb.c |2 +- drivers/watchdog/pcwd.c |2 +- fs/ncpfs/Kconfig |3 ++- fs/nls/Kconfig|2 +- fs/nls/nls_base.c |2 +- fs/reiserfs/procfs.c |4 ++-- include/linux/edd.h |5 +++-- include/linux/mtd/pismo.h |2 +- include/scsi/sg.h | 10 +- net/ipv4/Kconfig |4 ++-- net/ipv4/tcp_illinois.c |2 +- net/ipv4/tcp_lp.c |2 +- sound/isa/Kconfig |2 +- sound/isa/cmi8330.c |2 +- sound/oss/Kconfig |4 ++-- sound/pci/ac97/ac97_patch.c |2 +- sound/pci/nm256/nm256.c |2 +- 60 files changed, 108 insertions(+), 105 deletions(-) diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index de27768..645a3f8 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -169,7 +169,7 @@ config BLK_DEV_UMEM ---help--- Saying Y here will include support for the MM5415 family of battery backed (Non-volatile) RAM cards. - <http://www.umem.com/> + <http://web.archive.org/web/%2A/http://www.umem.com/> The cards appear as block devices that can be partitioned into as many as 15 partitions. diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c index 3218819..b2e6c21 100644 --- a/drivers/edac/i82975x_edac.c +++ b/drivers/edac/i82975x_edac.c @@ -1,6 +1,6 @@ /* * Intel 82975X Memory Controller kernel module - * (C) 2007 aCarLab (India) Pvt. Ltd. (http://acarlab.com) + * (C) 2007 aCarLab (India) Pvt. Ltd. (http://web.archive.org/web/%2A/http://acarlab.com) * (C) 2007 jetzbroadband (http://jetzbroadband.com) * This file may be distributed under the terms of the * GNU General Public License. diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c index 897702d..a26fa3f 100644 --- a/drivers/hwmon/hwmon-vid.c +++ b/drivers/hwmon/hwmon-vid.c @@ -43,15 +43,15 @@ * This corresponds to an arbitrary VRM code of 24 in the functions below. * These CPU models (K8 revision <= E) have 5 VID pins. See also: * Revision Guide for AMD Athlon 64 and AMD Opteron Processors, AMD Publication 25759, - * http://www.amd.c
[RFC 2/3 v3]update web addresses in stagging
The below patch, is a simple fix to a broken web address not using a period in it's name. I'll leave this up to you guys if you want to use it... Signed-off-by: Justin P. Mattock --- .../comedi/drivers/addi-data/APCI1710_82x54.c |2 +- .../comedi/drivers/addi-data/APCI1710_82x54.h |2 +- .../comedi/drivers/addi-data/APCI1710_Chrono.c |2 +- .../comedi/drivers/addi-data/APCI1710_Dig_io.c |2 +- .../comedi/drivers/addi-data/APCI1710_Dig_io.h |2 +- .../comedi/drivers/addi-data/APCI1710_INCCPT.c |2 +- .../comedi/drivers/addi-data/APCI1710_INCCPT.h |2 +- .../comedi/drivers/addi-data/APCI1710_Inp_cpt.c|2 +- .../comedi/drivers/addi-data/APCI1710_Inp_cpt.h|2 +- .../comedi/drivers/addi-data/APCI1710_Pwm.c|2 +- .../comedi/drivers/addi-data/APCI1710_Pwm.h|2 +- .../comedi/drivers/addi-data/APCI1710_Ssi.c|2 +- .../comedi/drivers/addi-data/APCI1710_Ssi.h|2 +- .../comedi/drivers/addi-data/APCI1710_Tor.c|2 +- .../comedi/drivers/addi-data/APCI1710_Tor.h|2 +- .../comedi/drivers/addi-data/APCI1710_Ttl.c|2 +- .../comedi/drivers/addi-data/APCI1710_Ttl.h|2 +- .../comedi/drivers/addi-data/addi_amcc_S5920.c |2 +- .../comedi/drivers/addi-data/addi_amcc_S5920.h |2 +- .../comedi/drivers/addi-data/addi_amcc_s5933.h |2 +- .../staging/comedi/drivers/addi-data/addi_common.c |2 +- .../staging/comedi/drivers/addi-data/addi_common.h |2 +- .../staging/comedi/drivers/addi-data/addi_eeprom.c |2 +- .../comedi/drivers/addi-data/hwdrv_APCI1710.c |2 +- .../comedi/drivers/addi-data/hwdrv_APCI1710.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci035.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci035.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1032.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1032.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1500.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1500.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1516.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1516.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1564.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1564.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci16xx.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2016.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2016.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci2032.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2032.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci2200.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2200.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3120.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3120.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3200.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3200.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3501.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3501.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3xxx.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3xxx.h |2 +- 50 files changed, 50 insertions(+), 50 deletions(-) diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c index 60213d2..b59f2d4 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c @@ -6,7 +6,7 @@ * D-77833 Ottersweier * Tel: +19(0)7223/9493-0 * Fax: +49(0)7223/9493-92 - * http://www.addi-data-com + * http://www.addi-data.com * info at addi-data.com * * This program is free software; you can redistribute it and/or modify it diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h index 9698ae1..81346db 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h @@ -6,7 +6,7 @@ * D-77833 Ottersweier * Tel: +19(0)7223/9493-0 * Fax: +49(0)7223/9493-92 - * http://www.addi-data-com + * http://www.addi-data.com * info at addi-data.com * * This program is free software; you can redistribute it and/or modify it diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c b/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c index fbc26a0..644bda4 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c @@ -8,7 +8,7 @@ Copyright (C) 2004,2005 ADDI-DATA GmbH for the source code of this module. D-77833 Ottersweier Tel: +19(0)7223/9493-0 Fax: +49(0)7223/9493-92 - http://www.addi-data-com
[RFC 1/3 v3]update web addresses in the kernel
Below is an updated patch to fix some of the broken web addresses in the kernel. Thanks to all the help from everybody, Ive made(hopefully)most of the changes. Please have a look when you have time, and let me know what might need fixing. Signed-off-by: Justin P. Mattock Cc: Maciej W. Rozycki Cc: Geert Uytterhoeven Cc: Finn Thain Cc: Randy Dunlap Cc: Matt Turner Cc: Dimitry Torokhov Cc: Mike Frysinger Acked-by: Ben Pfaff Acked-by: Hans J. Koch --- drivers/ata/pata_it821x.c |2 +- drivers/atm/Kconfig |2 +- drivers/char/agp/Kconfig|2 +- drivers/char/agp/i460-agp.c |2 +- drivers/char/apm-emulation.c|2 +- drivers/char/ipmi/ipmi_bt_sm.c |2 +- drivers/char/ipmi/ipmi_si_intf.c|3 +-- drivers/char/n_r3964.c |2 +- drivers/char/pcmcia/Kconfig |4 ++-- drivers/char/tpm/Kconfig|2 +- drivers/char/tpm/tpm_infineon.c |2 +- drivers/edac/edac_device_sysfs.c|2 +- drivers/edac/i82443bxgx_edac.c |2 +- drivers/firmware/Kconfig|3 ++- drivers/firmware/edd.c |2 +- drivers/firmware/pcdp.h |4 ++-- drivers/gpu/drm/README.drm |2 +- drivers/gpu/drm/drm_modes.c |2 +- drivers/hwmon/adm1025.c |2 +- drivers/hwmon/adm1026.c |2 +- drivers/hwmon/f75375s.c |4 ++-- drivers/hwmon/g760a.c |2 +- drivers/hwmon/hwmon-vid.c |2 +- drivers/ide/hpt366.c|2 +- drivers/ide/ht6560b.c |1 - drivers/infiniband/Kconfig |4 ++-- drivers/infiniband/hw/cxgb3/Kconfig |2 +- drivers/infiniband/hw/cxgb4/Kconfig |2 +- drivers/infiniband/ulp/iser/Kconfig |2 +- drivers/input/joystick/gamecon.c|3 +-- drivers/input/misc/cm109.c |2 +- drivers/input/mouse/Kconfig |5 + drivers/input/mouse/touchkit_ps2.c |2 +- drivers/input/touchscreen/mk712.c |2 +- drivers/isdn/i4l/isdn_audio.c |2 +- drivers/macintosh/therm_adt746x.c |4 ++-- drivers/media/IR/keymaps/rc-manli.c |1 - drivers/media/dvb/frontends/mt312.c |5 +++-- drivers/media/dvb/frontends/mt312.h |5 +++-- drivers/media/dvb/ttpci/av7110.c| 10 ++ drivers/media/dvb/ttpci/av7110_av.c |2 +- drivers/media/dvb/ttpci/av7110_ca.c |2 +- drivers/media/dvb/ttpci/av7110_hw.c |2 +- drivers/media/dvb/ttpci/av7110_v4l.c|2 +- drivers/media/dvb/ttpci/budget-av.c |2 +- drivers/media/dvb/ttpci/budget-ci.c |2 +- drivers/media/dvb/ttpci/budget-core.c |2 +- drivers/media/dvb/ttpci/budget-patch.c |2 +- drivers/media/dvb/ttpci/budget.c|2 +- drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-typhoon.c |2 -- drivers/media/video/Kconfig |2 +- drivers/media/video/cafe_ccic.c |2 +- drivers/media/video/cx18/cx18-cards.c |2 +- drivers/media/video/cx23885/cx23885-417.c |2 +- drivers/media/video/cx88/cx88-blackbird.c |2 +- drivers/media/video/gspca/gspca.c |1 + drivers/media/video/ivtv/ivtv-cards.c |2 +- drivers/media/video/mxb.c |2 +- drivers/media/video/sn9c102/sn9c102_pas202bcb.c |1 - drivers/misc/Kconfig|4 ++-- drivers/mtd/chips/cfi_cmdset_0002.c |4 ++-- drivers/mtd/devices/lart.c |2 +- drivers/mtd/ftl.c |2 +- drivers/mtd/maps/Kconfig|7 +++ drivers/mtd/maps/dilnetpc.c |3 +-- drivers/mtd/nand/cafe_nand.c|2 +- drivers/net/Kconfig | 18 +- drivers/net/appletalk/Kconfig |2 +- drivers/net/atp.c |2 +- drivers/net/epic100.c |4 ++-- drivers/net/hamachi.c |3 --- drivers/net/hamradio/Kconfig|2 +- drivers/net/ibmlana.c |2 +- drivers/net/irda/donauboe.h |4 ++-- drivers/net/pci-skeleton.c
[RFC 2/3 v3]update web addresses in stagging
The below patch, is a simple fix to a broken web address not using a period in it's name. I'll leave this up to you guys if you want to use it... Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- .../comedi/drivers/addi-data/APCI1710_82x54.c |2 +- .../comedi/drivers/addi-data/APCI1710_82x54.h |2 +- .../comedi/drivers/addi-data/APCI1710_Chrono.c |2 +- .../comedi/drivers/addi-data/APCI1710_Dig_io.c |2 +- .../comedi/drivers/addi-data/APCI1710_Dig_io.h |2 +- .../comedi/drivers/addi-data/APCI1710_INCCPT.c |2 +- .../comedi/drivers/addi-data/APCI1710_INCCPT.h |2 +- .../comedi/drivers/addi-data/APCI1710_Inp_cpt.c|2 +- .../comedi/drivers/addi-data/APCI1710_Inp_cpt.h|2 +- .../comedi/drivers/addi-data/APCI1710_Pwm.c|2 +- .../comedi/drivers/addi-data/APCI1710_Pwm.h|2 +- .../comedi/drivers/addi-data/APCI1710_Ssi.c|2 +- .../comedi/drivers/addi-data/APCI1710_Ssi.h|2 +- .../comedi/drivers/addi-data/APCI1710_Tor.c|2 +- .../comedi/drivers/addi-data/APCI1710_Tor.h|2 +- .../comedi/drivers/addi-data/APCI1710_Ttl.c|2 +- .../comedi/drivers/addi-data/APCI1710_Ttl.h|2 +- .../comedi/drivers/addi-data/addi_amcc_S5920.c |2 +- .../comedi/drivers/addi-data/addi_amcc_S5920.h |2 +- .../comedi/drivers/addi-data/addi_amcc_s5933.h |2 +- .../staging/comedi/drivers/addi-data/addi_common.c |2 +- .../staging/comedi/drivers/addi-data/addi_common.h |2 +- .../staging/comedi/drivers/addi-data/addi_eeprom.c |2 +- .../comedi/drivers/addi-data/hwdrv_APCI1710.c |2 +- .../comedi/drivers/addi-data/hwdrv_APCI1710.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci035.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci035.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1032.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1032.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1500.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1500.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1516.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1516.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci1564.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci1564.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci16xx.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2016.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2016.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci2032.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2032.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci2200.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci2200.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3120.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3120.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3200.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3200.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3501.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3501.h |2 +- .../comedi/drivers/addi-data/hwdrv_apci3xxx.c |2 +- .../comedi/drivers/addi-data/hwdrv_apci3xxx.h |2 +- 50 files changed, 50 insertions(+), 50 deletions(-) diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c index 60213d2..b59f2d4 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.c @@ -6,7 +6,7 @@ * D-77833 Ottersweier * Tel: +19(0)7223/9493-0 * Fax: +49(0)7223/9493-92 - * http://www.addi-data-com + * http://www.addi-data.com * i...@addi-data.com * * This program is free software; you can redistribute it and/or modify it diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h index 9698ae1..81346db 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_82x54.h @@ -6,7 +6,7 @@ * D-77833 Ottersweier * Tel: +19(0)7223/9493-0 * Fax: +49(0)7223/9493-92 - * http://www.addi-data-com + * http://www.addi-data.com * i...@addi-data.com * * This program is free software; you can redistribute it and/or modify it diff --git a/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c b/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c index fbc26a0..644bda4 100644 --- a/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c +++ b/drivers/staging/comedi/drivers/addi-data/APCI1710_Chrono.c @@ -8,7 +8,7 @@ Copyright (C) 2004,2005 ADDI-DATA GmbH for the source code of this module. D-77833 Ottersweier Tel: +19(0)7223/9493-0 Fax: +49(0)7223/9493-92 - http
[RFC 3/3 v3]update broken web addresses archive dot org
Below is just a patch showing all the archive.org in the kernel so far. up to you if you guys want to use this.. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/block/Kconfig |2 +- drivers/edac/i82975x_edac.c |2 +- drivers/hwmon/hwmon-vid.c |6 +++--- drivers/input/misc/cm109.c|4 ++-- drivers/media/IR/keymaps/rc-rc5-tv.c |2 +- drivers/media/dvb/pluto2/pluto2.c |2 +- drivers/media/radio/Kconfig |4 ++-- drivers/media/radio/radio-aztech.c|2 +- drivers/media/video/bt8xx/bttv-cards.c|2 +- drivers/media/video/pwc/philips.txt |2 +- drivers/mtd/maps/Kconfig |6 +++--- drivers/mtd/maps/pismo.c |2 +- drivers/mtd/maps/sc520cdp.c |2 +- drivers/net/8139too.c |2 +- drivers/net/Kconfig | 18 +- drivers/net/acenic.c |2 +- drivers/net/fealnx.c |2 +- drivers/net/hamachi.c |4 +++- drivers/net/lne390.c |4 ++-- drivers/net/natsemi.c |9 - drivers/net/pci-skeleton.c|4 ++-- drivers/net/starfire.c|7 +++ drivers/net/sundance.c|6 +++--- drivers/net/tokenring/Kconfig |2 +- drivers/net/wan/Kconfig | 12 ++-- drivers/net/wan/cosa.c|3 ++- drivers/net/wan/farsync.c |4 ++-- drivers/net/wan/sbni.c|2 +- drivers/net/wireless/ath/ath5k/reg.h |2 +- drivers/net/wireless/hostap/hostap_cs.c |2 +- drivers/parport/Kconfig |4 ++-- drivers/scsi/arm/Kconfig |2 +- drivers/scsi/ibmmca.c |4 ++-- drivers/serial/altera_uart.c |2 +- drivers/serial/sn_console.c |2 +- drivers/staging/comedi/drivers/c6xdigio.c |4 ++-- drivers/staging/comedi/drivers/pcl711.c |2 +- drivers/staging/go7007/go7007.txt |8 drivers/usb/serial/cypress_m8.c |2 +- drivers/usb/storage/unusual_devs.h|2 +- drivers/video/macfb.c |2 +- drivers/video/s3fb.c |2 +- drivers/video/svgalib.c |2 +- drivers/video/vt8623fb.c |2 +- drivers/watchdog/pcwd.c |2 +- fs/ncpfs/Kconfig |3 ++- fs/nls/Kconfig|2 +- fs/nls/nls_base.c |2 +- fs/reiserfs/procfs.c |4 ++-- include/linux/edd.h |5 +++-- include/linux/mtd/pismo.h |2 +- include/scsi/sg.h | 10 +- net/ipv4/Kconfig |4 ++-- net/ipv4/tcp_illinois.c |2 +- net/ipv4/tcp_lp.c |2 +- sound/isa/Kconfig |2 +- sound/isa/cmi8330.c |2 +- sound/oss/Kconfig |4 ++-- sound/pci/ac97/ac97_patch.c |2 +- sound/pci/nm256/nm256.c |2 +- 60 files changed, 108 insertions(+), 105 deletions(-) diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index de27768..645a3f8 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -169,7 +169,7 @@ config BLK_DEV_UMEM ---help--- Saying Y here will include support for the MM5415 family of battery backed (Non-volatile) RAM cards. - http://www.umem.com/ + http://web.archive.org/web/%2A/http://www.umem.com/ The cards appear as block devices that can be partitioned into as many as 15 partitions. diff --git a/drivers/edac/i82975x_edac.c b/drivers/edac/i82975x_edac.c index 3218819..b2e6c21 100644 --- a/drivers/edac/i82975x_edac.c +++ b/drivers/edac/i82975x_edac.c @@ -1,6 +1,6 @@ /* * Intel 82975X Memory Controller kernel module - * (C) 2007 aCarLab (India) Pvt. Ltd. (http://acarlab.com) + * (C) 2007 aCarLab (India) Pvt. Ltd. (http://web.archive.org/web/%2A/http://acarlab.com) * (C) 2007 jetzbroadband (http://jetzbroadband.com) * This file may be distributed under the terms of the * GNU General Public License. diff --git a/drivers/hwmon/hwmon-vid.c b/drivers/hwmon/hwmon-vid.c index 897702d..a26fa3f 100644 --- a/drivers/hwmon/hwmon-vid.c +++ b/drivers/hwmon/hwmon-vid.c @@ -43,15 +43,15 @@ * This corresponds to an arbitrary VRM code of 24 in the functions below. * These CPU models (K8 revision = E) have 5 VID pins. See also: * Revision Guide for AMD Athlon 64 and AMD Opteron Processors, AMD Publication 25759, - * http
Re: [RFC 2/3 v3]update web addresses in stagging
On 09/24/2010 05:34 PM, Greg KH wrote: On Fri, Sep 24, 2010 at 05:08:56PM -0700, Justin P. Mattock wrote: The below patch, is a simple fix to a broken web address not using a period in it's name. I'll leave this up to you guys if you want to use it... Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com I'll queue it up, thanks. Oh, it's staging, not stagging as you have up there in the Subject: :) thanks, greg k-h shoot... and I actually changed it from staging to stagging thinking that was correct..(duh).. Anyways alright.. I'll exclude this one if the other sets get finalized. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
On 07/07/2010 11:44 PM, Ingo Molnar wrote: > > * Justin P. Mattock wrote: > >> On 07/02/10 13:04, Justin P. Mattock wrote: >>> this is new(below) has anybody reported/bisected hit this yet >>> (if not I'll bisect it) >>> >>> [drm] Num pipes: 1 >>> [ 29.742432] [drm] writeback test succeeded in 1 usecs >>> [ 30.089717] X:2252 conflicting memory types 4000-4800 >>> uncached-minus<->write-combining >>> [ 30.089721] reserve_memtype failed 0x4000-0x4800, track >>> uncached-minus, req uncached-minus >>> [ 30.123517] [drm] Num pipes: 1 >>> [ 30.351017] X:2252 freeing invalid memtype 4000-4800 >>> [ 30.354255] CPU 0 >>> [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm >>> sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat >>> nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack >>> nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci >>> firewire_core video battery ath9k ac ath9k_common joydev sky2 >>> ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse >>> aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null >>> sha256_generic cbc des_generic cast5 blowfish serpent camellia >>> twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 >>> uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth >>> coretemp acpi_cpufreq processor mperf appletouch applesmc >>> uvcvideo[ 30.354255] >>> [ 30.354255] Pid: 2252, comm: X Not tainted >>> 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 >>> [ 30.354255] RIP: 0010:[] >>> [] radeon_read_ring_rptr+0x2b/0x2f [radeon] >>> [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 >>> [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: >>> c9cf8000 >>> [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: >>> 8800385e8848 >>> [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: >>> 0010 >>> [ 30.354255] R10: R11: ea930af0 R12: >>> 0010 >>> [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: >>> 8800385e8178 >>> [ 30.354255] FS: 7f0aaa823840() >>> GS:880001a0() knlGS: >>> [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 >>> [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: >>> 06f0 >>> [ 30.354255] DR0: DR1: DR2: >>> >>> [ 30.354255] DR3: DR6: 0ff0 DR7: >>> 0400 >>> [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, >>> task 880033dc5c40) >>> [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 >>> a035881c >>> [ 30.354255]<0> 8800385e8848 8800360dfcc8 >>> a0359ac7 >>> [ 30.354255]<0> 8800385e8848 8800360dfce8 >>> a035c961 8800385e8848 >>> [ 30.354255] [] >>> radeon_get_ring_head+0x11/0x3c [radeon] >>> [ 30.354255] [] radeon_commit_ring+0x48/0x97 >>> [radeon] >>> [ 30.354255] [] radeon_do_cp_idle+0x140/0x14d >>> [radeon] >>> [ 30.354255] [] >>> radeon_apply_surface_regs+0x22/0x138 [radeon] >>> [ 30.354255] [] free_surface+0xd8/0xee [radeon] >>> [ 30.354255] [] >>> radeon_driver_lastclose+0x3c/0x56 [radeon] >>> [ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] >>> [ 30.354255] [] drm_release+0x656/0x6a3 [drm] >>> [ 30.354255] [] put_files_struct+0x65/0xb3 >>> [ 30.354255] [] exit_files+0x46/0x4e >>> [ 30.354255] [] do_exit+0x214/0x69f >>> [ 30.354255] [] ? fput+0x1e2/0x1f1 >>> [ 30.354255] [] do_group_exit+0x72/0x9a >>> [ 30.354255] [] sys_exit_group+0x12/0x16 >>> [ 30.354255] [] system_call_fastpath+0x16/0x1b >>> [ 30.354255] RSP >>> [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- >>> [ 30.354255] [] fput+0x122/0x1f1 >>> [ 30.354255] [] filp_close+0x63/0x6d >>> >>> Justin P. Mattock >> >> o.k. finished bisecting.. the results point to this: 6a4f3b523 doing >> a git revert gets me to startx without crashing and burning. >> the problem code is this: >> new->subtree_max_end = new->end; >> >> which sends me to: (if im reading correctly) >> if (match->type != found_type&& newtype == NULL) >> goto failure; >> >> so how/what might be happening here?! > > Could you please check latest upstream, which has this fix: > >b945d6b: rbtree: Undo augmented trees performance damage and regression > > Does it fix your X too? > > Thanks, > > Ingo > yep.. just pulled, everything looks good... Justin P. Mattock
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
On 07/02/10 13:04, Justin P. Mattock wrote: > this is new(below) has anybody reported/bisected hit this yet > (if not I'll bisect it) > > [drm] Num pipes: 1 > [ 29.742432] [drm] writeback test succeeded in 1 usecs > [ 30.089717] X:2252 conflicting memory types 4000-4800 > uncached-minus<->write-combining > [ 30.089721] reserve_memtype failed 0x4000-0x4800, track > uncached-minus, req uncached-minus > [ 30.123517] [drm] Num pipes: 1 > [ 30.351017] X:2252 freeing invalid memtype 4000-4800 > [ 30.354255] CPU 0 > [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco > xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat > xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack > nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci > firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw > ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 > lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic > cbc des_generic cast5 blowfish serpent camellia twofish twofish_common > ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart > rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor > mperf appletouch applesmc uvcvideo[ 30.354255] > [ 30.354255] Pid: 2252, comm: X Not tainted > 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 > [ 30.354255] RIP: 0010:[] [] > radeon_read_ring_rptr+0x2b/0x2f [radeon] > [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 > [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: > c9cf8000 > [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: > 8800385e8848 > [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: > 0010 > [ 30.354255] R10: R11: ea930af0 R12: > 0010 > [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: > 8800385e8178 > [ 30.354255] FS: 7f0aaa823840() GS:880001a0() > knlGS: > [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 > [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: > 06f0 > [ 30.354255] DR0: DR1: DR2: > > [ 30.354255] DR3: DR6: 0ff0 DR7: > 0400 > [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, task > 880033dc5c40) > [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 > a035881c > [ 30.354255] <0> 8800385e8848 8800360dfcc8 a0359ac7 > > [ 30.354255] <0> 8800385e8848 8800360dfce8 a035c961 > 8800385e8848 > [ 30.354255] [] radeon_get_ring_head+0x11/0x3c > [radeon] > [ 30.354255] [] radeon_commit_ring+0x48/0x97 > [radeon] > [ 30.354255] [] radeon_do_cp_idle+0x140/0x14d > [radeon] > [ 30.354255] [] > radeon_apply_surface_regs+0x22/0x138 [radeon] > [ 30.354255] [] free_surface+0xd8/0xee [radeon] > [ 30.354255] [] radeon_driver_lastclose+0x3c/0x56 > [radeon] > [ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] > [ 30.354255] [] drm_release+0x656/0x6a3 [drm] > [ 30.354255] [] put_files_struct+0x65/0xb3 > [ 30.354255] [] exit_files+0x46/0x4e > [ 30.354255] [] do_exit+0x214/0x69f > [ 30.354255] [] ? fput+0x1e2/0x1f1 > [ 30.354255] [] do_group_exit+0x72/0x9a > [ 30.354255] [] sys_exit_group+0x12/0x16 > [ 30.354255] [] system_call_fastpath+0x16/0x1b > [ 30.354255] RSP > [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- > [ 30.354255] [] fput+0x122/0x1f1 > [ 30.354255] [] filp_close+0x63/0x6d > > Justin P. Mattock o.k. finished bisecting.. the results point to this: 6a4f3b523 doing a git revert gets me to startx without crashing and burning. the problem code is this: new->subtree_max_end = new->end; which sends me to: (if im reading correctly) if (match->type != found_type && newtype == NULL) goto failure; so how/what might be happening here?! Justin P. Mattock
X:2252 conflicting memory types 40000000-48000000 uncached-minus<->write-combining
this is new(below) has anybody reported/bisected hit this yet (if not I'll bisect it) [drm] Num pipes: 1 [ 29.742432] [drm] writeback test succeeded in 1 usecs [ 30.089717] X:2252 conflicting memory types 4000-4800 uncached-minus<->write-combining [ 30.089721] reserve_memtype failed 0x4000-0x4800, track uncached-minus, req uncached-minus [ 30.123517] [drm] Num pipes: 1 [ 30.351017] X:2252 freeing invalid memtype 4000-4800 [ 30.354255] CPU 0 [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc uvcvideo[ 30.354255] [ 30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 [ 30.354255] RIP: 0010:[] [] radeon_read_ring_rptr+0x2b/0x2f [radeon] [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: c9cf8000 [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 8800385e8848 [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 0010 [ 30.354255] R10: R11: ea930af0 R12: 0010 [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 8800385e8178 [ 30.354255] FS: 7f0aaa823840() GS:880001a0() knlGS: [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 06f0 [ 30.354255] DR0: DR1: DR2: [ 30.354255] DR3: DR6: 0ff0 DR7: 0400 [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 880033dc5c40) [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 a035881c [ 30.354255] <0> 8800385e8848 8800360dfcc8 a0359ac7 [ 30.354255] <0> 8800385e8848 8800360dfce8 a035c961 8800385e8848 [ 30.354255] [] radeon_get_ring_head+0x11/0x3c [radeon] [ 30.354255] [] radeon_commit_ring+0x48/0x97 [radeon] [ 30.354255] [] radeon_do_cp_idle+0x140/0x14d [radeon] [ 30.354255] [] radeon_apply_surface_regs+0x22/0x138 [radeon] [ 30.354255] [] free_surface+0xd8/0xee [radeon] [ 30.354255] [] radeon_driver_lastclose+0x3c/0x56 [radeon] [ 30.354255] [] drm_lastclose+0x44/0x2ad [drm] [ 30.354255] [] drm_release+0x656/0x6a3 [drm] [ 30.354255] [] put_files_struct+0x65/0xb3 [ 30.354255] [] exit_files+0x46/0x4e [ 30.354255] [] do_exit+0x214/0x69f [ 30.354255] [] ? fput+0x1e2/0x1f1 [ 30.354255] [] do_group_exit+0x72/0x9a [ 30.354255] [] sys_exit_group+0x12/0x16 [ 30.354255] [] system_call_fastpath+0x16/0x1b [ 30.354255] RSP [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- [ 30.354255] [] fput+0x122/0x1f1 [ 30.354255] [] filp_close+0x63/0x6d Justin P. Mattock
X:2252 conflicting memory types 40000000-48000000 uncached-minus-write-combining
this is new(below) has anybody reported/bisected hit this yet (if not I'll bisect it) [drm] Num pipes: 1 [ 29.742432] [drm] writeback test succeeded in 1 usecs [ 30.089717] X:2252 conflicting memory types 4000-4800 uncached-minus-write-combining [ 30.089721] reserve_memtype failed 0x4000-0x4800, track uncached-minus, req uncached-minus [ 30.123517] [drm] Num pipes: 1 [ 30.351017] X:2252 freeing invalid memtype 4000-4800 [ 30.354255] CPU 0 [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc uvcvideo[ 30.354255] [ 30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 [ 30.354255] RIP: 0010:[a035811b] [a035811b] radeon_read_ring_rptr+0x2b/0x2f [radeon] [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: c9cf8000 [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 8800385e8848 [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 0010 [ 30.354255] R10: R11: ea930af0 R12: 0010 [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 8800385e8178 [ 30.354255] FS: 7f0aaa823840() GS:880001a0() knlGS: [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 06f0 [ 30.354255] DR0: DR1: DR2: [ 30.354255] DR3: DR6: 0ff0 DR7: 0400 [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 880033dc5c40) [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 a035881c [ 30.354255] 0 8800385e8848 8800360dfcc8 a0359ac7 [ 30.354255] 0 8800385e8848 8800360dfce8 a035c961 8800385e8848 [ 30.354255] [a0358130] radeon_get_ring_head+0x11/0x3c [radeon] [ 30.354255] [a035881c] radeon_commit_ring+0x48/0x97 [radeon] [ 30.354255] [a0359ac7] radeon_do_cp_idle+0x140/0x14d [radeon] [ 30.354255] [a035c961] radeon_apply_surface_regs+0x22/0x138 [radeon] [ 30.354255] [a035cb4f] free_surface+0xd8/0xee [radeon] [ 30.354255] [a0365036] radeon_driver_lastclose+0x3c/0x56 [radeon] [ 30.354255] [a031440b] drm_lastclose+0x44/0x2ad [drm] [ 30.354255] [a0314eda] drm_release+0x656/0x6a3 [drm] [ 30.354255] [8105abaf] put_files_struct+0x65/0xb3 [ 30.354255] [8105ac43] exit_files+0x46/0x4e [ 30.354255] [8105c2e6] do_exit+0x214/0x69f [ 30.354255] [810ebc2e] ? fput+0x1e2/0x1f1 [ 30.354255] [8105c7e3] do_group_exit+0x72/0x9a [ 30.354255] [8105c81d] sys_exit_group+0x12/0x16 [ 30.354255] [81026442] system_call_fastpath+0x16/0x1b [ 30.354255] RSP 8800360dfc80 [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- [ 30.354255] [810ebb6e] fput+0x122/0x1f1 [ 30.354255] [810e9181] filp_close+0x63/0x6d Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected]X:2252 conflicting memory types 40000000-48000000 uncached-minus-write-combining
On 07/02/10 13:04, Justin P. Mattock wrote: this is new(below) has anybody reported/bisected hit this yet (if not I'll bisect it) [drm] Num pipes: 1 [ 29.742432] [drm] writeback test succeeded in 1 usecs [ 30.089717] X:2252 conflicting memory types 4000-4800 uncached-minus-write-combining [ 30.089721] reserve_memtype failed 0x4000-0x4800, track uncached-minus, req uncached-minus [ 30.123517] [drm] Num pipes: 1 [ 30.351017] X:2252 freeing invalid memtype 4000-4800 [ 30.354255] CPU 0 [ 30.354255] Modules linked in: radeon ttm drm_kms_helper drm sco xcbc bnep rmd160 sha512_generic xt_tcpudp ipt_LOG iptable_nat nf_nat xt_state nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables firewire_ohci firewire_core video battery ath9k ac ath9k_common joydev sky2 ath9k_hw ohci1394 ath thermal evdev button i2c_i801 hid_magicmouse aes_x86_64 lzo lzo_compress zlib ipcomp xfrm_ipcomp crypto_null sha256_generic cbc des_generic cast5 blowfish serpent camellia twofish twofish_common ctr ah4 esp4 authenc raw1394 ieee1394 uhci_hcd ehci_hcd hci_uart rfcomm btusb hidp l2cap bluetooth coretemp acpi_cpufreq processor mperf appletouch applesmc uvcvideo[ 30.354255] [ 30.354255] Pid: 2252, comm: X Not tainted 2.6.35-rc3-00397-g123f94f #3 Mac-F42187C8/MacBookPro2,2 [ 30.354255] RIP: 0010:[a035811b] [a035811b] radeon_read_ring_rptr+0x2b/0x2f [radeon] [ 30.354255] RSP: 0018:8800360dfc80 EFLAGS: 00010202 [ 30.354255] RAX: 88003e0085d8 RBX: 8800385e8848 RCX: c9cf8000 [ 30.354255] RDX: 0028 RSI: 6b6b6b6b6b6b6b6b RDI: 8800385e8848 [ 30.354255] RBP: 8800360dfc80 R08: 8800385e8a28 R09: 0010 [ 30.354255] R10: R11: ea930af0 R12: 0010 [ 30.354255] R13: 8800385e8000 R14: 8800385e89c8 R15: 8800385e8178 [ 30.354255] FS: 7f0aaa823840() GS:880001a0() knlGS: [ 30.354255] CS: 0010 DS: ES: CR0: 80050033 [ 30.354255] CR2: 7f0a9ad67118 CR3: 0166d000 CR4: 06f0 [ 30.354255] DR0: DR1: DR2: [ 30.354255] DR3: DR6: 0ff0 DR7: 0400 [ 30.354255] Process X (pid: 2252, threadinfo 8800360de000, task 880033dc5c40) [ 30.354255] 8800360dfc90 a0358130 8800360dfca8 a035881c [ 30.354255] 0 8800385e8848 8800360dfcc8 a0359ac7 [ 30.354255] 0 8800385e8848 8800360dfce8 a035c961 8800385e8848 [ 30.354255] [a0358130] radeon_get_ring_head+0x11/0x3c [radeon] [ 30.354255] [a035881c] radeon_commit_ring+0x48/0x97 [radeon] [ 30.354255] [a0359ac7] radeon_do_cp_idle+0x140/0x14d [radeon] [ 30.354255] [a035c961] radeon_apply_surface_regs+0x22/0x138 [radeon] [ 30.354255] [a035cb4f] free_surface+0xd8/0xee [radeon] [ 30.354255] [a0365036] radeon_driver_lastclose+0x3c/0x56 [radeon] [ 30.354255] [a031440b] drm_lastclose+0x44/0x2ad [drm] [ 30.354255] [a0314eda] drm_release+0x656/0x6a3 [drm] [ 30.354255] [8105abaf] put_files_struct+0x65/0xb3 [ 30.354255] [8105ac43] exit_files+0x46/0x4e [ 30.354255] [8105c2e6] do_exit+0x214/0x69f [ 30.354255] [810ebc2e] ? fput+0x1e2/0x1f1 [ 30.354255] [8105c7e3] do_group_exit+0x72/0x9a [ 30.354255] [8105c81d] sys_exit_group+0x12/0x16 [ 30.354255] [81026442] system_call_fastpath+0x16/0x1b [ 30.354255] RSP 8800360dfc80 [ 31.312879] ---[ end trace 9a7b92300d4121f6 ]--- [ 30.354255] [810ebb6e] fput+0x122/0x1f1 [ 30.354255] [810e9181] filp_close+0x63/0x6d Justin P. Mattock o.k. finished bisecting.. the results point to this: 6a4f3b523 doing a git revert gets me to startx without crashing and burning. the problem code is this: new-subtree_max_end = new-end; which sends me to: (if im reading correctly) if (match-type != found_type newtype == NULL) goto failure; so how/what might be happening here?! Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8 v2]drm:drm_gem Fix warning: variable 'dev' set but not used
This is a redu due to the original being completly wrong
(better to leave a warning than shut it off).
I've removed the "dev =" variable but then receive a
drm_gem.c:207:2: warning: statement with no effect
telling me this thing is not doing anything according to gcc
so the below patch fixes a warning from gcc:
CC [M] drivers/gpu/drm/drm_gem.o
drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete':
drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used
have a look if you have the time, and if theres something else
to do then let me know(i'll test it out!!)
Signed-off-by: Justin P. Mattock
---
drivers/gpu/drm/drm_gem.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 33dad3f..d1648bf 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -185,7 +185,6 @@ EXPORT_SYMBOL(drm_gem_object_alloc);
static int
drm_gem_handle_delete(struct drm_file *filp, u32 handle)
{
- struct drm_device *dev;
struct drm_gem_object *obj;
/* This is gross. The idr system doesn't let us try a delete and
@@ -205,7 +204,6 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
spin_unlock(>table_lock);
return -EINVAL;
}
- dev = obj->dev;
/* Release reference and decrement refcount. */
idr_remove(>object_idr, handle);
--
1.7.1.rc1.21.gf3bd6
Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/15/2010 04:43 AM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 14:06:12 -0700, Justin P. Mattock wrote: On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) I was not (yet) arguing on the code itself, but on its format. Any patch you send should pass the formatting tests performed by scripts/checkpatch.pl. Thanks. o.k. I'll make sure I run everything through checkpatch.pl before sending anything. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/15/2010 11:53 AM, Sergey V. wrote:
> On Tuesday 15 of June 2010 00:26:44 Justin P. Mattock wrote:
>> Im getting this warning when compiling:
>> CC drivers/char/tpm/tpm.o
>> drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt':
>> drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used
>>
>> The below patch gets rid of the warning,
>> but I'm not sure if it's the best solution.
>>
>> Signed-off-by: Justin P. Mattock
>>
>> ---
>> drivers/char/tpm/tpm.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
>> index 05ad4a1..3d685dc 100644
>> --- a/drivers/char/tpm/tpm.c
>> +++ b/drivers/char/tpm/tpm.c
>> @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip)
>>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
>> "attempting to determine the timeouts");
>> +if (!rc)
>> +rc = 0;
>> }
>> EXPORT_SYMBOL_GPL(tpm_gen_interrupt);
>>
>> --
>> 1.7.1.rc1.21.gf3bd6
>>
>
> Hi Justin
>
> IMHO
> See code of functions tpm_transmit(), transmit_cmd and tpm_gen_interrupt().
> In tpm_gen_interrupt() not need check rc for wrong value bacause if in
> function
> transmit_cmd() len == TPM_ERROR_SIZE then put a debug message (dev_dbg()).
> Again, if something wrong in tpm_transmit() then runs dev_err() and rc in
> tpm_gen_interrupt() get -E* value.
> So, we can remove unused rc variable in tpm_gen_interrupt().
>
> See patch below. Note: I not tested it.
>
>
> Subject: [PATCH] drivers: tpm.c: Remove unused variable 'rc'
>
> ---
> drivers/char/tpm/tpm.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
> index 05ad4a1..f9f5b47 100644
> --- a/drivers/char/tpm/tpm.c
> +++ b/drivers/char/tpm/tpm.c
> @@ -505,15 +505,14 @@ ssize_t tpm_getcap(struct device *dev, __be32 subcap_id,
> cap_t *cap,
> void tpm_gen_interrupt(struct tpm_chip *chip)
> {
> struct tpm_cmd_t tpm_cmd;
> - ssize_t rc;
>
> tpm_cmd.header.in = tpm_getcap_header;
> tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_TIMEOUT;
>
> - rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
> - "attempting to determine the timeouts");
> + transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
> + "attempting to determine the timeouts");
> }
> EXPORT_SYMBOL_GPL(tpm_gen_interrupt);
>
o.k. applied this patch and rebuilt, here is what I see:
CC [M] drivers/char/ipmi/ipmi_poweroff.o
CC drivers/char/tpm/tpm.o
CC drivers/char/tpm/tpm_bios.o
CC drivers/char/tpm/tpm_tis.o
LD drivers/char/tpm/built-in.o
looks good over here Thanks for sending this..
Justin P. Mattock
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
On 06/15/2010 04:38 AM, Jean Delvare wrote: > On Mon, 14 Jun 2010 13:26:47 -0700, Justin P. Mattock wrote: >> Temporary fix until something is resolved > > This is wrong by design, sorry. Warnings aren't blocking, and thus need > no "temporary fix". Such temporary fixes would be only hiding the > warning, cancelling the good work of gcc developers. Nack nack nack. > o.k. >> to fix the below warning: >>CC [M] drivers/ieee1394/sbp2.o >> drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': >> drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set >> but not used >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/ieee1394/sbp2.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c >> index 4565cb5..fcf8bd5 100644 >> --- a/drivers/ieee1394/sbp2.c >> +++ b/drivers/ieee1394/sbp2.c >> @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu >> *lu, >> >> management_agent_addr = 0; >> unit_characteristics = 0; >> +if (!unit_characteristics) >> +unit_characteristics = 0; >> firmware_revision = SBP2_ROM_VALUE_MISSING; >> model = ud->flags& UNIT_DIRECTORY_MODEL_ID ? >> ud->model_id : SBP2_ROM_VALUE_MISSING; > > Thanks for the response and info on this. Justin P. Mattock
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/15/2010 04:43 AM, Jean Delvare wrote: > Hi Justin, > > On Mon, 14 Jun 2010 14:06:12 -0700, Justin P. Mattock wrote: >> On 06/14/2010 01:53 PM, Jean Delvare wrote: >>> Hi Justin, >>> >>> On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: >>>> could be a right solution, could be wrong >>>> here is the warning: >>>> CC drivers/i2c/i2c-core.o >>>> drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': >>>> drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used >>>> >>>>Signed-off-by: Justin P. Mattock >>>> >>>> --- >>>>drivers/i2c/i2c-core.c |2 ++ >>>>1 files changed, 2 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c >>>> index 1cca263..79c6c26 100644 >>>> --- a/drivers/i2c/i2c-core.c >>>> +++ b/drivers/i2c/i2c-core.c >>>> @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter >>>> *adap) >>>>mutex_lock(_lock); >>>>dummy = bus_for_each_drv(_bus_type, NULL, adap, >>>> __process_new_adapter); >>>> + if(!dummy) >>>> + dummy = 0; >>> >>> One word: scripts/checkpatch.pl >> >> it was this, and/or just take the code out >> (since I'm a newbie) > > I was not (yet) arguing on the code itself, but on its format. Any > patch you send should pass the formatting tests performed by > scripts/checkpatch.pl. Thanks. > o.k. I'll make sure I run everything through checkpatch.pl before sending anything. Justin P. Mattock
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: On 14 Jun, Justin P. Mattock wrote: On 06/14/2010 02:47 PM, Edward Shishkin wrote: Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Since you appear to generate the patches with git, you can use git diff --check [...] for some basic whitespace checks (additions of trailing space, additions of space before tab). For more extensive checks, try git diff [...] | scripts/checkpatch.pl -. Check this before you commit. If you committed already, git commit --amend [-a] [...] lets you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 13:26:44 PDT, Justin P. Mattock said: Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } Good thing that's a void function. ;) Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would be a better solution? what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); I error out with transmit_cmd not having enough functions to it.. so I just added the rc = 0; and went on to the next. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, valdis.kletni...@vt.edu wrote: On Mon, 14 Jun 2010 19:12:31 PDT, Justin P. Mattock said: what I tried was this: if (!rc) printk(test\n) and everything looked good, but as a soon as I changed rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); to this: rc = transmit_cmd(chip,tpm_cmd, TPM_INTERNAL_RESULT_SIZE); if (!rc) printk(attempting to determine the timeouts\n); *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. So I kind of just scrambled with this one. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: Em 14-06-2010 23:26, Justin P. Mattock escreveu: not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe-tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv-tun; - + Why are you adding an extra blank line here? Except for that, the patch looks sane. /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: > Justin P. Mattock wrote: >>> *baffled* Why did you think that would work? transmit_cmd()s signature >>> has 4 parameters. >> >> I have no manual in front of me. Did a quick google, but came up with >> (no hits) info on what that function does. grep showed too many entries >> to really see why/what this is. > > Check out the tool cscope. (Or kscope, if you prefer a GUI.) > > > //Peter > thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: > > > Em 14-06-2010 23:26, Justin P. Mattock escreveu: >> not sure if this is correct or not for >> fixing this warning: >>CC [M] drivers/media/common/tuners/tuner-simple.o >> drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': >> drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' >> set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/media/common/tuners/tuner-simple.c |4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/media/common/tuners/tuner-simple.c >> b/drivers/media/common/tuners/tuner-simple.c >> index 8abbcc5..4465b99 100644 >> --- a/drivers/media/common/tuners/tuner-simple.c >> +++ b/drivers/media/common/tuners/tuner-simple.c >> @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, >> struct tuner_simple_priv *priv = fe->tuner_priv; >> u8 config, cb; >> u16 div; >> -struct tunertype *tun; >> u8 buffer[4]; >> int rc, IFPCoff, i; >> enum param_type desired_type; >> struct tuner_params *t_params; >> >> -tun = priv->tun; >> - >> + > Why are you adding an extra blank line here? Except for that, the patch > looks sane. > >> /* IFPCoff = Video Intermediate Frequency - Vif: >> 940 =16*58.75 NTSC/J (Japan) >> 732 =16*45.75 M/N STD > > o.k. resent this.. I ended up doing a git reset do make sure things dont get funky etc.. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
On 06/14/2010 10:16 PM, Mauro Carvalho Chehab wrote: > > > Em 14-06-2010 23:26, Justin P. Mattock escreveu: >> not sure if this is correct or not for >> fixing this warning: >>CC [M] drivers/media/common/tuners/tuner-simple.o >> drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': >> drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' >> set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/media/common/tuners/tuner-simple.c |4 +--- >> 1 files changed, 1 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/media/common/tuners/tuner-simple.c >> b/drivers/media/common/tuners/tuner-simple.c >> index 8abbcc5..4465b99 100644 >> --- a/drivers/media/common/tuners/tuner-simple.c >> +++ b/drivers/media/common/tuners/tuner-simple.c >> @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, >> struct tuner_simple_priv *priv = fe->tuner_priv; >> u8 config, cb; >> u16 div; >> -struct tunertype *tun; >> u8 buffer[4]; >> int rc, IFPCoff, i; >> enum param_type desired_type; >> struct tuner_params *t_params; >> >> -tun = priv->tun; >> - >> + > Why are you adding an extra blank line here? Except for that, the patch > looks sane. > I think I was doing something wrong when creating these patches. i.g. I just hightlight the code then move the cursor highlight all the way to the right before pressing "x". normally would be o.k. but for some reason seems to be doing this. found if I highlight left to ; (or the end of the code I want to delete) then git commit creates the patch properly. >> /* IFPCoff = Video Intermediate Frequency - Vif: >> 940 =16*58.75 NTSC/J (Japan) >> 732 =16*45.75 M/N STD > > I'll resend this. Thanks for having a look. Justin P. Mattock
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 08:49 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 14 Jun 2010 19:12:31 PDT, "Justin P. Mattock" said:
>
>> what I tried was this:
>>
>> if (!rc)
>> printk("test"\n")
>>
>> and everything looked good,
>> but as a soon as I changed
>>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
>> "attempting to determine the timeouts");
>>
>> to this:
>>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE);
>>
>> if (!rc)
>> printk("attempting to determine the timeouts\n");
>
> *baffled* Why did you think that would work? transmit_cmd()s signature
> has 4 parameters.
I have no manual in front of me. Did a quick google, but came up with
(no hits) info on what that function does. grep showed too many entries
to really see why/what this is. So I kind of just scrambled with this one.
Justin P. Mattock
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 05:13 PM, Valdis.Kletnieks at vt.edu wrote:
> On Mon, 14 Jun 2010 13:26:44 PDT, "Justin P. Mattock" said:
>> Im getting this warning when compiling:
>> CC drivers/char/tpm/tpm.o
>> drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt':
>> drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used
>>
>> The below patch gets rid of the warning,
>> but I'm not sure if it's the best solution.
>
>> rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
>> "attempting to determine the timeouts");
>> +if (!rc)
>> +rc = 0;
>> }
>
> Good thing that's a void function. ;)
>
> Unless transmit_cmd() is marked 'must_check', maybe losing the 'rc =' would
> be a better solution?
what I tried was this:
if (!rc)
printk("test"\n")
and everything looked good,
but as a soon as I changed
rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE,
"attempting to determine the timeouts");
to this:
rc = transmit_cmd(chip,_cmd, TPM_INTERNAL_RESULT_SIZE);
if (!rc)
printk("attempting to determine the timeouts\n");
I error out with transmit_cmd not having enough
functions to it.. so I just added the rc = 0;
and went on to the next.
Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 04:07 PM, Stefan Richter wrote: > On 14 Jun, Justin P. Mattock wrote: >> On 06/14/2010 02:47 PM, Edward Shishkin wrote: >>> Whitespaces should be removed. >>> I recommend quilt package for managing patches: >>> "quilt refresh --strip-trailing-whitespace" is your friend.. >> >> o.k. I resent this.. fixed the whitespace(hopefully) >> and add your Acked to it. >> as for quilt I'll have to look into that.. >> (using a lfs system, so if the sourcecode is easy >> to deal with(build), then it's a good but if it becomes >> a nightmare maybe not!!). > > Since you appear to generate the patches with git, you can use "git diff > --check [...]" for some basic whitespace checks (additions of trailing > space, additions of space before tab). For more extensive checks, try > "git diff [...] | scripts/checkpatch.pl -". Check this before you > commit. If you committed already, "git commit --amend [-a] [...]" lets > you alter the very last commit of course. Thanks for the info on this, copied it down in my book of commands... Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: > Justin P. Mattock wrote: >> On 06/14/2010 02:05 PM, Edward Shishkin wrote: >>> Justin P. Mattock wrote: >>>> Not sure if this is correct or not. >>>> the below patch gets rid of this warning message >>>> produced by gcc 4.6.0 >>>> >>>> fs/reiserfs/stree.c: In function 'search_by_key': >>>> fs/reiserfs/stree.c:602:6: warning: variable >>>> 'right_neighbor_of_leaf_node' set but not used >>>> >>>> Signed-off-by: Justin P. Mattock >>> >>> Acked-by: Edward Shishkin >>> >> >> o.k.!! >> what about the whitespace issue? > > Whitespaces should be removed. > I recommend quilt package for managing patches: > "quilt refresh --strip-trailing-whitespace" is your friend.. > > Thanks, > Edward. > o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: > Justin P. Mattock wrote: >> Not sure if this is correct or not. >> the below patch gets rid of this warning message >> produced by gcc 4.6.0 >> >> fs/reiserfs/stree.c: In function 'search_by_key': >> fs/reiserfs/stree.c:602:6: warning: variable >> 'right_neighbor_of_leaf_node' set but not used >> >> Signed-off-by: Justin P. Mattock > > Acked-by: Edward Shishkin > o.k.!! what about the whitespace issue? from what I remember I did notice the "+" that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. >> --- >> fs/reiserfs/stree.c | 7 ++- >> 1 files changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c >> index 313d39d..73086ad 100644 >> --- a/fs/reiserfs/stree.c >> +++ b/fs/reiserfs/stree.c >> @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> struct buffer_head *bh; >> struct path_element *last_element; >> int node_level, retval; >> - int right_neighbor_of_leaf_node; >> int fs_gen; >> struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; >> b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; >> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> >> pathrelse(search_path); >> >> - right_neighbor_of_leaf_node = 0; >> - >> + >> /* With each iteration of this loop we search through the items in the >> current node, and calculate the next current node(next path element) >> for the next iteration of this loop.. */ >> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const >> struct cpu_key *key, /* Key to s >> starting from the root. */ >> block_number = SB_ROOT_BLOCK(sb); >> expected_level = -1; >> - right_neighbor_of_leaf_node = 0; >> - >> + >> /* repeat search from the root */ >> continue; >> } > >
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: > On 13:26 Mon 14 Jun , Justin P. Mattock wrote: >> @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct >> cpu_key *key, /* Key to s >> >> pathrelse(search_path); >> >> -right_neighbor_of_leaf_node = 0; >> - >> + > > This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) > >> /* With each iteration of this loop we search through the items in the >> current node, and calculate the next current node(next path element) >> for the next iteration of this loop.. */ >> @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct >> cpu_key *key, /* Key to s >> starting from the root. */ >> block_number = SB_ROOT_BLOCK(sb); >> expected_level = -1; >> -right_neighbor_of_leaf_node = 0; >> - >> + > > Here, too. > > Most of the patches in this series have similar issues. > main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: > Hi Justin, > > On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: >> could be a right solution, could be wrong >> here is the warning: >>CC drivers/i2c/i2c-core.o >> drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': >> drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used >> >> Signed-off-by: Justin P. Mattock >> >> --- >> drivers/i2c/i2c-core.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c >> index 1cca263..79c6c26 100644 >> --- a/drivers/i2c/i2c-core.c >> +++ b/drivers/i2c/i2c-core.c >> @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) >> mutex_lock(_lock); >> dummy = bus_for_each_drv(_bus_type, NULL, adap, >> __process_new_adapter); >> +if(!dummy) >> +dummy = 0; > > One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) > > In other news, the above is just plain wrong. First we force people to > read the result of bus_for_each_drv() and then when they do and don't > need the value, gcc complains, so we add one more layer of useless > code, which developers and possibly tools will later wonder and > complain about? I can easily imagine that a static code analyzer would > spot the above code as being a potential bug. > > Let's stop this madness now please. > your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) > Either __must_check goes away from bus_for_each_drv() and from every > other function which raises this problem, or we must disable that new > type of warning gcc 4.6.0 generates. Depends which warnings we value > more, as we can't sanely have both. > >> mutex_unlock(_lock); >> >> return 0; > > up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock
[PATCH 8/8]tuners:tuner-simple Fix warning: variable 'tun' set but not used
not sure if this is correct or not for fixing this warning: CC [M] drivers/media/common/tuners/tuner-simple.o drivers/media/common/tuners/tuner-simple.c: In function 'simple_set_tv_freq': drivers/media/common/tuners/tuner-simple.c:548:20: warning: variable 'tun' set but not used Signed-off-by: Justin P. Mattock --- drivers/media/common/tuners/tuner-simple.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/common/tuners/tuner-simple.c b/drivers/media/common/tuners/tuner-simple.c index 8abbcc5..4465b99 100644 --- a/drivers/media/common/tuners/tuner-simple.c +++ b/drivers/media/common/tuners/tuner-simple.c @@ -545,14 +545,12 @@ static int simple_set_tv_freq(struct dvb_frontend *fe, struct tuner_simple_priv *priv = fe->tuner_priv; u8 config, cb; u16 div; - struct tunertype *tun; u8 buffer[4]; int rc, IFPCoff, i; enum param_type desired_type; struct tuner_params *t_params; - tun = priv->tun; - + /* IFPCoff = Video Intermediate Frequency - Vif: 940 =16*58.75 NTSC/J (Japan) 732 =16*45.75 M/N STD -- 1.7.1.rc1.21.gf3bd6
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud->flags & UNIT_DIRECTORY_MODEL_ID ? ud->model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(_lock); dummy = bus_for_each_drv(_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(_lock); return 0; -- 1.7.1.rc1.21.gf3bd6
[PATCH 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj->dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(>object_idr, handle); -- 1.7.1.rc1.21.gf3bd6
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, _cmd, TPM_INTERNAL_RESULT_SIZE, "attempting to determine the timeouts"); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6
[PATCH 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp->hd_timer;
- hpet = devp->hd_hpet;
hpetp = devp->hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
[PATCH 2/8]bluetooth/hci_ldisc.c Fix warning: variable 'tty' set but not used
Im getting this while building:
CC [M] drivers/bluetooth/hci_ldisc.o
drivers/bluetooth/hci_ldisc.c: In function 'hci_uart_send_frame':
drivers/bluetooth/hci_ldisc.c:213:21: warning: variable 'tty' set but not used
the below fixed it for me, but am not sure if
it's correct.
Signed-off-by: Justin P. Mattock
---
drivers/bluetooth/hci_ldisc.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 76a1abb..f693dfe 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -210,7 +210,6 @@ static int hci_uart_close(struct hci_dev *hdev)
static int hci_uart_send_frame(struct sk_buff *skb)
{
struct hci_dev* hdev = (struct hci_dev *) skb->dev;
- struct tty_struct *tty;
struct hci_uart *hu;
if (!hdev) {
@@ -222,8 +221,7 @@ static int hci_uart_send_frame(struct sk_buff *skb)
return -EBUSY;
hu = (struct hci_uart *) hdev->driver_data;
- tty = hu->tty;
-
+
BT_DBG("%s: type %d len %d", hdev->name, bt_cb(skb)->pkt_type,
skb->len);
hu->proto->enqueue(hu, skb);
--
1.7.1.rc1.21.gf3bd6
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock
[PATCH 0/8] Fix gcc 4.6.0 set but not used warning messages.
First and foremost, I must thank anybody taking the time to even look at these(I know you people have better things to be doing). And secondly here is my try at trying to fix some of the warning messages spammed by gcc 4.6.0 when building the kernel. Some of them I removed, and some of them I just shut off. Note: Removing the code does seem like a good approach(if it's actually dead), but if not then something needs to be fixed. As for shutting off the code to shutup gcc does seem like a temporary fix, but would rather have a warning message, than see it get lost in the sands of time. In any case Thanks for taking the time, and hopefully we can get fixes for all of this mess generated by gcc.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- fs/reiserfs/stree.c |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8]char/hpet.c Fix variable 'hpet' set but not used
The below fixes this warning:
drivers/char/hpet.c: In function 'hpet_ioctl_common':
drivers/char/hpet.c:559:23: warning: variable 'hpet' set but not used
please have a look.
Signed-off-by: Justin P. Mattock justinmatt...@gmail.com
---
drivers/char/hpet.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hpet.c b/drivers/char/hpet.c
index a0a1829..7932858 100644
--- a/drivers/char/hpet.c
+++ b/drivers/char/hpet.c
@@ -556,7 +556,6 @@ static int
hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned long arg, int
kernel)
{
struct hpet_timer __iomem *timer;
- struct hpet __iomem *hpet;
struct hpets *hpetp;
int err;
unsigned long v;
@@ -568,7 +567,6 @@ hpet_ioctl_common(struct hpet_dev *devp, int cmd, unsigned
long arg, int kernel)
case HPET_DPI:
case HPET_IRQFREQ:
timer = devp-hd_timer;
- hpet = devp-hd_hpet;
hpetp = devp-hd_hpets;
break;
case HPET_IE_ON:
--
1.7.1.rc1.21.gf3bd6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
Im getting this warning when compiling: CC drivers/char/tpm/tpm.o drivers/char/tpm/tpm.c: In function 'tpm_gen_interrupt': drivers/char/tpm/tpm.c:508:10: warning: variable 'rc' set but not used The below patch gets rid of the warning, but I'm not sure if it's the best solution. Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/char/tpm/tpm.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c index 05ad4a1..3d685dc 100644 --- a/drivers/char/tpm/tpm.c +++ b/drivers/char/tpm/tpm.c @@ -514,6 +514,8 @@ void tpm_gen_interrupt(struct tpm_chip *chip) rc = transmit_cmd(chip, tpm_cmd, TPM_INTERNAL_RESULT_SIZE, attempting to determine the timeouts); + if (!rc) + rc = 0; } EXPORT_SYMBOL_GPL(tpm_gen_interrupt); -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8]drm:drm_gem Fix warning: variable 'dev' set but not used
Probably not even a fix for this warning: CC [M] drivers/gpu/drm/drm_gem.o drivers/gpu/drm/drm_gem.c: In function 'drm_gem_handle_delete': drivers/gpu/drm/drm_gem.c:188:21: warning: variable 'dev' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/gpu/drm/drm_gem.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 33dad3f..e8180c9 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -206,6 +206,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) return -EINVAL; } dev = obj-dev; + if (!dev) + dev = 0; /* Release reference and decrement refcount. */ idr_remove(filp-object_idr, handle); -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; mutex_unlock(core_lock); return 0; -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8]ieee1394/sdp2 Fix warning: variable 'unit_characteristics' set but not used
Temporary fix until something is resolved to fix the below warning: CC [M] drivers/ieee1394/sbp2.o drivers/ieee1394/sbp2.c: In function 'sbp2_parse_unit_directory': drivers/ieee1394/sbp2.c:1353:6: warning: variable 'unit_characteristics' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com --- drivers/ieee1394/sbp2.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/ieee1394/sbp2.c b/drivers/ieee1394/sbp2.c index 4565cb5..fcf8bd5 100644 --- a/drivers/ieee1394/sbp2.c +++ b/drivers/ieee1394/sbp2.c @@ -1356,6 +1356,8 @@ static void sbp2_parse_unit_directory(struct sbp2_lu *lu, management_agent_addr = 0; unit_characteristics = 0; + if (!unit_characteristics) + unit_characteristics = 0; firmware_revision = SBP2_ROM_VALUE_MISSING; model = ud-flags UNIT_DIRECTORY_MODEL_ID ? ud-model_id : SBP2_ROM_VALUE_MISSING; -- 1.7.1.rc1.21.gf3bd6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8]i2c:i2c_core Fix warning: variable 'dummy' set but not used
On 06/14/2010 01:53 PM, Jean Delvare wrote: Hi Justin, On Mon, 14 Jun 2010 13:26:46 -0700, Justin P. Mattock wrote: could be a right solution, could be wrong here is the warning: CC drivers/i2c/i2c-core.o drivers/i2c/i2c-core.c: In function 'i2c_register_adapter': drivers/i2c/i2c-core.c:757:15: warning: variable 'dummy' set but not used Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com --- drivers/i2c/i2c-core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c index 1cca263..79c6c26 100644 --- a/drivers/i2c/i2c-core.c +++ b/drivers/i2c/i2c-core.c @@ -794,6 +794,8 @@ static int i2c_register_adapter(struct i2c_adapter *adap) mutex_lock(core_lock); dummy = bus_for_each_drv(i2c_bus_type, NULL, adap, __process_new_adapter); + if(!dummy) + dummy = 0; One word: scripts/checkpatch.pl it was this, and/or just take the code out (since I'm a newbie) In other news, the above is just plain wrong. First we force people to read the result of bus_for_each_drv() and then when they do and don't need the value, gcc complains, so we add one more layer of useless code, which developers and possibly tools will later wonder and complain about? I can easily imagine that a static code analyzer would spot the above code as being a potential bug. Let's stop this madness now please. your telling me!! I haven't even compiled all the way through the kernel yet.(lots of warnings) Either __must_check goes away from bus_for_each_drv() and from every other function which raises this problem, or we must disable that new type of warning gcc 4.6.0 generates. Depends which warnings we value more, as we can't sanely have both. mutex_unlock(core_lock); return 0; up to you guys.. best thing now is deciphering what and what not is an actual issue. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 01:48 PM, Nick Bowler wrote: On 13:26 Mon 14 Jun , Justin P. Mattock wrote: @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + This hunk introduces whitespace on the empty line, which is not cool. I can resend!!(biggest problem is working through these warnings) /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key,/* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + Here, too. Most of the patches in this series have similar issues. main thing now(for me atleast)is, is this actual dead code or what? if not then something else needs to be done, if yes then I guess I can resend this, with out the whitespace issue. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? from what I remember I did notice the + that git does when making patches like this but given some many of these warnings I just did a quick workaround or however then figured to worry later on that. --- fs/reiserfs/stree.c | 7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/fs/reiserfs/stree.c b/fs/reiserfs/stree.c index 313d39d..73086ad 100644 --- a/fs/reiserfs/stree.c +++ b/fs/reiserfs/stree.c @@ -599,7 +599,6 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s struct buffer_head *bh; struct path_element *last_element; int node_level, retval; - int right_neighbor_of_leaf_node; int fs_gen; struct buffer_head *reada_bh[SEARCH_BY_KEY_READA]; b_blocknr_t reada_blocks[SEARCH_BY_KEY_READA]; @@ -617,8 +616,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s pathrelse(search_path); - right_neighbor_of_leaf_node = 0; - + /* With each iteration of this loop we search through the items in the current node, and calculate the next current node(next path element) for the next iteration of this loop.. */ @@ -695,8 +693,7 @@ int search_by_key(struct super_block *sb, const struct cpu_key *key, /* Key to s starting from the root. */ block_number = SB_ROOT_BLOCK(sb); expected_level = -1; - right_neighbor_of_leaf_node = 0; - + /* repeat search from the root */ continue; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8]reiserfs:stree.c Fix variable set but not used.
On 06/14/2010 02:47 PM, Edward Shishkin wrote: Justin P. Mattock wrote: On 06/14/2010 02:05 PM, Edward Shishkin wrote: Justin P. Mattock wrote: Not sure if this is correct or not. the below patch gets rid of this warning message produced by gcc 4.6.0 fs/reiserfs/stree.c: In function 'search_by_key': fs/reiserfs/stree.c:602:6: warning: variable 'right_neighbor_of_leaf_node' set but not used Signed-off-by: Justin P. Mattock justinmatt...@gmail.com Acked-by: Edward Shishkin edward.shish...@gmail.com o.k.!! what about the whitespace issue? Whitespaces should be removed. I recommend quilt package for managing patches: quilt refresh --strip-trailing-whitespace is your friend.. Thanks, Edward. o.k. I resent this.. fixed the whitespace(hopefully) and add your Acked to it. as for quilt I'll have to look into that.. (using a lfs system, so if the sourcecode is easy to deal with(build), then it's a good but if it becomes a nightmare maybe not!!). Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8]drivers:tmp.c Fix warning: variable 'rc' set but not used
On 06/14/2010 10:29 PM, Peter Stuge wrote: Justin P. Mattock wrote: *baffled* Why did you think that would work? transmit_cmd()s signature has 4 parameters. I have no manual in front of me. Did a quick google, but came up with (no hits) info on what that function does. grep showed too many entries to really see why/what this is. Check out the tool cscope. (Or kscope, if you prefer a GUI.) //Peter thanks for this tool.. I think this is what I need.. running around not knowing what/where the manual is for a call is a bit daunting. I'll give this a look. Thanks for this.. Justin P. Mattock ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
