Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 19 6月, 2015 6 次提交
    • H
      acer-wmi: Port to new backlight interface selection API · 9a65f0df
      由 Hans de Goede 提交于 
      Port the backlight selection logic to the new backlight interface
selection API.

This commit also removes various obsolete pr_xxx messages related to
backlight interface selection. These are obsolete because they assume
there is only a vendor or acpi backlight driver and no other choice.
Also they are not necessary, if the user wants to know which backlight
interfaces are registered a simple "ls /sys/class/backlight" suffices.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NLee, Chun-Yi <jlee@suse.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9a65f0df
    • H
      acpi-video-detect: video: Make video_detect code part of the video module · 14ca7a47
      由 Hans de Goede 提交于 
      This is a preparation patch for the backlight interface selection logic
cleanup, there are 2 reasons to not always build the video_detect code
into the kernel:

1) In order for the video_detect.c to also deal with / select native
backlight interfaces on win8 systems, instead of doing this in video.c
where it does not belong, video_detect.c needs to call into the backlight
class code. Which cannot be done if it is builtin and the blacklight class
is not.

2) Currently all the platform/x86 drivers which have quirks to prefer
the vendor driver over acpi-video call acpi_video_unregister_backlight()
to remove the acpi-video backlight interface, this logic really belongs
in video_detect.c, which will cause video_detect.c to depend on symbols of
video.c and video.c already depends on video_detect.c symbols, so they
really need to be a single module.

Note that this commits make 2 changes so as to maintain 100% kernel
commandline compatibility:

1) The __setup call for the acpi_backlight= handling is moved to
   acpi/util.c as __setup may only be used by code which is alwasy builtin
2) video.c is renamed to acpi_video.c so that it can be combined with
   video_detect.c into video.ko

This commit also makes changes to drivers/platform/x86/Kconfig to ensure
that drivers which use acpi_video_backlight_support() from video_detect.c,
will not be built-in when acpi_video is not built in. This also changes
some "select" uses to "depends on" to avoid dependency loops.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      14ca7a47
    • H
      apple-gmux: Stop using acpi_video_dmi_demote_vendor() · a341b8ab
      由 Hans de Goede 提交于 
      acpi_video_dmi_demote_vendor() is going away as part of the cleanup of
the code for determinging which backlight class driver(s) to register.

The call to acpi_video_dmi_demote_vendor() was meant to undo the call to
acpi_video_dmi_promote_vendor() when the gmux device is removed, this is
questionable though since the promote call sets a flag, not a counter, so
the demote call may undo a promoto done elsewhere. Moreover in practice
this is a nop since the gmux device is never removed, and the flag is only
checked when acpi/video.ko gets loaded, so even if the user manually
removes apple-gmux the demote call is still a nop as video.ko will already
have loaded by this time.

Also note that none of the other users of acpi_video_dmi_promote_vendor()
use acpi_video_dmi_demote_vendor().

If we ever encounter a system with a gmux where the acpi-video interface
should be used, then the proper fix would be to dmi-blacklist the gmux
driver on that system.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a341b8ab
    • H
      samsung-laptop: Use acpi_video_unregister_backlight instead of acpi_video_unregister · acf5493c
      由 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.

Cc: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      acf5493c
    • H
      asus-wmi: Use acpi_video_unregister_backlight instead of acpi_video_unregister · 4c27febf
      由 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 wmi_backlight_power 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) asus-wmi.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) asus-wmi.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.

Cc: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4c27febf
    • H
      apple_gmux: Use acpi_video_unregister_backlight instead of acpi_video_unregister · 10bffa65
      由 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) 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) apple-gmux.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) apple-gmux.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.

Cc: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      10bffa65
  3. 20 5月, 2015 1 次提交
  5. 06 5月, 2015 1 次提交
  7. 04 5月, 2015 1 次提交
  9. 25 4月, 2015 2 次提交
    • D
      platform/chrome: chromeos_laptop - instantiate Atmel at primary address · 96cba9b0
      由 Dmitry Torokhov 提交于 
      The new Atmel MXT driver expects i2c client's address contain the
primary (main address) of the chip, and calculates the expected
bootloader address form the primary address. Unfortunately chrome_laptop
does probe the devices and if touchpad (or touchscreen, or both) comes
up in bootloader mode the i2c device gets instantiated with the
bootloader address which confuses the driver.

To work around this issue let's probe the primary address first. If the
device is not detected at the primary address we'll probe alternative
addresses as "dummy" devices. If any of them are found, destroy the
dummy client and instantiate client with proper name at primary address
still.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
      96cba9b0
    • H
      toshiba_acpi: Do not register vendor backlight when acpi_video bl is available · 358d6a2c
      由 Hans de Goede 提交于 
      commit a39f46df ("toshiba_acpi: Fix regression caused by backlight extra
check code") causes the backlight to no longer work on the Toshiba Z30,
reverting that commit fixes this but restores the original issue fixed
by that commit.

Looking at the toshiba_acpi backlight code for a fix for this I noticed that
the toshiba code is the only code under platform/x86 which unconditionally
registers a vendor acpi backlight interface, without checking for acpi_video
backlight support first.

This commit adds the necessary checks bringing toshiba_acpi in line with the
other drivers, and fixing the Z30 regression without needing to revert the
commit causing it.

Chances are that there will be some Toshiba models which have a non working
acpi-video implementation while the toshiba vendor backlight interface does
work, this commit adds an empty dmi_id table where such systems can be added,
this is identical to how other drivers handle such systems.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1206036
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=86521Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-and-tested-by: NAzael Avalos <coproscefalo@gmail.com>
Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      358d6a2c
  11. 08 4月, 2015 4 次提交
  13. 01 4月, 2015 2 次提交
  15. 27 3月, 2015 3 次提交
  17. 26 3月, 2015 4 次提交
  19. 19 3月, 2015 2 次提交
  21. 15 3月, 2015 4 次提交
  23. 14 3月, 2015 4 次提交
    • K
      power_supply: Change ownership from driver to core · 297d716f
      由 Krzysztof Kozlowski 提交于 
      Change the ownership of power_supply structure from each driver
implementing the class to the power supply core.

The patch changes power_supply_register() function thus all drivers
implementing power supply class are adjusted.

Each driver provides the implementation of power supply. However it
should not be the owner of power supply class instance because it is
exposed by core to other subsystems with power_supply_get_by_name().
These other subsystems have no knowledge when the driver will unregister
the power supply. This leads to several issues when driver is unbound -
mostly because user of power supply accesses freed memory.

Instead let the core own the instance of struct 'power_supply'.  Other
users of this power supply will still access valid memory because it
will be freed when device reference count reaches 0. Currently this
means "it will leak" but power_supply_put() call in next patches will
solve it.

This solves invalid memory references in following race condition
scenario:

Thread 1: charger manager
Thread 2: power supply driver, used by charger manager

THREAD 1 (charger manager)         THREAD 2 (power supply driver)
==========================         ==============================
psy = power_supply_get_by_name()
                                   Driver unbind, .remove
                                     power_supply_unregister()
                                     Device fully removed
psy->get_property()

The 'get_property' call is executed in invalid context because the driver was
unbound and struct 'power_supply' memory was freed.

This could be observed easily with charger manager driver (here compiled
with max17040 fuel gauge):

$ cat /sys/devices/virtual/power_supply/cm-battery/capacity &
$ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind
[   55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   55.732584] pgd = d98d4000
[   55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000
[   55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[   55.746210] Modules linked in:
[   55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G        W       3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496
[   55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000
[   55.771647] PC is at 0x0
[   55.774182] LR is at charger_get_property+0x2f4/0x36c
[   55.779201] pc : [<00000000>]    lr : [<c034b0b4>]    psr: 60000013
[   55.779201] sp : daf55e90  ip : 00000003  fp : 00000000
[   55.790657] r10: 00000000  r9 : c06e2878  r8 : d9b26c68
[   55.795865] r7 : dad81610  r6 : daec7410  r5 : daf55ebc  r4 : 00000000
[   55.802367] r3 : 00000000  r2 : daf55ebc  r1 : 0000002a  r0 : d9b26c68
[   55.808879] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   55.815994] Control: 10c5387d  Table: 598d406a  DAC: 00000015
[   55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210)
[   55.827451] Stack: (0xdaf55e90 to 0xdaf56000)
[   55.831795] 5e80:                                     60000013 c01459c4 0000002a c06f8ef8
[   55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4
[   55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80
[   55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001
[   55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000
[   55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000
[   55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124
[   55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550
[   55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364
[   55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c
[   55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000
[   55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000
[   55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c)
[   55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48)
[   55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104)
[   55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28)
[   55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484)
[   55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c)
[   55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100)
[   55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c)
[   55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48)
[   56.000626] Code: bad PC value
[   56.011652] ---[ end trace 7b64343fbdae8ef1 ]---
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>

[for the nvec part]
Reviewed-by: NMarc Dietrich <marvin24@gmx.de>

[for compal-laptop.c]
Acked-by: NDarren Hart <dvhart@linux.intel.com>

[for the mfd part]
Acked-by: NLee Jones <lee.jones@linaro.org>

[for the hid part]
Acked-by: NJiri Kosina <jkosina@suse.cz>

[for the acpi part]
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      297d716f
    • K
      power_supply: Move run-time configuration to separate structure · 2dc9215d
      由 Krzysztof Kozlowski 提交于 
      Add new structure 'power_supply_config' for holding run-time
initialization data like of_node, supplies and private driver data.

The power_supply_register() function is changed so all power supply
drivers need updating.

When registering the power supply this new 'power_supply_config' should be
used instead of directly initializing 'struct power_supply'. This allows
changing the ownership of power_supply structure from driver to the
power supply core in next patches.

When a driver does not use of_node or supplies then it should use NULL
as config. If driver uses of_node or supplies then it should allocate
config on stack and initialize it with proper values.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NPavel Machek <pavel@ucw.cz>

[for the nvec part]
Reviewed-by: NMarc Dietrich <marvin24@gmx.de>

[for drivers/platform/x86/compal-laptop.c]
Reviewed-by: NDarren Hart <dvhart@linux.intel.com>

[for drivers/hid/*]
Reviewed-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      2dc9215d
    • K
      compal-laptop: Check return value of power_supply_register · 1915a718
      由 Krzysztof Kozlowski 提交于 
      The return value of power_supply_register() call was not checked and
even on error probe() function returned 0. If registering failed then
during unbind the driver tried to unregister power supply which was not
actually registered.

This could lead to memory corruption because power_supply_unregister()
unconditionally cleans up given power supply.

Fix this by checking return status of power_supply_register() call. In
case of failure, clean up sysfs entries and fail the probe.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 9be0fcb5 ("compal-laptop: add JHL90, battery & hwmon interface")
Cc: <stable@vger.kernel.org>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      1915a718
    • K
      compal-laptop: Fix leaking hwmon device · ad774702
      由 Krzysztof Kozlowski 提交于 
      The commit c2be45f0 ("compal-laptop: Use
devm_hwmon_device_register_with_groups") wanted to change the
registering of hwmon device to resource-managed version. It mostly did
it except the main thing - it forgot to use devm-like function so the
hwmon device leaked after device removal or probe failure.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: c2be45f0 ("compal-laptop: Use devm_hwmon_device_register_with_groups")
Cc: <stable@vger.kernel.org>
Acked-by: NGuenter Roeck <linux@roeck-us.net>
Acked-by: NDarren Hart <dvhart@linux.intel.com>
Signed-off-by: NSebastian Reichel <sre@kernel.org>
      ad774702
  25. 07 3月, 2015 1 次提交
  27. 05 3月, 2015 5 次提交