kernel.git/drivers/video/i810, branch linux-3.14.y

i810: delete useless variable

2014-01-17T08:57:50Z

Delete a variable that is at most only assigned to a constant, but never used otherwise. A simplified version of the semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @@ type T; identifier i; constant c; @@ -T i; <... when != i -i = c; ...> // Signed-off-by: Julia Lawall Signed-off-by: Tomi Valkeinen

video: i810fb: remove unnecessary pci_set_drvdata()

2013-09-19T10:30:07Z

The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han Signed-off-by: Tomi Valkeinen

Drivers: video: remove __dev* attributes.

2013-01-03T23:57:01Z

CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton Signed-off-by: Greg Kroah-Hartman

sections: fix section conflicts in drivers/video

2012-10-05T18:04:44Z

Signed-off-by: Andi Kleen Cc: Florian Tobias Schandinat Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

module_param: make bool parameters really bool (drivers/video/i810)

2012-01-12T23:28:59Z

module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. It's time to remove the int/unsigned int option. For this version it'll simply give a warning, but it'll break next kernel version. Signed-off-by: Rusty Russell Signed-off-by: Florian Tobias Schandinat

i810: fix module_param bool abuse.

2011-12-19T20:21:55Z

The driver says "module_param(ddc3, bool, 0);". But it's not a used as a bool, it's used as a count. Make it a bool. Cc: Antonino Daplas Cc: linux-fbdev@vger.kernel.org Signed-off-by: Rusty Russell Signed-off-by: Florian Tobias Schandinat

treewide: fix potentially dangerous trailing ';' in #defined values/expressions

2011-07-21T12:10:00Z

All these are instances of #define NAME value; or #define NAME(params_opt) value; These of course fail to build when used in contexts like if(foo $OP NAME) while(bar $OP NAME) and may silently generate the wrong code in contexts such as foo = NAME + 1; /* foo = value; + 1; */ bar = NAME - 1; /* bar = value; - 1; */ baz = NAME & quux; /* baz = value; & quux; */ Reported on comp.lang.c, Message-ID: Initial analysis of the dangers provided by Keith Thompson in that thread. There are many more instances of more complicated macros having unnecessary trailing semicolons, but this pile seems to be all of the cases of simple values suffering from the problem. (Thus things that are likely to be found in one of the contexts above, more complicated ones aren't.) Signed-off-by: Phil Carmody Signed-off-by: Jiri Kosina

Fix common misspellings

2011-03-31T14:26:23Z

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi

console: rename acquire/release_console_sem() to console_lock/unlock()

2011-01-26T00:50:06Z

The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by: Torben Hohn Cc: Thomas Gleixner Cc: Greg KH Cc: Ingo Molnar Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

drivers/video/i810/i810-i2c.c: fix i2c bus handling

2011-01-06T06:52:19Z

These patch fix a longstanding bug in the i810 frame buffer driver. The handling of the i2c bus is wrong: A 1 bit should not written to the i2c, these will be done by switch the i2c to input. Driving an 1 bit active is against the i2c spec. An active driven of a 1 bit will result in very strange error, depending which side is the more powerful one. In my case it depends on the temperature of the Display-Controller-EEprom: With an cold eprom a got the correct EDID datas, with a warm one some of the 1 bits was 0 :-( The same bug is also in the intelfb driver in the file drivers/video/intelfb/intelfb_i2c.c. The functions intelfb_gpio_setscl() and intelfb_gpio_setsda() do drive the 1 bit active to the i2c bus. But since i have no card which is used by the intelfb driver i cannot fix it. Signed-off-by: Stefani Seibold Cc: Paul Mundt Cc: Jean Delvare Signed-off-by: Andrew Morton Signed-off-by: Paul Mundt