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 3098735FF58 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-43fe608cb92so363976f8f.2 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=E9BK4lDkpm6xsm5cyk16bitQb1LwACHi7Aru3RrRQfuDXiYvhQP0HCPBUweQfmBk+6 Y8xJ7YW/wZwZSBOKPHPvfeyWNSOPY4Ye8eMk0FXn8pZbjz5/+1IBfvz25Y4ypysWvOws ZfMEaT6zjfk6gahh3WTNOG2MC41F5v663BABUuVkXjIoZtRB3ThbT3GOCH0CqhUK/Q+g djeOYAuROA6tZ+NkgKP+7XeB71tTuGhni3ymY8MzIO5Fiz2d4ANzN3xmu8gbU+8D4hK7 4N/kkY2y2DxaOhVtt2Lr0ot44011EZPKLo4FtW0124ZQDR3HVIfVC0rlNm8mSnp4db+b HnAQ== X-Forwarded-Encrypted: i=1; AFNElJ9iZSNMZoEDG8kWWbEDp2rh4TQbBNQZJrope9qUt0UuJih/5yLJhZsXqzyoc0xS8pV6cbA+trdUvik=@vger.kernel.org X-Gm-Message-State: AOJu0YwmblPVgsduiyXol+mlxTY8c2WUVGfltnbTXcsBqYEs0a+vq01u vVQu0SUf2PjmpfYS86EbUx5fWkS0H1hjQQXOy8jiy21SAAaz5KKMtewYeCoVFcMx0zw= X-Gm-Gg: AeBDietv6KSOzbPFjgjlg3rVQtswWoqXEXYhXRdoLugpxpFRHOO7Rv9LKFoxJcTCYgI r6b8Dxkz3D4POYXV2O/7MNzyy1+E1icc+Y/W3ius42rvU9P/pffD1HBLyrg+LgDkp7xeH1HGxl7 JFxcH2P4IN/iFxB8S3ijusKk9T5UN1I5KBN0FVMrXw0u/CnLa+FDF03g7MPKxs6/sepHPq+naN8 2ZsupxKxIHc/uHNB4ec4T1nYqcQTCSL5zIImT6cQSBB9TEsIGJBEgTYbW6YXDCBGsO5iw/bfuJy rAjspb71nIieIdMdeFPmtMAQew9fcWA01YNuRK4wMvRiVmFLfR1qE+nptJdwnsIBo6Ji53V2lAK 2iLSYCtevYCmuybweq/SR7shku0z6Ufakld/JYpTwZEiH05Y7yWAx4RgrOIWhzDC/6AE0PLVZcK 3PwhEY0xJbSAZjJkUNkiv3jBi+ePYcrRYGry6V7h93tyi03y2QIx1hRRk0JvMRDYAe9Dv9JUbpx OKySoqatkcB7+LpVEM41JFo 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-mmc@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