Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 3月, 2010 1 次提交
  3. 15 3月, 2010 1 次提交
  5. 28 1月, 2010 1 次提交
  7. 31 12月, 2009 1 次提交
  9. 30 12月, 2009 2 次提交
  11. 28 10月, 2009 1 次提交
    • A
      ACPI: clean up video.c boundary checks and types · 52a2b11c
      由 Arjan van de Ven 提交于 
      proc.c and video.c are a bit sloppy around types and style,
confusing gcc for a new feature that'll be in 2.6.33 and will
cause a warning on the current code.

This patch changes

if  (foo + 1 > sizeof bar)

into

if (foo >= sizeof(bar))

which is more kernel-style.

it also changes a variable in proc.c to unsigned; it gets assigned
a value from an unsigned type, and is then only compared for > not
for negative, so using unsigned is just outright the right type
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      52a2b11c
  13. 13 10月, 2009 1 次提交
  15. 02 10月, 2009 1 次提交
  17. 22 9月, 2009 1 次提交
  19. 19 9月, 2009 1 次提交
  21. 01 9月, 2009 1 次提交
  23. 30 8月, 2009 3 次提交
  25. 29 8月, 2009 2 次提交
  27. 28 8月, 2009 1 次提交
  29. 24 6月, 2009 3 次提交
  31. 18 6月, 2009 1 次提交
  33. 30 5月, 2009 3 次提交
  35. 08 5月, 2009 1 次提交
  37. 25 4月, 2009 1 次提交
  39. 20 4月, 2009 1 次提交
  41. 18 4月, 2009 1 次提交
  43. 11 4月, 2009 1 次提交
    • Z
      ACPI video: handle indexed _BQC correctly · e047cca6
      由 Zhang Rui 提交于 
      In the current code, for a box with an indexed _BQC method, we
1. get the current brightness level by evaluating _BQC
2. set the value gotten in step 1 to _BCM
3. get the current brightness level again
4. set the _BQC_use_index flag if the results gotten
   in step 1 and in step 3 don't equal.

But this logic doesn't work actually, because the _BQC_use_index
is not set when acpi_video_device_lcd_set_level is invoked.
This results in a failure in step 2.
http://bugzilla.kernel.org/show_bug.cgi?id=12249#c83

Now, we set the _BQC_use_index flag after invoking _BQC for the first
time. And reevaluate the _BQC to get the correct brightness level.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
      e047cca6
  45. 08 4月, 2009 1 次提交
  47. 04 4月, 2009 3 次提交
  49. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      由 Alexey Dobriyan 提交于 
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  51. 28 3月, 2009 5 次提交