- 24 9月, 2009 23 次提交
-
-
由 Julia Lawall 提交于
Use the function resource_size, which reduces the chance of introducing off-by-one errors in calculating the resource size. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ struct resource *res; @@ - (res->end - res->start) + 1 + resource_size(res) // </smpl> Signed-off-by: NJulia Lawall <julia@diku.dk> Signed-off-by: NDoug Thompson <dougthompson@xmission.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ira W. Snyder 提交于
Add support for the Freescale MPC83xx memory controller to the existing driver for the Freescale MPC85xx memory controller. The only difference between the two processors are in the CS_BNDS register parsing code, which has been changed so it will work on both processors. The L2 cache controller does not exist on the MPC83xx, but the OF subsystem will not use the driver if the device is not present in the OF device tree. I had to change the nr_pages calculation to make the math work out. I checked it on my board and did the math by hand for a 64GB 85xx using 64K pages. In both cases, nr_pages * PAGE_SIZE comes out to the correct value. Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu> Signed-off-by: NDoug Thompson <dougthompson@xmission.com> Cc: Kumar Gala <galak@gate.crashing.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Yang Shi 提交于
Based on Kumar's new compatible types patch, add P2020 into MPC85xx EDAC compatible lists so that EDAC can recognize P2020 meomry controller and L2 cache controller and export the relevant fields to sysfs. EDAC MPC85xx DDR3 support is needed if DDR3 memory stick is installed on a P2020DS board so that EDAC core can recognize DDR3 memory type. Signed-off-by: NYang Shi <yang.shi@windriver.com> Acked-by: NDave Jiang <djiang@mvista.com> Signed-off-by: NDoug Thompson <dougthompson@xmission.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alexey Dobriyan 提交于
It's unused. It isn't needed -- read or write flag is already passed and sysctl shouldn't care about the rest. It _was_ used in two places at arch/frv for some reason. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Cc: David Howells <dhowells@redhat.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Morris <jmorris@namei.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Mike Frysinger 提交于
The on-chip OTP may be written at runtime, so enable support for it in the driver. However, since writing should really be done only on development systems, don't bend over backwards to make sure the simple software lock is per-fd -- per-device is OK. Signed-off-by: NMike Frysinger <vapier@gentoo.org> Signed-off-by: NBryan Wu <cooloney@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dimitri Sivanich 提交于
This driver memory maps the UV Hub RTC. Signed-off-by: NDimitri Sivanich <sivanich@sgi.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dan Carpenter 提交于
If DownLoad.ProductCode == MAX_PRODUCT, that would be a problem when we do RIOBootTable[DownLoad.ProductCode] a couple lines down. Found by smatch (http://repo.or.cz/w/smatch.git). Signed-off-by: NDan Carpenter <error27@gmail.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Nils Carlson 提交于
The periodic interrupt from drivers/char/hpet.c does not work correctly, both when using the periodic capability of the hardware and while emulating the periodic interrupt (when hardware does not support periodic mode). With timers capable of periodic interrupts, the comparator field is first set with the period value followed by set of hidden accumulator, which has the side effect of overwriting the comparator value. This results in wrong periodicity for the interrupts. For, periodic interrupts to work, following steps are necessary, in that order. * Set config with Tn_VAL_SET_CNF bit * Write to hidden accumulator, the value written is the time when the first interrupt should be generated * Write compartor with period interval for subsequent interrupts (http://www.intel.com/hardwaredesign/hpetspec_1.pdf ) When emulating periodic timer with timers not capable of periodic interrupt, driver is adding the period to counter value instead of comparator value, which causes slow drift when using this emulation. Also, driver seems to add hpetp->hp_delta both while setting up periodic interrupt and while emulating periodic interrupts with timers not capable of doing periodic interrupts. This hp_delta will result in slower than expected interrupt rate and should not be used while setting the interval. Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NNils Carlson <nils.carlson@ericsson.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Roel Kluin 提交于
Check whether index is within bounds before grabbing the element. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Nikanth Karthikesan 提交于
In read_zero, we check for access_ok() once for the count bytes. It is unnecessarily checked again in clear_user. Use __clear_user, which does not check for access_ok(). Signed-off-by: NNikanth Karthikesan <knikanth@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ingo Molnar 提交于
input: fix build failures caused by Kconfig Winbond WPCD376I Consumer IR hardware driver Kconfig entry Fix these warnings: drivers/built-in.o: In function `apanel_remove': apanel.c:(.text+0x56e852): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `apanel_probe': apanel.c:(.text+0x56eae3): undefined reference to `led_classdev_register' drivers/built-in.o: In function `acpi_fujitsu_hotkey_add': fujitsu-laptop.c:(.text+0x5d7647): undefined reference to `led_classdev_register' fujitsu-laptop.c:(.text+0x5d76b5): undefined reference to `led_classdev_register' drivers/built-in.o: In function `wbcir_probe': winbond-cir.c:(.devinit.text+0x5f375): undefined reference to `led_classdev_register' winbond-cir.c:(.devinit.text+0x5f663): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `wbcir_remove': winbond-cir.c:(.devexit.text+0x7f23): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `fujitsu_cleanup': fujitsu-laptop.c:(.exit.text+0xbe37): undefined reference to `led_classdev_unregister' fujitsu-laptop.c:(.exit.text+0xbe53): undefined reference to `led_classdev_unregister' It happens because the new INPUT_WINBOND_CIR driver relies on new-leds infrastructure - but does not select it in drivers/input/misc/Kconfig. But it selects LEDS_CLASS, which confuses a number of other drivers into thinking that all the leds infrastructure is in place. Fix this by selecting NEW_LEDS as well, like similar drivers do. Eventually, this whole leds infrastructure complexity should be cleaned up, it's been going on for years. Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: David Härdeman <david@hardeman.nu> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Alexey Dobriyan 提交于
* remove asm/atomic.h inclusion from linux/utsname.h -- not needed after kref conversion * remove linux/utsname.h inclusion from files which do not need it NOTE: it looks like fs/binfmt_elf.c do not need utsname.h, however due to some personality stuff it _is_ needed -- cowardly leave ELF-related headers and files alone. Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Bjorn Helgaas 提交于
set_cpus_allowed() is on the way out; replace it with set_cpus_allowed_ptr(). Reference: http://lkml.org/lkml/2008/11/6/448Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Li Zefan 提交于
Remove open-coded zalloc_cpumask_var() and zalloc_cpumask_var_node(). Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
由 Ira W. Snyder 提交于
When power is applied to the ltc4245 chip it sometimes reports spurious faults, which are exposed as alarms in the hwmon output. Clear the fault register when the driver is installed to clear the alarms. Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Ira W. Snyder 提交于
When power is applied to the ltc4215 chip it sometimes reports spurious faults. The faults are not yet exposed via sysfs, however it may be useful for userspace to read the fault register directly with the i2cget command. Clear the fault register when the driver is installed so userspace doesn't have to worry about spurious fault indications. Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Huaxu Wan 提交于
Add Lynnfield processor support. Lynnfield is a quad-core Nehalem based microprocessor for Desktop market, which is introduced in September 2009. Signed-off-by: NHuaxu Wan <huaxu.wan@linux.intel.com> Signed-off-by: NKent Liu <kent.liu@linux.intel.com> Acked-by: NRudolf Marek <r.marek@assembler.cz> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Rudolf Marek 提交于
Following patch adds support for mobile Penryn CPUs. Intel documents this poorly. I asked the Coretemp author for some help. This is totally untested and may not work. Please test! Signed-off-by: NRudolf Marek <r.marek@assembler.cz> Cc: Huaxu Wan <huaxu.wan@linux.intel.com> Cc: Kent Liu <kent.liu@linux.intel.com> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Rudolf Marek 提交于
Fix Atom CPUs support. Intel documents TjMax at 90 degrees C but some Atoms may have 125 degrees C (this is undocumented speculation). Signed-off-by: NRudolf Marek <r.marek@assembler.cz> Cc: Huaxu Wan <huaxu.wan@linux.intel.com> Cc: Kent Liu <kent.liu@linux.intel.com> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Jean Delvare 提交于
The legacy fscpos and fscher drivers have been replaced by the unified fschmd driver. The transition period is over now, we can delete them. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NHans de Goede <hdegoede@redhat.com>
-
由 Ira Snyder 提交于
The ADM1030/ADM1031 chips have temperature offset registers, for both the local and remote temperature sensors. Following the example set forth in the LM90/ADM1032 driver, expose the offset registers to userspace. Signed-off-by: NIra W. Snyder <iws@ovro.caltech.edu> Signed-off-by: NJean Delvare <khali@linux-fr.org>
-
由 Randy Dunlap 提交于
Fix new kernel-doc warnings in serial_core.[hc] files. Warning(include/linux/serial_core.h:485): No description found for parameter 'uport' Warning(include/linux/serial_core.h:485): Excess function parameter 'port' description in 'uart_handle_dcd_change' Warning(include/linux/serial_core.h:511): No description found for parameter 'uport' Warning(include/linux/serial_core.h:511): Excess function parameter 'port' description in 'uart_handle_cts_change' Warning(drivers/serial/serial_core.c:2437): No description found for parameter 'uport' Warning(drivers/serial/serial_core.c:2437): Excess function parameter 'port' description in 'uart_add_one_port' Warning(drivers/serial/serial_core.c:2509): No description found for parameter 'uport' Warning(drivers/serial/serial_core.c:2509): Excess function parameter 'port' description in 'uart_remove_one_port' Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jason Gunthorpe 提交于
Signed-off-by: NJason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: Debora Velarde <debora@linux.vnet.ibm.com> Cc: Rajiv Andrade <srajiv@linux.vnet.ibm.com> Cc: Marcel Selhorst <m.selhorst@sirrix.com> Cc: James Morris <jmorris@namei.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NJames Morris <jmorris@namei.org>
-
- 23 9月, 2009 17 次提交
-
-
由 Aaro Koskinen 提交于
The patch enables the driver to be used on platforms such as ARM where an I/O address is a 32-bit memory address. The patch avoids the following kernel oops: debian:~# modprobe sisfb [ 73.070000] sisfb: Video ROM found [ 73.080000] sisfb: Video RAM at 0x80000000, mapped to 0xe0a00000, size 1024k [ 73.090000] sisfb: MMIO at 0x84080000, mapped to 0xe0b80000, size 256k [ 73.090000] sisfb: Memory heap starting at 800K, size 32K [ 73.360000] Unable to handle kernel paging request at virtual address 6e000844 [ 73.380000] pgd = df230000 [ 73.380000] [6e000844] *pgd=00000000 [ 73.380000] Internal error: Oops: 8f5 [#1] [ 73.380000] Modules linked in: sisfb(+) fb cfbcopyarea cfbimgblt cfbfillrect [ 73.380000] CPU: 0 Not tainted (2.6.31-iop32x #1) [ 73.380000] PC is at SiS_SetRegANDOR+0x10/0x38 [sisfb] [ 73.380000] LR is at SiS_SetSCLKHigh+0x38/0x94 [sisfb] [ 73.380000] pc : [<bf01dc00>] lr : [<bf0238f8>] psr: 60000013 [ 73.380000] sp : df38fd00 ip : 6e000000 fp : 00000002 [ 73.380000] r10: 00000108 r9 : 00000000 r8 : 00000108 [ 73.380000] r7 : df064258 r6 : 00000110 r5 : 6e000844 r4 : 0000010a [ 73.380000] r3 : 00000001 r2 : 0000000e r1 : 00000011 r0 : 00000844 [ 73.380000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 73.380000] Control: 0000397f Table: bf230000 DAC: 00000015 [ 73.380000] Process modprobe (pid: 1849, stack limit = 0xdf38e270) [ 73.380000] Stack: (0xdf38fd00 to 0xdf390000) [ 73.380000] fd00: 0000010a 00000108 df064258 df064258 df064258 00000000 00000000 bf02c4e0 [ 73.380000] fd20: 00000114 bf02c50c 00000013 00000114 0000010a df064258 00000000 bf02c980 [ 73.380000] fd40: 00009c66 00000004 00000001 df064250 a0010000 a6a2a0a0 df064250 00000003 [ 73.380000] fd60: df064250 00000000 df064258 0000fffd 00000000 00000000 00000000 bf033948 [ 73.380000] fd80: 00000000 00000000 00000000 bf019e2c 00000000 df064a70 bf03b470 00010000 [ 73.380000] fda0: 00000000 df064250 00000000 df831c00 00000012 bf039f70 00000000 c00abed8 [ 73.380000] fdc0: 000008a6 000008a4 df0649b0 df064878 df064258 df064000 00000000 00000000 [ 73.380000] fde0: 00000001 00008000 00000001 00030000 df81c930 bf049f88 df831c00 00000000 [ 73.380000] fe00: bf049f58 df3952a0 c0447708 bf049f88 bf049fe0 c0191980 df831c00 c0191b10 [ 73.380000] fe20: df831c58 bf049f58 df831c00 bf04aca8 df3952a0 df831c58 df831c58 bf049f88 [ 73.380000] fe40: c01ba1b4 c01ba0a0 df831c58 df831c8c bf049f88 c01ba1b4 df3952a0 00000000 [ 73.380000] fe60: c03e265c c01ba240 00000000 df38fe78 bf049f88 c01b990c df812938 df81b8d0 [ 73.380000] fe80: df3952a0 df807780 00000000 00000060 bf049f88 c01b9224 bf0429c8 00000000 [ 73.380000] fea0: bf049f58 00000000 bf049f88 00000000 00000000 bf04aea8 00000000 c01ba4e4 [ 73.380000] fec0: e09861a0 bf049f58 00000000 bf049f88 00000000 c0191f20 00000000 00000000 [ 73.380000] fee0: c03f7bac bf04d418 0000fff2 0000fff1 bf04ad08 0002f260 0002f260 e0986038 [ 73.380000] ff00: e0986150 e098568b df143340 e0990280 00000036 c03d8b00 fffffffd 00000000 [ 73.380000] ff20: bf04acfc 00000000 fffffffc 0003cf4b 00018098 c03f7bac 00000000 bf04d000 [ 73.380000] ff40: df38e000 00000000 bedc0984 c00272a4 ffffffff c005bc88 00000000 00000000 [ 73.380000] ff60: 0003cf4b 0003cf4b 00018098 bf04acfc 00000000 c0027fe8 df38e000 00000000 [ 73.380000] ff80: bedc0984 c006882c 00001000 00000003 00000000 00009064 00000000 00008edc [ 73.380000] ffa0: 00000080 c0027e20 00009064 00000000 4014e000 0003cf4b 00018098 0003cf4b [ 73.380000] ffc0: 00009064 00000000 00008edc 00000080 00000000 00000000 40025000 bedc0984 [ 73.380000] ffe0: 00000000 bedc08fc 0000b6b0 400e8f34 60000010 4014e000 00000000 00000000 [ 73.380000] [<bf01dc00>] (SiS_SetRegANDOR+0x10/0x38 [sisfb]) from [<df064258>] (0xdf064258) [ 73.380000] Code: e92d0030 e20110ff e280546e e3a0c46e (e5c51000) [ 73.680000] ---[ end trace 62a93e01df37a5f2 ]--- Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi> Cc: Thomas Winischhofer <thomas@winischhofer.net> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Peter Korsgaard 提交于
Fixes `s3c_fb_remove' referenced in section `.data' of drivers/built-in.o: defined in discarded section `.devexit.text' of drivers/built-in.o With CONFIG_HOTPLUG=n, functions marked with __devexit gets removed, so make sure we use __devexit_p when referencing pointers to them. Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk> Acked-by: NBen Dooks <ben-linux@fluff.org> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrew Morton 提交于
drivers/video/tmiofb.c: In function 'tmiofb_resume': drivers/video/tmiofb.c:977: warning: 'retval' may be used uninitialized in this function Acked-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Francisco Jerez 提交于
fbcon makes the (reasonable) assumption that it only needs to program the hardware once, when fbcon_init() is called for the foreground console. This doesn't always play well with vgacon because vgacon_deinit() is only doing its job when the last console it owns is closed (when switching from vgacon to fbcon, that's usually *after* fbcon_init() has set the new mode). Depending on the hardware this can cause the wrong framebuffer location to be scanned out (e.g. reproduced on nv05 with the nouveau framebuffer driver). Signed-off-by: NFrancisco Jerez <currojerez@riseup.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ian Armstrong 提交于
Attempting to unload a framebuffer module calls unregister_framebuffer() which in turn gets fbcon to release it. If fbcon has no framebuffers linked to a console, it will also unbind itself from the console driver. However, if fbcon never registered itself as a console driver, the unbind will fail causing the framebuffer device entry to persist. In most cases this failure will result in an oops when attempting to access the now non-existent device. This patch ensures that the fbcon unbind request will succeed even if a bind was never done. It tracks if a successful bind ever occurred & will only attempt to unbind if needed. If there never was a bind, it simply returns with no error. Signed-off-by: NIan Armstrong <ian@iarmst.demon.co.uk> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
CONFIG_FB_MATROX_32MB is always enabled, so there is no point in having ifdefs all around. And it is bad practice to use CONFIG_* as a name for something which is not a Kconfig option. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
With multihead support always enabled, macros MINFO_FROM and MINFO_FROM_INFO are no longer needed and make the code harder to read. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
With multihead support always enabled, these macros are no longer needed and make the code harder to read. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
With multihead support always enabled, these macros are no longer needed and make the code harder to read. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jean Delvare 提交于
I would like to get rid of option CONFIG_FB_MATROX_MULTIHEAD and just always enable it. There are many reasons for doing this: * CONFIG_FB_MATROX_MULTIHEAD=y is what all x86 distributions do, so it definitely works or we would know by now. * Building the matroxfb driver with CONFIG_FB_MATROX_MULTIHEAD not set results in the following build warning: drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_open': drivers/video/matrox/matroxfb_crtc2.c:265: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' drivers/video/matrox/matroxfb_crtc2.c: In function 'matroxfb_dh_release': drivers/video/matrox/matroxfb_crtc2.c:285: warning: the address of 'matroxfb_global_mxinfo' will always evaluate as 'true' This is nothing to be worried about, the driver will work fine, but build warnings are still annoying. * The trick to get multihead support without CONFIG_FB_MATROX_MULTIHEAD, which is described in the config help text, no longer works: you can't load the same kernel module more than once. * I fail to see how CONFIG_FB_MATROX_MULTIHEAD=y would make the code significantly slower, contrary to what the help text says. A few extra parameters on the stack here and there can't really slow things down in comaprison to the rest of the code, and register access. * The driver built without CONFIG_FB_MATROX_MULTIHEAD is larger than the driver build with CONFIG_FB_MATROX_MULTIHEAD=y by 8%. * One less configuration option makes things simpler. We add options all the time, being able to remove one for once is nice. It improves testing coverage. And I don't think the Matrox adapters are still popular enough to warrant overdetailed configuration settings. * We should be able to unobfuscate the driver code quite a bit after this change (patches follow.) Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NPetr Vandrovec <vandrove@vc.cvut.cz> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
At the moment about half of the framebuffer drivers can return an error code in fb_set_par. Until now it would be silently ignored by fbmem.c and fbcon.c. This patch fixes fbmem.c to return the error code and restore var on error. But it is not clear in which video mode the device is when fb_set_par fails. It would be good and reasonable if it were in the old state but there is no guarantee that this is true for all existing drivers. Additionally print a message if a failing fb_set_par is detected in fbmem.c or fbcon.c. Although most errors should be caught by the previous fb_check_var some errors can't as they are dynamic (memory allocations, ...) and can only be detected while performing the operations which is forbidden in fb_check_var. This patch shouldn't have a negative impact on normal operation as all drivers return 0 on success. The impact in case of error depends heavily on the driver and caller but it's expected to be better than before. Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ben Dooks 提交于
In the final part of the calculation for the tft display clockrate we divide the output pf s3c2410fb_calc_pixclk() by 2 which leaves us with a rounding error if the result is odd. Change to using DIV_ROUND_UP() to ensure that we always choose a higher divisor and thus a lower frequency. Signed-off-by: NBen Dooks <ben@simtec.co.uk> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jiri Slaby 提交于
Use DIV_ROUND_UP explicitly instead of manual shifts and adds. It makes the code more readable and consistent (sometimes there were shifts, sometimes divs). There is no change on the assembly level (compilers should do the right job). Signed-off-by: NJiri Slaby <jirislaby@gmail.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
Fix the range check for panning. The current code fails to detect some invalid values (very high ones that can occur if an app tries to move further up/left than 0,0) as the check uses the unknown values for calculation so that an overflow can occur. To fix this it is sufficient to move the calculation to the right side to use only trusted values. Kai Jiang detected this problem and proposed an initial patch. Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Kai Jiang <b18973@freescale.com> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Julia Lawall 提交于
Check that the result of kmalloc is not NULL before passing it to other functions. The semantic match that finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression *x; identifier f; constant char *C; @@ x = \(kmalloc\|kcalloc\|kzalloc\)(...); ... when != x == NULL when != x != NULL when != (x || ...) ( kfree(x) | f(...,C,...,x,...) | *f(...,x,...) | *x->f ) // </smpl> [akpm@linux-foundation.org: convert to kstrdup() as well] Signed-off-by: NJulia Lawall <julia@diku.dk> Cc: Ming Lei <tom.leiming@gmail.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Roel Kluin 提交于
It reads linetable[] before checking bounds of index, and ARRAY_SIZE is required because linetable[] are unsigned shorts. Signed-off-by: NRoel Kluin <roel.kluin@gmail.com> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Harald Welte 提交于
Signed-off-by: NHarald Welte <HaraldWelte@viatech.com> Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Scott Fang <ScottFang@viatech.com.cn> Cc: Joseph Chan <JosephChan@via.com.tw> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-