From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 30A0B37266D for ; Fri, 17 Apr 2026 13:11:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776431489; cv=none; b=c++LPYQ9A0DWQTASbfngyfevyCLstxMXi8toyNxaAA2+Rv0xZBCqCH/mlu0cV2szJvo8gCeBaENusgKVdsoarM6/XD71gtXmKBcH9N1CT/vk+3MiJGRxQ5nu8qzuEneIv+WKAC/6Jl1NaNw3+pT3xeMrpZeFYikIJdfB/FjFH7E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776431489; c=relaxed/simple; bh=gRLZDYjP8rAyYDu/dxhxXrW55dQHWBhhz4Mp7s9yll4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=HdoBGLNam/ubF4rWwKqM7Shh19VxFT/CHKXQg387bDK/wtN+H8MEes5JnYQMo9jz5Fjycf5HglXHZDwKFORaBYY17AWagGh9oqFtTjkcFk1H6VLYc8vkmYzuXY/KRvWnWfgwbT4XFjDHc3RLniJDHOmju4czoBoZNB3ovIZe3hg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b=VvArZr1y; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20251104.gappssmtp.com header.i=@baylibre-com.20251104.gappssmtp.com header.b="VvArZr1y" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-43d70b3e159so338686f8f.0 for ; Fri, 17 Apr 2026 06:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20251104.gappssmtp.com; s=20251104; t=1776431484; x=1777036284; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=KCc9El91v2tJeTyCQTpkqW7vYe/zKOnr7R5NXhlhOxk=; b=VvArZr1y+esjXP9Fkt1hwUdDRTxtksIGaH9R6ylZc+w3tKLPxsKo4koXmB3ViLSx7J pDgMuL5mdZGpicySRMr4Rtc7gEjES2CCcEENqzVf20iUq/gK8GJhG6q0uYR1yslK+gMC norEuIU8GkMmsZLGvKtJE1IxuckNnapfE6FiZqnpphtszWJUzRgLpQPBWGUk/spJxm+K bpyGeGSuLjPDhwfGajRuUT0rtRkzILhja3fO4Tl8kXzMnsGugCV3IExsETfD4pd3Ik+T CVS8oV4b6aLRUoTRoDmHS7+/X7yKUdRPv3gGC9lTk9/hCS0uVZVF2uRF5v5OWtRefNw8 KfUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776431484; x=1777036284; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=KCc9El91v2tJeTyCQTpkqW7vYe/zKOnr7R5NXhlhOxk=; b=sYLA4M2r+yVnp9eb4aoDGLqVsG2xuUzkKyepmC6P+ji5huaNlmL66QGAvGMBcpcHuo iYJuyGQiS/LMgzdCDI7L2gwYSCn+JWnsDJTrdTD4gkhJUYs4P8XtkHAlPvAN4INukStn A/wQGsOOe9QAr/0qQVSeKNBezhQcke9xeYIRmMyINznMGNt1MW3GU9UW80OvX5aw+B8Y 2SnJwHYlVczxE9W+mKxD3C2ofQeBouwuFP41gQqoiveoihjQbwFGs0T7KRuSR8dVFkC/ X29cP/ehzcJ3bVfRj7N0pThFJ+D6QT98DKdFxgfL16GWzCC7bVsvrWocZ9yxDD86YvK+ iVIQ== X-Forwarded-Encrypted: i=1; AFNElJ+QhbutJVVbQ+d8jhaymPrBylQKfFOEbg+JujyzEVI0t7n0s8wkYhnnRI7BQSICGvFrAXEdKv2SwPNvcQGypPc=@vger.kernel.org X-Gm-Message-State: AOJu0YwcHsa8+1DxLGEJwBR56tib0Own1CrFiK4z4/axUs4INY/m+t5m 690tMm+Ro2c1Lo7PpCcQIPNuSKOJPMj5lXDohOHpmjs2POdHTw477FCkvslGCnVwM/c= X-Gm-Gg: AeBDietXgTX61ncHXsRYN1AaFEIto1Xuxn4BpHbo71wWdm7qLw24F1qG1tlwwn8g5xR 9r3puaF4/Lxw3kUsbvPvxQnJbIDDLqD2kbDTyVUIHyjBa5/Ve86rMIx+f/4Be+8FwJ5Qek6AOGA RC6bSqdeQviPjN17FtKaNAbGA7Rc1w4+s/SRR01rMMeTzEf2XgN+/g+gpzV0D1DEnLi4ci1HhGE bP1jUT+6mDjCZSvRT/AVVBq6K2Z4UFDpIC69ZJJmnlj6PCqpL9lZ2vrgnxzR3sARNuXf5mmihv0 062SFAVMXE3Lhu4Ds7Q8CCNe6QW+YZuwNAvk1i38dwe4csEycHl68KNCbBW1oQ70Ye9H5AokY9m Vk9ImL/E7GyXjffGL2/8bxjCUEZbEkT0+IXJAZjqZnoQTMWHWOMgtksEtMzsGm1deAnBQPUo4Tp fVP2ba2QQEXnaadEu2l0CbXjnK2DQ1xJ1sf0jXsjgVB+gY2g0mOXSE5VR162gfdWc939RHoeJKD ExjtvivAJM8Ma29hmEBYJ/a X-Received: by 2002:a05:6000:2005:b0:43d:77a8:3ba7 with SMTP id ffacd0b85a97d-43fe3e12484mr4104740f8f.44.1776431484359; Fri, 17 Apr 2026 06:11:24 -0700 (PDT) Received: from localhost (p200300f65f20eb08db61cfc60d8aa232.dip0.t-ipconnect.de. [2003:f6:5f20:eb08:db61:cfc6:d8a:a232]) by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-43fe4e3a7b4sm4356620f8f.22.2026.04.17.06.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Apr 2026 06:11:23 -0700 (PDT) From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig=20=28The=20Capable=20Hub=29?= To: Ulf Hansson Cc: "Christian A. Ehrhardt" , linux-mmc@vger.kernel.org, Greg Kroah-Hartman , Wolfram Sang , linux-kernel@vger.kernel.org, Marcel Holtmann , Luiz Augusto von Dentz , linux-bluetooth@vger.kernel.org, Matthias Brugger , AngeloGioacchino Del Regno , linux-mediatek@lists.infradead.org, Ping-Ke Shih , linux-wireless@vger.kernel.org, Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Brian Norris , Francesco Dolcini , Andy Shevchenko Subject: [PATCH v1 0/6] sdio: About pointers in sdio_device_id::driver_data Date: Fri, 17 Apr 2026 15:10:46 +0200 Message-ID: X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: linux-bluetooth@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Developer-Signature: v=1; a=openpgp-sha256; l=3816; i=u.kleine-koenig@baylibre.com; h=from:subject:message-id; bh=gRLZDYjP8rAyYDu/dxhxXrW55dQHWBhhz4Mp7s9yll4=; b=owEBbQGS/pANAwAKAY+A+1h9Ev5OAcsmYgBp4jFWdaRCcbA6UCRSVtfbncEwOSti40CoPsvF+ vdIuFxTidWJATMEAAEKAB0WIQQ/gaxpOnoeWYmt/tOPgPtYfRL+TgUCaeIxVgAKCRCPgPtYfRL+ Ts32B/9u8msCou5BwhNaY0DlL45F+7qpQKpSsQuRk2gI42hvAESq9kyeVN/MZWif44tjir6LK2z uIl/GDbOQMK01aikDbfuVOtkDDghRBSTEB7Jka+OjfPnDumnNigRsaaBGNvsAFjIJkLhEy6qJDP Tn8woM7fN22cukUBpxin+S+kcXgM00Q8TjTUzEfguVA/yR/5l3z2E6JOyddLE7skD3BcWZth7gw bSohFR1HxMGAwUA7mKVNzLdYdPXW7y8rKtYwlVFZUsZmtrNFbfl9Br+UBebFAMyx3Rll6Um30xM RwO7mqAqqwH8Ox2CRHpiyR61s3V9bmt+/v2tLxnaw2vhp3PI X-Developer-Key: i=u.kleine-koenig@baylibre.com; a=openpgp; fpr=0D2511F322BFAB1C1580266BE2DCDD9132669BD6 Content-Transfer-Encoding: 8bit contains several device_id structs for various device types. Most of them have one of: - kernel_ulong_t driver_data (sometimes called "driver_info") - unsigned long driver_data - const void *data (sometimes called "driver_data" or "context", sometimes not const) Taking sdio_device_id as an arbitrary[1] example (which has kernel_ulong_t driver_data), there are drivers that store integer values in it (e.g. drivers/media/mmc/siano/smssdio.c) and others use pointers (e.g. drivers/net/wireless/realtek/rtw88/rtw8723ds.c). The latter involves explicit casting, both for initialisation and for usage. In the past I tried to address this using i2c as discussion case[2]. Back then the motivation was just to get rid of the ugly casts. Today I'm working on CHERI which is an architecture extension (currently for arm and riscv) that uses 128 bit pointers to store additional information, implementing e.g. read-only pointers and preventing out of bounds access on the hardware level. The complication here is that a kernel_ulong_t (which is still 64 bit with CHERI) cannot store a pointer. The obvious way to fix that is to replace the kernel_ulong_t by an anonymous union that contains the original unsigned long and a pointer. This doesn't change the size (or layout) of the device id struct for archs where sizeof(long) >= sizeof(void *) [3] and gets rid of the casting. On CHERI archs this is an ABI change, but as a new architecture changing ABI isn't an issue there. I was surprised that changing struct sdio_device_id didn't require preparation in the various drivers as they all already use named initializers. So the first patch expands struct sdio_device_id and the 5 following patches implement cleanups that can be done then. Patches 2 to 6 all depend on the first patch (only). This is not urgent and thus merge window material. I guess merging of this series has to happen in 3 steps: 1) patch #1 via mmc 2) patches #2 and #3 via bluetooth 3) patches #4 - #6 via wireless (where 2) and 3) are independent). The series was build tested on arm64. [1] well, one that isn't used as much as spi_device_id or i2c_device_id to have get a manageable POC. [2] https://lore.kernel.org/lkml/20240426213832.915485-2-u.kleine-koenig@pengutronix.de [3] As of now this is true on all architectures running Linux even with s/>=/==/ Uwe Kleine-König (The Capable Hub) (6): sdio: Add syntactic sugar to store a pointer in sdio_driver_id Bluetooth: btmrvl_sdio: Make use of driver data pointer in sdio_device_id Bluetooth: btmtksdio: Make use of driver data pointer in sdio_device_id wifi: rtw88: Benefit from sdio_device_id::driver_data_ptr wifi: mt76: mt7921-sdio: Make use of driver data pointer in sdio_device_id wifi: mwifiex: Make use of driver data pointer in sdio_device_id drivers/bluetooth/btmrvl_sdio.c | 22 ++++++++--------- drivers/bluetooth/btmtksdio.c | 8 +++---- drivers/net/wireless/marvell/mwifiex/sdio.c | 24 +++++++++---------- .../net/wireless/mediatek/mt76/mt7921/sdio.c | 4 ++-- drivers/net/wireless/mediatek/mt76/mt792x.h | 2 +- .../net/wireless/mediatek/mt76/mt792x_core.c | 2 +- .../net/wireless/realtek/rtw88/rtw8723cs.c | 2 +- .../net/wireless/realtek/rtw88/rtw8723ds.c | 4 ++-- .../net/wireless/realtek/rtw88/rtw8821cs.c | 2 +- .../net/wireless/realtek/rtw88/rtw8822bs.c | 2 +- .../net/wireless/realtek/rtw88/rtw8822cs.c | 2 +- drivers/net/wireless/realtek/rtw88/sdio.c | 2 +- include/linux/mod_devicetable.h | 5 +++- 13 files changed, 42 insertions(+), 39 deletions(-) base-commit: 028ef9c96e96197026887c0f092424679298aae8 -- 2.47.3