05 Nov, 2011

1 commit


28 Sep, 2011

1 commit

  • There are numerous broken references to Documentation files (in other
    Documentation files, in comments, etc.). These broken references are
    caused by typo's in the references, and by renames or removals of the
    Documentation files. Some broken references are simply odd.

    Fix these broken references, sometimes by dropping the irrelevant text
    they were part of.

    Signed-off-by: Paul Bolle
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

07 Jul, 2011

2 commits

  • Handle events 0x4010 and 0x4011 so that we do not pester users about them.

    These events report when the thinkpad is docked/undocked to a native
    hotplug dock (i.e. one that does not need ACPI handling, nor is represented
    in the ACPI device tree). Such docks are based on USB 2.0/3.0, and also
    work as port replicators.

    We really want a proper dock class to report these, or at least new input
    EV_SW events. Since it is not clear which one to use yet, keep reporting
    them as vendor-specific ThinkPad events.

    WARNING: As defined by the thinkpad-acpi sysfs ABI rules of engagement, the
    vendor-specific events will be REMOVED as soon as generic events are made
    available (duplicate events are a big problem), with an appropriate update
    to the thinkpad-acpi sysfs/event ABI versioning. Userspace is already
    prepared to provide easy backwards compatibility for such changes when
    convenient to the distro (see acpi-fakekey).

    * Event 0x4010: docking to hotplug dock/port replicator
    * Event 0x4011: undocking from hotplug dock/port replicator

    Typical usecase would be to trigger display reconfiguration.

    Reports mention T410, T510, and series 3 docks/port replicators. Special
    thanks to Robert de Rooy for his extensive report and analysis of the
    situation.

    http://www.thinkwiki.org/wiki/ThinkPad_Port_Replicator_Series_3
    http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Series_3
    http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3
    http://www.thinkwiki.org/wiki/ThinkPad_Mini_Dock_Plus_Series_3_for_Mobile_Workstations
    http://lenovoblogs.com/insidethebox/?p=290

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Matthew Garrett
    Reported-by: Claudius Hubig
    Reported-by: Doctor Bill
    Reported-by: Korte Noack
    Reported-by: Robert de Rooy
    Reported-by: Sebastian Will
    Signed-off-by: Matthew Garrett

    Henrique de Moraes Holschuh
     
  • Handle some user interface events from the newer Lenovo models. We are likely
    to do something smart with these events in the future, for now, hide the ones
    we are already certain about from the user and userspace both.

    * Events 0x6000 and 0x6005 are key-related. 0x6005 is not properly identified
    yet. Ignore these events, and do not report them.

    * Event 0x6040 has not been properly identified yet, and we don't know if it
    is important (looks like it isn't, but still...). Keep reporting it.

    * Change the message the driver outputs on unknown 0x6xxx events, as all
    recent events are not related to thermal alarms. Degrade log level from
    ALERT to WARNING.

    Thanks to all users who reported these events or asked about them in a number
    of mailing lists. Your help is highly appreciated, even if I did took a lot of
    time to act on them. For that I apologise.

    I will list those that identified the reasons for the events as "reported-by",
    and I apologise in advance if I leave anyone out: it was not done on purpose, I
    made the mistake of not properly tagging all event report emails separately,
    and might have missed some.

    Signed-off-by: Henrique de Moraes Holschuh
    Reported-by: Markus Malkusch
    Reported-by: Peter Giles
    Signed-off-by: Matthew Garrett

    Henrique de Moraes Holschuh
     

28 May, 2011

1 commit


05 Apr, 2011

1 commit


28 Mar, 2011

1 commit


22 Mar, 2011

1 commit

  • The hp_accel driver isn't a hardware monitoring driver, so it doesn't
    belong to drivers/hwmon. Move it to drivers/platform/x86, assuming HP
    doesn't ship non-x86 laptops.

    Signed-off-by: Jean Delvare
    Acked-by: Guenter Roeck
    Acked-by: Eric Piel
    Acked-by: Jonathan Cameron
    Tested-by: Eric Piel
    Tested-by: Takashi Iwai

    Jean Delvare
     

16 Aug, 2010

1 commit


05 Aug, 2010

1 commit

  • * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (48 commits)
    Documentation: update broken web addresses.
    fix comment typo "choosed" -> "chosen"
    hostap:hostap_hw.c Fix typo in comment
    Fix spelling contorller -> controller in comments
    Kconfig.debug: FAIL_IO_TIMEOUT: typo Faul -> Fault
    fs/Kconfig: Fix typo Userpace -> Userspace
    Removing dead MACH_U300_BS26
    drivers/infiniband: Remove unnecessary casts of private_data
    fs/ocfs2: Remove unnecessary casts of private_data
    libfc: use ARRAY_SIZE
    scsi: bfa: use ARRAY_SIZE
    drm: i915: use ARRAY_SIZE
    drm: drm_edid: use ARRAY_SIZE
    synclink: use ARRAY_SIZE
    block: cciss: use ARRAY_SIZE
    comment typo fixes: charater => character
    fix comment typos concerning "challenge"
    arm: plat-spear: fix typo in kerneldoc
    reiserfs: typo comment fix
    update email address
    ...

    Linus Torvalds
     

04 Aug, 2010

1 commit

  • Below you will find an updated version from the original series bunching all patches into one big patch
    updating broken web addresses that are located in Documentation/*
    Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult,
    the best way to deal with these is to use web.archive.org to locate these addresses that are outdated.
    Now there are also some addresses pointing to .spec files some are located, but some(after searching
    on the companies site)where still no where to be found. In this case I just changed the address
    to the company site this way the users can contact the company and they can locate them for the users.

    Signed-off-by: Justin P. Mattock
    Signed-off-by: Thomas Weber
    Signed-off-by: Mike Frysinger
    Cc: Paulo Marques
    Cc: Randy Dunlap
    Cc: Michael Neuling
    Signed-off-by: Jiri Kosina

    Justin P. Mattock
     

03 Aug, 2010

1 commit

  • There is a general interface for that now (provided by
    other patches in this patch series):
    /sys/kernel/debug/ec/*/io

    Signed-off-by: Thomas Renninger

    CC: Alexey Starikovskiy
    CC: Len Brown
    CC: linux-kernel@vger.kernel.org
    CC: linux-acpi@vger.kernel.org
    CC: platform-driver-x86@vger.kernel.org
    CC: Henrique de Moraes Holschuh
    CC: ibm-acpi-devel@lists.sourceforge.net
    Signed-off-by: Matthew Garrett

    Thomas Renninger
     

22 May, 2010

1 commit

  • * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86: (32 commits)
    Move N014, N051 and CR620 dmi information to load scm dmi table
    drivers/platform/x86/eeepc-wmi.c: fix build warning
    X86 platfrom wmi: Add debug facility to dump WMI data in a readable way
    X86 platform wmi: Also log GUID string when an event happens and debug is set
    X86 platform wmi: Introduce debug param to log all WMI events
    Clean up all objects used by scm model when driver initial fail or exit
    msi-laptop: fix up some coding style issues found by checkpatch
    msi-laptop: Add i8042 filter to sync sw state with BIOS when function key pressed
    msi-laptop: Set rfkill init state when msi-laptop intiial
    msi-laptop: Add MSI CR620 notebook dmi information to scm models table
    msi-laptop: Add N014 N051 dmi information to scm models table
    drivers/platform/x86: Use kmemdup
    drivers/platform/x86: Use kzalloc
    drivers/platform/x86: Clarify the MRST IPC driver description slightly
    eeepc-wmi: depends on BACKLIGHT_CLASS_DEVICE
    IPC driver for Intel Mobile Internet Device (MID) platforms
    classmate-laptop: Add RFKILL support.
    thinkpad-acpi: document backlight level writeback at driver init
    thinkpad-acpi: clean up ACPI handles handling
    thinkpad-acpi: don't depend on led_path for led firmware type (v2)
    ...

    Linus Torvalds
     

17 May, 2010

1 commit


23 Apr, 2010

1 commit


13 Mar, 2010

2 commits

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (56 commits)
    doc: fix typo in comment explaining rb_tree usage
    Remove fs/ntfs/ChangeLog
    doc: fix console doc typo
    doc: cpuset: Update the cpuset flag file
    Fix of spelling in arch/sparc/kernel/leon_kernel.c no longer needed
    Remove drivers/parport/ChangeLog
    Remove drivers/char/ChangeLog
    doc: typo - Table 1-2 should refer to "status", not "statm"
    tree-wide: fix typos "ass?o[sc]iac?te" -> "associate" in comments
    No need to patch AMD-provided drivers/gpu/drm/radeon/atombios.h
    devres/irq: Fix devm_irq_match comment
    Remove reference to kthread_create_on_cpu
    tree-wide: Assorted spelling fixes
    tree-wide: fix 'lenght' typo in comments and code
    drm/kms: fix spelling in error message
    doc: capitalization and other minor fixes in pnp doc
    devres: typo fix s/dev/devm/
    Remove redundant trailing semicolons from macros
    fix typo "definetly" -> "definitely" in comment
    tree-wide: s/widht/width/g typo in comments
    ...

    Fix trivial conflict in Documentation/laptops/00-INDEX

    Linus Torvalds
     
  • Documentation/laptops/laptop-mode.txt:
    Expose example and tool source files in the Documentation/ directory in
    their own files instead of being buried (almost hidden) in readme/txt files.
    This should help to prevent bitrot.

    This will make them more visible/usable to users who may need
    to use them, to developers who may need to test with them, and
    to anyone who would fix/update them if they were more visible.

    Also, if any of these possibly should not be in the kernel tree at
    all, it will be clearer that they are here and we can discuss if
    they should be removed.

    Signed-off-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

08 Mar, 2010

1 commit


26 Feb, 2010

1 commit

  • Given the right combination of ThinkPad and X.org, just reading the
    video output control state is enough to hard-crash X.org.

    Until the day I somehow find out a model or BIOS cut date to not
    provide this feature to ThinkPads that can do video switching through
    X RandR, change permissions so that only processes with CAP_SYS_ADMIN
    can access any sort of video output control state.

    This bug could be considered a local DoS I suppose, as it allows any
    non-privledged local user to cause some versions of X.org to
    hard-crash some ThinkPads.

    Reported-by: Jidanni
    Signed-off-by: Henrique de Moraes Holschuh
    Cc: stable@kernel.org

    Henrique de Moraes Holschuh
     

05 Feb, 2010

1 commit


27 Dec, 2009

1 commit


16 Dec, 2009

5 commits

  • Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Add the basic ALSA mixer functionality. The mixer is event-driven,
    and will work fine on IBM ThinkPads. I expect Lenovo ThinkPads will
    cause some trouble with the event interface.

    Heavily based on work by Lorne Applebaum
    and ideas from Matthew Garrett .

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Lorne Applebaum
    Cc: Matthew Garrett
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Disable volume control by default. It can be enabled at module load
    time by a module parameter (volume_control=1).

    The audio control mixer that thinkpad-acpi interacts with is fully
    functional without any drivers, and operated by hotkeys.

    The idea behind the console audio control is that the human operator
    is the only one that can interact with it. The ThinkVantage suite in
    Windows does not allow any software-based overrides, and only does OSD
    (on-screen-display) functions.

    The Linux driver will, with the addition of the ALSA interface, try to
    follow and enforce the ThinkVantage UI design:

    The user is supposed to use the keyboard hotkeys to interact with the
    console audio control. The kernel and the desktop environment is
    supposed to cooperate to provide proper user feedback through
    on-screen-display functions.

    Distros are urged to not to enable volume control by default.
    Enabling this must be a local admin's decision. This is the reason
    why there is no Kconfig option.

    Keep in mind that all ThinkPads have a normal, main mixer (AC97 or
    HDA) for regular software-based audio control. We are not talking
    about that mixer here.

    Advanced users are, of course, free to enable volume control and do as
    they please.

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Lorne Applebaum
    Cc: Matthew Garrett
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Lenovo removed the extra mixer since the T61 and thereabouts.
    Newer Lenovo models only have the mute gate function, and leave
    the volume control to the HDA mixer.

    Until a way to automatically query the firmware about its audio
    control capabilities is discovered (there might not be any), use a
    white/black list.

    We will likely need to ask T60 (old and new model) and Z60/Z61 users
    whether they have volume control to populate the black/white list.
    Meanwhile, provide a volume_capabilities parameter that can be used to
    override the defaults.

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Lorne Applebaum
    Cc: Matthew Garrett
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • I don't trust the coupled EC writes and SMI calls the current volume
    control code does very much, although it is exactly what the IBM DSDTs
    seem to do (they never do more than a single step though).

    Change the driver to stop issuing SMIs, and just drive the EC directly
    to the desired level (DSDTs seem to confirm this will work even on
    very old models like the 570 and 600e/x).

    We checkpoint directly to NVRAM (this can be turned off) at
    suspend/shutdown/driver unload, which from what I can see in tbp,
    should also work on every ThinkPad.

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Lorne Applebaum
    Cc: Matthew Garrett
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

10 Dec, 2009

1 commit

  • Take advantage of the new events capabilities of the backlight class to
    notify userspace of backlight changes.

    This depends on "backlight: Allow drivers to update the core, and
    generate events on changes", by Matthew Garrett.

    Signed-off-by: Henrique de Moraes Holschuh
    Cc: Matthew Garrett
    Cc: Richard Purdie
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

26 Sep, 2009

1 commit


21 Sep, 2009

2 commits

  • Update the HKEY event driver to:

    1. Handle better the second-gen firmware, which has no HKEY mask
    support but does report FN+F3, FN+F4 and FN+F12 without the need
    for NVRAM polling.

    a) always make the mask-related attributes available in sysfs;
    b) use DMI quirks to detect the second-gen firmware;
    c) properly report that FN+F3, FN+F4 and FN+F12 are enabled,
    and available even on mask-less second-gen firmware;

    2. Decouple the issuing of hotkey events towards userspace from
    their reception from the firmware. ALSA mixer and brightness
    event reporting support will need this feature.

    3. Clean up the mess in the hotkey driver a great deal. It is
    still very convoluted, and wants a full refactoring into a
    proper event API interface, but that is not going to happen
    today.

    4. Fully reset firmware interface on resume (restore hotkey
    mask and status).

    5. Stop losing polled events for no good reason when changing the
    mask and poll frequencies. We will still lose them when the
    hotkey_source_mask is changed, as well as any that happened
    between driver suspend and driver resume.

    The hotkey subdriver now has the notion of user-space-visible hotkey
    event mask, as well as of the set of "hotkey" events the driver needs
    (because brightness/volume change reports are not just keypress
    reports in most ThinkPad models).

    With this rewrite, the ABI level is bumped to 0x020500 should
    userspace need to know it is dealing with the updated hotkey
    subdriver.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • HKEY event 0x5010 is useless to us: old ThinkPads don't issue it. Newer
    ThinkPads won't issue it anymore. And all ThinkPads issue 0x1010 and
    0x1011 events.

    Just silently drop it instead of sending it to userspace.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

19 Sep, 2009

3 commits

  • Len Brown
     
  • echo "reset" > /proc/acpi/ibm/hotkey should do something non-useless,
    so instead of setting it to Fn+F2, Fn+F3, Fn+F5, set it to
    hotkey_recommended_mask.

    It is not like it will survive for much longer, anyway.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Some analysis of the ACPI DSDTs shows that the HKEY pre-enabled mask
    is always 0x80c (FN+F3,FN+F4 and FN+F12), which are the hotkeys that
    the second gen of HKEY firmware supported (the first gen didn't report
    any hotkeys, the second reported these tree hotkeys but had no mask
    support, and the third added mask support).

    So, this is probably some sort of backwards compatibility with older
    versions of the IBM ThinkVantage suite. We have no use for that, and
    I know of exactly ZERO users of that attribute, anyway. Start the
    process of getting rid of it.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

29 Aug, 2009

1 commit


02 Aug, 2009

1 commit

  • The standard ACPI dock driver can handle the hotplug bays and docks of
    the ThinkPads just fine (including batteries) as of 2.6.27, and the
    code in thinkpad-acpi for the dock and bay subdrivers is currently
    broken anyway...

    Userspace needs some love to support the two-stage ejection nicely,
    but it is simple enough to do through udev rules (you don't even need
    HAL) so this wouldn't justify fixing the dock and bay subdrivers,
    either.

    That leaves warm-swap bays (_EJ3) support for thinkpad-acpi, as well
    as support for the weird dock of the model 570, but since such support
    has never left the "experimental" stage, it is also not a strong
    enough reason to find a way to fix this code.

    Users of ThinkPads with warm-swap bays are urged to request that _EJ3
    support be added to the regular ACPI dock driver, if such feature is
    indeed useful for them.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

24 Jun, 2009

1 commit


18 Jun, 2009

3 commits

  • Support reading the tachometer of the auxiliary fan of a X60/X61.

    It was found out by sheer luck, that bit 0 of EC register 0x31
    (formely HBRV) selects which fan is active for tachometer readings
    through EC 0x84/0x085: 0 for fan1, 1 for fan2.

    Many thanks to Christoph Kl??nter, to Whoopie, and to weasel, who
    helped confirm that behaviour.

    Fan control through EC HFSP applies to both fans equally, regardless
    of the state of bit 0 of EC 0x31. That matches the way the DSDT uses
    HFSP.

    In order to better support the secondary fan, export a second
    tachometer over hwmon, and add defensive measures to make sure we are
    reading the correct tachometer.

    Support for the second fan is whitelist-based, as I have not found
    anything obvious to look for in the DSDT to detect the presence of
    the second fan.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Forcing thinkpad-acpi to do EC-based brightness control (HBRV) on a
    X61 has very... interesting effects, instead of doing nothing (since
    it doesn't have EC-based backlight control), it causes "weirdness" in
    the fan tachometer readings, for example.

    This means the EC register that used to be HBRV has been reused by
    Lenovo for something else, but they didn't remove it from the DSDT.

    Make sure the documentation reflects this data, and forbid the user
    from forcing the driver to access HBRV on Lenovo ThinkPads.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     
  • Add support for extra LEDs on recent ThinkPads, and avoid registering
    with the led class the LEDs which are not available for a given
    ThinkPad model.

    All non-restricted LEDs are always available through the procfs
    interface, as the firmware doesn't care if an attempt is made to
    access an invalid LED.

    Signed-off-by: Henrique de Moraes Holschuh
    Signed-off-by: Len Brown

    Henrique de Moraes Holschuh
     

13 Jun, 2009

1 commit