Jo Jan On Fri, Nov 22, 2013 at 08:36:23PM +0100, Jan Hinnerk Stosch wrote: > I just wanted to ask whether there is something I could do about this? I'm not sure. To recap what you have found: > since commit "a57f7f9175b8ccbc9df83ac13860488913115de4" (bisected) the > wireless key on my Fujitsu E753 is not working any more. If I boot up > with parameter "acpi_osi="!Windows 2012"" it works, though. > I filed an ACPI-bug > (https://bugzilla.kernel.org/show_bug.cgi?id=60161), but was told > (https://bugzilla.kernel.org/show_bug.cgi?id=60161#c5) that this is > caused by the fujitsu_laptop driver. So I report it here. Should I > file a bug anywhere or is it enough to write it to the list? You then answered a followup question which indicated that if fujitsu_laptop module is *not* loaded the key still doesn't work. Does the key work without fujitsu_laptop loaded on a kernel before the commit in question? As I have said previously I am not sure I am in a position to offer assistance here. Firstly I do not have access to any Fujitsu hardware other than my S7020, and that hardware does not implement a wireless key like the E753 does. Secondly, I do not presently understand how the OSI changes in commit a57f7f9175b8ccbc9df83ac13860488913115de4 could affect the fujitsu_laptop module and break the handling of this "wireless key". > Should I ask in another mailing list or sth? I don't think so. Platform-driver-x86 is the appropriate mailing list. As I said in an earlier email: > If someone could explain what the new _OSI string could be doing (or point > to documentation) I could try to work out what might be happening. I am a > little restricted in what I can do though because I don't have fujitsu > hardware that supports the software RF kill switch. Understanding what this _OSI string does and how it could be causing fujitsu_laptop to loose control of the "wireless" key is fundamental to solving this problem. I do not have this knowledge at this point in time, and I do not have the time available right now to start looking into the whole OSI thing from scratch. Not having hardware affected by the problem also makes it difficult for me to investigate. To make progress with this issue, we need to work out what this OSI change has done to the seemingly unrelated code in fujitsu_laptop. This involves working out what OSI does in the first place. Sorry that I can't be more definitive than this. Regards jonathan -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
