Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 6月, 2015 1 次提交
  3. 27 6月, 2015 1 次提交
  5. 25 6月, 2015 1 次提交
  7. 23 6月, 2015 2 次提交
  9. 19 6月, 2015 22 次提交
  11. 17 6月, 2015 1 次提交
    • P
      drivers/platform: Convert non-modular pdev_bus to use builtin_platform_driver · 1dda2b42
      由 Paul Gortmaker 提交于 
      This driver is configured with a Kconfig option that is
declared as a bool.  Hence it is not possible for the code
to be built as modular.  However the code is currently using
the module_platform_driver() macro for driver registration.

While this currently works, we really don't want to be including
the module.h header in non-modular code, which we'll be forced
to do, pending some upcoming code relocation from init.h into
module.h.  So we fix it now by using the non-modular equivalent.
And since we've already established that the code is non-modular,
we can completely drop any code relating to module_exit.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      1dda2b42
  13. 16 6月, 2015 1 次提交
    • A
      ideapad: fix software rfkill setting · 4b200b46
      由 Arnd Bergmann 提交于 
      This fixes a several year old regression that I found while trying
to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
to send a command to the embedded controller through ACPI, but
as of c1f73658, it sends the index of the rfkill device instead
of the command, and ignores the opcode field.

This changes it back to the original behavior, which indeed
flips the rfkill state as seen in the debugfs interface.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: c1f73658 ("ideapad: pass ideapad_priv as argument (part 2)")
Cc: stable@vger.kernel.org # v2.6.38+
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      4b200b46
  15. 15 6月, 2015 7 次提交
  17. 11 6月, 2015 3 次提交
  19. 08 6月, 2015 1 次提交
    • H
      samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister · 9330dcdd
      由 Hans de Goede 提交于 
      acpi_video_unregister() not only unregisters the acpi-video backlight
interface but also unregisters the acpi video bus event listener, causing
e.g. brightness hotkey presses to no longer generate keypress events.

The unregistering of the acpi video bus event listener usually is
undesirable, which by itself is a good reason to switch to
acpi_video_unregister_backlight().

Another problem with using acpi_video_unregister() rather then using
acpi_video_unregister_backlight() is that on systems with an intel video
opregion (most systems) and a broken_acpi_video quirk, whether or not
the acpi video bus event listener actually gets unregistered depends on
module load ordering:

Scenario a:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
   is an intel opregion.
2) intel.ko gets loaded, calls acpi_video_register() which registers both
   the listener and the acpi backlight interface
3) samsung-laptop.ko gets loaded, calls acpi_video_unregister() causing
   both the listener and the acpi backlight interface to unregister

Scenario b:
1) acpi/video.ko gets loaded (*), does not do acpi_video_register as there
   is an intel opregion.
2) samsung-laptop.ko gets loaded, calls acpi_video_dmi_promote_vendor(),
   calls acpi_video_unregister(), which is a nop since acpi_video_register
   has not yet been called
2) intel.ko gets loaded, calls acpi_video_register() which registers
   the listener, but does not register the acpi backlight interface due to
   the call to the preciding call to acpi_video_dmi_promote_vendor()

*) acpi/video.ko always loads first as both other modules depend on it.

So we end up with or without an acpi video bus event listener depending
on module load ordering, not good.

Switching to using acpi_video_unregister_backlight() means that independ
of ordering we will always have an acpi video bus event listener fixing
this.

Note that this commit means that systems without an intel video opregion,
and systems which were hitting scenario a wrt module load ordering, are
now getting an acpi video bus event listener while before they were not!

On some systems this may cause the brightness hotkeys to start generating
keypresses while before they were not (good), while on other systems this
may cause the brightness hotkeys to generate multiple keypress events for
a single press (not so good). Since on most systems the acpi video bus is
the canonical source for brightness events I believe that the latter case
will needs to be handled on a case by case basis by filtering out the
duplicate keypresses at the other source for them.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: Corentin Chary <corentin.chary@gmail.com)
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      9330dcdd