From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0058237C106 for ; Mon, 3 Aug 2026 05:17:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785734234; cv=none; b=YHqtDj0vSF1f6mNkm2T99N1QM3zZDgQZnIh61kIICNPRBF4Ed4bQ64HAZFIrPv8c5GG8LRN2FbmcTqosMMnl56KcM0GqDKywYnD64cY5KdBR2cR2uKGvwisMji21YhwsCe+lkH7sgcURZ9dYJmnjB8c4iAqMqKXjsfGusxRRnNY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785734234; c=relaxed/simple; bh=KmL2sbnHKLahsnko/p7IL/HAXoGfUFNYPlNNLbso7Xo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=d/DX/nFFhJ8GSMMZZHiSFDtim7x8Gq4UcaogCIAixu79tCBmuEh+Y0fQa+fWpDpatWD1W4k+dsrqR9BrRNcBsP+4PVjgC3Bcy6rEN8R7n3t2ZLaQ0NTwEJk5iVFl6HGgqsmAORype3KXB17FhTlwZRC3ZSYPGw1vhC/2S7MXRdE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=psvhIjBH; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="psvhIjBH" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-92edb12cdf2so181837685a.3 for ; Sun, 02 Aug 2026 22:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785734232; x=1786339032; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=4k0ugYvWzxtiO//veve6HLDZsW72yaJjTh1QvzWOQdk=; b=psvhIjBHdX2GlggxYuOa1Q0S/3N8PkcQnoXVPxr2HwgLno4UNWDVv2odoMKqFrYQfx EyeUzYmiZRg7HHDXdyCntEI4lZXxnV7Sf8clmr4OJMirfHf2vtkvYt8WlxIz6IazvlnL emDsR6W/l8uaxQomEdvXF07sjoGhhe2C8pJ6SNZIkw+wgtmRBq408Dhx60JdvIHa0oEO iD8tjmw+cavSebg9qchyFhB41UhUhngfmIqGRqNLO92BdF8YPdD3f4Jog2EhpP5i9Hqk pvqRJ+qMjJVbmEbrXH+DqYBb7xqRgdJi2vgGBTu3jorx2LNdurZ2r0zJdZUqLtEKjuy2 9vHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785734232; x=1786339032; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=4k0ugYvWzxtiO//veve6HLDZsW72yaJjTh1QvzWOQdk=; b=ZnD54uHEU2NfDDNqBLDp/GPu8izag+GQs0rXpSzJoIl2tRY/iEKHZII3PCESYhCa8i S8eyzMGZkCM40UGxJ0Ph9ATv7mIIegPcZZqkqCc0TPe8JakJM7QSlO2Wh5pdUuxumgj6 DnzmEIF9RFbZbGlf5epE1zgOtSf/iLwKnRTKV9O6UrpxB0FTbU8CMJ13xILFNN05i1FH EnezYJXi7gIE2y54pm4oBbZGfb3LkmdgFj1Oh2hbTST8bddWhWCmyDI6T1QsFR+mMNVk K9uC6yRjsw7v7x30Ie4ktSKYUDaFaFoILovgW97avpqJl40g9reHyopzEPXgza/zHoXs GArw== X-Gm-Message-State: AOJu0Yzrf/V9s0u4kf75uGmUkzCfar/j48jn3Z/44EMHYekgyUOmwF4B H9qPLbpQsQAs1cTr2MJI5gScAJ241xXnXC/K8u2a4M2BRC2Nn/pqEHsK X-Gm-Gg: AR+sD11ALv5JfyjrXIjOXtSjUdXkzFjX2psFvC+tmbd8w0WY3daj/bpPdns7EeP9smO 4A4ERL5ixXa1cYZaH8tIb2FZgV0CLKXIjVrbaJJFngs1t3flajbTvjDE36VnzdbRnvCwQ37X90Z 75GwCH/QWHV/jR8RWgyS7J+AwqOCbO2AMgfwTeMoHHVXYKJrEoSltB5oP7dYvoRcvA0G8mOYf48 1QVqbWcwyOAIg3IhqaEfO55XRRemFs26O1dlusMxzKKFtTH0zLadCZ9kjXAPzEp0aYWut2vA6je ZWNehGWKyEVq/p0aGKhyr8VN/+g7Dc8CrJwiDxAc8Vxjpdxymp+r81EN4yU4rEWo345fpy5n5lB l154CCr11/RK0ez22YJshCZiOoKv2MDysuqOVjFFH/wUB8Ea8qbF/qFQMmAUT2hUOQzP8rzcU60 FdPXRqUgyAJiPTSUCTKJMMkYHhdydGv6vMolIKNV0ZHERcaDxeF0+urkKWTbpHR/XtLFDRcIHb0 +7n//Rvlg== X-Received: by 2002:a05:620a:6506:b0:923:45bb:a95c with SMTP id af79cd13be357-934a07395d4mr1649450685a.10.1785734231869; Sun, 02 Aug 2026 22:17:11 -0700 (PDT) Received: from FairplayBox ([2601:5cf:837e:d920::f9a2]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9349c1dcee1sm585700185a.38.2026.08.02.22.17.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Aug 2026 22:17:11 -0700 (PDT) From: Alec Hall To: jikos@kernel.org, bentiss@kernel.org, linux-input@vger.kernel.org Cc: linux-kernel@vger.kernel.org, pepemontfort@gmail.com, Alec Hall Subject: Re: [PATCH 0/3] HID: Apple Magic Keyboard/Trackpad battery over Bluetooth Date: Mon, 3 Aug 2026 01:17:06 -0400 Message-ID: <20260803051707.53252-1-signshop.alec@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260714101235.99447-1-signshop.alec@gmail.com> References: <20260714101235.99447-1-signshop.alec@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Gentle ping on this series, posted three weeks ago. No rush intended -- I am mostly checking it has not fallen through a crack, and asking whether anything is wanted from me before it can be looked at. Some context that has accumulated on the list since, in case it affects how you would like to sequence things: Jose Villaseñor Montfort has three fixes in flight touching the same driver and the generic battery path. I have reviewed and tested all three on a Magic Keyboard and a Magic Trackpad 2 over both USB and Bluetooth: HID: magicmouse: prevent unbounded recursion in magicmouse_raw_event() https://lore.kernel.org/linux-input/20260715053526.574725-1-pepemontfort@gmail.com/ HID: magicmouse: avoid NULL pointer deref when there is no input device https://lore.kernel.org/linux-input/20260728184059.688513-1-pepemontfort@gmail.com/ HID: magicmouse: do not keep a stale msc->input if no input is claimed https://lore.kernel.org/linux-input/20260729041557.1185819-1-pepemontfort@gmail.com/ Patch 3/3 of this series touches the top of magicmouse_raw_event(), which the recursion fix splits into a wrapper and an inner function. Whichever lands first, the other is a one-hunk rebase; I have both applied together here and can respin this series on top of his at any point -- just say which order you would prefer, and I will send a v2 rather than leave you to resolve it. There is also a generic fix from him for the battery query path: HID: input: read battery capacity from its actual report offset https://lore.kernel.org/linux-input/20260728201309.776026-1-pepemontfort@gmail.com/ That one is complementary to this series rather than overlapping: it corrects where hidinput_query_battery_capacity() reads the capacity from, while this series changes which devices get a solicited fetch at all. Worth noting it also improves the behaviour of this series -- until the first battery report is parsed, capacity reads go through that query path, so on my trackpad the power supply reads the flags byte for about a minute after a Bluetooth reconnect before settling on the real value. Happy to send a v2 with any changes you would like. Thanks for your time. Alec