Support rfkill-any led trigger for Fujitsu u727

Bug #1745130 reported by Jan-Marek Glogowski on 2018-01-24
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Joseph Salisbury
Xenial
Medium
Joseph Salisbury

Bug Description

== SRU Justification ==
This bug was reported against a Fujitsu u7x7 laptop series based on Skylake hardware.
It has a single rfkill button and a single LED for wlan and bluetooth. Both
drivers currently provide a single rfkill trigger, so the led could
just be assigned to one. This was resolved by mainline commit 9b8e34e211, which added a
"rfkill-any" led trigger to correctly handle the led with multiple
rfkill devices. That was added by one of the fujitsu-laptop maintainers and
the driver sets it as the default trigger.

Commit 9b8e34e211b1 is in mainline as of 4.11-rc1.

== Fix ==
commit 9b8e34e211b15af429b72388a8f2b3b1823d172e
Author: Michał Kępień <email address hidden>
Date: Fri Jan 6 07:07:47 2017 +0100

    rfkill: Add rfkill-any LED trigger

== Regression Potential ==
Medium. This commit affects all arches, but it has been in mainline since
4.11-rc1 with no reported issues.

== Test Case ==
A test kernel was built with this patch and tested by the original bug reporter.
The bug reporter states the test kernel resolved the bug.

== Original Bug Description ==
I got new HW from our supplier, which is the Fujitsu u7x7 laptop series based on Skylake hardware.
It has a single rfkill button and a single LED for wlan and bluetooth. Both device driver currently provide a single rfkill trigger, so the led could just be assigned to one. As a result the upstream kernel got a new "rfkill-any" led trigger to correctly handle the led with multiple rfkill devices. That was added by one of the fujitsu-laptop maintainers and the driver sets it as the default trigger.

commit 9b8e34e211b15af429b72388a8f2b3b1823d172e
Author: Michał Kępień <email address hidden>
Date: Fri Jan 6 07:07:47 2017 +0100

    rfkill: Add rfkill-any LED trigger

Normally I would simply patch the affected modules using DKMS, like the i915_bpo driver, fujitsu-laptop and snd_hda_codec_realtek to support the HW without messing with the kernel packages.
I'm currently waiting for some reviews, like https://www.spinics.net/lists/platform-driver-x86/msg14606.html

But the rfkill support is compiled in, so I can't patch it using DKMS.

So my first proposed fix would be to include a backport of this patch. Alternatively rfkill can be compiled as a module, so I can patch it and provide an updated module.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-4.4.0-111-generic 4.4.0-111.134~14.04.1
ProcVersionSignature: Ubuntu 4.4.0-111.134~14.04.1-generic 4.4.98
Uname: Linux 4.4.0-111-generic i686
ApportVersion: 2.14.1-0ubuntu3.27
Architecture: i386
Date: Wed Jan 24 10:48:28 2018
SourcePackage: linux-lts-xenial
UpgradeStatus: No upgrade log present (probably fresh install)

Jan-Marek Glogowski (jmglogow) wrote :
tags: added: patch
affects: linux-lts-xenial (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: New → Triaged
Changed in linux (Ubuntu Xenial):
status: New → Triaged
Changed in linux (Ubuntu):
importance: Undecided → Medium
Changed in linux (Ubuntu Xenial):
importance: Undecided → Medium
Joseph Salisbury (jsalisbury) wrote :

I built a test kernel with commit 9b8e34e211b15af429b72388a8f2b3b1823d172e. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1745130

Can you test this kernel and see if it resolves this bug?

Note, to test this kernel, you need to install both the linux-image and linux-image-extra .deb packages.

Thanks in advance.

Changed in linux (Ubuntu):
assignee: nobody → Joseph Salisbury (jsalisbury)
Changed in linux (Ubuntu Xenial):
assignee: nobody → Joseph Salisbury (jsalisbury)
status: Triaged → In Progress
Changed in linux (Ubuntu):
status: Triaged → In Progress
Jan-Marek Glogowski (jmglogow) wrote :

Thanks a lot. After apw's comment on IRC I expected something in the next weeks :-)

I can just tell you it boots and seems to work. When I tried to manually build my hw-support-dkms against the kernel I got:

LANG=C ./r
+ pwd
+ make -C /usr/src/linux-headers-4.4.0-112-generic M=/home/glg/mod
make: Entering directory `/usr/src/linux-headers-4.4.0-112-generic'
Makefile:702: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
  CC [M] /home/glg/mod/fujitsu-laptop.o
gcc: error: unrecognized command line option '-fstack-protector-strong'
make[1]: *** [/home/glg/mod/fujitsu-laptop.o] Error 1
make: *** [_module_/home/glg/mod] Error 2
make: Leaving directory `/usr/src/linux-headers-4.4.0-112-generic'

So I guess this kernel was build on Xenial, which I don't have installed. I have Trusty and Bionic, which has the upstream patch included.

But generally it looks ok'ish, as rfkill-any shows up:

$ cat /sys/class/leds/input2\:\:capslock/trigger
none rfkill-any kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online CMB1-charging-or-full CMB1-charging CMB1-full CMB1-charging-blink-full-solid usb-gadget usb-host cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 mmc0 rfkill0 rfkill1 phy0rx phy0tx phy0assoc phy0radio

For a test I used the the caspslock led and manually set the soft rfkill, which triggers the led correctly:

$ echo "rfkill-any" | sudo tee /sys/class/leds/input2\:\:capslock/trigger
rfkill-any
$ cat /sys/class/leds/input2\:\:capslock/trigger
none [rfkill-any] kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock AC-online CMB1-charging-or-full CMB1-charging CMB1-full CMB1-charging-blink-full-solid usb-gadget usb-host cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 mmc0 rfkill0 rfkill1 phy0rx phy0tx phy0assoc phy0radio

=> capslock led is on

$ sudo rfkill list
0: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no

$ sudo rfkill block 0
$ sudo rfkill block 1

=> capslock led is off

I tried all combinations of block and unblock.
No stacks in the dmesg.

So I guess it works as expected.

If you can provide a Trusty based kernel, I'll test it tomorrow.

Changed in linux (Ubuntu Trusty):
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Joseph Salisbury (jsalisbury)
Joseph Salisbury (jsalisbury) wrote :

There is now a Trusty based test kernel with this patch available from:
http://kernel.ubuntu.com/~jsalisbury/lp1745130/trusty/

Jan-Marek Glogowski (jmglogow) wrote :

I can't test this 3.13 kernel, as it has multiple other problems.

What I was talking about was the 4.4 Xenial kernel compiled with the Trusty config / compiler, so my modules will build against:

Makefile:702: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler.

So on Trusty with HWE Xenial I get:

$ grep CONFIG_CC_STACKPROTECTOR_STRONG /boot/config-4.4.0-111-generic
# CONFIG_CC_STACKPROTECTOR_STRONG is not set

while on Xenial I have

$ grep CONFIG_CC_STACKPROTECTOR_STRONG /boot/config-4.4.0-112-generic
CONFIG_CC_STACKPROTECTOR_STRONG=y

Sorry for not being explicit enough.

BTW: I manually compiled the Ubuntu kernel source with my attached patch, the config from /boot as .config and a make oldconfig etc. and it worked as expected.

Joseph Salisbury (jsalisbury) wrote :
no longer affects: linux (Ubuntu Trusty)
description: updated
Stefan Bader (smb) on 2018-03-12
Changed in linux (Ubuntu Xenial):
status: In Progress → Fix Committed
Stefan Bader (smb) wrote :

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed-xenial'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: verification-needed-xenial
Jan-Marek Glogowski (jmglogow) wrote :

I did the same tests as in comment #3 and it works for me.

Thanks.

tags: added: verification-done-xenial
removed: verification-needed-xenial
Launchpad Janitor (janitor) wrote :
Download full text (56.9 KiB)

This bug was fixed in the package linux - 4.4.0-119.143

---------------
linux (4.4.0-119.143) xenial; urgency=medium

  * linux: 4.4.0-119.143 -proposed tracker (LP: #1760327)

  * Dell XPS 13 9360 bluetooth scan can not detect any device (LP: #1759821)
    - Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

linux (4.4.0-118.142) xenial; urgency=medium

  * linux: 4.4.0-118.142 -proposed tracker (LP: #1759607)

  * Kernel panic with AWS 4.4.0-1053 / 4.4.0-1015 (Trusty) (LP: #1758869)
    - x86/microcode/AMD: Do not load when running on a hypervisor

  * CVE-2018-8043
    - net: phy: mdio-bcm-unimac: fix potential NULL dereference in
      unimac_mdio_probe()

linux (4.4.0-117.141) xenial; urgency=medium

  * linux: 4.4.0-117.141 -proposed tracker (LP: #1755208)

  * Xenial update to 4.4.114 stable release (LP: #1754592)
    - x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
    - usbip: prevent vhci_hcd driver from leaking a socket pointer address
    - usbip: Fix implicit fallthrough warning
    - usbip: Fix potential format overflow in userspace tools
    - x86/microcode/intel: Fix BDW late-loading revision check
    - x86/retpoline: Fill RSB on context switch for affected CPUs
    - sched/deadline: Use the revised wakeup rule for suspending constrained dl
      tasks
    - can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
    - can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
    - PM / sleep: declare __tracedata symbols as char[] rather than char
    - time: Avoid undefined behaviour in ktime_add_safe()
    - timers: Plug locking race vs. timer migration
    - Prevent timer value 0 for MWAITX
    - drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled
    - drivers: base: cacheinfo: fix boot error message when acpi is enabled
    - PCI: layerscape: Add "fsl,ls2085a-pcie" compatible ID
    - PCI: layerscape: Fix MSG TLP drop setting
    - mmc: sdhci-of-esdhc: add/remove some quirks according to vendor version
    - fs/select: add vmalloc fallback for select(2)
    - hwpoison, memcg: forcibly uncharge LRU pages
    - cma: fix calculation of aligned offset
    - mm, page_alloc: fix potential false positive in __zone_watermark_ok
    - ipc: msg, make msgrcv work with LONG_MIN
    - x86/ioapic: Fix incorrect pointers in ioapic_setup_resources()
    - ACPI / processor: Avoid reserving IO regions too early
    - ACPI / scan: Prefer devices without _HID/_CID for _ADR matching
    - ACPICA: Namespace: fix operand cache leak
    - netfilter: x_tables: speed up jump target validation
    - netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT ACCEPT" failed
      in 64bit kernel
    - netfilter: nf_dup_ipv6: set again FLOWI_FLAG_KNOWN_NH at flowi6_flags
    - netfilter: nf_ct_expect: remove the redundant slash when policy name is
      empty
    - netfilter: nfnetlink_queue: reject verdict request from different portid
    - netfilter: restart search if moved to other chain
    - netfilter: nf_conntrack_sip: extend request line validation
    - netfilter: use fwmark_reflect in nf_send_reset
    - ext2: Don't clear SGID when inheriting ACLs
    - reiserfs: fix race in prealloc discard
    - re...

Changed in linux (Ubuntu Xenial):
status: Fix Committed → Fix Released
Changed in linux (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers