Re: Linux 5.12-rc7
105/psparse-529) [0.960195] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.CPU0._CPC], AE_NOT_FOUND (20210105/psargs-330) [0.960197] ACPI Error: Aborting method \_PR.CPU3._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529) [0.960222] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.CPU0._CPC], AE_NOT_FOUND (20210105/psargs-330) [0.960224] ACPI Error: Aborting method \_PR.CPU4._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529) [0.960248] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.CPU0._CPC], AE_NOT_FOUND (20210105/psargs-330) [0.960250] ACPI Error: Aborting method \_PR.CPU5._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529) [0.960274] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.CPU0._CPC], AE_NOT_FOUND (20210105/psargs-330) [0.960276] ACPI Error: Aborting method \_PR.CPU6._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529) [0.960300] ACPI BIOS Error (bug): Could not resolve symbol [\_PR.CPU0._CPC], AE_NOT_FOUND (20210105/psargs-330) [0.960302] ACPI Error: Aborting method \_PR.CPU7._CPC due to previous error (AE_NOT_FOUND) (20210105/psparse-529) ... and this one since 5.11 or earlier: [2.598268] i915 :00:02.0: [drm] failed to retrieve link info, disabling eDP box is connected via HDMI only. regards Ronald
Re: [PATCH 5.11 000/252] 5.11.11-rc2 review
On 29.03.21 16:46, Greg KH wrote:
On Mon, Mar 29, 2021 at 04:40:00PM +0200, Ronald Warsow wrote:
hello
5.11.11-rc2 compiles, boots and run fine here (on an i7-6700 with Fedora
34 Beta)
Thanks.
but I see some error's/warning's with the new gcc-11.0.1 compared to the
elder gcc-10.2.1-11
Do you also see those gcc-11 warnings on Linus's tree? I don't think
I've started to backport any gcc-11 fixes like this to older kernels
just yet.
thanks,
greg k-h
it seems so (I'm not an developer, just a home user compiling kernels).
AFAIK, there is a new gcc 11.x.y release with fixes for Fedora 34 in the
pipe, but not yet released, so no need to invest time.
just an report what I see here.
with linux-5.12-rc5 from https://www.kernel.org/
I see:
...
CC mm/gup.o
AR arch/x86/kernel/acpi/built-in.a
CC fs/proc/inode.o
In function ‘poly1305_simd_init’,
inlined from ‘crypto_poly1305_setdctxkey’ at
arch/x86/crypto/poly1305_glue.c:150:4,
inlined from ‘crypto_poly1305_setdctxkey’ at
arch/x86/crypto/poly1305_glue.c:144:21,
inlined from ‘poly1305_update_arch’ at
arch/x86/crypto/poly1305_glue.c:181:8:
arch/x86/crypto/poly1305_glue.c:86:9: warning: ‘poly1305_init_x86_64’
reading 32 bytes from a region of size 16 [-Wstringop-overread]
86 | poly1305_init_x86_64(ctx, key);
| ^~
arch/x86/crypto/poly1305_glue.c: In function ‘poly1305_update_arch’:
arch/x86/crypto/poly1305_glue.c:86:9: note: referencing argument 2 of
type ‘const u8 *’ {aka ‘const unsigned char *’}
arch/x86/crypto/poly1305_glue.c:18:17: note: in a call to function
‘poly1305_init_x86_64’
18 | asmlinkage void poly1305_init_x86_64(void *ctx,
| ^~~~
AS arch/x86/crypto/nh-sse2-x86_64.o
...
CC kernel/cgroup/cpuset.o
In file included from ./include/linux/string.h:269,
from ./include/linux/bitmap.h:9,
from ./include/linux/cpumask.h:12,
from ./arch/x86/include/asm/cpumask.h:5,
from ./arch/x86/include/asm/msr.h:11,
from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:59,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from ./include/linux/rcupdate.h:27,
from ./include/linux/rbtree.h:22,
from ./include/linux/iova.h:14,
from ./include/linux/intel-iommu.h:14,
from arch/x86/kernel/tboot.c:9:
In function ‘memcmp’,
inlined from ‘tboot_probe’ at arch/x86/kernel/tboot.c:70:6:
./include/linux/fortify-string.h:19:33: warning: ‘__builtin_memcmp_eq’
specified bound 16 exceeds source size 0 [-Wstringop-overread]
19 | #define __underlying_memcmp __builtin_memcmp
| ^
./include/linux/fortify-string.h:235:16: note: in expansion of macro
‘__underlying_memcmp’
235 | return __underlying_memcmp(p, q, size);
|^~~
CC kernel/time/tick-common.o
...
CC drivers/acpi/acpica/utglobal.o
lib/crypto/poly1305-donna64.c:15:67: warning: argument 2 of type ‘const
u8[16]’ {aka ‘const unsigned char[16]’} with mismatched bound
[-Warray-parameter=]
15 | void poly1305_core_setkey(struct poly1305_core_key *key, const
u8 raw_key[16])
|
~^~~
In file included from lib/crypto/poly1305-donna64.c:11:
./include/crypto/internal/poly1305.h:21:68: note: previously declared as
‘const u8 *’ {aka ‘const unsigned char *’}
21 | void poly1305_core_setkey(struct poly1305_core_key *key, const
u8 *raw_key);
|
~~^~~
CC fs/btrfs/raid56.o
..
CC lib/decompress_unlzma.o
arch/x86/lib/msr-smp.c:255:51: warning: argument 2 of type ‘u32 *’ {aka
‘unsigned int *’} declared as a pointer [-Warray-parameter=]
255 | int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 *regs)
| ~^~~~
In file included from ./arch/x86/include/asm/processor.h:22,
from ./arch/x86/include/asm/cpufeature.h:5,
from ./arch/x86/include/asm/thread_info.h:53,
from ./include/linux/thread_info.h:59,
from ./arch/x86/include/asm/preempt.h:7,
from ./include/linux/preempt.h:78,
from arch/x86/lib/msr-smp.c:3:
./arch/x86/include/asm/msr.h:347:50: note: previously declared as an
array ‘u32[8]’ {aka ‘unsigned int[8]’}
347 | int rdmsr_safe_regs_on_cpu(unsigned int cpu, u32 regs[8]);
| ^~~
arch/x86/lib/msr-smp.c:268:51: warning: argument 2 of type ‘u32 *’ {aka
‘unsigned int *’} declared as a pointer [-Warray-parameter=]
268 | int wrmsr_safe_regs_on_cpu(unsigned int
RE: [PATCH 5.11 000/252] 5.11.11-rc2 review
ka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘ilk_setup_wm_latency’,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7650:3:
drivers/gpu/drm/i915/intel_pm.c:3103:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
3103 | intel_print_wm_latency(dev_priv, "Primary",
dev_priv->wm.pri_latency);
|
^
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3103:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘ilk_setup_wm_latency’,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7650:3:
drivers/gpu/drm/i915/intel_pm.c:3104:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
3104 | intel_print_wm_latency(dev_priv, "Sprite",
dev_priv->wm.spr_latency);
|
^~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3104:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘ilk_setup_wm_latency’,
inlined from ‘intel_init_pm’ at drivers/gpu/drm/i915/intel_pm.c:7650:3:
drivers/gpu/drm/i915/intel_pm.c:3105:9: warning:
‘intel_print_wm_latency’ reading 16 bytes from a region of size 10
[-Wstringop-overread]
3105 | intel_print_wm_latency(dev_priv, "Cursor",
dev_priv->wm.cur_latency);
|
^~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘intel_init_pm’:
drivers/gpu/drm/i915/intel_pm.c:3105:9: note: referencing argument 3 of
type ‘const u16 *’ {aka ‘const short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2994:13: note: in a call to function
‘intel_print_wm_latency’
2994 | static void intel_print_wm_latency(struct drm_i915_private
*dev_priv,
| ^~
In function ‘intel_dp_check_mst_status’,
inlined from ‘intel_dp_hpd_pulse’ at
drivers/gpu/drm/i915/display/intel_dp.c:7122:8:
drivers/gpu/drm/i915/display/intel_dp.c:5797:22: warning:
‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4
[-Wstringop-overread]
5797 | !drm_dp_channel_eq_ok([10],
intel_dp->lane_count)) {
| ^~~~
drivers/gpu/drm/i915/display/intel_dp.c: In function ‘intel_dp_hpd_pulse’:
drivers/gpu/drm/i915/display/intel_dp.c:5797:22: note: referencing
argument 1 of type ‘const u8 *’ {aka ‘const unsigned char *’}
In file included from drivers/gpu/drm/i915/display/intel_dp.c:38:
./include/drm/drm_dp_helper.h:1267:6: note: in a call to function
‘drm_dp_channel_eq_ok’
1267 | bool drm_dp_channel_eq_ok(const u8
link_status[DP_LINK_STATUS_SIZE],
| ^~~~
--
regards
Ronald
Re: [PATCH 5.11 000/306] 5.11.7-rc1 review
On 16.03.21 13:57, Greg KH wrote: On Tue, Mar 16, 2021 at 01:34:31PM +0100, Ronald Warsow wrote: ... bug/error (since 5.11.1 or 2): i915 :00:02.0: [drm] *ERROR* mismatch in DDB state pipe A plane 1 (expected (0,0), found (0,446)) What is the commit id here for the fix that you are looking for? thanks, greg k-h sorry, I do not have an commit id. *An* error report is here: https://gitlab.freedesktop.org/drm/intel/-/issues/2708 and the fix: sh*t, I searched and found it yesterday somewhere here: https://cgit.freedesktop.org/drm-intel/ but can't find it anymore now. Aaarrggghhh ! IIRC, it seemed to me that a fix regarding the error in(?) ./drivers/gpu/drm/i915/display/intel_display.c: was ~queued~ in one of the *next* or *fixes* I've no idea which *next* or *fixes* will when go into stable or maybe 5.12... sorry, I can't help here much -- regards Ronald
Re: [PATCH 5.11 000/306] 5.11.7-rc1 review
Hallo 5.11.7-rc1 compiles, boots and works fine here (Intel i7-6700) alas a fix doesn't made it in (correct english ?), but AFAIK it's known and queued in drm-next or so bug/error (since 5.11.1 or 2): i915 :00:02.0: [drm] *ERROR* mismatch in DDB state pipe A plane 1 (expected (0,0), found (0,446)) anyway, thanks -- regards Ronald
Re: stable kernel checksumming fails
On 07.03.21 16:48, Greg KH wrote: On Sun, Mar 07, 2021 at 10:43:54AM -0500, Konstantin Ryabitsev wrote: On Sun, Mar 07, 2021 at 03:45:15PM +0100, Greg KH wrote: checksumming the downloaded kernel manually gives an "Okay" though. ... I think it's just cache invalidation problems. I've committed a tiny change to the script that always grabs that file from the origin servers instead of going via the CDN. https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/commit/?id=71e570c5f090b5740e323f98504bf38592785b49 This should sidestep the problem. -K Nice, fixed it for me, thanks! Ronald, does it now work for you too? greg k-h yes, all is fine again. thanks all ! -- regards Ronald
stable kernel checksumming fails
hello
getting stable kernels with this script:
https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/tree/get-verified-tarball
fails since the last 2 (?) stable releases with (last lines):
...
+ /usr/bin/curl -L -o
/home/ron/Downloads/linux-tarball-verify.1GiZid5WT.untrusted/linux-5.11.4.tar.xz
https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.11.4.tar.xz
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft
Speed
100 112M 100 112M0 0 5757k 0 0:00:19 0:00:19 --:--:--
5938k
pushd ${TMPDIR} >/dev/null
+ pushd /home/ron/Downloads/linux-tarball-verify.1GiZid5WT.untrusted
echo "Verifying checksum on linux-${VER}.tar.xz"
+ echo 'Verifying checksum on linux-5.11.4.tar.xz'
Verifying checksum on linux-5.11.4.tar.xz
if ! ${SHA256SUMBIN} -c ${SHACHECK}; then
echo "FAILED to verify the downloaded tarball checksum"
popd >/dev/null
rm -rf ${TMPDIR}
exit 1
fi
+ /usr/bin/sha256sum -c
/home/ron/Downloads/linux-tarball-verify.1GiZid5WT.untrusted/sha256sums.txt
/usr/bin/sha256sum:
/home/ron/Downloads/linux-tarball-verify.1GiZid5WT.untrusted/sha256sums.txt:
no properly formatted SHA256 checksum lines found
+ echo 'FAILED to verify the downloaded tarball checksum'
FAILED to verify the downloaded tarball checksum
+ popd
+ rm -rf /home/ron/Downloads/linux-tarball-verify.1GiZid5WT.untrusted
+ exit 1
checksumming the downloaded kernel manually gives an "Okay" though.
is this just me (on Fedora 33) ?
--
regards
Ronald
[PATCH 1/5] HID: Recognize sensors with application collections too.
According to HUTRR39 logical sensor devices may be nested inside
physical collections or may be specified in multiple top-level
application collections (see page 59, strategies 1 and 2). However,
the current code was only recognizing those with physical collections.
This issue turned up in recent MacBook Pro's which define the ALS in
a top-level application collection.
Signed-off-by: Ronald Tschalär
---
drivers/hid/hid-core.c | 3 ++-
drivers/hid/hid-sensor-hub.c | 6 --
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 56172fe6995cd..a96b252f97366 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -799,7 +799,8 @@ static void hid_scan_collection(struct hid_parser *parser,
unsigned type)
int i;
if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
- type == HID_COLLECTION_PHYSICAL)
+ (type == HID_COLLECTION_PHYSICAL ||
+type == HID_COLLECTION_APPLICATION))
hid->group = HID_GROUP_SENSOR_HUB;
if (hid->vendor == USB_VENDOR_ID_MICROSOFT &&
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index 3dd7d32467378..9aea558407794 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -393,7 +393,8 @@ int sensor_hub_input_get_attribute_info(struct
hid_sensor_hub_device *hsdev,
for (i = 0; i < report->maxfield; ++i) {
field = report->field[i];
if (field->maxusage) {
- if (field->physical == usage_id &&
+ if ((field->physical == usage_id ||
+field->application == usage_id) &&
(field->logical == attr_usage_id ||
field->usage[0].hid ==
attr_usage_id) &&
@@ -502,7 +503,8 @@ static int sensor_hub_raw_event(struct hid_device *hdev,
collection->usage);
callback = sensor_hub_get_callback(hdev,
- report->field[i]->physical,
+ report->field[i]->physical ?:
+ report->field[i]->application,
report->field[i]->usage[0].collection_index,
, );
if (!callback) {
--
2.26.2
[PATCH 4/5] HID: apple-ibridge: Add Apple iBridge HID driver for T1 chip.
The iBridge device provides access to several devices, including: - the Touch Bar - the iSight webcam - the light sensor - the fingerprint sensor This driver provides the core support for managing the iBridge device and the access to the underlying devices. In particular, the functionality for the touch bar and light sensor is exposed via USB HID interfaces, and on devices with the T1 chip one of the HID devices is used for both functions. So this driver creates virtual HID devices, one per top-level report collection on each HID device (for a total of 3 virtual HID devices). The sub-drivers then bind to these virtual HID devices. This way the Touch Bar and ALS drivers can be kept in their own modules, while at the same time making them look very much like as if they were connected to the real HID devices. And those drivers then work (mostly) without further changes on MacBooks with the T2 chip that don't need this driver. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 16 + drivers/hid/Makefile| 1 + drivers/hid/apple-ibridge.c | 682 drivers/hid/apple-ibridge.h | 15 + drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c| 3 + 6 files changed, 718 insertions(+) create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 drivers/hid/apple-ibridge.h diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 09fa75a2b289e..579c45c3e36e5 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -136,6 +136,22 @@ config HID_APPLE Say Y here if you want support for keyboards of Apple iBooks, PowerBooks, MacBooks, MacBook Pros and Apple Aluminum. +config HID_APPLE_IBRIDGE + tristate "Apple iBridge" + depends on ACPI + depends on USB_HID + depends on X86 || COMPILE_TEST + imply HID_SENSOR_HUB + imply HID_SENSOR_ALS + help + This module provides the core support for the Apple T1 chip found + on 2016 and 2017 MacBookPro's, also known as the iBridge. The drivers + for the Touch Bar (apple-touchbar) and light sensor (hid-sensor-hub + and hid-sensor-als) need to be enabled separately. + + To compile this driver as a module, choose M here: the + module will be called apple-ibridge. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 014d21fe7dac6..d29a3934bfaa9 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o obj-$(CONFIG_HID_ALPS) += hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o +obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_CREATIVE_SB0540) += hid-creative-sb0540.o obj-$(CONFIG_HID_ASUS) += hid-asus.o diff --git a/drivers/hid/apple-ibridge.c b/drivers/hid/apple-ibridge.c new file mode 100644 index 0..5f2b71c199746 --- /dev/null +++ b/drivers/hid/apple-ibridge.c @@ -0,0 +1,682 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple iBridge Driver + * + * Copyright (c) 2018 Ronald Tschalär + */ + +/** + * DOC: Overview + * + * 2016 and 2017 MacBookPro models with a Touch Bar (MacBookPro13,[23] and + * MacBookPro14,[23]) have an Apple iBridge chip (also known as T1 chip) which + * exposes the touch bar, built-in webcam (iSight), ambient light sensor, and + * Secure Enclave Processor (SEP) for TouchID. It shows up in the system as a + * USB device with 3 configurations: 'Default iBridge Interfaces', 'Default + * iBridge Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'. + * + * In the first (default after boot) configuration, 4 usb interfaces are + * exposed: 2 related to the webcam, and 2 USB HID interfaces representing + * the touch bar and the ambient light sensor. The webcam interfaces are + * already handled by the uvcvideo driver. However, there is a problem with + * the other two interfaces: one of them contains functionality (HID reports) + * used by both the touch bar and the ALS, which is an issue because the kernel + * allows only one driver to be attached to a given device. This driver exists + * to solve this issue. + * + * This driver is implemented as a HID driver that attaches to both HID + * interfaces and in turn creates several virtual child HID devices, one for + * each top-level collection found in each interfaces report descriptor. The + * touch bar and ALS drivers then attach to these virtual HID devices, and this + * driver forwards the operations between the real and virtual devices. + * + * One important aspect of this approach is that resulting (virtual) HID + * devices look much like the HID devices found on the later MacBookPro models + * which have a T2 chip, where there are sep
[PATCH 5/5] HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's.
This driver enables basic touch bar functionality: enabling it, switching between modes on FN key press, and dimming and turning the display off/on when idle/active. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 10 + drivers/hid/Makefile |1 + drivers/hid/apple-touchbar.c | 1523 ++ 3 files changed, 1534 insertions(+) create mode 100644 drivers/hid/apple-touchbar.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 579c45c3e36e5..1609a60d65cc3 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -141,6 +141,7 @@ config HID_APPLE_IBRIDGE depends on ACPI depends on USB_HID depends on X86 || COMPILE_TEST + imply HID_APPLE_TOUCHBAR imply HID_SENSOR_HUB imply HID_SENSOR_ALS help @@ -152,6 +153,15 @@ config HID_APPLE_IBRIDGE To compile this driver as a module, choose M here: the module will be called apple-ibridge. +config HID_APPLE_TOUCHBAR + tristate "Apple Touch Bar" + help + Say Y here if you want support for the Touch Bar on recent + MacBook Pros. + + To compile this driver as a module, choose M here: the + module will be called apple-touchbar. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index d29a3934bfaa9..b82a8256785da 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_HID_ALPS)+= hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o +obj-$(CONFIG_HID_APPLE_TOUCHBAR) += apple-touchbar.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_CREATIVE_SB0540) += hid-creative-sb0540.o obj-$(CONFIG_HID_ASUS) += hid-asus.o diff --git a/drivers/hid/apple-touchbar.c b/drivers/hid/apple-touchbar.c new file mode 100644 index 0..87cb9ebafb615 --- /dev/null +++ b/drivers/hid/apple-touchbar.c @@ -0,0 +1,1523 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple Touch Bar Driver + * + * Copyright (c) 2017-2018 Ronald Tschalär + */ + +/* + * Recent MacBookPro models (MacBookPro 13,[23] and later) have a touch bar, + * which is exposed via several USB interfaces. MacOS supports a fancy mode + * where arbitrary buttons can be defined; this driver currently only + * supports the simple mode that consists of 3 predefined layouts + * (escape-only, esc + special keys, and esc + function keys). + * + * The first USB HID interface supports two reports, an input report that + * is used to report the key presses, and an output report which can be + * used to set the touch bar "mode": touch bar off (in which case no touches + * are reported at all), escape key only, escape + 12 function keys, and + * escape + several special keys (including brightness, audio volume, + * etc). The second interface supports several, complex reports, most of + * which are unknown at this time, but one of which has been determined to + * allow for controlling of the touch bar's brightness: off (though touches + * are still reported), dimmed, and full brightness. This driver makes + * use of these two reports. + */ + +#define dev_fmt(fmt) "tb: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "hid-ids.h" +#include "apple-ibridge.h" + +#define HID_UP_APPLE 0xff12 +#define HID_USAGE_MODE (HID_UP_CUSTOM | 0x0004) +#define HID_USAGE_APPLE_APP(HID_UP_APPLE | 0x0001) +#define HID_USAGE_DISP (HID_UP_APPLE | 0x0021) +#define HID_USAGE_DISP_AUX1(HID_UP_APPLE | 0x0020) + +#define APPLETB_MAX_TB_KEYS13 /* ESC, F1-F12 */ + +#define APPLETB_CMD_MODE_ESC 0 +#define APPLETB_CMD_MODE_FN1 +#define APPLETB_CMD_MODE_SPCL 2 +#define APPLETB_CMD_MODE_OFF 3 +#define APPLETB_CMD_MODE_UPD 254 +#define APPLETB_CMD_MODE_NONE 255 + +#define APPLETB_CMD_DISP_ON1 +#define APPLETB_CMD_DISP_DIM 2 +#define APPLETB_CMD_DISP_OFF 4 +#define APPLETB_CMD_DISP_UPD 254 +#define APPLETB_CMD_DISP_NONE 255 + +#define APPLETB_FN_MODE_FKEYS 0 +#define APPLETB_FN_MODE_NORM 1 +#define APPLETB_FN_MODE_INV2 +#define APPLETB_FN_MODE_SPCL 3 +#define APPLETB_FN_MODE_ESC4 +#define APPLETB_FN_MODE_MAXAPPLETB_FN_MODE_ESC + +#define APPLETB_DEVID_KEYBOARD 1 +#define APPLETB_DEVID_TOUCHPAD 2 + +#define APPLETB_MAX_DIM_TIME 30 + +#define APPLETB_FEATURE_IS_T1 BIT(0) + +static int appletb_tb_def_idle_timeout = 5 * 60; +module_param_named(idle_timeout, appletb_tb_def_idle_timeout, int, 0444); +MODULE_PARM_DESC(idle_timeout, "Default touch bar idle timeout:\n" + "[>0] - t
[PATCH 3/5] HID: core: Export some report item parsing functions.
These are useful to drivers that need to scan or parse reports
themselves.
Signed-off-by: Ronald Tschalär
---
drivers/hid/hid-core.c | 54 +-
include/linux/hid.h| 4
2 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index a96b252f97366..b4c3d71a0ddda 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -340,7 +340,7 @@ static int hid_add_field(struct hid_parser *parser,
unsigned report_type, unsign
* Read data value from item.
*/
-static u32 item_udata(struct hid_item *item)
+u32 hid_item_udata(struct hid_item *item)
{
switch (item->size) {
case 1: return item->data.u8;
@@ -349,8 +349,9 @@ static u32 item_udata(struct hid_item *item)
}
return 0;
}
+EXPORT_SYMBOL_GPL(hid_item_udata);
-static s32 item_sdata(struct hid_item *item)
+s32 hid_item_sdata(struct hid_item *item)
{
switch (item->size) {
case 1: return item->data.s8;
@@ -359,6 +360,7 @@ static s32 item_sdata(struct hid_item *item)
}
return 0;
}
+EXPORT_SYMBOL_GPL(hid_item_sdata);
/*
* Process a global item.
@@ -391,29 +393,29 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_USAGE_PAGE:
- parser->global.usage_page = item_udata(item);
+ parser->global.usage_page = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_LOGICAL_MINIMUM:
- parser->global.logical_minimum = item_sdata(item);
+ parser->global.logical_minimum = hid_item_sdata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_LOGICAL_MAXIMUM:
if (parser->global.logical_minimum < 0)
- parser->global.logical_maximum = item_sdata(item);
+ parser->global.logical_maximum = hid_item_sdata(item);
else
- parser->global.logical_maximum = item_udata(item);
+ parser->global.logical_maximum = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_PHYSICAL_MINIMUM:
- parser->global.physical_minimum = item_sdata(item);
+ parser->global.physical_minimum = hid_item_sdata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_PHYSICAL_MAXIMUM:
if (parser->global.physical_minimum < 0)
- parser->global.physical_maximum = item_sdata(item);
+ parser->global.physical_maximum = hid_item_sdata(item);
else
- parser->global.physical_maximum = item_udata(item);
+ parser->global.physical_maximum = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_UNIT_EXPONENT:
@@ -421,7 +423,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
* nibble due to the common misunderstanding of HID
* specification 1.11, 6.2.2.7 Global Items. Attempt to handle
* both this and the standard encoding. */
- raw_value = item_sdata(item);
+ raw_value = hid_item_sdata(item);
if (!(raw_value & 0xfff0))
parser->global.unit_exponent = hid_snto32(raw_value, 4);
else
@@ -429,11 +431,11 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_UNIT:
- parser->global.unit = item_udata(item);
+ parser->global.unit = hid_item_udata(item);
return 0;
case HID_GLOBAL_ITEM_TAG_REPORT_SIZE:
- parser->global.report_size = item_udata(item);
+ parser->global.report_size = hid_item_udata(item);
if (parser->global.report_size > 256) {
hid_err(parser->device, "invalid report_size %d\n",
parser->global.report_size);
@@ -442,7 +444,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG_REPORT_COUNT:
- parser->global.report_count = item_udata(item);
+ parser->global.report_count = hid_item_udata(item);
if (parser->global.report_count > HID_MAX_USAGES) {
hid_err(parser->device, "invalid report_count %d\n",
parser->global.report_count);
@@ -451,7 +453,7 @@ static int hid_parser_global(struct hid_parser *parser,
struct hid_item *item)
return 0;
case HID_GLOBAL_ITEM_TAG
[PATCH 2/5] iio: hid-sensor-als: Support change sensitivity in illuminance too.
Recent MacBook Pro's specify the usage of the change sensitivity field as illuminance (with a change sensitivity modifier) rather than as light. Signed-off-by: Ronald Tschalär --- drivers/iio/light/hid-sensor-als.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c index a21c827e4953d..849ee37dcd866 100644 --- a/drivers/iio/light/hid-sensor-als.c +++ b/drivers/iio/light/hid-sensor-als.c @@ -252,6 +252,14 @@ static int als_parse_report(struct platform_device *pdev, HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS | HID_USAGE_SENSOR_DATA_LIGHT, >common_attributes.sensitivity); + + if (st->common_attributes.sensitivity.index < 0) + sensor_hub_input_get_attribute_info(hsdev, + HID_FEATURE_REPORT, usage_id, + HID_USAGE_SENSOR_DATA_MOD_CHANGE_SENSITIVITY_ABS | + HID_USAGE_SENSOR_LIGHT_ILLUM, + >common_attributes.sensitivity); + dev_dbg(>dev, "Sensitivity index:report %d:%d\n", st->common_attributes.sensitivity.index, st->common_attributes.sensitivity.report_id); -- 2.26.2
[PATCH 0/5] Touch Bar and ALS support for MacBook Pro's
This patch set provides Touch Bar and ALS support on MacBook Pro's 13,*, 14,*, and 15,*. Some time a go an earlier version of these were posted to the list; all code comments from there have been incorporated. In addition the approach has been cleaned up, especially given that we now know how the 15,* models are implemented, so that the ibridge driver is only needed for the pre-15,* models and the ALS and Touch Bar drivers work unchanged for all models. Ronald Tschalär (5): HID: Recognize sensors with application collections too. iio: hid-sensor-als: Support change sensitivity in illuminance too. HID: core: Export some report item parsing functions. HID: apple-ibridge: Add Apple iBridge HID driver for T1 chip. HID: apple-touchbar - Add driver for the Touch Bar on MacBook Pro's. drivers/hid/Kconfig| 26 + drivers/hid/Makefile |2 + drivers/hid/apple-ibridge.c| 682 + drivers/hid/apple-ibridge.h| 15 + drivers/hid/apple-touchbar.c | 1523 drivers/hid/hid-core.c | 57 +- drivers/hid/hid-ids.h |1 + drivers/hid/hid-quirks.c |3 + drivers/hid/hid-sensor-hub.c |6 +- drivers/iio/light/hid-sensor-als.c |8 + include/linux/hid.h|4 + 11 files changed, 2302 insertions(+), 25 deletions(-) create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 drivers/hid/apple-ibridge.h create mode 100644 drivers/hid/apple-touchbar.c -- 2.26.2
[PATCH 1/3] Input: applespi: Don't wait for responses to commands indefinitely.
The response to a command may never arrive or it may be corrupted (and
hence dropped) for some reason. While exceedingly rare, when it did
happen it blocked all further commands. One way to fix this was to
do a suspend/resume. However, recovering automatically seems like a
nicer option. Hence this puts a time limit (1 sec) on how long we're
willing to wait for a response, after which we assume it got lost.
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/applespi.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index d3154177f..8494bf610fd70 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -409,7 +410,7 @@ struct applespi_data {
unsigned intcmd_msg_cntr;
/* lock to protect the above parameters and flags below */
spinlock_t cmd_msg_lock;
- boolcmd_msg_queued;
+ ktime_t cmd_msg_queued;
enum applespi_evt_type cmd_evt_type;
struct led_classdev backlight_info;
@@ -729,7 +730,7 @@ static void applespi_msg_complete(struct applespi_data
*applespi,
wake_up_all(>drain_complete);
if (is_write_msg) {
- applespi->cmd_msg_queued = false;
+ applespi->cmd_msg_queued = 0;
applespi_send_cmd_msg(applespi);
}
@@ -771,8 +772,16 @@ static int applespi_send_cmd_msg(struct applespi_data
*applespi)
return 0;
/* check whether send is in progress */
- if (applespi->cmd_msg_queued)
- return 0;
+ if (applespi->cmd_msg_queued) {
+ if (ktime_ms_delta(ktime_get(), applespi->cmd_msg_queued) <
1000)
+ return 0;
+
+ dev_warn(>spi->dev, "Command %d timed out\n",
+applespi->cmd_evt_type);
+
+ applespi->cmd_msg_queued = 0;
+ applespi->write_active = false;
+ }
/* set up packet */
memset(packet, 0, APPLESPI_PACKET_SIZE);
@@ -869,7 +878,7 @@ static int applespi_send_cmd_msg(struct applespi_data
*applespi)
return sts;
}
- applespi->cmd_msg_queued = true;
+ applespi->cmd_msg_queued = ktime_get();
applespi->write_active = true;
return 0;
@@ -1921,7 +1930,7 @@ static int __maybe_unused applespi_resume(struct device
*dev)
applespi->drain = false;
applespi->have_cl_led_on = false;
applespi->have_bl_level = 0;
- applespi->cmd_msg_queued = false;
+ applespi->cmd_msg_queued = 0;
applespi->read_active = false;
applespi->write_active = false;
--
2.26.2
[PATCH 2/3] Input: applespi: Fix occasional crc errors under load.
For some reason, when the system is under heavy CPU load, the read
following the write sometimes occurs unusually quickly, resulting in
the read data not being quite ready and hence a bad packet getting read.
Adding another delay after reading the status message appears to fix
this.
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/applespi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index 8494bf610fd70..f0a0067c48ff6 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -749,6 +749,8 @@ static void applespi_async_write_complete(void *context)
applespi->tx_status,
APPLESPI_STATUS_SIZE);
+ udelay(SPI_RW_CHG_DELAY_US);
+
if (!applespi_check_write_status(applespi, applespi->wr_m.status)) {
/*
* If we got an error, we presumably won't get the expected
--
2.26.2
[PATCH 3/3] Input: applespi: Add trace_event module param for early tracing.
The problem is that tracing can't be set via sysfs until the module is
loaded, at which point the keyboard and trackpad initialization commands
have already been run and hence tracing can't be used to debug problems
here.
Adding this param allows tracing to be enabled for messages sent and
received during module probing. It takes comma-separated list of events,
e.g.
trace_event=applespi_tp_ini_cmd,applespi_bad_crc
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/applespi.c | 32 +++
1 file changed, 32 insertions(+)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index f0a0067c48ff6..03f9ad0f83967 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -53,6 +53,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -110,6 +112,10 @@ module_param_string(touchpad_dimensions,
touchpad_dimensions,
sizeof(touchpad_dimensions), 0444);
MODULE_PARM_DESC(touchpad_dimensions, "The pixel dimensions of the touchpad,
as XxY+W+H .");
+static char *trace_event;
+module_param(trace_event, charp, 0444);
+MODULE_PARM_DESC(trace_event, "Enable early event tracing. It takes the form
of a comma-separated list of events to enable.");
+
/**
* struct keyboard_protocol - keyboard message.
* message.type = 0x0110, message.length = 0x000a
@@ -1645,6 +1651,30 @@ static void applespi_save_bl_level(struct applespi_data
*applespi,
"Error saving backlight level to EFI vars: %d\n", sts);
}
+static void applespi_enable_early_event_tracing(struct device *dev)
+{
+ char *buf, *event;
+ int sts;
+
+ if (trace_event && trace_event[0]) {
+ buf = kstrdup(trace_event, GFP_KERNEL);
+ if (!buf)
+ return;
+
+ while ((event = strsep(, ","))) {
+ if (event[0]) {
+ sts = trace_set_clr_event("applespi", event, 1);
+ if (sts)
+ dev_warn(dev,
+"Error setting trace event
'%s': %d\n",
+event, sts);
+ }
+ }
+
+ kfree(buf);
+ }
+}
+
static int applespi_probe(struct spi_device *spi)
{
struct applespi_data *applespi;
@@ -1653,6 +1683,8 @@ static int applespi_probe(struct spi_device *spi)
int sts, i;
unsigned long long gpe, usb_status;
+ applespi_enable_early_event_tracing(>dev);
+
/* check if the USB interface is present and enabled already */
acpi_sts = acpi_evaluate_integer(spi_handle, "UIST", NULL, _status);
if (ACPI_SUCCESS(acpi_sts) && usb_status) {
--
2.26.2
Re: [PATCH 5.9 000/757] 5.9.2-rc1 review
On 29.10.20 20:17, Greg KH wrote:
On Thu, Oct 29, 2020 at 03:42:09PM +0100, Ronald Warsow wrote:
On 29.10.20 10:14, Greg KH wrote:
On Tue, Oct 27, 2020 at 07:09:52PM +0100, Ronald Warsow wrote:
Hallo
this rc1 runs here (pure Intel-box) without errors.
Thanks !
An RPC (I'm thinking about since some month)
==
Wouldn't it be better (and not so much add. work) to sort the
Pseudo-Shortlog towards subsystem/driver ?
something like this:
...
usb: gadget: f_ncm: allow using NCM in SuperSpeed Plus gadgets.
usb: cdns3: gadget: free interrupt after gadget has deleted
Lorenzo Colitti
Peter Chen
...
Think of searching a bugfix in the shortlog.
With the current layout I need to read/"visual grep" the whole log.
With the new layout I'm able to jump to the "buggy" subsystem/driver and
only need to read that part of the log to get the info if the bug is
fixed or not yet
Do you have an example script that generates such a thing? If so, I'll
be glad to look into it, but am not going to try to create it on my own,
sorry.
thanks,
greg k-h
first of all: in the above mail it should read "RFC"
Surely, who get the most benefit of it (the layout) does the most work.
Agreed, I will see what I can do -I'm unsure -
Currently, I'm thinking that the data for your shortlog are coming from
a sort of an git query or so and it would just be an easy adjustment of
the query parameter.
This seems not to be the case ?
To get an idea if my knowledge is sufficing (I'm no developer):
Where do you get the data from to generate your shortlog ?
A "simple" git command:
git log --abbrev=12 --format="%aN <%aE>%n%s%n" ${VERSION}..HEAD >
${TMP_LOG}
If you can come up with a command that replaces that, I'll be glad to
try it out.
thanks,
greg k-h
I'll have a look into it.
--
regards
Ronald
Re: [PATCH 5.9 000/757] 5.9.2-rc1 review
On 29.10.20 10:14, Greg KH wrote: On Tue, Oct 27, 2020 at 07:09:52PM +0100, Ronald Warsow wrote: Hallo this rc1 runs here (pure Intel-box) without errors. Thanks ! An RPC (I'm thinking about since some month) == Wouldn't it be better (and not so much add. work) to sort the Pseudo-Shortlog towards subsystem/driver ? something like this: ... usb: gadget: f_ncm: allow using NCM in SuperSpeed Plus gadgets. usb: cdns3: gadget: free interrupt after gadget has deleted Lorenzo Colitti Peter Chen ... Think of searching a bugfix in the shortlog. With the current layout I need to read/"visual grep" the whole log. With the new layout I'm able to jump to the "buggy" subsystem/driver and only need to read that part of the log to get the info if the bug is fixed or not yet Do you have an example script that generates such a thing? If so, I'll be glad to look into it, but am not going to try to create it on my own, sorry. thanks, greg k-h first of all: in the above mail it should read "RFC" Surely, who get the most benefit of it (the layout) does the most work. Agreed, I will see what I can do -I'm unsure - Currently, I'm thinking that the data for your shortlog are coming from a sort of an git query or so and it would just be an easy adjustment of the query parameter. This seems not to be the case ? To get an idea if my knowledge is sufficing (I'm no developer): Where do you get the data from to generate your shortlog ? -- regards Ronald
Re: [PATCH 5.9 000/757] 5.9.2-rc1 review
Hallo this rc1 runs here (pure Intel-box) without errors. Thanks ! An RPC (I'm thinking about since some month) == Wouldn't it be better (and not so much add. work) to sort the Pseudo-Shortlog towards subsystem/driver ? something like this: ... usb: gadget: f_ncm: allow using NCM in SuperSpeed Plus gadgets. usb: cdns3: gadget: free interrupt after gadget has deleted Lorenzo Colitti Peter Chen ... Think of searching a bugfix in the shortlog. With the current layout I need to read/"visual grep" the whole log. With the new layout I'm able to jump to the "buggy" subsystem/driver and only need to read that part of the log to get the info if the bug is fixed or not yet Well, surely there are other ways to get the info I need, e.g. search-function of my favorite browser, but ... -- regards Ronald
Re: BUG with 5.8.x and make xconfig
On 20.08.20 19:14, Masahiro Yamada wrote: On Fri, Aug 21, 2020 at 12:46 AM Ronald Warsow wrote: ... qt-devel-4.8.7-55.fc32.x86_64 This one is the Qt4 development package. I thought that, but I wasn't 100 % sure. I do not know why, but both "dnf install qt-devel" and "dnf install qt4-devel" works equivalently. something learned. ... I know, this was reported by somebody else before. I will fix this too. Thanks again. -- regards Ronald
Re: BUG with 5.8.x and make xconfig
On 20.08.20 13:33, Masahiro Yamada wrote:
On Thu, Aug 20, 2020 at 4:19 AM Ronald Warsow wrote:
...
I think you are using Qt4
(dnf install qt4-devel).
no, there is no qt4-devel in the Fedora repos:
rpm -qa|grep -i qt4
adwaita-qt4-1.1.3-2.fc32.x86_64
all qt relative currently installed, is this:
rpm -qa|grep -i qt|sort:
adwaita-qt4-1.1.3-2.fc32.x86_64
adwaita-qt5-1.1.3-2.fc32.x86_64
dbusmenu-qt-0.9.3-0.22.20160218.fc32.x86_64
gstreamer1-plugins-good-qt-1.16.2-2.fc32.x86_64
ibus-qt-1.3.3-24.fc32.x86_64
qt-4.8.7-55.fc32.x86_64
qt5-qtbase-5.14.2-5.fc32.x86_64
qt5-qtbase-common-5.14.2-5.fc32.noarch
qt5-qtbase-gui-5.14.2-5.fc32.x86_64
qt5-qtdeclarative-5.14.2-1.fc32.x86_64
qt5-qtmultimedia-5.14.2-1.fc32.x86_64
qt5-qtsvg-5.14.2-1.fc32.x86_64
qt5-qtwayland-5.14.2-4.fc32.x86_64
qt5-qtx11extras-5.14.2-1.fc32.x86_64
qt5-qtxmlpatterns-5.14.2-1.fc32.x86_64
qt5-srpm-macros-5.14.2-3.fc32.noarch
qt-common-4.8.7-55.fc32.noarch
qt-devel-4.8.7-55.fc32.x86_64
qt-settings-32.0-3.fc32.noarch
qt-x11-4.8.7-55.fc32.x86_64
quazip-qt5-0.7.6-6.fc32.x86_64
sni-qt-0.2.7-0.4.20170217.fc32.x86_64
If you install Qt5
(dnf install qt5-devel),
you will be able to do "make xconfig".
so I did dnf install qt5-devel
make xconfig runs now, but it gives:
UPD scripts/kconfig/qconf-cfg
HOSTCXX scripts/kconfig/qconf.o
scripts/kconfig/qconf.cc: In member function ‘void
ConfigInfoView::menuInfo()’:
scripts/kconfig/qconf.cc:1080:61: warning: ‘QString&
QString::sprintf(const char*, ...)’ is deprecated: Use asprintf(), arg()
or QTextStream instead [-Wdeprecated-declarations]
1080 | head += QString().sprintf("", sym->name);
| ^
In file included from /usr/include/qt5/QtGui/qkeysequence.h:44,
from /usr/include/qt5/QtWidgets/qaction.h:44,
from /usr/include/qt5/QtWidgets/QAction:1,
from scripts/kconfig/qconf.cc:7:
/usr/include/qt5/QtCore/qstring.h:382:14: note: declared here
382 | QString (const char *format, ...)
Q_ATTRIBUTE_FORMAT_PRINTF(2, 3);
| ^~~
scripts/kconfig/qconf.cc:1089:60: warning: ‘QString&
QString::sprintf(const char*, ...)’ is deprecated: Use asprintf(), arg()
or QTextStream instead [-Wdeprecated-declarations]
1089 | head += QString().sprintf("", sym->name);
|^
In file included from /usr/include/qt5/QtGui/qkeysequence.h:44,
from /usr/include/qt5/QtWidgets/qaction.h:44,
from /usr/include/qt5/QtWidgets/QAction:1,
from scripts/kconfig/qconf.cc:7:
/usr/include/qt5/QtCore/qstring.h:382:14: note: declared here
382 | QString (const char *format, ...)
Q_ATTRIBUTE_FORMAT_PRINTF(2, 3);
| ^~~
scripts/kconfig/qconf.cc:1117:90: warning: ‘QString&
QString::sprintf(const char*, ...)’ is deprecated: Use asprintf(), arg()
or QTextStream instead [-Wdeprecated-declarations]
1117 | debug += QString().sprintf("defined at %s:%d",
_menu->file->name, _menu->lineno);
|
^
In file included from /usr/include/qt5/QtGui/qkeysequence.h:44,
from /usr/include/qt5/QtWidgets/qaction.h:44,
from /usr/include/qt5/QtWidgets/QAction:1,
from scripts/kconfig/qconf.cc:7:
/usr/include/qt5/QtCore/qstring.h:382:14: note: declared here
382 | QString (const char *format, ...)
Q_ATTRIBUTE_FORMAT_PRINTF(2, 3);
| ^~~
scripts/kconfig/qconf.cc: In member function ‘QString
ConfigInfoView::debug_info(symbol*)’:
scripts/kconfig/qconf.cc:1140:68: warning: ‘QString&
QString::sprintf(const char*, ...)’ is deprecated: Use asprintf(), arg()
or QTextStream instead [-Wdeprecated-declarations]
1140 |debug += QString().sprintf("prompt: ",
sym->name);
|
^
In file included from /usr/include/qt5/QtGui/qkeysequence.h:44,
from /usr/include/qt5/QtWidgets/qaction.h:44,
from /usr/include/qt5/QtWidgets/QAction:1,
from scripts/kconfig/qconf.cc:7:
/usr/include/qt5/QtCore/qstring.h:382:14: note: declared here
382 | QString (const char *format, ...)
Q_ATTRIBUTE_FORMAT_PRINTF(2, 3);
| ^~~
scripts/kconfig/qconf.cc: In static member function ‘static void
ConfigInfoView::expr_print_help(void*, symbol*, const char*)’:
scripts/kconfig/qconf.cc:1215:59: warning: ‘QString&
QString::sprintf(const char*, ...)’ is deprecated: Use asprintf(), arg()
or QTextStream instead [-Wdeprecated-declarations]
1215 | *text += QString().sprintf("", sym->name);
| ^
In file included from /usr/include/qt5/QtGui/qkeysequence.h:44,
from /usr/include/qt5/QtWidgets/qaction.h:44,
from /usr/include/qt5/QtWidgets/QActio
BUG with 5.8.x and make xconfig
Hallo configuring kernel 5.8.x on Fedora 32 via "make xconfig" gives me this: HOSTCXX scripts/kconfig/qconf.o scripts/kconfig/qconf.cc: In member function ‘void ConfigInfoView::clicked(const QUrl&)’: scripts/kconfig/qconf.cc:1231:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1231 | qInfo() << "Clicked link is empty"; | ^ | setInfo scripts/kconfig/qconf.cc:1244:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1244 | qInfo() << "Clicked symbol is invalid:" << data; | ^ | setInfo make[1]: *** [scripts/Makefile.host:137: scripts/kconfig/qconf.o] Error 1 make: *** [Makefile:606: xconfig] Error 2 I have never seen this with kernel 5.7.x. I haven't found a solution to the above, yet. - apart from the workaround: "make menuconfig", etc.- pointers/hints/ideas ? -- regards Ronald
Re: [PATCH 5.6 000/126] 5.6.15-rc1 review
hallo 5.6.15-rc1 compiles, boots and works without errors here on an Intel-i7-6700-box Thanks ! -- regards Ronald
[PATCH] mtd: parser: cmdline: Support MTD names containing one or more colons
From: Boris Brezillon
Looks like some drivers define MTD names with a colon in it, thus
making mtdpart= parsing impossible. Let's fix the parser to gracefully
handle that case: the last ':' in a partition definition sequence is
considered instead of the first one.
Signed-off-by: Boris Brezillon
Signed-off-by: Ron Minnich
Tested-by: Ron Minnich
---
drivers/mtd/parsers/cmdlinepart.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/parsers/cmdlinepart.c
b/drivers/mtd/parsers/cmdlinepart.c
index c86f2db8c882..0625b25620ca 100644
--- a/drivers/mtd/parsers/cmdlinepart.c
+++ b/drivers/mtd/parsers/cmdlinepart.c
@@ -218,12 +218,29 @@ static int mtdpart_setup_real(char *s)
struct cmdline_mtd_partition *this_mtd;
struct mtd_partition *parts;
int mtd_id_len, num_parts;
- char *p, *mtd_id;
+ char *p, *mtd_id, *semicol;
+
+ /*
+* Replace the first ';' by a NULL char so strrchr can work
+* properly.
+*/
+ semicol = strchr(s, ';');
+ if (semicol)
+ *semicol = '\0';
mtd_id = s;
- /* fetch */
- p = strchr(s, ':');
+ /*
+* fetch . We use strrchr to ignore all ':' that could
+* be present in the MTD name, only the last one is interpreted
+* as an / separator.
+*/
+ p = strrchr(s, ':');
+
+ /* Restore the ';' now. */
+ if (semicol)
+ *semicol = ';';
+
if (!p) {
pr_err("no mtd-id\n");
return -EINVAL;
[PATCH v2] Input: applespi: fix warnings detected by sparse
Reported-by: kbuild test robot
Signed-off-by: Ronald Tschalär
---
Changes in v2:
replaced min_t/max_t with plain min/max since both arguments are now
int's and don't need further casting
drivers/input/keyboard/applespi.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index d5defdefbc34..cd140a92e731 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -998,10 +998,14 @@ static inline int le16_to_int(__le16 x)
static void applespi_debug_update_dimensions(struct applespi_data *applespi,
const struct tp_finger *f)
{
- applespi->tp_dim_min_x = min_t(int, applespi->tp_dim_min_x, f->abs_x);
- applespi->tp_dim_max_x = max_t(int, applespi->tp_dim_max_x, f->abs_x);
- applespi->tp_dim_min_y = min_t(int, applespi->tp_dim_min_y, f->abs_y);
- applespi->tp_dim_max_y = max_t(int, applespi->tp_dim_max_y, f->abs_y);
+ applespi->tp_dim_min_x = min(applespi->tp_dim_min_x,
+le16_to_int(f->abs_x));
+ applespi->tp_dim_max_x = max(applespi->tp_dim_max_x,
+le16_to_int(f->abs_x));
+ applespi->tp_dim_min_y = min(applespi->tp_dim_min_y,
+le16_to_int(f->abs_y));
+ applespi->tp_dim_max_y = max(applespi->tp_dim_max_y,
+le16_to_int(f->abs_y));
}
static int applespi_tp_dim_open(struct inode *inode, struct file *file)
@@ -1653,8 +1657,8 @@ static void applespi_save_bl_level(struct applespi_data
*applespi,
efi_attr = EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS;
- sts = efivar_entry_set_safe(EFI_BL_LEVEL_NAME, efi_guid, efi_attr, true,
- efi_data_len, _data);
+ sts = efivar_entry_set_safe((efi_char16_t *)EFI_BL_LEVEL_NAME, efi_guid,
+ efi_attr, true, efi_data_len, _data);
if (sts)
dev_warn(>spi->dev,
"Error saving backlight level to EFI vars: %d\n", sts);
@@ -2027,7 +2031,7 @@ static const struct acpi_device_id applespi_acpi_match[]
= {
};
MODULE_DEVICE_TABLE(acpi, applespi_acpi_match);
-const struct dev_pm_ops applespi_pm_ops = {
+static const struct dev_pm_ops applespi_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(applespi_suspend, applespi_resume)
.poweroff_late = applespi_poweroff_late,
};
--
2.21.0
[PATCH 2/2] Input: applespi: fix warnings detected by sparse
Reported-by: kbuild test robot
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/applespi.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index d5defdefbc34..00cd8dccd4f5 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -998,10 +998,14 @@ static inline int le16_to_int(__le16 x)
static void applespi_debug_update_dimensions(struct applespi_data *applespi,
const struct tp_finger *f)
{
- applespi->tp_dim_min_x = min_t(int, applespi->tp_dim_min_x, f->abs_x);
- applespi->tp_dim_max_x = max_t(int, applespi->tp_dim_max_x, f->abs_x);
- applespi->tp_dim_min_y = min_t(int, applespi->tp_dim_min_y, f->abs_y);
- applespi->tp_dim_max_y = max_t(int, applespi->tp_dim_max_y, f->abs_y);
+ applespi->tp_dim_min_x = min_t(int, applespi->tp_dim_min_x,
+ le16_to_int(f->abs_x));
+ applespi->tp_dim_max_x = max_t(int, applespi->tp_dim_max_x,
+ le16_to_int(f->abs_x));
+ applespi->tp_dim_min_y = min_t(int, applespi->tp_dim_min_y,
+ le16_to_int(f->abs_y));
+ applespi->tp_dim_max_y = max_t(int, applespi->tp_dim_max_y,
+ le16_to_int(f->abs_y));
}
static int applespi_tp_dim_open(struct inode *inode, struct file *file)
@@ -1653,8 +1657,8 @@ static void applespi_save_bl_level(struct applespi_data
*applespi,
efi_attr = EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS;
- sts = efivar_entry_set_safe(EFI_BL_LEVEL_NAME, efi_guid, efi_attr, true,
- efi_data_len, _data);
+ sts = efivar_entry_set_safe((efi_char16_t *)EFI_BL_LEVEL_NAME, efi_guid,
+ efi_attr, true, efi_data_len, _data);
if (sts)
dev_warn(>spi->dev,
"Error saving backlight level to EFI vars: %d\n", sts);
@@ -2027,7 +2031,7 @@ static const struct acpi_device_id applespi_acpi_match[]
= {
};
MODULE_DEVICE_TABLE(acpi, applespi_acpi_match);
-const struct dev_pm_ops applespi_pm_ops = {
+static const struct dev_pm_ops applespi_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(applespi_suspend, applespi_resume)
.poweroff_late = applespi_poweroff_late,
};
--
2.21.0
[PATCH v2] Input: applespi - register touchpad device synchronously in probe
This allows errors during registration to properly fail the probe
function.
Doing this requires waiting for a response from the device inside the
probe function. While this generally takes about 15ms, in case of errors
it could be arbitrarily long, and hence a 3 second timeout is used.
This also adds 3 second timeouts to the drain functions to avoid the
potential for suspend or remove hanging forever.
Signed-off-by: Ronald Tschalär
---
Changes in v2:
merged the two wait-queue's into one
drivers/input/keyboard/applespi.c | 132 +++---
1 file changed, 103 insertions(+), 29 deletions(-)
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
index 548737e7aeda..d5defdefbc34 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -48,12 +48,12 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
@@ -405,13 +405,19 @@ struct applespi_data {
struct led_classdev backlight_info;
+ wait_queue_head_t wait_queue;
+
boolsuspended;
booldrain;
- wait_queue_head_t drain_complete;
boolread_active;
boolwrite_active;
- struct work_struct work;
+ struct applespi_complete_info {
+ void(*complete)(void *context);
+ struct applespi_data*applespi;
+ } spi_complete[2];
+ boolcancel_spi;
+
struct touchpad_info_protocol rcvd_tp_info;
struct dentry *debugfs_root;
@@ -593,13 +599,61 @@ static void applespi_setup_write_txfrs(struct
applespi_data *applespi)
spi_message_add_tail(st_t, msg);
}
+static bool applespi_async_outstanding(struct applespi_data *applespi)
+{
+ return applespi->spi_complete[0].complete ||
+ applespi->spi_complete[1].complete;
+}
+
+static void applespi_async_complete(void *context)
+{
+ struct applespi_complete_info *info = context;
+ struct applespi_data *applespi = info->applespi;
+ unsigned long flags;
+
+ info->complete(applespi);
+
+ spin_lock_irqsave(>cmd_msg_lock, flags);
+
+ info->complete = NULL;
+
+ if (applespi->cancel_spi && !applespi_async_outstanding(applespi))
+ wake_up_all(>wait_queue);
+
+ spin_unlock_irqrestore(>cmd_msg_lock, flags);
+}
+
static int applespi_async(struct applespi_data *applespi,
struct spi_message *message, void (*complete)(void *))
{
- message->complete = complete;
- message->context = applespi;
+ struct applespi_complete_info *info;
+ int sts;
+
+ if (applespi->cancel_spi) {
+ if (!applespi_async_outstanding(applespi))
+ wake_up_all(>wait_queue);
+ return -ESHUTDOWN;
+ }
+
+ /*
+* There can only be at most 2 spi requests in flight, one for "reads"
+* and one for "writes".
+*/
+ if (!applespi->spi_complete[0].complete)
+ info = >spi_complete[0];
+ else
+ info = >spi_complete[1];
+ info->complete = complete;
+ info->applespi = applespi;
+
+ message->complete = applespi_async_complete;
+ message->context = info;
+
+ sts = spi_async(applespi->spi, message);
+ if (sts)
+ info->complete = NULL;
- return spi_async(applespi->spi, message);
+ return sts;
}
static inline bool applespi_check_write_status(struct applespi_data *applespi,
@@ -663,7 +717,7 @@ static int applespi_setup_spi(struct applespi_data
*applespi)
return sts;
spin_lock_init(>cmd_msg_lock);
- init_waitqueue_head(>drain_complete);
+ init_waitqueue_head(>wait_queue);
return 0;
}
@@ -713,7 +767,7 @@ static void applespi_msg_complete(struct applespi_data
*applespi,
applespi->write_active = false;
if (applespi->drain && !applespi->write_active)
- wake_up_all(>drain_complete);
+ wake_up_all(>wait_queue);
if (is_write_msg) {
applespi->cmd_msg_queued = false;
@@ -1011,7 +1065,7 @@ static void report_tp_state(struct applespi_data
*applespi,
const struct applespi_tp_info *tp_info = >tp_info;
int i, n;
- /* touchpad_input_dev is set async in worker */
+ /* touchpad_input_dev is set async in probe */
input = smp_load_acquire(>touchpad_input_dev);
if (!input)
return; /* touchpad isn't in
[PATCH v2 1/3] HID: apple-ibridge: Add Apple iBridge HID driver.
The iBridge device provides access to several devices, including: - the Touch Bar - the iSight webcam - the light sensor - the fingerprint sensor This driver provides the core support for managing the iBridge device and the access to the underlying devices. In particular, since the functionality for the touch bar and light sensor is exposed via USB HID interfaces, and the same HID device is used for multiple functions, this driver creates virtual HID devices, one per real HID device and sub-driver pair (for a total of 4 virtual HID devices). The sub-drivers then bind to these virtual HID devices. This way the Touch Bar and ALS drivers can be kept in their own modules, while at the same time making them look very much like as if they were connected to the real HID devices; e.g. in particular the Touch Bar driver is aware of the fact that it is dealing with two HID devices that need to managed differently. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 14 + drivers/hid/Makefile | 1 + drivers/hid/apple-ibridge.c | 585 ++ drivers/hid/hid-ids.h | 1 + include/linux/apple-ibridge.h | 23 ++ 5 files changed, 624 insertions(+) create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 include/linux/apple-ibridge.h diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 4ca0cdfa6b33..545d3691fc1c 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -135,6 +135,20 @@ config HID_APPLE Say Y here if you want support for keyboards of Apple iBooks, PowerBooks, MacBooks, MacBook Pros and Apple Aluminum. +config HID_APPLE_IBRIDGE + tristate "Apple iBridge" + depends on ACPI + depends on USB_HID + depends on X86 || COMPILE_TEST + help + This module provides the core support for the Apple T1 chip found + on recent MacBookPro's, also known as the iBridge. The drivers for + the Touch Bar (apple-ib-tb) and light sensor (apple-ib-als) need to + be enabled separately. + + To compile this driver as a module, choose M here: the + module will be called apple-ibridge. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 170163b41303..a4da5663a541 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o obj-$(CONFIG_HID_ALPS) += hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o +obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_ASUS) += hid-asus.o obj-$(CONFIG_HID_AUREAL) += hid-aureal.o diff --git a/drivers/hid/apple-ibridge.c b/drivers/hid/apple-ibridge.c new file mode 100644 index ..565f080a38d6 --- /dev/null +++ b/drivers/hid/apple-ibridge.c @@ -0,0 +1,585 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple iBridge Driver + * + * Copyright (c) 2018 Ronald Tschalär + */ + +/** + * DOC: Overview + * + * MacBookPro models with a Touch Bar (13,[23] and 14,[23]) have an Apple + * iBridge chip (also known as T1 chip) which exposes the touch bar, + * built-in webcam (iSight), ambient light sensor, and Secure Enclave + * Processor (SEP) for TouchID. It shows up in the system as a USB device + * with 3 configurations: 'Default iBridge Interfaces', 'Default iBridge + * Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'. While + * the second one is used by MacOS to provide the fancy touch bar + * functionality with custom buttons etc, this driver just uses the first. + * + * In the first (default after boot) configuration, 4 usb interfaces are + * exposed: 2 related to the webcam, and 2 USB HID interfaces representing + * the touch bar and the ambient light sensor. The webcam interfaces are + * already handled by the uvcvideo driver; furthermore, the handling of the + * input reports when "keys" on the touch bar are pressed is already handled + * properly by the generic USB HID core. This leaves the management of the + * touch bar modes (e.g. switching between function and special keys when the + * FN key is pressed), the touch bar display (dimming and turning off), the + * key-remapping when the FN key is pressed, and handling of the light sensor. + * + * This driver is implemented as a HID driver that creates virtual HID devices + * for the ALS and touch bar functionality, and the ALS and touch bar drivers + * are HID drivers which in turn attach to these virtual HID devices. This + * driver then relays the calls on the real HID devices to the virtual ones, + * and visa versa. + * + * Lastly, this driver also takes care of the power-management for the + * iBridge when suspending and resuming. + */ + +#include +#include +#include +#include +
[PATCH v2 3/3] iio: light: apple-ib-als: Add driver for ALS on iBridge chip.
On 2016/2017 MacBook Pro's with a Touch Bar the ALS is attached to,
and exposed via the iBridge device. This provides the driver for that
sensor.
Signed-off-by: Ronald Tschalär
---
drivers/iio/light/Kconfig| 12 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/apple-ib-als.c | 607 +++
3 files changed, 620 insertions(+)
create mode 100644 drivers/iio/light/apple-ib-als.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 5190eacfeb0a..b477aa5d2024 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -64,6 +64,18 @@ config APDS9960
To compile this driver as a module, choose M here: the
module will be called apds9960
+config APPLE_IBRIDGE_ALS
+ tristate "Apple iBridge ambient light sensor"
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ depends on HID_APPLE_IBRIDGE
+ help
+ Say Y here to build the driver for the Apple iBridge ALS
+ sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called apple-ib-als.
+
config BH1750
tristate "ROHM BH1750 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index e40794fbb435..cd6cd5ba6da5 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_AL3320A) += al3320a.o
obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_APDS9960) += apds9960.o
+obj-$(CONFIG_APPLE_IBRIDGE_ALS)+= apple-ib-als.o
obj-$(CONFIG_BH1750) += bh1750.o
obj-$(CONFIG_BH1780) += bh1780.o
obj-$(CONFIG_CM32181) += cm32181.o
diff --git a/drivers/iio/light/apple-ib-als.c b/drivers/iio/light/apple-ib-als.c
new file mode 100644
index ..b84be0076e0f
--- /dev/null
+++ b/drivers/iio/light/apple-ib-als.c
@@ -0,0 +1,607 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Apple Ambient Light Sensor Driver
+ *
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * MacBookPro models with an iBridge chip (13,[23] and 14,[23]) have an
+ * ambient light sensor that is exposed via one of the USB interfaces on
+ * the iBridge as a standard HID light sensor. However, we cannot use the
+ * existing hid-sensor-als driver, for two reasons:
+ *
+ * 1. The hid-sensor-als driver is part of the hid-sensor-hub which in turn
+ *is a hid driver, but you can't have more than one hid driver per hid
+ *device, which is a problem because the touch bar also needs to
+ *register as a driver for this hid device.
+ *
+ * 2. While the hid-sensors-als driver stores sensor readings received via
+ *interrupt in an iio buffer, reads on the sysfs
+ *.../iio:deviceX/in_illuminance_YYY attribute result in a get of the
+ *feature report; however, in the case of this sensor here the
+ *illuminance field of that report is always 0. Instead, the input
+ *report needs to be requested.
+ */
+
+#define dev_fmt(fmt) "als: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define APPLEALS_DYN_SENS 0 /* our dynamic sensitivity */
+#define APPLEALS_DEF_CHANGE_SENS APPLEALS_DYN_SENS
+
+struct appleals_device {
+ struct hid_device *hid_dev;
+ struct hid_report *cfg_report;
+ struct hid_field*illum_field;
+ struct iio_dev *iio_dev;
+ int cur_sensitivity;
+ int cur_hysteresis;
+ boolevents_enabled;
+};
+
+static struct hid_driver appleals_hid_driver;
+
+/*
+ * This is a primitive way to get a relative sensitivity, one where we get
+ * notified when the value changes by a certain percentage rather than some
+ * absolute value. MacOS somehow manages to configure the sensor to work this
+ * way (with a 15% relative sensitivity), but I haven't been able to figure
+ * out how so far. So until we do, this provides a less-than-perfect
+ * simulation.
+ *
+ * When the brightness value is within one of the ranges, the sensitivity is
+ * set to that range's sensitivity. But in order to reduce flapping when the
+ * brightness is right on the border between two ranges, the ranges overlap
+ * somewhat (by at least one sensitivity), and sensitivity is only changed if
+ * the value leaves the current sensitivity's range.
+ *
+ * The values chosen for the map are somewhat arbitrary: a compromise of not
+ * too many ranges (and hence changing the sensitivity) but not too small or
+ * large of a percentage of the min and max values in the range (currently
+ * from 7.5% to 30%, i.e. within a factor of 2 of 15%), as well as just plain
+ * "this feels reasonable to me".
+ */
+struct appleals_sensitivity_map {
+ int
[PATCH v2 2/3] HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's.
This driver enables basic touch bar functionality: enabling it, switching between modes on FN key press, and dimming and turning the display off/on when idle/active. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 10 + drivers/hid/Makefile |1 + drivers/hid/apple-ib-tb.c | 1389 + 3 files changed, 1400 insertions(+) create mode 100644 drivers/hid/apple-ib-tb.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 545d3691fc1c..7621c2500d71 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -149,6 +149,16 @@ config HID_APPLE_IBRIDGE To compile this driver as a module, choose M here: the module will be called apple-ibridge. +config HID_APPLE_IBRIDGE_TB + tristate "Apple iBridge Touch Bar" + depends on HID_APPLE_IBRIDGE + ---help--- + Say Y here if you want support for the Touch Bar on recent + MacBook Pros. + + To compile this driver as a module, choose M here: the + module will be called apple-ib-tb. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index a4da5663a541..0c46e5f70db1 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -27,6 +27,7 @@ obj-$(CONFIG_HID_ALPS)+= hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o obj-$(CONFIG_HID_APPLE_IBRIDGE)+= apple-ibridge.o +obj-$(CONFIG_HID_APPLE_IBRIDGE_TB) += apple-ib-tb.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_ASUS) += hid-asus.o obj-$(CONFIG_HID_AUREAL) += hid-aureal.o diff --git a/drivers/hid/apple-ib-tb.c b/drivers/hid/apple-ib-tb.c new file mode 100644 index ..6daee80060ce --- /dev/null +++ b/drivers/hid/apple-ib-tb.c @@ -0,0 +1,1389 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple Touch Bar Driver + * + * Copyright (c) 2017-2018 Ronald Tschalär + */ + +/* + * Recent MacBookPro models (13,[23] and 14,[23]) have a touch bar, which + * is exposed via several USB interfaces. MacOS supports a fancy mode + * where arbitrary buttons can be defined; this driver currently only + * supports the simple mode that consists of 3 predefined layouts + * (escape-only, esc + special keys, and esc + function keys). + * + * The first USB HID interface supports two reports, an input report that + * is used to report the key presses, and an output report which can be + * used to set the touch bar "mode": touch bar off (in which case no touches + * are reported at all), escape key only, escape + 12 function keys, and + * escape + several special keys (including brightness, audio volume, + * etc). The second interface supports several, complex reports, most of + * which are unknown at this time, but one of which has been determined to + * allow for controlling of the touch bar's brightness: off (though touches + * are still reported), dimmed, and full brightness. This driver makes + * use of these two reports. + */ + +#define dev_fmt(fmt) "tb: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HID_UP_APPLE 0xff12 +#define HID_USAGE_MODE (HID_UP_CUSTOM | 0x0004) +#define HID_USAGE_APPLE_APP(HID_UP_APPLE | 0x0001) +#define HID_USAGE_DISP (HID_UP_APPLE | 0x0021) +#define HID_USAGE_DISP_AUX1(HID_UP_APPLE | 0x0020) + +#define APPLETB_MAX_TB_KEYS13 /* ESC, F1-F12 */ + +#define APPLETB_CMD_MODE_ESC 0 +#define APPLETB_CMD_MODE_FN1 +#define APPLETB_CMD_MODE_SPCL 2 +#define APPLETB_CMD_MODE_OFF 3 +#define APPLETB_CMD_MODE_UPD 254 +#define APPLETB_CMD_MODE_NONE 255 + +#define APPLETB_CMD_DISP_ON1 +#define APPLETB_CMD_DISP_DIM 2 +#define APPLETB_CMD_DISP_OFF 4 +#define APPLETB_CMD_DISP_UPD 254 +#define APPLETB_CMD_DISP_NONE 255 + +#define APPLETB_FN_MODE_FKEYS 0 +#define APPLETB_FN_MODE_NORM 1 +#define APPLETB_FN_MODE_INV2 +#define APPLETB_FN_MODE_SPCL 3 +#define APPLETB_FN_MODE_MAXAPPLETB_FN_MODE_SPCL + +#define APPLETB_DEVID_KEYBOARD 1 +#define APPLETB_DEVID_TOUCHPAD 2 + +#define APPLETB_MAX_DIM_TIME 30 + +static int appletb_tb_def_idle_timeout = 5 * 60; +module_param_named(idle_timeout, appletb_tb_def_idle_timeout, int, 0444); +MODULE_PARM_DESC(idle_timeout, "Default touch bar idle timeout:\n" + ">0 - turn touch bar display off after no keyboard, trackpad, or touch bar input has been received for this many seconds;\n" + " the display will be turned back on as soon as new input is received\n" + " 0 - turn touch bar display off (input does not turn it on again)\n" +
[PATCH v2 0/3] Apple iBridge support
2016 and 2017 MacBook Pro's have a T1 chip that drives the Touch Bar, ambient light sensor, webcam, and fingerprint sensor; this shows up as an iBridge USB device in the system. These patches provide initial support for the Touch Bar and ALS - the webcam is already handled by existing drivers, and no information is currently known on how to access the fingerprint sensor (other than it's apparently via one of the extra interfaces available in the OS X USB configuration). One thing of note here is that both the ALS and (some of) the Touch Bar functionality are exposed via the same USB interface (and hence same hid_device), so both drivers need to share this device. This is solved by having the iBridge driver create multiple virtual HID devices for each real HID device to which the Touch Bar and ALS drivers attach, and then forwarding the calls between the real and virtual HID devices, so we end up with a structure like this: iBridge (HID) driverSub drivers -- vhdev0 -- (unbound) / hdev1 --- vhdev1 --- tb-drv / -- vhdev2 -- / hdev2 --- vhdev3 --- als-drv Changes in v2: - Changed iBridge driver from an MFD driver to a HID driver. Instead of creating virtual HID drivers and (de)multiplexing their calls, this now create virtual HID devices and (de)multiplexing the operations on them. This is from the feedback by Benjamin Tissoires. - Applied all feedback on ALS driver from Jonathan Cameron - Applied all feedback on Touch Bar driver from Jonathan Cameron and Peter Meerwald-Stadler - various smaller cleanups Ronald Tschalär (3): HID: apple-ibridge: Add Apple iBridge HID driver. HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's. iio: light: apple-ib-als: Add driver for ALS on iBridge chip. drivers/hid/Kconfig | 24 + drivers/hid/Makefile |2 + drivers/hid/apple-ib-tb.c| 1389 ++ drivers/hid/apple-ibridge.c | 588 + drivers/hid/hid-ids.h|1 + drivers/iio/light/Kconfig| 12 + drivers/iio/light/Makefile |1 + drivers/iio/light/apple-ib-als.c | 607 + include/linux/apple-ibridge.h| 23 + 9 files changed, 2647 insertions(+) create mode 100644 drivers/hid/apple-ib-tb.c create mode 100644 drivers/hid/apple-ibridge.c create mode 100644 drivers/iio/light/apple-ib-als.c create mode 100644 include/linux/apple-ibridge.h -- 2.21.0
[PATCH 1/3] mfd: apple-ibridge: Add Apple iBridge MFD driver.
The iBridge device provides access to several devices, including: - the Touch Bar - the iSight webcam - the light sensor - the fingerprint sensor This driver provides the core support for managing the iBridge device and the access to the underlying devices. In particular, since the functionality for the touch bar and light sensor is exposed via USB HID interfaces, and the same HID device is used for multiple functions, this driver provides a multiplexing layer that allows multiple HID drivers to be registered for a given HID device. This allows the touch bar and ALS driver to be separated out into their own modules. Signed-off-by: Ronald Tschalär --- drivers/mfd/Kconfig | 15 + drivers/mfd/Makefile | 1 + drivers/mfd/apple-ibridge.c | 883 ++ include/linux/mfd/apple-ibridge.h | 39 ++ 4 files changed, 938 insertions(+) create mode 100644 drivers/mfd/apple-ibridge.c create mode 100644 include/linux/mfd/apple-ibridge.h diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 76f9909cf396..d55fa77faacf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1916,5 +1916,20 @@ config RAVE_SP_CORE Select this to get support for the Supervisory Processor device found on several devices in RAVE line of hardware. +config MFD_APPLE_IBRIDGE + tristate "Apple iBridge chip" + depends on ACPI + depends on USB_HID + depends on X86 || COMPILE_TEST + select MFD_CORE + help + This MFD provides the core support for the Apple iBridge chip + found on recent MacBookPro's. The drivers for the Touch Bar + (apple-ib-tb) and light sensor (apple-ib-als) need to be + enabled separately. + + To compile this driver as a module, choose M here: the + module will be called apple-ibridge. + endmenu endif diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 12980a4ad460..c364e0e9d313 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -241,4 +241,5 @@ obj-$(CONFIG_MFD_MXS_LRADC) += mxs-lradc.o obj-$(CONFIG_MFD_SC27XX_PMIC) += sprd-sc27xx-spi.o obj-$(CONFIG_RAVE_SP_CORE) += rave-sp.o obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o +obj-$(CONFIG_MFD_APPLE_IBRIDGE)+= apple-ibridge.o diff --git a/drivers/mfd/apple-ibridge.c b/drivers/mfd/apple-ibridge.c new file mode 100644 index ..56d325396961 --- /dev/null +++ b/drivers/mfd/apple-ibridge.c @@ -0,0 +1,883 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple iBridge Driver + * + * Copyright (c) 2018 Ronald Tschalär + */ + +/** + * MacBookPro models with a Touch Bar (13,[23] and 14,[23]) have an Apple + * iBridge chip (also known as T1 chip) which exposes the touch bar, + * built-in webcam (iSight), ambient light sensor, and Secure Enclave + * Processor (SEP) for TouchID. It shows up in the system as a USB device + * with 3 configurations: 'Default iBridge Interfaces', 'Default iBridge + * Interfaces(OS X)', and 'Default iBridge Interfaces(Recovery)'. While + * the second one is used by MacOS to provide the fancy touch bar + * functionality with custom buttons etc, this driver just uses the first. + * + * In the first (default after boot) configuration, 4 usb interfaces are + * exposed: 2 related to the webcam, and 2 USB HID interfaces representing + * the touch bar and the ambient light sensor (and possibly the SEP, + * though at this point in time nothing is known about that). The webcam + * interfaces are already handled by the uvcvideo driver; furthermore, the + * handling of the input reports when "keys" on the touch bar are pressed + * is already handled properly by the generic USB HID core. This leaves + * the management of the touch bar modes (e.g. switching between function + * and special keys when the FN key is pressed), the touch bar display + * (dimming and turning off), the key-remapping when the FN key is + * pressed, and handling of the light sensor. + * + * This driver is implemented as an MFD driver, with the touch bar and ALS + * functions implemented by appropriate subdrivers (mfd cells). Because + * both those are basically hid drivers, but the current kernel driver + * structure does not allow more than one driver per device, this driver + * implements a demuxer for hid drivers: it registers itself as a hid + * driver with the core, and in turn it lets the subdrivers register + * themselves as hid drivers with this driver; the callbacks from the core + * are then forwarded to the subdrivers. + * + * Lastly, this driver also takes care of the power-management for the + * iBridge when suspending and resuming. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../hid/usbhid/usbhid.h" + +#define USB_ID_VENDOR_APPLE0x05ac +#define USB_ID_PRODUCT_IBRIDGE 0x8600 + +#define APPLETB_BASIC_CONFIG 1 +
[PATCH 3/3] iio: light: apple-ib-als: Add driver for ALS on iBridge chip.
On 2016/2017 MacBook Pro's with a Touch Bar the ALS is attached to,
and exposed via the iBridge device. This provides the driver for that
sensor.
Signed-off-by: Ronald Tschalär
---
drivers/iio/light/Kconfig| 12 +
drivers/iio/light/Makefile | 1 +
drivers/iio/light/apple-ib-als.c | 694 +++
3 files changed, 707 insertions(+)
create mode 100644 drivers/iio/light/apple-ib-als.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 36f458433480..49159fab1c0e 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -64,6 +64,18 @@ config APDS9960
To compile this driver as a module, choose M here: the
module will be called apds9960
+config APPLE_IBRIDGE_ALS
+ tristate "Apple iBridge ambient light sensor"
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ depends on MFD_APPLE_IBRIDGE
+ help
+ Say Y here to build the driver for the Apple iBridge ALS
+ sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called apple-ib-als.
+
config BH1750
tristate "ROHM BH1750 ambient light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 286bf3975372..144d918917f7 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o
obj-$(CONFIG_AL3320A) += al3320a.o
obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_APDS9960) += apds9960.o
+obj-$(CONFIG_APPLE_IBRIDGE_ALS)+= apple-ib-als.o
obj-$(CONFIG_BH1750) += bh1750.o
obj-$(CONFIG_BH1780) += bh1780.o
obj-$(CONFIG_CM32181) += cm32181.o
diff --git a/drivers/iio/light/apple-ib-als.c b/drivers/iio/light/apple-ib-als.c
new file mode 100644
index ..1718fcbe304f
--- /dev/null
+++ b/drivers/iio/light/apple-ib-als.c
@@ -0,0 +1,694 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Apple Ambient Light Sensor Driver
+ *
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * MacBookPro models with an iBridge chip (13,[23] and 14,[23]) have an
+ * ambient light sensor that is exposed via one of the USB interfaces on
+ * the iBridge as a standard HID light sensor. However, we cannot use the
+ * existing hid-sensor-als driver, for two reasons:
+ *
+ * 1. The hid-sensor-als driver is part of the hid-sensor-hub which in turn
+ *is a hid driver, but you can't have more than one hid driver per hid
+ *device, which is a problem because the touch bar also needs to
+ *register as a driver for this hid device.
+ *
+ * 2. While the hid-sensors-als driver stores sensor readings received via
+ *interrupt in an iio buffer, reads on the sysfs
+ *.../iio:deviceX/in_illuminance_YYY attribute result in a get of the
+ *feature report; however, in the case of this sensor here the
+ *illuminance field of that report is always 0. Instead, the input
+ *report needs to be requested.
+ */
+
+#define dev_fmt(fmt) "als: " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define APPLEALS_DYN_SENS 0 /* our dynamic sensitivity */
+#define APPLEALS_DEF_CHANGE_SENS APPLEALS_DYN_SENS
+
+struct appleals_device {
+ struct appleib_device *ib_dev;
+ struct device *log_dev;
+ struct hid_device *hid_dev;
+ struct hid_report *cfg_report;
+ struct hid_field*illum_field;
+ struct iio_dev *iio_dev;
+ struct iio_trigger *iio_trig;
+ int cur_sensitivity;
+ int cur_hysteresis;
+ boolevents_enabled;
+};
+
+static struct hid_driver appleals_hid_driver;
+
+/*
+ * This is a primitive way to get a relative sensitivity, one where we get
+ * notified when the value changes by a certain percentage rather than some
+ * absolute value. MacOS somehow manages to configure the sensor to work this
+ * way (with a 15% relative sensitivity), but I haven't been able to figure
+ * out how so far. So until we do, this provides a less-than-perfect
+ * simulation.
+ *
+ * When the brightness value is within one of the ranges, the sensitivity is
+ * set to that range's sensitivity. But in order to reduce flapping when the
+ * brightness is right on the border between two ranges, the ranges overlap
+ * somewhat (by at least one sensitivity), and sensitivity is only changed if
+ * the value leaves the current sensitivity's range.
+ *
+ * The values chosen for the map are somewhat arbitrary: a compromise of not
+ * too many ranges (and hence changing the sensitivity) but not too small or
+ * large of a percentage of the min and max values in the range (currently
+ * from 7.5% to 30%, i.e. within a factor of 2
[PATCH 0/3] Apple iBridge support
2016 and 2017 MacBook Pro's have a T1 chip that drives the Touch Bar, ambient light sensor, webcam, and fingerprint sensor; this shows up as an iBridge USB device in the system. These patches provide initial support for the Touch Bar and ALS - the webcam is already handled by existing drivers, and no information is currently known on how to access the fingerprint sensor (other than it's apparently via one of the extra interfaces available in the OS X USB configuration). One thing of note here is that both the ALS and (some of) the Touch Bar functionality are exposed via the same USB interface (and hence same hid_device), so both drivers need to share this device. This necessitated creating a demux hid driver in the mfd driver to which multiple hid devices can be attached, and implied not being able to make use of the existing hid-sensor-als driver. Ronald Tschalär (3): mfd: apple-ibridge: Add Apple iBridge MFD driver. HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's. iio: light: apple-ib-als: Add driver for ALS on iBridge chip. drivers/hid/Kconfig | 10 + drivers/hid/Makefile |1 + drivers/hid/apple-ib-tb.c | 1288 + drivers/iio/light/Kconfig | 12 + drivers/iio/light/Makefile|1 + drivers/iio/light/apple-ib-als.c | 694 drivers/mfd/Kconfig | 15 + drivers/mfd/Makefile |1 + drivers/mfd/apple-ibridge.c | 883 include/linux/mfd/apple-ibridge.h | 39 + 10 files changed, 2944 insertions(+) create mode 100644 drivers/hid/apple-ib-tb.c create mode 100644 drivers/iio/light/apple-ib-als.c create mode 100644 drivers/mfd/apple-ibridge.c create mode 100644 include/linux/mfd/apple-ibridge.h -- 2.20.1
[PATCH 2/3] HID: apple-ib-tb: Add driver for the Touch Bar on MacBook Pro's.
This driver enables basic touch bar functionality: enabling it, switching between modes on FN key press, and dimming and turning the display off/on when idle/active. Signed-off-by: Ronald Tschalär --- drivers/hid/Kconfig | 10 + drivers/hid/Makefile |1 + drivers/hid/apple-ib-tb.c | 1288 + 3 files changed, 1299 insertions(+) create mode 100644 drivers/hid/apple-ib-tb.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 41e9935fc584..f0a65bb4be6e 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -135,6 +135,16 @@ config HID_APPLE Say Y here if you want support for keyboards of Apple iBooks, PowerBooks, MacBooks, MacBook Pros and Apple Aluminum. +config HID_APPLE_IBRIDGE_TB + tristate "Apple iBridge Touch Bar" + depends on MFD_APPLE_IBRIDGE + ---help--- + Say Y here if you want support for the Touch Bar on recent + MacBook Pros. + + To compile this driver as a module, choose M here: the + module will be called apple-ib-tb. + config HID_APPLEIR tristate "Apple infrared receiver" depends on (USB_HID) diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile index 896a51ce7ce0..dedd8049d3fb 100644 --- a/drivers/hid/Makefile +++ b/drivers/hid/Makefile @@ -26,6 +26,7 @@ obj-$(CONFIG_HID_ACCUTOUCH) += hid-accutouch.o obj-$(CONFIG_HID_ALPS) += hid-alps.o obj-$(CONFIG_HID_ACRUX)+= hid-axff.o obj-$(CONFIG_HID_APPLE)+= hid-apple.o +obj-$(CONFIG_HID_APPLE_IBRIDGE_TB) += apple-ib-tb.o obj-$(CONFIG_HID_APPLEIR) += hid-appleir.o obj-$(CONFIG_HID_ASUS) += hid-asus.o obj-$(CONFIG_HID_AUREAL) += hid-aureal.o diff --git a/drivers/hid/apple-ib-tb.c b/drivers/hid/apple-ib-tb.c new file mode 100644 index ..6b72ff56b17f --- /dev/null +++ b/drivers/hid/apple-ib-tb.c @@ -0,0 +1,1288 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Apple Touch Bar Driver + * + * Copyright (c) 2017-2018 Ronald Tschalär + */ + +/* + * Recent MacBookPro models (13,[23] and 14,[23]) have a touch bar, which + * is exposed via several USB interfaces. MacOS supports a fancy mode + * where arbitrary buttons can be defined; this driver currently only + * supports the simple mode that consists of 3 predefined layouts + * (escape-only, esc + special keys, and esc + function keys). + * + * The first USB HID interface supports two reports, an input report that + * is used to report the key presses, and an output report which can be + * used to set the touch bar "mode": touch bar off (in which case no touches + * are reported at all), escape key only, escape + 12 function keys, and + * escape + several special keys (including brightness, audio volume, + * etc). The second interface supports several, complex reports, most of + * which are unknown at this time, but one of which has been determined to + * allow for controlling of the touch bar's brightness: off (though touches + * are still reported), dimmed, and full brightness. This driver makes + * use of these two reports. + */ + +#define dev_fmt(fmt) "tb: " fmt + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define HID_UP_APPLE 0xff12 +#define HID_USAGE_MODE (HID_UP_CUSTOM | 0x0004) +#define HID_USAGE_APPLE_APP(HID_UP_APPLE | 0x0001) +#define HID_USAGE_DISP (HID_UP_APPLE | 0x0021) + +#define APPLETB_MAX_TB_KEYS13 /* ESC, F1-F12 */ + +#define APPLETB_CMD_MODE_ESC 0 +#define APPLETB_CMD_MODE_FN1 +#define APPLETB_CMD_MODE_SPCL 2 +#define APPLETB_CMD_MODE_OFF 3 +#define APPLETB_CMD_MODE_NONE 255 + +#define APPLETB_CMD_DISP_ON1 +#define APPLETB_CMD_DISP_DIM 2 +#define APPLETB_CMD_DISP_OFF 4 +#define APPLETB_CMD_DISP_NONE 255 + +#define APPLETB_FN_MODE_FKEYS 0 +#define APPLETB_FN_MODE_NORM 1 +#define APPLETB_FN_MODE_INV2 +#define APPLETB_FN_MODE_SPCL 3 +#define APPLETB_FN_MODE_MAXAPPLETB_FN_MODE_SPCL + +#define APPLETB_DEVID_KEYBOARD 1 +#define APPLETB_DEVID_TOUCHPAD 2 + +#define APPLETB_MAX_DIM_TIME 30 + +static int appletb_tb_def_idle_timeout = 5 * 60; +module_param_named(idle_timeout, appletb_tb_def_idle_timeout, int, 0444); +MODULE_PARM_DESC(idle_timeout, "Default touch bar idle timeout (in seconds); 0 disables touch bar, -1 disables timeout"); + +static int appletb_tb_def_dim_timeout = -2; +module_param_named(dim_timeout, appletb_tb_def_dim_timeout, int, 0444); +MODULE_PARM_DESC(dim_timeout, "Default touch bar dim timeout (in seconds); 0 means always dimmmed, -1 disables dimming, [-2] calculates timeout based on idle-timeout"); + +static int appletb_tb_def_fn_mode = APPLETB_FN_MODE_NORM; +module_param_named(fnmode, appletb_tb_def_fn_mode, int, 0444); +MODULE_PARM_DESC(fnmode, "Default Fn key mode: 0 = f-keys only, [
[PATCH v7 0/2] Add Apple SPI keyboard and trackpad driver
This changeset adds a driver for the SPI keyboard and trackpad on recent MacBook's and MacBook Pro's. The driver has seen a fair amount of use over the last 2 years (basically anybody running linux on these machines), with only relatively small changes in the last year or so. For those interested, the driver development has been hosted at https://github.com/cb22/macbook12-spi-driver/ (as well as my clone at https://github.com/roadrunner2/macbook12-spi-driver/). The first patch fixes a problem during config. While it affects the drm tree, Andrzej Hajda has given his ok for this patch to be taken via the input tree because the second patch here depends on it. The second patch contains the new applespi driver. Changes in v7: - Fixed unused variable warning introduced in previous patch series and accidently overlooked Ronald Tschalär (2): drm/bridge: sil_sii8620: make remote control optional. Input: add Apple SPI keyboard and trackpad driver. drivers/gpu/drm/bridge/Kconfig |3 +- drivers/gpu/drm/bridge/sil-sii8620.c| 10 +- drivers/input/keyboard/Kconfig | 15 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/applespi.c | 1975 +++ drivers/input/keyboard/applespi.h | 29 + drivers/input/keyboard/applespi_trace.h | 94 ++ 7 files changed, 2122 insertions(+), 5 deletions(-) create mode 100644 drivers/input/keyboard/applespi.c create mode 100644 drivers/input/keyboard/applespi.h create mode 100644 drivers/input/keyboard/applespi_trace.h -- 2.20.1
[PATCH v4 2/2] Input: add Apple SPI keyboard and trackpad driver.
The keyboard and trackpad on recent MacBook's (since 8,1) and
MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
of USB, as previously. The higher level protocol is not publicly
documented and hence has been reverse engineered. As a consequence there
are still a number of unknown fields and commands. However, the known
parts have been working well and received extensive testing and use.
In order for this driver to work, the proper SPI drivers need to be
loaded too; for MB8,1 these are spi_pxa2xx_platform and spi_pxa2xx_pci;
for all others they are spi_pxa2xx_platform and intel_lpss_pci. For this
reason enabling this driver in the config implies enabling the above
drivers.
CC: Federico Lorenzi
CC: Lukas Wunner
CC: Andy Shevchenko
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/Kconfig | 15 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/applespi.c | 1999 +++
drivers/input/keyboard/applespi.h | 29 +
drivers/input/keyboard/applespi_trace.h | 94 ++
5 files changed, 2138 insertions(+)
create mode 100644 drivers/input/keyboard/applespi.c
create mode 100644 drivers/input/keyboard/applespi.h
create mode 100644 drivers/input/keyboard/applespi_trace.h
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a878351f1643..d0a9e7fa2508 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -70,6 +70,21 @@ config KEYBOARD_AMIGA
config ATARI_KBD_CORE
bool
+config KEYBOARD_APPLESPI
+ tristate "Apple SPI keyboard and trackpad"
+ depends on ACPI && EFI
+ depends on SPI
+ depends on X86 || COMPILE_TEST
+ imply SPI_PXA2XX
+ imply SPI_PXA2XX_PCI
+ imply MFD_INTEL_LPSS_PCI
+ help
+ Say Y here if you are running Linux on any Apple MacBook8,1 or later,
+ or any MacBookPro13,* or MacBookPro14,*.
+
+ To compile this driver as a module, choose M here: the
+ module will be called applespi.
+
config KEYBOARD_ATARI
tristate "Atari keyboard"
depends on ATARI
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 182e92985dbf..9283fee2505a 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5520)+=
adp5520-keys.o
obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
+obj-$(CONFIG_KEYBOARD_APPLESPI)+= applespi.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
new file mode 100644
index ..f49bc6e544d7
--- /dev/null
+++ b/drivers/input/keyboard/applespi.c
@@ -0,0 +1,1999 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MacBook (Pro) SPI keyboard and touchpad driver
+ *
+ * Copyright (c) 2015-2018 Federico Lorenzi
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * The keyboard and touchpad controller on the MacBookAir6, MacBookPro12,
+ * MacBook8 and newer can be driven either by USB or SPI. However the USB
+ * pins are only connected on the MacBookAir6 and 7 and the MacBookPro12.
+ * All others need this driver. The interface is selected using ACPI methods:
+ *
+ * * UIEN ("USB Interface Enable"): If invoked with argument 1, disables SPI
+ * and enables USB. If invoked with argument 0, disables USB.
+ * * UIST ("USB Interface Status"): Returns 1 if USB is enabled, 0 otherwise.
+ * * SIEN ("SPI Interface Enable"): If invoked with argument 1, disables USB
+ * and enables SPI. If invoked with argument 0, disables SPI.
+ * * SIST ("SPI Interface Status"): Returns 1 if SPI is enabled, 0 otherwise.
+ * * ISOL: Resets the four GPIO pins used for SPI. Intended to be invoked with
+ * argument 1, then once more with argument 0.
+ *
+ * UIEN and UIST are only provided on models where the USB pins are connected.
+ *
+ * SPI-based Protocol
+ * --
+ *
+ * The device and driver exchange messages (struct message); each message is
+ * encapsulated in one or more packets (struct spi_packet). There are two types
+ * of exchanges: reads, and writes. A read is signaled by a GPE, upon which one
+ * message can be read from the device. A write exchange consists of writing a
+ * command message, immediately reading a short status packet, and then, upon
+ * receiving a GPE, reading the response message. Write exchanges cannot be
+ * interleaved, i.e. a new write exchange must not be started till the previous
+ * write exchange is
[PATCH v4 0/2] Add Apple SPI keyboard and trackpad driver
This changeset adds a driver for the SPI keyboard and trackpad on recent MacBook's and MacBook Pro's. The driver has seen a fair amount of use over the last 2 years (basically anybody running linux on these machines), with only relatively small changes in the last year or so. For those interested, the driver development has been hosted at https://github.com/cb22/macbook12-spi-driver/ (as well as my clone at https://github.com/roadrunner2/macbook12-spi-driver/). The first patch fixes a problem during config and is provided for anybody wanting to compile the driver while it's being reviewed here. The patch is the latest version that has been submitted for review at dri-devel; the intent is to get an Ack and permission to merge it through the input subsystem tree here as part of this patch series. The second patch contains the new applespi driver. Changes in v4: Applied all feedback from review by Andy Shevchenko and Greg Kroah-Hartman, including: - minor include path fix - moved debug logging to debugfs and tracepoints The full set of changes to applespi can be viewed at https://github.com/roadrunner2/macbook12-spi-driver/ as individual commits 3a6262e..daf60f8 in the upstreaming-review branch. Ronald Tschalär (2): drm/bridge: sil_sii8620: make remote control optional. Input: add Apple SPI keyboard and trackpad driver. drivers/gpu/drm/bridge/Kconfig |3 +- drivers/gpu/drm/bridge/sil-sii8620.c| 21 + drivers/input/keyboard/Kconfig | 15 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/applespi.c | 1999 +++ drivers/input/keyboard/applespi.h | 29 + drivers/input/keyboard/applespi_trace.h | 94 ++ 7 files changed, 2160 insertions(+), 2 deletions(-) create mode 100644 drivers/input/keyboard/applespi.c create mode 100644 drivers/input/keyboard/applespi.h create mode 100644 drivers/input/keyboard/applespi_trace.h -- 2.20.1
[PATCH v4 1/2] drm/bridge: sil_sii8620: make remote control optional.
commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
of RC_CORE) changed the driver to select both RC_CORE and INPUT.
However, this causes problems with other drivers, in particular an input
driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
commit):
drivers/clk/Kconfig:9:error: recursive dependency detected!
drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS
drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by
MFD_INTEL_LPSS_PCI
drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by
KEYBOARD_APPLESPI
drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on
INPUT
drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620
drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on
DRM_BRIDGE
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by
DRM_PL111
drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK
According to the docs and general consensus, select should only be used
for non user-visible symbols, but both RC_CORE and INPUT are
user-visible. Furthermore almost all other references to INPUT
throughout the kernel config are depends, not selects. For this reason
the first part of this change reverts commit d6abe6df706c.
In order to address the original reason for commit d6abe6df706c, namely
that not all boards use the remote controller functionality and hence
should not need have to deal with RC_CORE, the second part of this
change now makes the remote control support in the driver optional and
contingent on RC_CORE being defined. And with this the hard dependency
on INPUT also goes away as that is only needed if RC_CORE is defined
(which in turn already depends on INPUT).
CC: Inki Dae
CC: Andrzej Hajda
CC: Laurent Pinchart
CC: Dmitry Torokhov
Signed-off-by: Ronald Tschalär
---
drivers/gpu/drm/bridge/Kconfig | 3 +--
drivers/gpu/drm/bridge/sil-sii8620.c | 21 +
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..9cf07105b73a 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -85,8 +85,7 @@ config DRM_SIL_SII8620
depends on OF
select DRM_KMS_HELPER
imply EXTCON
- select INPUT
- select RC_CORE
+ imply RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index a6e8f4591e63..f8dfbf01caa8 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -66,7 +66,9 @@ enum sii8620_mt_state {
struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+#if IS_ENABLED(CONFIG_RC_CORE)
struct rc_dev *rc_dev;
+#endif
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -1757,6 +1759,7 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
{
bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
@@ -1775,6 +1778,12 @@ static bool sii8620_rcp_consume(struct sii8620 *ctx, u8
scancode)
return true;
}
+#else
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+ return false;
+}
+#endif
static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
{
@@ -2098,6 +2107,7 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
{
struct rc_dev *rc_dev;
@@ -2127,6 +2137,11 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
}
ctx->rc_dev = rc_dev;
}
+#else
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+}
+#endif
static void sii8620_cable_out(struct sii8620 *ctx)
{
@@ -2213,12 +2228,18 @@ static int sii8620_attach(struct drm_bridge *bridge)
return sii8620_clear_error(ctx);
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static void sii8620_detach(struct drm_bridge *bridge)
{
struct sii8620 *ctx = bridge_to_sii8620(bridge);
rc_unregister_device(ctx->rc_dev);
}
+#else
+static void sii8620_detach(struct drm_bridge *bridge)
+{
+}
+#endif
static int sii8620_is_packing_required(struct sii8620 *ctx,
const struct drm_display_mode *mode)
--
2.20.1
[PATCH v3 4/4] Input: add Apple SPI keyboard and trackpad driver.
The keyboard and trackpad on recent MacBook's (since 8,1) and
MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
of USB, as previously. The higher level protocol is not publicly
documented and hence has been reverse engineered. As a consequence there
are still a number of unknown fields and commands. However, the known
parts have been working well and received extensive testing and use.
In order for this driver to work, the proper SPI drivers need to be
loaded too; for MB8,1 these are spi_pxa2xx_platform and spi_pxa2xx_pci;
for all others they are spi_pxa2xx_platform and intel_lpss_pci. For this
reason enabling this driver in the config implies enabling the above
drivers.
CC: Federico Lorenzi
CC: Lukas Wunner
CC: Andy Shevchenko
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/Kconfig| 15 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/applespi.c | 1988 +
3 files changed, 2004 insertions(+)
create mode 100644 drivers/input/keyboard/applespi.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a878351f1643..d0a9e7fa2508 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -70,6 +70,21 @@ config KEYBOARD_AMIGA
config ATARI_KBD_CORE
bool
+config KEYBOARD_APPLESPI
+ tristate "Apple SPI keyboard and trackpad"
+ depends on ACPI && EFI
+ depends on SPI
+ depends on X86 || COMPILE_TEST
+ imply SPI_PXA2XX
+ imply SPI_PXA2XX_PCI
+ imply MFD_INTEL_LPSS_PCI
+ help
+ Say Y here if you are running Linux on any Apple MacBook8,1 or later,
+ or any MacBookPro13,* or MacBookPro14,*.
+
+ To compile this driver as a module, choose M here: the
+ module will be called applespi.
+
config KEYBOARD_ATARI
tristate "Atari keyboard"
depends on ATARI
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 182e92985dbf..9283fee2505a 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5520)+=
adp5520-keys.o
obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
+obj-$(CONFIG_KEYBOARD_APPLESPI)+= applespi.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
new file mode 100644
index ..39e38d98869e
--- /dev/null
+++ b/drivers/input/keyboard/applespi.c
@@ -0,0 +1,1988 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MacBook (Pro) SPI keyboard and touchpad driver
+ *
+ * Copyright (c) 2015-2018 Federico Lorenzi
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * The keyboard and touchpad controller on the MacBookAir6, MacBookPro12,
+ * MacBook8 and newer can be driven either by USB or SPI. However the USB
+ * pins are only connected on the MacBookAir6 and 7 and the MacBookPro12.
+ * All others need this driver. The interface is selected using ACPI methods:
+ *
+ * * UIEN ("USB Interface Enable"): If invoked with argument 1, disables SPI
+ * and enables USB. If invoked with argument 0, disables USB.
+ * * UIST ("USB Interface Status"): Returns 1 if USB is enabled, 0 otherwise.
+ * * SIEN ("SPI Interface Enable"): If invoked with argument 1, disables USB
+ * and enables SPI. If invoked with argument 0, disables SPI.
+ * * SIST ("SPI Interface Status"): Returns 1 if SPI is enabled, 0 otherwise.
+ * * ISOL: Resets the four GPIO pins used for SPI. Intended to be invoked with
+ * argument 1, then once more with argument 0.
+ *
+ * UIEN and UIST are only provided on models where the USB pins are connected.
+ *
+ * SPI-based Protocol
+ * --
+ *
+ * The device and driver exchange messages (struct message); each message is
+ * encapsulated in one or more packets (struct spi_packet). There are two types
+ * of exchanges: reads, and writes. A read is signaled by a GPE, upon which one
+ * message can be read from the device. A write exchange consists of writing a
+ * command message, immediately reading a short status packet, and then, upon
+ * receiving a GPE, reading the response message. Write exchanges cannot be
+ * interleaved, i.e. a new write exchange must not be started till the previous
+ * write exchange is complete. Whether a received message is part of a read or
+ * write exchange is indicated in the encapsulating packet's flags field.
+ *
+ * A single message may be too large to fit in a single packet (which has a
+
[PATCH v3 1/4] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge: sil_sii8620: do not have a dependency of RC_CORE) added a dependency on INPUT. However, this causes problems with other drivers, in particular an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a future commit): drivers/clk/Kconfig:9:error: recursive dependency detected! drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK According to the docs, select should only be used for non-visible symbols. Furthermore almost all other references to INPUT throughout the kernel config are depends, not selects. Hence this change. CC: Inki Dae CC: Andrzej Hajda Signed-off-by: Ronald Tschalär --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 2fee47b0d50b..eabedc83f25c 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -83,9 +83,9 @@ config DRM_PARADE_PS8622 config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF + depends on INPUT select DRM_KMS_HELPER imply EXTCON - select INPUT select RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.20.1
[PATCH v3 3/4] driver core: add dev_print_hex_dump() logging function.
This is the dev_xxx() analog to print_hex_dump(), using dev_printk()
instead of straight printk() to match other dev_xxx() logging functions.
---
drivers/base/core.c| 43 ++
include/linux/device.h | 15 +++
2 files changed, 58 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 0073b09bb99f..eb260d482750 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3097,6 +3097,49 @@ define_dev_printk_level(_dev_warn, KERN_WARNING);
define_dev_printk_level(_dev_notice, KERN_NOTICE);
define_dev_printk_level(_dev_info, KERN_INFO);
+static void
+print_to_dev_printk(const char *level, void *arg, const char *fmt, ...)
+{
+ struct va_format vaf;
+ va_list args;
+
+ va_start(args, fmt);
+
+ vaf.fmt = fmt;
+ vaf.va =
+
+ __dev_printk(level, (const struct device *)arg, );
+
+ va_end(args);
+}
+
+/**
+ * _dev_print_hex_dump - print a text hex dump to syslog for a binary blob of
+ * data
+ * @level: kernel log level (e.g. KERN_DEBUG)
+ * @dev: the device to which this log message pertains
+ * @prefix_str: string to prefix each line with;
+ * caller supplies trailing spaces for alignment if desired
+ * @prefix_type: controls whether prefix of an offset, address, or none
+ * is printed (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
+ * @rowsize: number of bytes to print per line; must be 16 or 32
+ * @groupsize: number of bytes to print at a time (1, 2, 4, 8; default = 1)
+ * @buf: data blob to dump
+ * @len: number of bytes in the @buf
+ * @ascii: include ASCII after the hex output
+ *
+ * See print_hex_dump() for additional details and examples.
+ */
+void _dev_print_hex_dump(const char *level, const struct device *dev,
+const char *prefix_str, int prefix_type,
+int rowsize, int groupsize,
+const void *buf, size_t len, bool ascii)
+{
+ print_hex_dump_to_cb(level, prefix_str, prefix_type, rowsize, groupsize,
+buf, len, ascii, print_to_dev_printk, (void *)dev);
+}
+EXPORT_SYMBOL(_dev_print_hex_dump);
+
#endif
static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..dc6fcae3002a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1405,6 +1405,10 @@ __printf(2, 3)
void _dev_notice(const struct device *dev, const char *fmt, ...);
__printf(2, 3)
void _dev_info(const struct device *dev, const char *fmt, ...);
+void _dev_print_hex_dump(const char *level, const struct device *dev,
+const char *prefix_str, int prefix_type,
+int rowsize, int groupsize,
+const void *buf, size_t len, bool ascii);
#else
@@ -1445,6 +1449,12 @@ void _dev_notice(const struct device *dev, const char
*fmt, ...)
static inline __printf(2, 3)
void _dev_info(const struct device *dev, const char *fmt, ...)
{}
+static inline
+void _dev_print_hex_dump(const char *level, const struct device *dev,
+const char *prefix_str, int prefix_type,
+int rowsize, int groupsize,
+const void *buf, size_t len, bool ascii);
+{}
#endif
@@ -1467,6 +1477,11 @@ void _dev_info(const struct device *dev, const char
*fmt, ...)
_dev_notice(dev, dev_fmt(fmt), ##__VA_ARGS__)
#define dev_info(dev, fmt, ...)
\
_dev_info(dev, dev_fmt(fmt), ##__VA_ARGS__)
+#define dev_print_hex_dump(level, dev, prefix_str, prefix_type,
\
+ rowsize, groupsize, buf, len, ascii) \
+ _dev_print_hex_dump(level, dev, dev_fmt(prefix_str),\
+ prefix_type, rowsize, groupsize, buf, len, \
+ ascii);
#if defined(CONFIG_DYNAMIC_DEBUG)
#define dev_dbg(dev, fmt, ...) \
--
2.20.1
[PATCH v3 2/4] lib/hexdump.c: factor out generic hexdump formatting for reuse.
This introduces print_hex_dump_to_cb() which contains all the hexdump
formatting minus the actual printk() call, allowing an arbitrary print
function to be supplied instead. And print_hex_dump() is re-implemented
using print_hex_dump_to_cb().
This allows other hex-dump logging functions to be provided which call
printk() differently or even log the hexdump somewhere entirely
different.
---
include/linux/printk.h | 12 ++
lib/hexdump.c | 95 +++---
2 files changed, 83 insertions(+), 24 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 77740a506ebb..4ebdacd7a287 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -483,10 +483,16 @@ enum {
extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
int groupsize, char *linebuf, size_t linebuflen,
bool ascii);
+typedef
+void (*hex_dump_callback)(const char *level, void *arg, const char *fmt, ...);
#ifdef CONFIG_PRINTK
extern void print_hex_dump(const char *level, const char *prefix_str,
int prefix_type, int rowsize, int groupsize,
const void *buf, size_t len, bool ascii);
+extern void print_hex_dump_to_cb(const char *level, const char *prefix_str,
+int prefix_type, int rowsize, int groupsize,
+const void *buf, size_t len, bool ascii,
+hex_dump_callback print, void *print_arg);
#if defined(CONFIG_DYNAMIC_DEBUG)
#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len)\
dynamic_hex_dump(prefix_str, prefix_type, 16, 1, buf, len, true)
@@ -500,6 +506,12 @@ static inline void print_hex_dump(const char *level, const
char *prefix_str,
const void *buf, size_t len, bool ascii)
{
}
+extern void print_hex_dump_to_cb(const char *level, const char *prefix_str,
+int prefix_type, int rowsize, int groupsize,
+const void *buf, size_t len, bool ascii,
+hex_dump_callback *print, void *print_arg);
+{
+}
static inline void print_hex_dump_bytes(const char *prefix_str, int
prefix_type,
const void *buf, size_t len)
{
diff --git a/lib/hexdump.c b/lib/hexdump.c
index 81b70ed37209..43583cf6accd 100644
--- a/lib/hexdump.c
+++ b/lib/hexdump.c
@@ -210,7 +210,8 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
#ifdef CONFIG_PRINTK
/**
- * print_hex_dump - print a text hex dump to syslog for a binary blob of data
+ * print_hex_dump_to_cb - print a text hex dump using given callback for a
+ * binary blob of data
* @level: kernel log level (e.g. KERN_DEBUG)
* @prefix_str: string to prefix each line with;
* caller supplies trailing spaces for alignment if desired
@@ -221,28 +222,18 @@ EXPORT_SYMBOL(hex_dump_to_buffer);
* @buf: data blob to dump
* @len: number of bytes in the @buf
* @ascii: include ASCII after the hex output
+ * @print: the print function, called once for each line
+ * @print_arg: an arbitrary argument to pass to the print function
*
- * Given a buffer of u8 data, print_hex_dump() prints a hex + ASCII dump
- * to the kernel log at the specified kernel log level, with an optional
- * leading prefix.
- *
- * print_hex_dump() works on one "line" of output at a time, i.e.,
- * 16 or 32 bytes of input data converted to hex + ASCII output.
- * print_hex_dump() iterates over the entire input @buf, breaking it into
- * "line size" chunks to format and print.
- *
- * E.g.:
- * print_hex_dump(KERN_DEBUG, "raw data: ", DUMP_PREFIX_ADDRESS,
- * 16, 1, frame->data, frame->len, true);
+ * This is a low level helper function - normally you want to use
+ * print_hex_dump() or other wrapper around it.
*
- * Example output using %DUMP_PREFIX_OFFSET and 1-byte mode:
- * 0009ab42: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO
- * Example output using %DUMP_PREFIX_ADDRESS and 4-byte mode:
- * 88089af0: 73727170 77767574 7b7a7978 7f7e7d7c pqrstuvwxyz{|}~.
+ * See print_hex_dump() for more details and examples.
*/
-void print_hex_dump(const char *level, const char *prefix_str, int prefix_type,
- int rowsize, int groupsize,
- const void *buf, size_t len, bool ascii)
+void print_hex_dump_to_cb(const char *level, const char *prefix_str,
+ int prefix_type, int rowsize, int groupsize,
+ const void *buf, size_t len, bool ascii,
+ hex_dump_callback print, void *print_arg)
{
const u8 *ptr = buf;
int i, linelen, remaining = len;
@@ -260,18 +251,74 @@ void print_hex_dump(const char *level, const char
*prefix_str, int prefix_type,
switch (prefix_type) {
case DUMP_PREFIX_ADDRESS:
-
[PATCH v3 0/4] Add Apple SPI keyboard and trackpad driver
This changeset adds a driver for the SPI keyboard and trackpad on recent MacBook's and MacBook Pro's. The driver has seen a fair amount of use over the last 2 years (basically anybody running linux on these machines), with only relatively small changes in the last year or so. For those interested, the driver development has been hosted at https://github.com/cb22/macbook12-spi-driver/ (as well as my clone at https://github.com/roadrunner2/macbook12-spi-driver/). The first patch is just a placeholder for now and is provided in case somebody wants to compile the driver while it's being reviewed here; the real patch has been submitted to dri-devel and is being discussed there, with the intent/hope that I can get an Ack and permission to merge it through the input subsystem tree here as part of this patch series. The second and third patches add a new dev_print_hex_dump() helper as the dev_xxx() analog of print_hex_dump(). The fourth patch finally contains the new applespi driver. Changes in v3: Applied all feedback from review by Andy Shevchenko, including: - move dev_print_hex_dump() to driver core - clean up keyboard modifier bits testing/modifying - remove DEV() macro - minor style issues The full set of changes to applespi can be viewed at https://github.com/roadrunner2/macbook12-spi-driver/ as individual commits f832caa..3a6262e in the upstreaming-review branch. Ronald Tschalär (4): drm/bridge: sil_sii8620: depend on INPUT instead of selecting it. lib/hexdump.c: factor out generic hexdump formatting for reuse. driver core: add dev_print_hex_dump() logging function. Input: add Apple SPI keyboard and trackpad driver. drivers/base/core.c | 43 + drivers/gpu/drm/bridge/Kconfig|2 +- drivers/input/keyboard/Kconfig| 15 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/applespi.c | 1988 + include/linux/device.h| 15 + include/linux/printk.h| 12 + lib/hexdump.c | 95 +- 8 files changed, 2146 insertions(+), 25 deletions(-) create mode 100644 drivers/input/keyboard/applespi.c -- 2.20.1
[PATCH v2 1/2] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge: sil_sii8620: do not have a dependency of RC_CORE) added a dependency on INPUT. However, this causes problems with other drivers, in particular an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a future commit): drivers/clk/Kconfig:9:error: recursive dependency detected! drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK According to the docs, select should only be used for non-visible symbols. Furthermore almost all other references to INPUT throughout the kernel config are depends, not selects. Hence this change. CC: Inki Dae CC: Andrzej Hajda Signed-off-by: Ronald Tschalär --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 9eeb8ef0b174..bc838e7bb7c8 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -83,9 +83,9 @@ config DRM_PARADE_PS8622 config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF + depends on INPUT select DRM_KMS_HELPER imply EXTCON - select INPUT select RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.20.1
[PATCH v2 0/2] Add Apple SPI keyboard and trackpad driver
This changeset adds a driver for the SPI keyboard and trackpad on recent MacBook's and MacBook Pro's. The driver has seen a fair amount of use over the last 2 years (basically anybody running linux on these machines), with only relatively small changes in the last year or so. For those interested, the driver development has been hosted at https://github.com/cb22/macbook12-spi-driver/ (as well as my clone at https://github.com/roadrunner2/macbook12-spi-driver/). The first patch is just a placeholder for now and is provided in case somebody wants to compile the driver while it's being reviewed here; the real patch has been submitted to dri-devel and is being discussed there, with the intent/hope that I can get an Ack and permission to merge it through the input subsystem tree here as part of this patch series. Changes in v2: Applied all feedback from review by Andy Shevchenko, including: - reworked logging to use dev_xxx() everywhere - split 16-bit model_id field into 2 8-bit fields - factored out several pieces of code into separate functions - many code style improvements and cleanups - Kconfig dependency fixes The full set of changes (except for the Kconfig) can be viewed at https://github.com/roadrunner2/macbook12-spi-driver/ as individual commits a651bb9..f832caa in the upstreaming-review branch. Ronald Tschalär (2): drm/bridge: sil_sii8620: depend on INPUT instead of selecting it. Input: add Apple SPI keyboard and trackpad driver. drivers/gpu/drm/bridge/Kconfig|2 +- drivers/input/keyboard/Kconfig| 14 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/applespi.c | 2003 + 4 files changed, 2019 insertions(+), 1 deletion(-) create mode 100644 drivers/input/keyboard/applespi.c -- 2.20.1
[PATCH v2 2/2] Input: add Apple SPI keyboard and trackpad driver.
The keyboard and trackpad on recent MacBook's (since 8,1) and
MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
of USB, as previously. The higher level protocol is not publicly
documented and hence has been reverse engineered. As a consequence there
are still a number of unknown fields and commands. However, the known
parts have been working well and received extensive testing and use.
In order for this driver to work, the proper SPI drivers need to be
loaded too; for MB8,1 these are spi_pxa2xx_platform and spi_pxa2xx_pci;
for all others they are spi_pxa2xx_platform and intel_lpss_pci. For this
reason enabling this driver in the config implies enabling the above
drivers.
CC: Federico Lorenzi
CC: Lukas Wunner
CC: Andy Shevchenko
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/Kconfig| 14 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/applespi.c | 2003 +
3 files changed, 2018 insertions(+)
create mode 100644 drivers/input/keyboard/applespi.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4713957b0cbb..395e5ce0bc2d 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -70,6 +70,20 @@ config KEYBOARD_AMIGA
config ATARI_KBD_CORE
bool
+config KEYBOARD_APPLESPI
+ tristate "Apple SPI keyboard and trackpad"
+ depends on ACPI && SPI && EFI
+ depends on X86 || COMPILE_TEST
+ imply SPI_PXA2XX
+ imply SPI_PXA2XX_PCI
+ imply MFD_INTEL_LPSS_PCI
+ help
+ Say Y here if you are running Linux on any Apple MacBook8,1 or later,
+ or any MacBookPro13,* or MacBookPro14,*.
+
+ To compile this driver as a module, choose M here: the
+ module will be called applespi.
+
config KEYBOARD_ATARI
tristate "Atari keyboard"
depends on ATARI
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 182e92985dbf..9283fee2505a 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5520)+=
adp5520-keys.o
obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
+obj-$(CONFIG_KEYBOARD_APPLESPI)+= applespi.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
new file mode 100644
index ..2a8d1786011d
--- /dev/null
+++ b/drivers/input/keyboard/applespi.c
@@ -0,0 +1,2003 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MacBook (Pro) SPI keyboard and touchpad driver
+ *
+ * Copyright (c) 2015-2018 Federico Lorenzi
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/*
+ * The keyboard and touchpad controller on the MacBookAir6, MacBookPro12,
+ * MacBook8 and newer can be driven either by USB or SPI. However the USB
+ * pins are only connected on the MacBookAir6 and 7 and the MacBookPro12.
+ * All others need this driver. The interface is selected using ACPI methods:
+ *
+ * * UIEN ("USB Interface Enable"): If invoked with argument 1, disables SPI
+ * and enables USB. If invoked with argument 0, disables USB.
+ * * UIST ("USB Interface Status"): Returns 1 if USB is enabled, 0 otherwise.
+ * * SIEN ("SPI Interface Enable"): If invoked with argument 1, disables USB
+ * and enables SPI. If invoked with argument 0, disables SPI.
+ * * SIST ("SPI Interface Status"): Returns 1 if SPI is enabled, 0 otherwise.
+ * * ISOL: Resets the four GPIO pins used for SPI. Intended to be invoked with
+ * argument 1, then once more with argument 0.
+ *
+ * UIEN and UIST are only provided on models where the USB pins are connected.
+ *
+ * SPI-based Protocol
+ * --
+ *
+ * The device and driver exchange messages (struct message); each message is
+ * encapsulated in one or more packets (struct spi_packet). There are two types
+ * of exchanges: reads, and writes. A read is signaled by a GPE, upon which one
+ * message can be read from the device. A write exchange consists of writing a
+ * command message, immediately reading a short status packet, and then, upon
+ * receiving a GPE, reading the response message. Write exchanges cannot be
+ * interleaved, i.e. a new write exchange must not be started till the previous
+ * write exchange is complete. Whether a received message is part of a read or
+ * write exchange is indicated in the encapsulating packet's flags field.
+ *
+ * A single message may be too large to fit in a single packet (which has a
+ * fixed, 256-byte
[PATCH 2/2] Input: add Apple SPI keyboard and trackpad driver.
The keyboard and trackpad on recent MacBook's (since 8,1) and
MacBookPro's (13,* and 14,*) are attached to an SPI controller instead
of USB, as previously. The higher level protocol is not publicly
documented and hence has been reverse engineered. As a consequence there
are still a number of unknown fields and commands. However, the known
parts have been working well and received extensive testing and use.
In order for this driver to work, the proper SPI drivers need to be
loaded too; for MB8,1 these are spi_pxa2xx_platform and spi_pxa2xx_pci;
for all others they are spi_pxa2xx_platform and intel_lpss_pci. For this
reason enabling this driver in the config implies enabling the above
drivers.
CC: Federico Lorenzi
CC: Lukas Wunner
CC: Andy Shevchenko
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=108331
Signed-off-by: Ronald Tschalär
---
drivers/input/keyboard/Kconfig| 13 +
drivers/input/keyboard/Makefile |1 +
drivers/input/keyboard/applespi.c | 1919 +
3 files changed, 1933 insertions(+)
create mode 100644 drivers/input/keyboard/applespi.c
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a878351f1643..e35afa23b1db 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -70,6 +70,19 @@ config KEYBOARD_AMIGA
config ATARI_KBD_CORE
bool
+config KEYBOARD_APPLESPI
+ tristate "Apple SPI keyboard and trackpad"
+ depends on (X86 && ACPI && SPI) || COMPILE_TEST
+ imply SPI_PXA2XX
+ imply SPI_PXA2XX_PCI
+ imply MFD_INTEL_LPSS_PCI
+ help
+ Say Y here if you are running Linux on any Apple MacBook8,1 or later,
+ or any MacBookPro13,* or MacBookPro14,*.
+
+ To compile this driver as a module, choose M here: the
+ module will be called applespi.
+
config KEYBOARD_ATARI
tristate "Atari keyboard"
depends on ATARI
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 182e92985dbf..9283fee2505a 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KEYBOARD_ADP5520)+=
adp5520-keys.o
obj-$(CONFIG_KEYBOARD_ADP5588) += adp5588-keys.o
obj-$(CONFIG_KEYBOARD_ADP5589) += adp5589-keys.o
obj-$(CONFIG_KEYBOARD_AMIGA) += amikbd.o
+obj-$(CONFIG_KEYBOARD_APPLESPI)+= applespi.o
obj-$(CONFIG_KEYBOARD_ATARI) += atakbd.o
obj-$(CONFIG_KEYBOARD_ATKBD) += atkbd.o
obj-$(CONFIG_KEYBOARD_BCM) += bcm-keypad.o
diff --git a/drivers/input/keyboard/applespi.c
b/drivers/input/keyboard/applespi.c
new file mode 100644
index ..75780f3385c0
--- /dev/null
+++ b/drivers/input/keyboard/applespi.c
@@ -0,0 +1,1919 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MacBook (Pro) SPI keyboard and touchpad driver
+ *
+ * Copyright (c) 2015-2018 Federico Lorenzi
+ * Copyright (c) 2017-2018 Ronald Tschalär
+ */
+
+/**
+ * The keyboard and touchpad controller on the MacBookAir6, MacBookPro12,
+ * MacBook8 and newer can be driven either by USB or SPI. However the USB
+ * pins are only connected on the MacBookAir6 and 7 and the MacBookPro12.
+ * All others need this driver. The interface is selected using ACPI methods:
+ *
+ * * UIEN ("USB Interface Enable"): If invoked with argument 1, disables SPI
+ * and enables USB. If invoked with argument 0, disables USB.
+ * * UIST ("USB Interface Status"): Returns 1 if USB is enabled, 0 otherwise.
+ * * SIEN ("SPI Interface Enable"): If invoked with argument 1, disables USB
+ * and enables SPI. If invoked with argument 0, disables SPI.
+ * * SIST ("SPI Interface Status"): Returns 1 if SPI is enabled, 0 otherwise.
+ * * ISOL: Resets the four GPIO pins used for SPI. Intended to be invoked with
+ * argument 1, then once more with argument 0.
+ *
+ * UIEN and UIST are only provided on models where the USB pins are connected.
+ *
+ * SPI-based Protocol
+ * --
+ *
+ * The device and driver exchange messages (struct message); each message is
+ * encapsulated in one or more packets (struct spi_packet). There are two types
+ * of exchanges: reads, and writes. A read is signaled by a GPE, upon which one
+ * message can be read from the device. A write exchange consists of writing a
+ * command message, immediately reading a short status packet, and then, upon
+ * receiving a GPE, reading the response message. Write exchanges cannot be
+ * interleaved, i.e. a new write exchange must not be started till the previous
+ * write exchange is complete. Whether a received message is part of a read or
+ * write exchange is indicated in the encapsulating packet's flags field.
+ *
+ * A single message may be too large to fit in a single packet (which has a
+ * fixed, 256-byte size). In that c
[PATCH 1/2] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge: sil_sii8620: do not have a dependency of RC_CORE) added a dependency on INPUT. However, this causes problems with other drivers, in particular an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a future commit): drivers/clk/Kconfig:9:error: recursive dependency detected! drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK According to the docs, select should only be used for non-visible symbols. Furthermore almost all other references to INPUT throughout the kernel config are depends, not selects. Hence this change. CC: Inki Dae CC: Andrzej Hajda Signed-off-by: Ronald Tschalär --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 2fee47b0d50b..eabedc83f25c 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -83,9 +83,9 @@ config DRM_PARADE_PS8622 config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF + depends on INPUT select DRM_KMS_HELPER imply EXTCON - select INPUT select RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.20.1
[PATCH 0/2] Add Apple SPI keyboard and trackpad driver
This changeset adds a driver for the SPI keyboard and trackpad on recent MacBook's and MacBook Pro's. The driver has seen a fair amount of use over the last 2 years (basically anybody running linux on these machines), with only relatively small changes in the last year or so. For those interested, the driver development has been hosted at https://github.com/cb22/macbook12-spi-driver/ (as well as my clone at https://github.com/roadrunner2/macbook12-spi-driver/). The first patch is just a placeholder for now and is provided in case somebody wants to compile the driver while it's being reviewed here; the real patch has been submitted to dri-devel and is being discussed there, with the intent/hope that I can get an Ack and permission to merge it through the input subsystem tree here as part of this patch series. Ronald Tschalär (2): drm/bridge: sil_sii8620: depend on INPUT instead of selecting it. Input: add Apple SPI keyboard and trackpad driver. drivers/gpu/drm/bridge/Kconfig|2 +- drivers/input/keyboard/Kconfig| 13 + drivers/input/keyboard/Makefile |1 + drivers/input/keyboard/applespi.c | 1919 + 4 files changed, 1934 insertions(+), 1 deletion(-) create mode 100644 drivers/input/keyboard/applespi.c -- 2.20.1
[PATCH v2] drm/bridge: sil_sii8620: make remote control optional.
commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
of RC_CORE) changed the driver to select both RC_CORE and INPUT.
However, this causes problems with other drivers, in particular an input
driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
commit):
drivers/clk/Kconfig:9:error: recursive dependency detected!
drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS
drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by
MFD_INTEL_LPSS_PCI
drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by
KEYBOARD_APPLESPI
drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on
INPUT
drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620
drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on
DRM_BRIDGE
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by
DRM_PL111
drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK
According to the docs and general consensus, select should only be used
for non user-visible symbols, but both RC_CORE and INPUT are
user-visible. Furthermore almost all other references to INPUT
throughout the kernel config are depends, not selects. For this reason
the first part of this change reverts commit d6abe6df706c.
In order to address the original reason for commit d6abe6df706c, namely
that not all boards use the remote controller functionality and hence
should not need have to deal with RC_CORE, the second part of this
change now makes the remote control support in the driver optional and
contingent on RC_CORE being defined. And with this the hard dependency
on INPUT also goes away as that is only needed if RC_CORE is defined
(which in turn already depends on INPUT).
CC: Inki Dae
CC: Andrzej Hajda
CC: Laurent Pinchart
CC: Dmitry Torokhov
Signed-off-by: Ronald Tschalär
---
Resending this, as I somehow managed to forget to cc dri-devel.
Apologies for the duplication.
Changes in v2:
- completely remove dependencies on both RC_CORE and INPUT in Kconfig,
- make remote control functionality in driver contingent on RC_CORE
being defined
drivers/gpu/drm/bridge/Kconfig | 2 --
drivers/gpu/drm/bridge/sil-sii8620.c | 17 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..a11198a36005 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -85,8 +85,6 @@ config DRM_SIL_SII8620
depends on OF
select DRM_KMS_HELPER
imply EXTCON
- select INPUT
- select RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 0cc293a6ac24..dee47752791e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -66,7 +66,9 @@ enum sii8620_mt_state {
struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+#if IS_ENABLED(CONFIG_RC_CORE)
struct rc_dev *rc_dev;
+#endif
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -1756,6 +1758,7 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
{
bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
@@ -1774,6 +1777,12 @@ static bool sii8620_rcp_consume(struct sii8620 *ctx, u8
scancode)
return true;
}
+#else
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+ return false;
+}
+#endif
static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
{
@@ -2097,6 +2106,7 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
{
struct rc_dev *rc_dev;
@@ -2126,6 +2136,11 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
}
ctx->rc_dev = rc_dev;
}
+#else
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+}
+#endif
static void sii8620_cable_out(struct sii8620 *ctx)
{
@@ -2214,9 +2229,11 @@ static int sii8620_attach(struct drm_bridge *bridge)
static void sii8620_detach(struct drm_bridge *bridge)
{
+#if IS_ENABLED(CONFIG_RC_CORE)
struct sii8620 *ctx = bridge_to_sii8620(bridge);
rc_unregister_device(ctx->rc_dev);
+#endif
}
static int sii8620_is_packing_required(struct sii8620 *ctx,
--
2.20.1
[PATCH v2] drm/bridge: sil_sii8620: make remote control optional.
commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
of RC_CORE) changed the driver to select both RC_CORE and INPUT.
However, this causes problems with other drivers, in particular an input
driver that depends on MFD_INTEL_LPSS_PCI (to be added in a separate
commit):
drivers/clk/Kconfig:9:error: recursive dependency detected!
drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS
drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by
MFD_INTEL_LPSS_PCI
drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by
KEYBOARD_APPLESPI
drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on
INPUT
drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620
drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on
DRM_BRIDGE
drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by
DRM_PL111
drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK
According to the docs and general consensus, select should only be used
for non user-visible symbols, but both RC_CORE and INPUT are
user-visible. Furthermore almost all other references to INPUT
throughout the kernel config are depends, not selects. For this reason
the first part of this change reverts commit d6abe6df706c.
In order to address the original reason for commit d6abe6df706c, namely
that not all boards use the remote controller functionality and hence
should not need have to deal with RC_CORE, the second part of this
change now makes the remote control support in the driver optional and
contingent on RC_CORE being defined. And with this the hard dependency
on INPUT also goes away as that is only needed if RC_CORE is defined
(which in turn already depends on INPUT).
CC: Inki Dae
CC: Andrzej Hajda
CC: Laurent Pinchart
CC: Dmitry Torokhov
Signed-off-by: Ronald Tschalär
---
Changes in v2:
- completely remove dependencies on both RC_CORE and INPUT in Kconfig,
- make remote control functionality in driver contingent on RC_CORE
being defined
drivers/gpu/drm/bridge/Kconfig | 2 --
drivers/gpu/drm/bridge/sil-sii8620.c | 17 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2fee47b0d50b..a11198a36005 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -85,8 +85,6 @@ config DRM_SIL_SII8620
depends on OF
select DRM_KMS_HELPER
imply EXTCON
- select INPUT
- select RC_CORE
help
Silicon Image SII8620 HDMI/MHL bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 0cc293a6ac24..dee47752791e 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -66,7 +66,9 @@ enum sii8620_mt_state {
struct sii8620 {
struct drm_bridge bridge;
struct device *dev;
+#if IS_ENABLED(CONFIG_RC_CORE)
struct rc_dev *rc_dev;
+#endif
struct clk *clk_xtal;
struct gpio_desc *gpio_reset;
struct gpio_desc *gpio_int;
@@ -1756,6 +1758,7 @@ static void sii8620_send_features(struct sii8620 *ctx)
sii8620_write_buf(ctx, REG_MDT_XMIT_WRITE_PORT, buf, ARRAY_SIZE(buf));
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
{
bool pressed = !(scancode & MHL_RCP_KEY_RELEASED_MASK);
@@ -1774,6 +1777,12 @@ static bool sii8620_rcp_consume(struct sii8620 *ctx, u8
scancode)
return true;
}
+#else
+static bool sii8620_rcp_consume(struct sii8620 *ctx, u8 scancode)
+{
+ return false;
+}
+#endif
static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
{
@@ -2097,6 +2106,7 @@ static void sii8620_cable_in(struct sii8620 *ctx)
enable_irq(to_i2c_client(ctx->dev)->irq);
}
+#if IS_ENABLED(CONFIG_RC_CORE)
static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
{
struct rc_dev *rc_dev;
@@ -2126,6 +2136,11 @@ static void sii8620_init_rcp_input_dev(struct sii8620
*ctx)
}
ctx->rc_dev = rc_dev;
}
+#else
+static void sii8620_init_rcp_input_dev(struct sii8620 *ctx)
+{
+}
+#endif
static void sii8620_cable_out(struct sii8620 *ctx)
{
@@ -2214,9 +2229,11 @@ static int sii8620_attach(struct drm_bridge *bridge)
static void sii8620_detach(struct drm_bridge *bridge)
{
+#if IS_ENABLED(CONFIG_RC_CORE)
struct sii8620 *ctx = bridge_to_sii8620(bridge);
rc_unregister_device(ctx->rc_dev);
+#endif
}
static int sii8620_is_packing_required(struct sii8620 *ctx,
--
2.20.1
[PATCH] drm/bridge: sil_sii8620: depend on INPUT instead of selecting it.
commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge: sil_sii8620: do not have a dependency of RC_CORE) added a dependency on INPUT. However, this causes problems with other drivers, in particular an input driver that depends on MFD_INTEL_LPSS_PCI (to be added in a future commit): drivers/clk/Kconfig:9:error: recursive dependency detected! drivers/clk/Kconfig:9:symbol COMMON_CLK is selected by MFD_INTEL_LPSS drivers/mfd/Kconfig:566: symbol MFD_INTEL_LPSS is selected by MFD_INTEL_LPSS_PCI drivers/mfd/Kconfig:580: symbol MFD_INTEL_LPSS_PCI is implied by KEYBOARD_APPLESPI drivers/input/keyboard/Kconfig:73:symbol KEYBOARD_APPLESPI depends on INPUT drivers/input/Kconfig:8: symbol INPUT is selected by DRM_SIL_SII8620 drivers/gpu/drm/bridge/Kconfig:83:symbol DRM_SIL_SII8620 depends on DRM_BRIDGE drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_PL111 drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on COMMON_CLK According to the docs, select should only be used for non-visible symbols. Furthermore almost all other references to INPUT throughout the kernel config are depends, not selects. Hence this change. CC: Inki Dae CC: Andrzej Hajda Signed-off-by: Ronald Tschalär --- drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 2fee47b0d50b..eabedc83f25c 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -83,9 +83,9 @@ config DRM_PARADE_PS8622 config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF + depends on INPUT select DRM_KMS_HELPER imply EXTCON - select INPUT select RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.20.1
U.S. Customs and Border??
-- U.S. Customs and Border Protection Acting Deputy Commissioner I am writing. in regards of your Package in our custody. with Mr. Jerry A. Benson, A Diplomats from Global Agent Service was stopped at the border in possession of the above mention metal box weight of about 25kg (Internal dimension: W61 x H156 x D73 (cm). Effective capacity: 110 LBS.). Approximately, destine to your name and home address He could not produce all necessary clearance papers which made us to put your Package on hold until we receive the Customs Registration number from you to prove your ownership. You are hereby giving a grace of 96hours to provide the Customs Registration number, otherwise your Package will be confiscated and send back to the Treasury Office The Registration number is very necessary to enable us verify that you are the real beneficiary of the metal box, after which your Package will be release to you* to avoid any necessary delay, we will advise that you re-confirm your full name, postal address and contact information for faster and smooth communications. NOTE: If You Receive This Message In Your Junk Or Spam It's Due To Your Internet Provider. As soon as you receive this email and send me all the requested information to my direct email address: ronaldvitie...@aol.com U.S. Customs and Border Protection Acting Deputy Commissioner Ronald.D.Vitiello
U.S. Customs and Border??
-- U.S. Customs and Border Protection Acting Deputy Commissioner I am writing. in regards of your Package in our custody. with Mr. Jerry A. Benson, A Diplomats from Global Agent Service was stopped at the border in possession of the above mention metal box weight of about 25kg (Internal dimension: W61 x H156 x D73 (cm). Effective capacity: 110 LBS.). Approximately, destine to your name and home address He could not produce all necessary clearance papers which made us to put your Package on hold until we receive the Customs Registration number from you to prove your ownership. You are hereby giving a grace of 96hours to provide the Customs Registration number, otherwise your Package will be confiscated and send back to the Treasury Office The Registration number is very necessary to enable us verify that you are the real beneficiary of the metal box, after which your Package will be release to you* to avoid any necessary delay, we will advise that you re-confirm your full name, postal address and contact information for faster and smooth communications. NOTE: If You Receive This Message In Your Junk Or Spam It's Due To Your Internet Provider. As soon as you receive this email and send me all the requested information to my direct email address: ronaldvitie...@aol.com U.S. Customs and Border Protection Acting Deputy Commissioner Ronald.D.Vitiello
U.S. Customs and Border??
-- U.S. Customs and Border Protection Acting Deputy Commissioner I am writing. in regards of your Package in our custody. with Mr. Jerry A. Benson, A Diplomats from Global Agent Service was stopped at the border in possession of the above mention metal box weight of about 25kg (Internal dimension: W61 x H156 x D73 (cm). Effective capacity: 110 LBS.). Approximately, destine to your name and home address He could not produce all necessary clearance papers which made us to put your Package on hold until we receive the Customs Registration number from you to prove your ownership. You are hereby giving a grace of 96hours to provide the Customs Registration number, otherwise your Package will be confiscated and send back to the Treasury Office The Registration number is very necessary to enable us verify that you are the real beneficiary of the metal box, after which your Package will be release to you* to avoid any necessary delay, we will advise that you re-confirm your full name, postal address and contact information for faster and smooth communications. NOTE: If You Receive This Message In Your Junk Or Spam It's Due To Your Internet Provider. As soon as you receive this email and send me all the requested information to my direct email address: ronaldvitie...@aol.com U.S. Customs and Border Protection Acting Deputy Commissioner Ronald.D.Vitiello
U.S. Customs and Border??
-- U.S. Customs and Border Protection Acting Deputy Commissioner I am writing. in regards of your Package in our custody. with Mr. Jerry A. Benson, A Diplomats from Global Agent Service was stopped at the border in possession of the above mention metal box weight of about 25kg (Internal dimension: W61 x H156 x D73 (cm). Effective capacity: 110 LBS.). Approximately, destine to your name and home address He could not produce all necessary clearance papers which made us to put your Package on hold until we receive the Customs Registration number from you to prove your ownership. You are hereby giving a grace of 96hours to provide the Customs Registration number, otherwise your Package will be confiscated and send back to the Treasury Office The Registration number is very necessary to enable us verify that you are the real beneficiary of the metal box, after which your Package will be release to you* to avoid any necessary delay, we will advise that you re-confirm your full name, postal address and contact information for faster and smooth communications. NOTE: If You Receive This Message In Your Junk Or Spam It's Due To Your Internet Provider. As soon as you receive this email and send me all the requested information to my direct email address: ronaldvitie...@aol.com U.S. Customs and Border Protection Acting Deputy Commissioner Ronald.D.Vitiello
[PATCH] ACPI/sbs: Fix GPE storm on recent MacBookPro's.
On Apple machines, plugging-in or unplugging the power triggers a GPE for the EC. Since these machines expose an SBS device, this GPE ends up triggering the acpi_sbs_callback(). This in turn tries to get the status of the SBS charger. However, on MBP13,* and MBP14,* machines, performing the smbus-read operation to get the charger's status triggers the EC's GPE again. The result is an endless re-triggering and handling of that GPE, consuming significant CPU resources (> 50% in irq). In the end this is quite similar to commit 3031cddea633 (ACPI / SBS: Don't assume the existence of an SBS charger), except that on the above machines a status of all 1's is returned. And like there, we just want ignore the charger here. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169 CC: Zhang Rui Signed-off-by: Ronald Tschalär --- drivers/acpi/sbs.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c index 295b59271189..96c5e27967f4 100644 --- a/drivers/acpi/sbs.c +++ b/drivers/acpi/sbs.c @@ -441,9 +441,13 @@ static int acpi_ac_get_present(struct acpi_sbs *sbs) /* * The spec requires that bit 4 always be 1. If it's not set, assume -* that the implementation doesn't support an SBS charger +* that the implementation doesn't support an SBS charger. +* +* And on some MacBooks a status of 0x is always returned, no +* matter whether the charger is plugged in or not, which is also +* wrong, so ignore the SBS charger for those too. */ - if (!((status >> 4) & 0x1)) + if (!((status >> 4) & 0x1) || status == 0x) return -ENODEV; sbs->charger_present = (status >> 15) & 0x1; -- 2.17.1
[PATCH] ACPI/sbshc: Fix rare oops when removing modules.
There was a small race when removing the sbshc module where
smbus_alarm() had queued acpi_smbus_callback() for deferred execution
but it hadn't been run yet, so that when it did run hc had been freed
and the module unloaded, resulting in an invalid paging request.
A similar race existed when removing the sbs module with regards to
acpi_sbs_callback() (which is called from acpi_smbus_callback()).
We therefore need to ensure no callbacks are pending or executing before
the cleanups are done and the modules are removed.
Signed-off-by: Ronald Tschalär
---
drivers/acpi/osl.c | 1 +
drivers/acpi/sbshc.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8df9abfa947b..9d139727f164 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1129,6 +1129,7 @@ void acpi_os_wait_events_complete(void)
flush_workqueue(kacpid_wq);
flush_workqueue(kacpi_notify_wq);
}
+EXPORT_SYMBOL(acpi_os_wait_events_complete);
struct acpi_hp_work {
struct work_struct work;
diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
index 7a3431018e0a..5008ead4609a 100644
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -196,6 +196,7 @@ int acpi_smbus_unregister_callback(struct acpi_smb_hc *hc)
hc->callback = NULL;
hc->context = NULL;
mutex_unlock(>lock);
+ acpi_os_wait_events_complete();
return 0;
}
@@ -292,6 +293,7 @@ static int acpi_smbus_hc_remove(struct acpi_device *device)
hc = acpi_driver_data(device);
acpi_ec_remove_query_handler(hc->ec, hc->query_bit);
+ acpi_os_wait_events_complete();
kfree(hc);
device->driver_data = NULL;
return 0;
--
2.17.1
[PATCH] ACPI/sbs: Fix GPE storm on recent MacBookPro's.
On Apple machines, plugging-in or unplugging the power triggers a GPE for the EC. Since these machines expose an SBS device, this GPE ends up triggering the acpi_sbs_callback(). This in turn tries to get the status of the SBS charger. However, on MBP13,* and MBP14,* machines, performing the smbus-read operation to get the charger's status triggers the EC's GPE again. The result is an endless re-triggering and handling of that GPE, consuming significant CPU resources (> 50% in irq). In the end this is quite similar to commit 3031cddea633 (ACPI / SBS: Don't assume the existence of an SBS charger), except that on the above machines a status of all 1's is returned. And like there, we just want ignore the charger here. Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169 CC: Zhang Rui Signed-off-by: Ronald Tschalär --- drivers/acpi/sbs.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c index 295b59271189..96c5e27967f4 100644 --- a/drivers/acpi/sbs.c +++ b/drivers/acpi/sbs.c @@ -441,9 +441,13 @@ static int acpi_ac_get_present(struct acpi_sbs *sbs) /* * The spec requires that bit 4 always be 1. If it's not set, assume -* that the implementation doesn't support an SBS charger +* that the implementation doesn't support an SBS charger. +* +* And on some MacBooks a status of 0x is always returned, no +* matter whether the charger is plugged in or not, which is also +* wrong, so ignore the SBS charger for those too. */ - if (!((status >> 4) & 0x1)) + if (!((status >> 4) & 0x1) || status == 0x) return -ENODEV; sbs->charger_present = (status >> 15) & 0x1; -- 2.17.1
[PATCH] ACPI/sbshc: Fix rare oops when removing modules.
There was a small race when removing the sbshc module where
smbus_alarm() had queued acpi_smbus_callback() for deferred execution
but it hadn't been run yet, so that when it did run hc had been freed
and the module unloaded, resulting in an invalid paging request.
A similar race existed when removing the sbs module with regards to
acpi_sbs_callback() (which is called from acpi_smbus_callback()).
We therefore need to ensure no callbacks are pending or executing before
the cleanups are done and the modules are removed.
Signed-off-by: Ronald Tschalär
---
drivers/acpi/osl.c | 1 +
drivers/acpi/sbshc.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8df9abfa947b..9d139727f164 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1129,6 +1129,7 @@ void acpi_os_wait_events_complete(void)
flush_workqueue(kacpid_wq);
flush_workqueue(kacpi_notify_wq);
}
+EXPORT_SYMBOL(acpi_os_wait_events_complete);
struct acpi_hp_work {
struct work_struct work;
diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
index 7a3431018e0a..5008ead4609a 100644
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -196,6 +196,7 @@ int acpi_smbus_unregister_callback(struct acpi_smb_hc *hc)
hc->callback = NULL;
hc->context = NULL;
mutex_unlock(>lock);
+ acpi_os_wait_events_complete();
return 0;
}
@@ -292,6 +293,7 @@ static int acpi_smbus_hc_remove(struct acpi_device *device)
hc = acpi_driver_data(device);
acpi_ec_remove_query_handler(hc->ec, hc->query_bit);
+ acpi_os_wait_events_complete();
kfree(hc);
device->driver_data = NULL;
return 0;
--
2.17.1
lainoja
Olen Ronald Bernstein, olen lainanantaja, annan lainoja yksittäisille ja yrityksille, liike- ja henkilökohtaisiin tarkoituksiin, ota yhteyttä minuun, jos tarvitset minkäänlaista lainaa. Annan lainoja yleisölle 2 prosentin korolla. Ota yhteyttä minuun
lainoja
Olen Ronald Bernstein, olen lainanantaja, annan lainoja yksittäisille ja yrityksille, liike- ja henkilökohtaisiin tarkoituksiin, ota yhteyttä minuun, jos tarvitset minkäänlaista lainaa. Annan lainoja yleisölle 2 prosentin korolla. Ota yhteyttä minuun
[PATCH] Bluetooth: hci_ldisc: Fix another race when closing the tty.
The following race condition still existed:
P1P2
cancel_work_sync()
hci_uart_tx_wakeup()
hci_uart_write_work()
hci_uart_dequeue()
clear_bit(HCI_UART_PROTO_READY)
hci_unregister_dev(hdev)
hci_free_dev(hdev)
hu->proto->close(hu)
kfree(hu)
access to hdev and hu
Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
this as any hci_uart_tx_wakeup() issued after the flag is cleared will
detect that and not schedule further work.
Signed-off-by: Ronald Tschalär <ron...@innovation.ch>
Cc: Dean Jenkins <dean_jenk...@mentor.com>
Cc: Lukas Wunner <lu...@wunner.de>
Cc: Marcel Holtmann <mar...@holtmann.org>
Cc: Gustavo Padovan <gust...@padovan.org>
Cc: Johan Hedberg <johan.hedb...@gmail.com>
---
drivers/bluetooth/hci_ldisc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 31def781a562..c823914b3a80 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -523,13 +523,13 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
- cancel_work_sync(>write_work);
-
if (test_bit(HCI_UART_PROTO_READY, >flags)) {
percpu_down_write(>proto_lock);
clear_bit(HCI_UART_PROTO_READY, >flags);
percpu_up_write(>proto_lock);
+ cancel_work_sync(>write_work);
+
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, >flags))
hci_unregister_dev(hdev);
--
2.13.6
[PATCH] Bluetooth: hci_ldisc: Fix another race when closing the tty.
The following race condition still existed:
P1P2
cancel_work_sync()
hci_uart_tx_wakeup()
hci_uart_write_work()
hci_uart_dequeue()
clear_bit(HCI_UART_PROTO_READY)
hci_unregister_dev(hdev)
hci_free_dev(hdev)
hu->proto->close(hu)
kfree(hu)
access to hdev and hu
Cancelling the work after clearing the HCI_UART_PROTO_READY bit avoids
this as any hci_uart_tx_wakeup() issued after the flag is cleared will
detect that and not schedule further work.
Signed-off-by: Ronald Tschalär
Cc: Dean Jenkins
Cc: Lukas Wunner
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
---
drivers/bluetooth/hci_ldisc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index 31def781a562..c823914b3a80 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -523,13 +523,13 @@ static void hci_uart_tty_close(struct tty_struct *tty)
if (hdev)
hci_uart_close(hdev);
- cancel_work_sync(>write_work);
-
if (test_bit(HCI_UART_PROTO_READY, >flags)) {
percpu_down_write(>proto_lock);
clear_bit(HCI_UART_PROTO_READY, >flags);
percpu_up_write(>proto_lock);
+ cancel_work_sync(>write_work);
+
if (hdev) {
if (test_bit(HCI_UART_REGISTERED, >flags))
hci_unregister_dev(hdev);
--
2.13.6
[PATCH v2] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc:
Use rwlocking to avoid closing proto races") introduced locks in
hci_ldisc that are held while calling the proto functions. These locks
are rwlock's, and hence do not allow sleeping while they are held.
However, the proto functions that hci_bcm registers use mutexes and
hence need to be able to sleep.
In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
acquire the rwlock, after which they call proto->recv() and
proto->dequeue(), respectively. In the case of hci_bcm these point to
bcm_recv() and bcm_dequeue(). The latter both acquire the
bcm_device_lock, which is a mutex, so doing so results in a call to
might_sleep(). But since we're holding a rwlock in hci_ldisc, that
results in the following BUG (this for the dequeue case - a similar
one for the receive case is omitted for brevity):
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
INFO: lockdep is turned off.
CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: GW OE 4.13.2+ #17
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
Workqueue: events hci_uart_write_work [hci_uart]
Call Trace:
dump_stack+0x8e/0xd6
___might_sleep+0x164/0x250
__might_sleep+0x4a/0x80
__mutex_lock+0x59/0xa00
? lock_acquire+0xa3/0x1f0
? lock_acquire+0xa3/0x1f0
? hci_uart_write_work+0xd3/0x160 [hci_uart]
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
bcm_dequeue+0x21/0xc0 [hci_uart]
hci_uart_write_work+0xe6/0x160 [hci_uart]
process_one_work+0x253/0x6a0
worker_thread+0x4d/0x3b0
kthread+0x133/0x150
We can't replace the mutex in hci_bcm, because there are other calls
there that might sleep. Therefore this replaces the rwlock's in
hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
approach anyway as it reduces the restrictions on the proto callbacks.
Also, because acquiring write-lock is very rare compared to acquiring
the read-lock, the percpu variant of rw_semaphore is used.
Lastly, because hci_uart_tx_wakeup() may be called from an IRQ context,
we can't block (sleep) while trying acquire the read lock there, so we
use the trylock variant.
Signed-off-by: Ronald Tschalär <ron...@innovation.ch>
Cc: Lukas Wunner <lu...@wunner.de>
Cc: Marcel Holtmann <mar...@holtmann.org>
Cc: Gustavo Padovan <gust...@padovan.org>
Cc: Johan Hedberg <johan.hedb...@gmail.com>
Cc: Dean Jenkins <dean_jenk...@mentor.com>
---
Changes in v2:
- Add back locking in hci_uart_tx_wakeup(). Removing the locking
altogether there was wrong, as nicely pointed out by Dean Jenkins.
drivers/bluetooth/hci_ldisc.c | 38 ++
drivers/bluetooth/hci_uart.h | 2 +-
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index eec95019f15c..31def781a562 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -115,12 +115,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
struct sk_buff *skb = hu->tx_skb;
if (!skb) {
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
skb = hu->proto->dequeue(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
} else {
hu->tx_skb = NULL;
}
@@ -130,7 +130,14 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- read_lock(>proto_lock);
+ /* This may be called in an IRQ context, so we can't sleep. Therefore
+* we try to acquire the lock only, and if that fails we assume the
+* tty is being closed because that is the only time the write lock is
+* acquired. If, however, at some point in the future the write lock
+* is also acquired in other situations, then this must be revisited.
+*/
+ if (!percpu_down_read_trylock(>proto_lock))
+ return 0;
if (!test_bit(HCI_UART_PROTO_READY, >flags))
goto no_schedule;
@@ -145,7 +152,7 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
schedule_work(>write_work);
no_schedule:
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return 0;
}
@@ -247,12 +254,12 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
hu->proto->flush(hu);
- read_unlock(>proto_lock);
+ percpu_up_
[PATCH v2] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc:
Use rwlocking to avoid closing proto races") introduced locks in
hci_ldisc that are held while calling the proto functions. These locks
are rwlock's, and hence do not allow sleeping while they are held.
However, the proto functions that hci_bcm registers use mutexes and
hence need to be able to sleep.
In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
acquire the rwlock, after which they call proto->recv() and
proto->dequeue(), respectively. In the case of hci_bcm these point to
bcm_recv() and bcm_dequeue(). The latter both acquire the
bcm_device_lock, which is a mutex, so doing so results in a call to
might_sleep(). But since we're holding a rwlock in hci_ldisc, that
results in the following BUG (this for the dequeue case - a similar
one for the receive case is omitted for brevity):
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
INFO: lockdep is turned off.
CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: GW OE 4.13.2+ #17
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
Workqueue: events hci_uart_write_work [hci_uart]
Call Trace:
dump_stack+0x8e/0xd6
___might_sleep+0x164/0x250
__might_sleep+0x4a/0x80
__mutex_lock+0x59/0xa00
? lock_acquire+0xa3/0x1f0
? lock_acquire+0xa3/0x1f0
? hci_uart_write_work+0xd3/0x160 [hci_uart]
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
bcm_dequeue+0x21/0xc0 [hci_uart]
hci_uart_write_work+0xe6/0x160 [hci_uart]
process_one_work+0x253/0x6a0
worker_thread+0x4d/0x3b0
kthread+0x133/0x150
We can't replace the mutex in hci_bcm, because there are other calls
there that might sleep. Therefore this replaces the rwlock's in
hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
approach anyway as it reduces the restrictions on the proto callbacks.
Also, because acquiring write-lock is very rare compared to acquiring
the read-lock, the percpu variant of rw_semaphore is used.
Lastly, because hci_uart_tx_wakeup() may be called from an IRQ context,
we can't block (sleep) while trying acquire the read lock there, so we
use the trylock variant.
Signed-off-by: Ronald Tschalär
Cc: Lukas Wunner
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: Dean Jenkins
---
Changes in v2:
- Add back locking in hci_uart_tx_wakeup(). Removing the locking
altogether there was wrong, as nicely pointed out by Dean Jenkins.
drivers/bluetooth/hci_ldisc.c | 38 ++
drivers/bluetooth/hci_uart.h | 2 +-
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index eec95019f15c..31def781a562 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -115,12 +115,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
struct sk_buff *skb = hu->tx_skb;
if (!skb) {
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
skb = hu->proto->dequeue(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
} else {
hu->tx_skb = NULL;
}
@@ -130,7 +130,14 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- read_lock(>proto_lock);
+ /* This may be called in an IRQ context, so we can't sleep. Therefore
+* we try to acquire the lock only, and if that fails we assume the
+* tty is being closed because that is the only time the write lock is
+* acquired. If, however, at some point in the future the write lock
+* is also acquired in other situations, then this must be revisited.
+*/
+ if (!percpu_down_read_trylock(>proto_lock))
+ return 0;
if (!test_bit(HCI_UART_PROTO_READY, >flags))
goto no_schedule;
@@ -145,7 +152,7 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
schedule_work(>write_work);
no_schedule:
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return 0;
}
@@ -247,12 +254,12 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
hu->proto->flush(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return 0;
}
@@ -275,15 +282,15 @@ static int hci_uart_send_frame(struct hci_dev *hdev,
struct sk_buff *skb)
BT_DB
[PATCH] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc:
Use rwlocking to avoid closing proto races") introduced locks in
hci_ldisc that are held while calling the proto functions. These locks
are rwlock's, and hence do not allow sleeping while they are held.
However, the proto functions that hci_bcm registers use mutexes and
hence need to be able to sleep.
In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
acquire the rwlock, after which they call proto->recv() and
proto->dequeue(), respectively. In the case of hci_bcm these point to
bcm_recv() and bcm_dequeue(). The latter both acquire the
bcm_device_lock, which is a mutex, so doing so results in a call to
might_sleep(). But since we're holding a rwlock in hci_ldisc, that
results in the following BUG (this for the dequeue case - a similar
one for the receive case is omitted for brevity):
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
INFO: lockdep is turned off.
CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: GW OE 4.13.2+ #17
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
Workqueue: events hci_uart_write_work [hci_uart]
Call Trace:
dump_stack+0x8e/0xd6
___might_sleep+0x164/0x250
__might_sleep+0x4a/0x80
__mutex_lock+0x59/0xa00
? lock_acquire+0xa3/0x1f0
? lock_acquire+0xa3/0x1f0
? hci_uart_write_work+0xd3/0x160 [hci_uart]
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
bcm_dequeue+0x21/0xc0 [hci_uart]
hci_uart_write_work+0xe6/0x160 [hci_uart]
process_one_work+0x253/0x6a0
worker_thread+0x4d/0x3b0
kthread+0x133/0x150
We can't replace the mutex in hci_bcm, because there are other calls
there that might sleep. Therefore this replaces the rwlock's in
hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
approach anyway as it reduces the restrictions on the proto callbacks.
Also, because acquiring write-lock is very rare compared to acquiring
the read-lock, the percpu variant of rw_semaphore is used.
Lastly, the read-lock in the hci_uart_tx_wakeup() callback now needed
to be removed because that function is called from an IRQ context. But
since it doesn't actually call any proto functions, instead just
queueing the work, and the other operations are atomic bit operations,
this is ok.
Signed-off-by: Ronald Tschalär <ron...@innovation.ch>
Cc: Lukas Wunner <lu...@wunner.de>
Cc: Marcel Holtmann <mar...@holtmann.org>
Cc: Gustavo Padovan <gust...@padovan.org>
Cc: Johan Hedberg <johan.hedb...@gmail.com>
Cc: Dean Jenkins <dean_jenk...@mentor.com>
---
drivers/bluetooth/hci_ldisc.c | 31 +--
drivers/bluetooth/hci_uart.h | 2 +-
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index eec95019f15c..08bcb1239aa0 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -115,12 +115,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
struct sk_buff *skb = hu->tx_skb;
if (!skb) {
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
skb = hu->proto->dequeue(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
} else {
hu->tx_skb = NULL;
}
@@ -130,8 +130,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- read_lock(>proto_lock);
-
if (!test_bit(HCI_UART_PROTO_READY, >flags))
goto no_schedule;
@@ -145,8 +143,6 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
schedule_work(>write_work);
no_schedule:
- read_unlock(>proto_lock);
-
return 0;
}
EXPORT_SYMBOL_GPL(hci_uart_tx_wakeup);
@@ -247,12 +243,12 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
hu->proto->flush(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return 0;
}
@@ -275,15 +271,15 @@ static int hci_uart_send_frame(struct hci_dev *hdev,
struct sk_buff *skb)
BT_DBG("%s: type %d len %d", hdev->name, hci_skb_pkt_type(skb),
skb->len);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
[PATCH] Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.
Commit dec2c92880cc5435381d50e3045ef018a762a917 ("Bluetooth: hci_ldisc:
Use rwlocking to avoid closing proto races") introduced locks in
hci_ldisc that are held while calling the proto functions. These locks
are rwlock's, and hence do not allow sleeping while they are held.
However, the proto functions that hci_bcm registers use mutexes and
hence need to be able to sleep.
In more detail: hci_uart_tty_receive() and hci_uart_dequeue() both
acquire the rwlock, after which they call proto->recv() and
proto->dequeue(), respectively. In the case of hci_bcm these point to
bcm_recv() and bcm_dequeue(). The latter both acquire the
bcm_device_lock, which is a mutex, so doing so results in a call to
might_sleep(). But since we're holding a rwlock in hci_ldisc, that
results in the following BUG (this for the dequeue case - a similar
one for the receive case is omitted for brevity):
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
in_atomic(): 1, irqs_disabled(): 0, pid: 7303, name: kworker/7:3
INFO: lockdep is turned off.
CPU: 7 PID: 7303 Comm: kworker/7:3 Tainted: GW OE 4.13.2+ #17
Hardware name: Apple Inc. MacBookPro13,3/Mac-A5C67F76ED83108C, BIOS MBP133.8
Workqueue: events hci_uart_write_work [hci_uart]
Call Trace:
dump_stack+0x8e/0xd6
___might_sleep+0x164/0x250
__might_sleep+0x4a/0x80
__mutex_lock+0x59/0xa00
? lock_acquire+0xa3/0x1f0
? lock_acquire+0xa3/0x1f0
? hci_uart_write_work+0xd3/0x160 [hci_uart]
mutex_lock_nested+0x1b/0x20
? mutex_lock_nested+0x1b/0x20
bcm_dequeue+0x21/0xc0 [hci_uart]
hci_uart_write_work+0xe6/0x160 [hci_uart]
process_one_work+0x253/0x6a0
worker_thread+0x4d/0x3b0
kthread+0x133/0x150
We can't replace the mutex in hci_bcm, because there are other calls
there that might sleep. Therefore this replaces the rwlock's in
hci_ldisc with rw_semaphore's (which allow sleeping). This is a safer
approach anyway as it reduces the restrictions on the proto callbacks.
Also, because acquiring write-lock is very rare compared to acquiring
the read-lock, the percpu variant of rw_semaphore is used.
Lastly, the read-lock in the hci_uart_tx_wakeup() callback now needed
to be removed because that function is called from an IRQ context. But
since it doesn't actually call any proto functions, instead just
queueing the work, and the other operations are atomic bit operations,
this is ok.
Signed-off-by: Ronald Tschalär
Cc: Lukas Wunner
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: Dean Jenkins
---
drivers/bluetooth/hci_ldisc.c | 31 +--
drivers/bluetooth/hci_uart.h | 2 +-
2 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index eec95019f15c..08bcb1239aa0 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -115,12 +115,12 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
struct sk_buff *skb = hu->tx_skb;
if (!skb) {
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
skb = hu->proto->dequeue(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
} else {
hu->tx_skb = NULL;
}
@@ -130,8 +130,6 @@ static inline struct sk_buff *hci_uart_dequeue(struct
hci_uart *hu)
int hci_uart_tx_wakeup(struct hci_uart *hu)
{
- read_lock(>proto_lock);
-
if (!test_bit(HCI_UART_PROTO_READY, >flags))
goto no_schedule;
@@ -145,8 +143,6 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
schedule_work(>write_work);
no_schedule:
- read_unlock(>proto_lock);
-
return 0;
}
EXPORT_SYMBOL_GPL(hci_uart_tx_wakeup);
@@ -247,12 +243,12 @@ static int hci_uart_flush(struct hci_dev *hdev)
tty_ldisc_flush(tty);
tty_driver_flush_buffer(tty);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (test_bit(HCI_UART_PROTO_READY, >flags))
hu->proto->flush(hu);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return 0;
}
@@ -275,15 +271,15 @@ static int hci_uart_send_frame(struct hci_dev *hdev,
struct sk_buff *skb)
BT_DBG("%s: type %d len %d", hdev->name, hci_skb_pkt_type(skb),
skb->len);
- read_lock(>proto_lock);
+ percpu_down_read(>proto_lock);
if (!test_bit(HCI_UART_PROTO_READY, >flags)) {
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
return -EUNATCH;
}
hu->proto->enqueue(hu, skb);
- read_unlock(>proto_lock);
+ percpu_up_read(>proto_lock);
hci_uart_
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
On 19.12.2014 14:51, Luis Henriques wrote: Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl Acked-by: Alexandre Belloni Acked-by: Boris Brezillon Acked-by: Nicolas Ferre Cc: Felipe Balbi Cc: # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper "stable" tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f "usb: gadget: at91_udc: move prepare clk into process context") is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 "usb: gadget: at91_udc: prepare clk before calling enable"). Is there any reason for not applying it in these trees? Not to forget 3.14 (LTS) which was the branch where I primarily found the issue... - ron -- Ronald Wahl - ronald.w...@raritan.com - Phone +49 375271349-0 Fax -99 Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749 Amtsgericht Chemnitz HRB 23605 Geschäftsführung: Stuart Hopper, Ralf Ploenes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] usb: gadget: at91_udc: move prepare clk into process context
On 19.12.2014 14:51, Luis Henriques wrote: Hi Felipe, On Thu, Nov 20, 2014 at 01:50:49PM -0600, Felipe Balbi wrote: On Wed, Nov 19, 2014 at 04:37:27PM +0100, Nicolas Ferre wrote: From: Ronald Wahl ronald.w...@raritan.com Commit 7628083227b6bc4a7e33d7c381d7a4e558424b6b (usb: gadget: at91_udc: prepare clk before calling enable) added clock preparation in interrupt context. This is not allowed as it might sleep. Also setting the clock rate is unsafe to call from there for the same reason. Move clock preparation and setting clock rate into process context (at91udc_probe). Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Alexandre Belloni alexandre.bell...@free-electrons.com Acked-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Cc: Felipe Balbi ba...@ti.com Cc: sta...@vger.kernel.org # v3.17+ --- Hi Felipe, I forgot to answer you on this patch. So I resend it now with the proper stable tag. You can also queue it during this -rc phase if you feel it is still possible. I think it's late for v3.18, so it'll go on v3.19 and get backported to 3.17 and 3.18. Sorry :-s Although this commit (b2ba27a5c56f usb: gadget: at91_udc: move prepare clk into process context) is tagged for stable v3.17+, it seems like it could be applied to earlier kernels. 3.16, 3.13 and 3.12 seem to be affected by the same issue (and they all include commit 7628083227b6 usb: gadget: at91_udc: prepare clk before calling enable). Is there any reason for not applying it in these trees? Not to forget 3.14 (LTS) which was the branch where I primarily found the issue... - ron -- Ronald Wahl - ronald.w...@raritan.com - Phone +49 375271349-0 Fax -99 Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749 Amtsgericht Chemnitz HRB 23605 Geschäftsführung: Stuart Hopper, Ralf Ploenes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Create directories for external firmware
>> 2014-07-08 14:47 GMT+02:00 Michal Marek :
>>
>>> Commit 5180d5f4 ("firmware: Simplify directory creation") broke
>>> including firmware specified in CONFIG_EXTRA_FIRMWARE:
>>>
>>> MK_FW firmware/amd-ucode/microcode_amd.bin.gen.S
>>> /bin/sh: firmware/amd-ucode/microcode_amd.bin.gen.S: No such file or
>>> directory
>>> ...
>>> firmware/Makefile:185: recipe for target
>>> 'firmware/amd-ucode/microcode_amd.bin.gen.S' failed
>>>
>>> It works with O= builds, because the directory is created by
>>> Makefile.build. Create the directory in firmware/Makefile in non-O
>>> builds.
>>>
>>> Reported-by: Ronald
>>> Reported-by: Torsten Kaiser
>>> Signed-off-by: Michal Marek
>>> ---
>>>
>>> Can you try this patch?
>>>
>>> Ronald, can you tell me your full name for the Reported-by: line?
>>>
>>> Thanks.
>>> ---
>>>
>>> firmware/Makefile | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/firmware/Makefile b/firmware/Makefile
>>> index 5747417..0862d34 100644
>>> --- a/firmware/Makefile
>>> +++ b/firmware/Makefile
>>> @@ -219,6 +219,12 @@ $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep)
>>> obj-y += $(patsubst %,%.gen.o,
>>> $(fw-external-y))
>>> obj-$(CONFIG_FIRMWARE_IN_KERNEL) += $(patsubst %,%.gen.o,
>>> $(fw-shipped-y))
>>>
>>> +ifeq ($(KBUILD_SRC),)
>>> +# Makefile.build only creates subdirectories for O= builds, but external
>>> +# firmware might live outside the kernel source tree
>>> +_dummy := $(foreach d,$(addprefix $(obj)/,$(dir $(fw-external-y))),
>>> $(shell [ -d $(d) ] || mkdir -p $(d)))
>>> +endif
>>> +
>>> # Remove .S files and binaries created from ihex
>>> # (during 'make clean' .config isn't included so they're all in
>>> $(fw-shipped-))
>>> targets := $(fw-shipped-) $(patsubst $(obj)/%,%, \
>>> --
>>> 1.8.4.5
I can confirm that this patch on top of current HEAD fixes the issue.
Thanks a ton!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Create directories for external firmware
2014-07-08 17:18 GMT+02:00 Ronald :
> My full name is 'Ronald Uitermark'.
>
> I will try this patch tonight.
>
>
> 2014-07-08 14:47 GMT+02:00 Michal Marek :
>
>> Commit 5180d5f4 ("firmware: Simplify directory creation") broke
>> including firmware specified in CONFIG_EXTRA_FIRMWARE:
>>
>> MK_FW firmware/amd-ucode/microcode_amd.bin.gen.S
>> /bin/sh: firmware/amd-ucode/microcode_amd.bin.gen.S: No such file or
>> directory
>> ...
>> firmware/Makefile:185: recipe for target
>> 'firmware/amd-ucode/microcode_amd.bin.gen.S' failed
>>
>> It works with O= builds, because the directory is created by
>> Makefile.build. Create the directory in firmware/Makefile in non-O
>> builds.
>>
>> Reported-by: Ronald
>> Reported-by: Torsten Kaiser
>> Signed-off-by: Michal Marek
>> ---
>>
>> Can you try this patch?
>>
>> Ronald, can you tell me your full name for the Reported-by: line?
>>
>> Thanks.
>> ---
>>
>> firmware/Makefile | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/firmware/Makefile b/firmware/Makefile
>> index 5747417..0862d34 100644
>> --- a/firmware/Makefile
>> +++ b/firmware/Makefile
>> @@ -219,6 +219,12 @@ $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep)
>> obj-y += $(patsubst %,%.gen.o,
>> $(fw-external-y))
>> obj-$(CONFIG_FIRMWARE_IN_KERNEL) += $(patsubst %,%.gen.o,
>> $(fw-shipped-y))
>>
>> +ifeq ($(KBUILD_SRC),)
>> +# Makefile.build only creates subdirectories for O= builds, but external
>> +# firmware might live outside the kernel source tree
>> +_dummy := $(foreach d,$(addprefix $(obj)/,$(dir $(fw-external-y))),
>> $(shell [ -d $(d) ] || mkdir -p $(d)))
>> +endif
>> +
>> # Remove .S files and binaries created from ihex
>> # (during 'make clean' .config isn't included so they're all in
>> $(fw-shipped-))
>> targets := $(fw-shipped-) $(patsubst $(obj)/%,%, \
>> --
>> 1.8.4.5
>>
>
(resend for flat text mode, sorry for the dupe which included top posting)
My full name is 'Ronald Uitermark'.
I will try this patch tonight.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Create directories for external firmware
2014-07-08 17:18 GMT+02:00 Ronald ronald...@gmail.com: My full name is 'Ronald Uitermark'. I will try this patch tonight. 2014-07-08 14:47 GMT+02:00 Michal Marek mma...@suse.cz: Commit 5180d5f4 (firmware: Simplify directory creation) broke including firmware specified in CONFIG_EXTRA_FIRMWARE: MK_FW firmware/amd-ucode/microcode_amd.bin.gen.S /bin/sh: firmware/amd-ucode/microcode_amd.bin.gen.S: No such file or directory ... firmware/Makefile:185: recipe for target 'firmware/amd-ucode/microcode_amd.bin.gen.S' failed It works with O= builds, because the directory is created by Makefile.build. Create the directory in firmware/Makefile in non-O builds. Reported-by: Ronald ronald...@gmail.com Reported-by: Torsten Kaiser just.for.l...@googlemail.com Signed-off-by: Michal Marek mma...@suse.cz --- Can you try this patch? Ronald, can you tell me your full name for the Reported-by: line? Thanks. --- firmware/Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/firmware/Makefile b/firmware/Makefile index 5747417..0862d34 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -219,6 +219,12 @@ $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep) obj-y += $(patsubst %,%.gen.o, $(fw-external-y)) obj-$(CONFIG_FIRMWARE_IN_KERNEL) += $(patsubst %,%.gen.o, $(fw-shipped-y)) +ifeq ($(KBUILD_SRC),) +# Makefile.build only creates subdirectories for O= builds, but external +# firmware might live outside the kernel source tree +_dummy := $(foreach d,$(addprefix $(obj)/,$(dir $(fw-external-y))), $(shell [ -d $(d) ] || mkdir -p $(d))) +endif + # Remove .S files and binaries created from ihex # (during 'make clean' .config isn't included so they're all in $(fw-shipped-)) targets := $(fw-shipped-) $(patsubst $(obj)/%,%, \ -- 1.8.4.5 (resend for flat text mode, sorry for the dupe which included top posting) My full name is 'Ronald Uitermark'. I will try this patch tonight. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Create directories for external firmware
2014-07-08 14:47 GMT+02:00 Michal Marek mma...@suse.cz: Commit 5180d5f4 (firmware: Simplify directory creation) broke including firmware specified in CONFIG_EXTRA_FIRMWARE: MK_FW firmware/amd-ucode/microcode_amd.bin.gen.S /bin/sh: firmware/amd-ucode/microcode_amd.bin.gen.S: No such file or directory ... firmware/Makefile:185: recipe for target 'firmware/amd-ucode/microcode_amd.bin.gen.S' failed It works with O= builds, because the directory is created by Makefile.build. Create the directory in firmware/Makefile in non-O builds. Reported-by: Ronald ronald...@gmail.com Reported-by: Torsten Kaiser just.for.l...@googlemail.com Signed-off-by: Michal Marek mma...@suse.cz --- Can you try this patch? Ronald, can you tell me your full name for the Reported-by: line? Thanks. --- firmware/Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/firmware/Makefile b/firmware/Makefile index 5747417..0862d34 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -219,6 +219,12 @@ $(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep) obj-y += $(patsubst %,%.gen.o, $(fw-external-y)) obj-$(CONFIG_FIRMWARE_IN_KERNEL) += $(patsubst %,%.gen.o, $(fw-shipped-y)) +ifeq ($(KBUILD_SRC),) +# Makefile.build only creates subdirectories for O= builds, but external +# firmware might live outside the kernel source tree +_dummy := $(foreach d,$(addprefix $(obj)/,$(dir $(fw-external-y))), $(shell [ -d $(d) ] || mkdir -p $(d))) +endif + # Remove .S files and binaries created from ihex # (during 'make clean' .config isn't included so they're all in $(fw-shipped-)) targets := $(fw-shipped-) $(patsubst $(obj)/%,%, \ -- 1.8.4.5 I can confirm that this patch on top of current HEAD fixes the issue. Thanks a ton! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: firmware: Simplify directory creation + b43 = fails to build
>From my .config ==> cat /usr/src/config | grep -i b43 CONFIG_EXTRA_FIRMWARE="b43/ucode5.fw b43/b0g0initvals5.fw b43/b0g0bsinitvals5.fw b43/pcm5.fw" ... snip ... 2014-06-18 16:33 GMT+02:00 Michal Marek : > Dne 18.6.2014 10:46, Ronald napsal(a): >> Dear kernel developers, >> >> Latest git HEAD (from Torvalds): >> >> CC drivers/base/firmware_class.o >> LD drivers/base/built-in.o >> MK_FW firmware/b43/ucode5.fw.gen.S >> /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet >> (file or directory does not exist, it should not have the .gen.S >> suffix) >> /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet >> ... snip ... >> /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet >> firmware/Makefile:185: recept voor doel 'firmware/b43/ucode5.fw.gen.S' >> is mislukt >> make[1]: *** [firmware/b43/ucode5.fw.gen.S] Fout 1 >> Makefile:893: recept voor doel 'firmware' is mislukt >> make: *** [firmware] Fout 2 >> make: *** Wachten op onvoltooide taken... > > Where does firmware/b43 come from? > > Thanks, > Michal > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: firmware: Simplify directory creation + b43 = fails to build
Dear kernel developers, Latest git HEAD (from Torvalds): CC drivers/base/firmware_class.o LD drivers/base/built-in.o MK_FW firmware/b43/ucode5.fw.gen.S /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet (file or directory does not exist, it should not have the .gen.S suffix) /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet ... snip ... /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet firmware/Makefile:185: recept voor doel 'firmware/b43/ucode5.fw.gen.S' is mislukt make[1]: *** [firmware/b43/ucode5.fw.gen.S] Fout 1 Makefile:893: recept voor doel 'firmware' is mislukt make: *** [firmware] Fout 2 make: *** Wachten op onvoltooide taken... ==> git revert 5180d5f [bleed 55a169f] Revert "firmware: Simplify directory creation" 2 files changed, 38 insertions(+), 16 deletions(-) 09:57 ronald@Charlie /usr/src/linux :) ==> time make -j2 ... snip ... LD drivers/base/built-in.o MKDIR firmware/b43/ MK_FW firmware/b43/ucode5.fw.gen.S MK_FW firmware/b43/b0g0initvals5.fw.gen.S MK_FW firmware/b43/b0g0bsinitvals5.fw.gen.S MK_FW firmware/b43/pcm5.fw.gen.S AS firmware/b43/ucode5.fw.gen.o AS firmware/b43/b0g0initvals5.fw.gen.o AS firmware/b43/b0g0bsinitvals5.fw.gen.o AS firmware/b43/pcm5.fw.gen.o LD firmware/built-in.o If you require more info, please let me know. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Regression: firmware: Simplify directory creation + b43 = fails to build
Dear kernel developers, Latest git HEAD (from Torvalds): CC drivers/base/firmware_class.o LD drivers/base/built-in.o MK_FW firmware/b43/ucode5.fw.gen.S /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet (file or directory does not exist, it should not have the .gen.S suffix) /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet ... snip ... /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet firmware/Makefile:185: recept voor doel 'firmware/b43/ucode5.fw.gen.S' is mislukt make[1]: *** [firmware/b43/ucode5.fw.gen.S] Fout 1 Makefile:893: recept voor doel 'firmware' is mislukt make: *** [firmware] Fout 2 make: *** Wachten op onvoltooide taken... == git revert 5180d5f [bleed 55a169f] Revert firmware: Simplify directory creation 2 files changed, 38 insertions(+), 16 deletions(-) 09:57 ronald@Charlie /usr/src/linux :) == time make -j2 ... snip ... LD drivers/base/built-in.o MKDIR firmware/b43/ MK_FW firmware/b43/ucode5.fw.gen.S MK_FW firmware/b43/b0g0initvals5.fw.gen.S MK_FW firmware/b43/b0g0bsinitvals5.fw.gen.S MK_FW firmware/b43/pcm5.fw.gen.S AS firmware/b43/ucode5.fw.gen.o AS firmware/b43/b0g0initvals5.fw.gen.o AS firmware/b43/b0g0bsinitvals5.fw.gen.o AS firmware/b43/pcm5.fw.gen.o LD firmware/built-in.o If you require more info, please let me know. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: firmware: Simplify directory creation + b43 = fails to build
From my .config == cat /usr/src/config | grep -i b43 CONFIG_EXTRA_FIRMWARE=b43/ucode5.fw b43/b0g0initvals5.fw b43/b0g0bsinitvals5.fw b43/pcm5.fw ... snip ... 2014-06-18 16:33 GMT+02:00 Michal Marek mma...@suse.cz: Dne 18.6.2014 10:46, Ronald napsal(a): Dear kernel developers, Latest git HEAD (from Torvalds): CC drivers/base/firmware_class.o LD drivers/base/built-in.o MK_FW firmware/b43/ucode5.fw.gen.S /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet (file or directory does not exist, it should not have the .gen.S suffix) /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet ... snip ... /bin/sh: firmware/b43/ucode5.fw.gen.S: Bestand of map bestaat niet firmware/Makefile:185: recept voor doel 'firmware/b43/ucode5.fw.gen.S' is mislukt make[1]: *** [firmware/b43/ucode5.fw.gen.S] Fout 1 Makefile:893: recept voor doel 'firmware' is mislukt make: *** [firmware] Fout 2 make: *** Wachten op onvoltooide taken... Where does firmware/b43 come from? Thanks, Michal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
This could be a coincidence, but I had a disk data corruption in /var
(LVM). Most other partitions are read-only during normal operation. So
I can safely keep testing this kernel. Just mentioning this, in case
you see this happening with other ppl testing this patch as well.
2013/9/30 Rafael J. Wysocki :
> On Monday, September 30, 2013 07:45:54 AM Ronald wrote:
>> Yes, works as well. Just survived twe cycles with s2disk. I'm
>> surprised someone else did not report this earlier btw... Because it
>> looks pretty generic (i.e. not specific to a 64bit UP system).
>
> It is a generic bug, actually. Well, this means the user space driven
> hibernation doesn't receive much testing coverage these days ...
>
> I'll resend the patch with a proper changelog and then push it for v3.12-rc4.
>
> Thanks,
> Rafael
>
>
>> 2013/9/30 Rafael J. Wysocki :
>> > On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
>> >> Attached patch fixes the issue. Both methods function as they did
>> >> before. Thanks for the superfast fix!
>> >
>> > You're welcome, it's not the final one, however.
>> >
>> > Can you please test the one below and report back?
>> >
>> > Rafael
>> >
>> >
>> > ---
>> > kernel/power/snapshot.c |5 -
>> > kernel/power/user.c |8
>> > 2 files changed, 12 insertions(+), 1 deletion(-)
>> >
>> > Index: linux-pm/kernel/power/snapshot.c
>> > ===
>> > --- linux-pm.orig/kernel/power/snapshot.c
>> > +++ linux-pm/kernel/power/snapshot.c
>> > @@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
>> > struct memory_bitmap *bm1, *bm2;
>> > int error = 0;
>> >
>> > - BUG_ON(forbidden_pages_map || free_pages_map);
>> > + if (forbidden_pages_map && free_pages_map)
>> > + return 0;
>> > + else
>> > + BUG_ON(forbidden_pages_map || free_pages_map);
>> >
>> > bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
>> > if (!bm1)
>> > Index: linux-pm/kernel/power/user.c
>> > ===
>> > --- linux-pm.orig/kernel/power/user.c
>> > +++ linux-pm/kernel/power/user.c
>> > @@ -39,6 +39,7 @@ static struct snapshot_data {
>> > char frozen;
>> > char ready;
>> > char platform_support;
>> > + bool free_bitmaps;
>> > } snapshot_state;
>> >
>> > atomic_t snapshot_device_available = ATOMIC_INIT(1);
>> > @@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
>> > data->swap = -1;
>> > data->mode = O_WRONLY;
>> > error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
>> > + if (!error) {
>> > + error = create_basic_memory_bitmaps();
>> > + data->free_bitmaps = !error;
>> > + }
>> > if (error)
>> > pm_notifier_call_chain(PM_POST_RESTORE);
>> > }
>> > @@ -111,6 +116,8 @@ static int snapshot_release(struct inode
>> > pm_restore_gfp_mask();
>> > free_basic_memory_bitmaps();
>> > thaw_processes();
>> > + } else if (data->free_bitmaps) {
>> > + free_basic_memory_bitmaps();
>> > }
>> > pm_notifier_call_chain(data->mode == O_RDONLY ?
>> > PM_POST_HIBERNATION : PM_POST_RESTORE);
>> > @@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
>> > break;
>> > pm_restore_gfp_mask();
>> > free_basic_memory_bitmaps();
>> > + data->free_bitmaps = false;
>> > thaw_processes();
>> > data->frozen = 0;
>> > break;
>> >
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
This could be a coincidence, but I had a disk data corruption in /var
(LVM). Most other partitions are read-only during normal operation. So
I can safely keep testing this kernel. Just mentioning this, in case
you see this happening with other ppl testing this patch as well.
2013/9/30 Rafael J. Wysocki r...@rjwysocki.net:
On Monday, September 30, 2013 07:45:54 AM Ronald wrote:
Yes, works as well. Just survived twe cycles with s2disk. I'm
surprised someone else did not report this earlier btw... Because it
looks pretty generic (i.e. not specific to a 64bit UP system).
It is a generic bug, actually. Well, this means the user space driven
hibernation doesn't receive much testing coverage these days ...
I'll resend the patch with a proper changelog and then push it for v3.12-rc4.
Thanks,
Rafael
2013/9/30 Rafael J. Wysocki r...@rjwysocki.net:
On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
Attached patch fixes the issue. Both methods function as they did
before. Thanks for the superfast fix!
You're welcome, it's not the final one, however.
Can you please test the one below and report back?
Rafael
---
kernel/power/snapshot.c |5 -
kernel/power/user.c |8
2 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-pm/kernel/power/snapshot.c
===
--- linux-pm.orig/kernel/power/snapshot.c
+++ linux-pm/kernel/power/snapshot.c
@@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
struct memory_bitmap *bm1, *bm2;
int error = 0;
- BUG_ON(forbidden_pages_map || free_pages_map);
+ if (forbidden_pages_map free_pages_map)
+ return 0;
+ else
+ BUG_ON(forbidden_pages_map || free_pages_map);
bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
if (!bm1)
Index: linux-pm/kernel/power/user.c
===
--- linux-pm.orig/kernel/power/user.c
+++ linux-pm/kernel/power/user.c
@@ -39,6 +39,7 @@ static struct snapshot_data {
char frozen;
char ready;
char platform_support;
+ bool free_bitmaps;
} snapshot_state;
atomic_t snapshot_device_available = ATOMIC_INIT(1);
@@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
data-swap = -1;
data-mode = O_WRONLY;
error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
+ if (!error) {
+ error = create_basic_memory_bitmaps();
+ data-free_bitmaps = !error;
+ }
if (error)
pm_notifier_call_chain(PM_POST_RESTORE);
}
@@ -111,6 +116,8 @@ static int snapshot_release(struct inode
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
thaw_processes();
+ } else if (data-free_bitmaps) {
+ free_basic_memory_bitmaps();
}
pm_notifier_call_chain(data-mode == O_RDONLY ?
PM_POST_HIBERNATION : PM_POST_RESTORE);
@@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
break;
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
+ data-free_bitmaps = false;
thaw_processes();
data-frozen = 0;
break;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
Yes, works as well. Just survived twe cycles with s2disk. I'm
surprised someone else did not report this earlier btw... Because it
looks pretty generic (i.e. not specific to a 64bit UP system).
Thanks again!
2013/9/30 Rafael J. Wysocki :
> On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
>> Attached patch fixes the issue. Both methods function as they did
>> before. Thanks for the superfast fix!
>
> You're welcome, it's not the final one, however.
>
> Can you please test the one below and report back?
>
> Rafael
>
>
> ---
> kernel/power/snapshot.c |5 -
> kernel/power/user.c |8
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> Index: linux-pm/kernel/power/snapshot.c
> ===
> --- linux-pm.orig/kernel/power/snapshot.c
> +++ linux-pm/kernel/power/snapshot.c
> @@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
> struct memory_bitmap *bm1, *bm2;
> int error = 0;
>
> - BUG_ON(forbidden_pages_map || free_pages_map);
> + if (forbidden_pages_map && free_pages_map)
> + return 0;
> + else
> + BUG_ON(forbidden_pages_map || free_pages_map);
>
> bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
> if (!bm1)
> Index: linux-pm/kernel/power/user.c
> ===
> --- linux-pm.orig/kernel/power/user.c
> +++ linux-pm/kernel/power/user.c
> @@ -39,6 +39,7 @@ static struct snapshot_data {
> char frozen;
> char ready;
> char platform_support;
> + bool free_bitmaps;
> } snapshot_state;
>
> atomic_t snapshot_device_available = ATOMIC_INIT(1);
> @@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
> data->swap = -1;
> data->mode = O_WRONLY;
> error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
> + if (!error) {
> + error = create_basic_memory_bitmaps();
> + data->free_bitmaps = !error;
> + }
> if (error)
> pm_notifier_call_chain(PM_POST_RESTORE);
> }
> @@ -111,6 +116,8 @@ static int snapshot_release(struct inode
> pm_restore_gfp_mask();
> free_basic_memory_bitmaps();
> thaw_processes();
> + } else if (data->free_bitmaps) {
> + free_basic_memory_bitmaps();
> }
> pm_notifier_call_chain(data->mode == O_RDONLY ?
> PM_POST_HIBERNATION : PM_POST_RESTORE);
> @@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
> break;
> pm_restore_gfp_mask();
> free_basic_memory_bitmaps();
> + data->free_bitmaps = false;
> thaw_processes();
> data->frozen = 0;
> break;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
Attached patch fixes the issue. Both methods function as they did before. Thanks for the superfast fix! 2013/9/29 Rafael J. Wysocki : > On Saturday, September 28, 2013 08:18:18 PM Ronald wrote: >> [ resend, forgot to disable HTML (sorry!) ] >> >> Dear kernel developers, >> >> Commit 8fd37a4c9 (PM / hibernate: Create memory bitmaps after freezing >> user space) causes resume to fail. >> >> Only, when using the s2disk utility (through pm-hibernate). >> >> Not when I do: >> >> echo -n "disk" > /sys/power/state >> >> Reverting the commit did not work. >> >> I am using a encrypted LUKS partition with a temporary key that is >> functioning as the swap device used for the suspend image. >> >> Awaiting further orders > > I'm traveling now, so I can't really test things, but I think I know what the > problem is. > > Can you please check if the appended patch makes any difference for you? > > Rafael > > > --- > kernel/power/snapshot.c |5 - > kernel/power/user.c |5 + > 2 files changed, 9 insertions(+), 1 deletion(-) > > Index: linux-pm/kernel/power/snapshot.c > === > --- linux-pm.orig/kernel/power/snapshot.c > +++ linux-pm/kernel/power/snapshot.c > @@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void) > struct memory_bitmap *bm1, *bm2; > int error = 0; > > - BUG_ON(forbidden_pages_map || free_pages_map); > + if (forbidden_pages_map && free_pages_map) > + return 0; > + else > + BUG_ON(forbidden_pages_map || free_pages_map); > > bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL); > if (!bm1) > Index: linux-pm/kernel/power/user.c > === > --- linux-pm.orig/kernel/power/user.c > +++ linux-pm/kernel/power/user.c > @@ -82,6 +82,9 @@ static int snapshot_open(struct inode *i > data->swap = -1; > data->mode = O_WRONLY; > error = pm_notifier_call_chain(PM_RESTORE_PREPARE); > + if (!error) > + error = create_basic_memory_bitmaps(); > + > if (error) > pm_notifier_call_chain(PM_POST_RESTORE); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
Attached patch fixes the issue. Both methods function as they did before. Thanks for the superfast fix! 2013/9/29 Rafael J. Wysocki r...@rjwysocki.net: On Saturday, September 28, 2013 08:18:18 PM Ronald wrote: [ resend, forgot to disable HTML (sorry!) ] Dear kernel developers, Commit 8fd37a4c9 (PM / hibernate: Create memory bitmaps after freezing user space) causes resume to fail. Only, when using the s2disk utility (through pm-hibernate). Not when I do: echo -n disk /sys/power/state Reverting the commit did not work. I am using a encrypted LUKS partition with a temporary key that is functioning as the swap device used for the suspend image. Awaiting further orders I'm traveling now, so I can't really test things, but I think I know what the problem is. Can you please check if the appended patch makes any difference for you? Rafael --- kernel/power/snapshot.c |5 - kernel/power/user.c |5 + 2 files changed, 9 insertions(+), 1 deletion(-) Index: linux-pm/kernel/power/snapshot.c === --- linux-pm.orig/kernel/power/snapshot.c +++ linux-pm/kernel/power/snapshot.c @@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void) struct memory_bitmap *bm1, *bm2; int error = 0; - BUG_ON(forbidden_pages_map || free_pages_map); + if (forbidden_pages_map free_pages_map) + return 0; + else + BUG_ON(forbidden_pages_map || free_pages_map); bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL); if (!bm1) Index: linux-pm/kernel/power/user.c === --- linux-pm.orig/kernel/power/user.c +++ linux-pm/kernel/power/user.c @@ -82,6 +82,9 @@ static int snapshot_open(struct inode *i data-swap = -1; data-mode = O_WRONLY; error = pm_notifier_call_chain(PM_RESTORE_PREPARE); + if (!error) + error = create_basic_memory_bitmaps(); + if (error) pm_notifier_call_chain(PM_POST_RESTORE); } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
Yes, works as well. Just survived twe cycles with s2disk. I'm
surprised someone else did not report this earlier btw... Because it
looks pretty generic (i.e. not specific to a 64bit UP system).
Thanks again!
2013/9/30 Rafael J. Wysocki r...@rjwysocki.net:
On Sunday, September 29, 2013 09:22:45 AM Ronald wrote:
Attached patch fixes the issue. Both methods function as they did
before. Thanks for the superfast fix!
You're welcome, it's not the final one, however.
Can you please test the one below and report back?
Rafael
---
kernel/power/snapshot.c |5 -
kernel/power/user.c |8
2 files changed, 12 insertions(+), 1 deletion(-)
Index: linux-pm/kernel/power/snapshot.c
===
--- linux-pm.orig/kernel/power/snapshot.c
+++ linux-pm/kernel/power/snapshot.c
@@ -743,7 +743,10 @@ int create_basic_memory_bitmaps(void)
struct memory_bitmap *bm1, *bm2;
int error = 0;
- BUG_ON(forbidden_pages_map || free_pages_map);
+ if (forbidden_pages_map free_pages_map)
+ return 0;
+ else
+ BUG_ON(forbidden_pages_map || free_pages_map);
bm1 = kzalloc(sizeof(struct memory_bitmap), GFP_KERNEL);
if (!bm1)
Index: linux-pm/kernel/power/user.c
===
--- linux-pm.orig/kernel/power/user.c
+++ linux-pm/kernel/power/user.c
@@ -39,6 +39,7 @@ static struct snapshot_data {
char frozen;
char ready;
char platform_support;
+ bool free_bitmaps;
} snapshot_state;
atomic_t snapshot_device_available = ATOMIC_INIT(1);
@@ -82,6 +83,10 @@ static int snapshot_open(struct inode *i
data-swap = -1;
data-mode = O_WRONLY;
error = pm_notifier_call_chain(PM_RESTORE_PREPARE);
+ if (!error) {
+ error = create_basic_memory_bitmaps();
+ data-free_bitmaps = !error;
+ }
if (error)
pm_notifier_call_chain(PM_POST_RESTORE);
}
@@ -111,6 +116,8 @@ static int snapshot_release(struct inode
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
thaw_processes();
+ } else if (data-free_bitmaps) {
+ free_basic_memory_bitmaps();
}
pm_notifier_call_chain(data-mode == O_RDONLY ?
PM_POST_HIBERNATION : PM_POST_RESTORE);
@@ -231,6 +238,7 @@ static long snapshot_ioctl(struct file *
break;
pm_restore_gfp_mask();
free_basic_memory_bitmaps();
+ data-free_bitmaps = false;
thaw_processes();
data-frozen = 0;
break;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
[ resend, forgot to disable HTML (sorry!) ]
Dear kernel developers,
Commit 8fd37a4c9 (PM / hibernate: Create memory bitmaps after freezing
user space) causes resume to fail.
Only, when using the s2disk utility (through pm-hibernate).
Not when I do:
echo -n "disk" > /sys/power/state
Reverting the commit did not work.
I am using a encrypted LUKS partition with a temporary key that is
functioning as the swap device used for the suspend image.
Awaiting further orders
Ronald
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: [v3.12-rc1] [regression] PM / hibernate: Create memory bitmaps after freezing user space
[ resend, forgot to disable HTML (sorry!) ] Dear kernel developers, Commit 8fd37a4c9 (PM / hibernate: Create memory bitmaps after freezing user space) causes resume to fail. Only, when using the s2disk utility (through pm-hibernate). Not when I do: echo -n disk /sys/power/state Reverting the commit did not work. I am using a encrypted LUKS partition with a temporary key that is functioning as the swap device used for the suspend image. Awaiting further orders Ronald -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
On 20.06.2013 17:00, Marc Kleine-Budde wrote: Hello Thomas, On 04/25/2013 04:53 PM, Marc Kleine-Budde wrote: On 04/25/2013 04:21 PM, Thomas Gleixner wrote: On Tue, 23 Apr 2013, Marc Kleine-Budde wrote: The commit 77cc982 clocksource: use clockevents_config_and_register() where possible switches from manually calculating min_delta_ns (and others) and clockevents_register_device() to automatic calculation via clockevents_config_and_register(). During this conversation the "+ 1" in min_delta_ns = clockevent_delta2ns(1, ) + 1; was lost. This leads to problems with schedule_delayed_work() with a delay of "1". Resulting in the work not scheduled in time. Errm. How is schedule_delayed_work() related to this? I also stumbled over this issue now after upgrading from 3.4.57 to 3.10.10. Even sleep() is unreliable - sleeping for 2 seconds often sleeps just more than 3 seconds. The now lost +1 has actually been added in 2007 to solve a rounding issue: http://permalink.gmane.org/gmane.linux.kernel/549744 So I think this should either be fixed by always rounding up in clockevent_delta2ns() or by adding +1 to the min_delta_ns in the clockevents_config_and_register() function. Dunno if rounding up will cause problems with the max_delta_ns as it might be too big then so probably the second approach is better. Opinions? - ron -- Ronald Wahl - ronald.w...@raritan.com - Phone +49 375271349-0 Fax -99 Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749 Amtsgericht Chemnitz HRB 23605 Geschäftsführung: Stuart Hopper, Ralf Ploenes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: [PATCH] clocksource: tcb: fix min_delta calculation
On 20.06.2013 17:00, Marc Kleine-Budde wrote: Hello Thomas, On 04/25/2013 04:53 PM, Marc Kleine-Budde wrote: On 04/25/2013 04:21 PM, Thomas Gleixner wrote: On Tue, 23 Apr 2013, Marc Kleine-Budde wrote: The commit 77cc982 clocksource: use clockevents_config_and_register() where possible switches from manually calculating min_delta_ns (and others) and clockevents_register_device() to automatic calculation via clockevents_config_and_register(). During this conversation the + 1 in min_delta_ns = clockevent_delta2ns(1, clkevt.clkevt) + 1; was lost. This leads to problems with schedule_delayed_work() with a delay of 1. Resulting in the work not scheduled in time. Errm. How is schedule_delayed_work() related to this? I also stumbled over this issue now after upgrading from 3.4.57 to 3.10.10. Even sleep() is unreliable - sleeping for 2 seconds often sleeps just more than 3 seconds. The now lost +1 has actually been added in 2007 to solve a rounding issue: http://permalink.gmane.org/gmane.linux.kernel/549744 So I think this should either be fixed by always rounding up in clockevent_delta2ns() or by adding +1 to the min_delta_ns in the clockevents_config_and_register() function. Dunno if rounding up will cause problems with the max_delta_ns as it might be too big then so probably the second approach is better. Opinions? - ron -- Ronald Wahl - ronald.w...@raritan.com - Phone +49 375271349-0 Fax -99 Raritan Deutschland GmbH, Kornmarkt 7, 08056 Zwickau, Germany USt-IdNr. DE813094160, Steuer-Nr. 227/117/01749 Amtsgericht Chemnitz HRB 23605 Geschäftsführung: Stuart Hopper, Ralf Ploenes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression
In reply to [1]: I have the same issue. Git bisect took 50+ rebuilds xD Smartd does not work anymore since 84a9a8cd9 ([libata] Set proper SK when CK_COND is set.). I hope I'm not stepping on anyone's toe's by chosing the same title. I'm not subscribed to this list. Just wanted to add a 'me2' [1] http://www.spinics.net/lists/linux-ide/msg45268.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ata: HDIO_DRIVE_* ioctl() Linux 3.9 regression
In reply to [1]: I have the same issue. Git bisect took 50+ rebuilds xD Smartd does not work anymore since 84a9a8cd9 ([libata] Set proper SK when CK_COND is set.). I hope I'm not stepping on anyone's toe's by chosing the same title. I'm not subscribed to this list. Just wanted to add a 'me2' [1] http://www.spinics.net/lists/linux-ide/msg45268.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] drivers/media/video/zoran_card.c: en/decoder loading
Hi, On Jan 27, 2008 1:01 PM, Martin Samuelsson <[EMAIL PROTECTED]> wrote: > This enables the avs6eyes to load the bt866 and ks0127 drivers automatically. > > Signed-off-by: Martin Samuelsson <[EMAIL PROTECTED]> > --- > zoran_card.c |6 ++ > 1 file changed, 6 insertions(+) > --- linux-2.6.24-ori/drivers/media/video/zoran_card.c 2008-01-24 > 23:58:37.0 +0100 > +++ linux-2.6.24-sam/drivers/media/video/zoran_card.c 2008-01-27 > 17:16:51.0 +0100 > @@ -366,6 +366,12 @@ i2cid_to_modulename (u16 i2c_id) >case I2C_DRIVERID_MSE3000: >name = "mse3000"; >break;*/ > + case I2C_DRIVERID_BT866: > + name = "bt866"; > + break; > + case I2C_DRIVERID_KS0127: > + name = "ks0127"; > + break; >default: >break; >} (For upstream people who will apply the patch in mainstream kernel:) ack from maintainer. Ronald (and sorry to Martin for getting this msg twice.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] drivers/media/video/zoran_card.c: en/decoder loading
Hi, On Jan 27, 2008 1:01 PM, Martin Samuelsson [EMAIL PROTECTED] wrote: This enables the avs6eyes to load the bt866 and ks0127 drivers automatically. Signed-off-by: Martin Samuelsson [EMAIL PROTECTED] --- zoran_card.c |6 ++ 1 file changed, 6 insertions(+) --- linux-2.6.24-ori/drivers/media/video/zoran_card.c 2008-01-24 23:58:37.0 +0100 +++ linux-2.6.24-sam/drivers/media/video/zoran_card.c 2008-01-27 17:16:51.0 +0100 @@ -366,6 +366,12 @@ i2cid_to_modulename (u16 i2c_id) case I2C_DRIVERID_MSE3000: name = mse3000; break;*/ + case I2C_DRIVERID_BT866: + name = bt866; + break; + case I2C_DRIVERID_KS0127: + name = ks0127; + break; default: break; } (For upstream people who will apply the patch in mainstream kernel:) ack from maintainer. Ronald (and sorry to Martin for getting this msg twice.) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question Regarding The Radeon Framebuffer
I'm quite new to the lists, so I hope I placed my question correctly... I want to know if my Ati Radeon X700 Pro (REV410) is supported with the current radeonfb framebuffer driver. I recompiled the kernel a lot, but with no succes... lspci -v 01:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] Secondary Subsystem: PC Partner Limited Unknown device 0621 Flags: fast devsel Memory at d101 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 01:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] (prog-if 00 [VGA]) Subsystem: PC Partner Limited Unknown device 0620 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d100 (64-bit, non-prefetchable) [size=64K] I/O ports at a000 [size=256] Expansion ROM at d000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [100] Advanced Error Reporting Thanks in advance - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question Regarding The Radeon Framebuffer
I'm quite new to the lists, so I hope I placed my question correctly... I want to know if my Ati Radeon X700 Pro (REV410) is supported with the current radeonfb framebuffer driver. I recompiled the kernel a lot, but with no succes... lspci -v 01:00.1 Display controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] Secondary Subsystem: PC Partner Limited Unknown device 0621 Flags: fast devsel Memory at d101 (64-bit, non-prefetchable) [disabled] [size=64K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 01:00.0 VGA compatible controller: ATI Technologies Inc RV410 [Radeon X700 Pro (PCIE)] (prog-if 00 [VGA]) Subsystem: PC Partner Limited Unknown device 0620 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d100 (64-bit, non-prefetchable) [size=64K] I/O ports at a000 [size=256] Expansion ROM at d000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [58] Express Endpoint IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [100] Advanced Error Reporting Thanks in advance - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
On Thu, 28 Jul 2005, Christoph Hellwig wrote: > Couldn't the two other transports be implemented ontop of this one using > a mount helper doing the pipe or tcp setup? that's how we did it in the version we did for 2.4. I don't see why not. ron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] Re: [PATCH 2.6.13-rc3-mm2] v9fs: add fd based transport
On Thu, 28 Jul 2005, Christoph Hellwig wrote: Couldn't the two other transports be implemented ontop of this one using a mount helper doing the pipe or tcp setup? that's how we did it in the version we did for 2.4. I don't see why not. ron - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: NUMA support for dual core Opteron
On Fri, 15 Jul 2005, Andi Kleen wrote: > Only on uniprocessor machines. Question for the AMD guys: is there a chance of getting non-proprietary-bios ACPI tables from AMD directly? I.e. ACPI tables as needed for power-now etc. could be released under GPL, making inclusion into linuxbios a bit simpler. Right now, the only ACPI table's I've seen all bear "IF I COPY THIS PLEASE SUE ME UNDER THE DMCA" notices :-) If such tables are available, and I'm just out of touch, I'd be very happy to hear that; please send me a URL. It makes no sense at all to me that ACPI would be copyright anyone, since they merely describe hardware, and even the OS guys might want to copy them around from node to node in some cases. But that's the problem right now. ron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [discuss] Re: NUMA support for dual core Opteron
On Fri, 15 Jul 2005, Andi Kleen wrote: Only on uniprocessor machines. Question for the AMD guys: is there a chance of getting non-proprietary-bios ACPI tables from AMD directly? I.e. ACPI tables as needed for power-now etc. could be released under GPL, making inclusion into linuxbios a bit simpler. Right now, the only ACPI table's I've seen all bear IF I COPY THIS PLEASE SUE ME UNDER THE DMCA notices :-) If such tables are available, and I'm just out of touch, I'd be very happy to hear that; please send me a URL. It makes no sense at all to me that ACPI would be copyright anyone, since they merely describe hardware, and even the OS guys might want to copy them around from node to node in some cases. But that's the problem right now. ron - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NUMA support for dual core Opteron
if there is any chance of getting along without ACPI entries that is best. Linux did do this once already, for SMP K8: K8 can boot and run NUMA without an SRAT table. What more is needed for dual core, and could Linux support in this area be extended? ron - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
