[ltp] Re: Gen 2 (Haswell) X1 Carbon suspend to RAM hang

[Nikos Alexandris]

Nikos:

>>>> So, here is some attempt:

>>>> --%<---
>>>> tpx1c2g linux-3.14.19 # patch -p1 < /tmp/foo
>>>> patching file drivers/platform/x86/thinkpad_acpi.c
>>>> Reversed (or previously applied) patch detected!  Assume -R? [n] n
>>>> Apply anyway? [n] y
>>>> Hunk #1 succeeded at 3537 with fuzz 1 (offset 100 lines).
>>>> Hunk #2 FAILED at 3556.
>>>> 1 out of 2 hunks FAILED -- saving rejects to file
>>>> drivers/platform/x86/thinkpad_acpi.c.rej
>>>> patch unexpectedly ends in middle of line
>>>> --->%--
>>>>
>>>> and
>>>>
>>>> --%<---
>>>> cat drivers/platform/x86/thinkpad_acpi.c.rej
>>>> --- drivers/platform/x86/thinkpad_acpi.c
>>>> +++ drivers/platform/x86/thinkpad_acpi.c
>>>> @@ -3556,6 +3656,8 @@
>>>>                         *ignore_acpi_ev =3D true;
>>>>                 }
>>>>                 return true;
>>>> +       } else {
>>>> +               return
>>>> adaptive_keyboard_hotkey_notify_hotkey(scancode);
>>>>         }
>>>>         return false;
>>>>  }
>>>> --->%--

Bj=C3=B8rn:

>>> So this failed hunk looks like something that should be fairly easy=20
>>> to
>>> add by hand.  Just open the drivers/platform/x86/thinkpad_acpi.c=20
>>> file,
>>> go look for whatever is there around line 3556 and add that
>>> "else return ..." block at the right spot.

Nikos:

> I think it's already there (after patching!?):

> --%<---
> static bool hotkey_notify_hotkey(const u32 hkey,
> 			 bool *send_acpi_ev,
> 			 bool *ignore_acpi_ev)
> {
> /* 0x1000-0x1FFF: key presses */
> unsigned int scancode =3D hkey & 0xfff;
> *send_acpi_ev =3D true;
> *ignore_acpi_ev =3D false;
>
> /* HKEY event 0x1001 is scancode 0x00 */
> if (scancode > 0 && scancode <=3D TPACPI_HOTKEY_MAP_LEN) {
> 	scancode--;
> 	if (!(hotkey_source_mask & (1 << scancode))) {
> 		tpacpi_input_send_key_masked(scancode);
> 		*send_acpi_ev =3D false;
> 	} else {
> 		*ignore_acpi_ev =3D true;
> 	}
> 	return true;
> } else {
> 	return adaptive_keyboard_hotkey_notify_hotkey(scancode);
> }
> return false;
> }
> -->%--
>
> The above is not my edit, it is just there in
>
> tpx1c2g linux-3.14.19 # ls -l drivers/platform/x86/thinkpad_acpi.c
> -rw-r--r-- 1 root root 242202 Sep 22 13:07=20
> drivers/platform/x86/thinkpad_acpi.c
>
> Looks like something else went wrong!  However, I can't force-remove
> the module. It seems that the kernel I am running doesn't support=20
> this
> kind of action.


The previous kernel, under which removing the thinkpad_acpi module,=20
worked without issues, has:

linux-3.12.18-KS.01 # grep -nr UNLOAD .config*
.config--2014-05-07--14-03-00.bak:277:CONFIG_MODULE_UNLOAD=3Dy
.config--2014-05-07--14-03-00.bak:278:# CONFIG_MODULE_FORCE_UNLOAD is=20
not set


The current one has:

linux-3.14.19-KS.01 # grep -nr UNLOAD .config*
282:CONFIG_MODULE_UNLOAD=3Dy
283:# CONFIG_MODULE_FORCE_UNLOAD is not set

Where is the crux? Why can't I simply remove, and re-load, the=20
thinkpad_acpi module under the current kernel I am running?

Is the thinkpad_acpi module built in a different way? Is it used=20
differently than before?

Nikos