[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250523161352.20f0589a@canb.auug.org.au>
Date: Fri, 23 May 2025 16:13:52 +1000
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: Miguel Ojeda <ojeda@...nel.org>, Dave Airlie <airlied@...hat.com>
Cc: Andreas Hindborg <a.hindborg@...nel.org>, Asahi Lina
<lina+kernel@...hilina.net>, Danilo Krummrich <dakr@...nel.org>, DRI
<dri-devel@...ts.freedesktop.org>, Linux Kernel Mailing List
<linux-kernel@...r.kernel.org>, Linux Next Mailing List
<linux-next@...r.kernel.org>, Tamir Duberstein <tamird@...il.com>
Subject: linux-next: manual merge of the rust tree with the drm tree
Hi all,
Today's linux-next merge of the rust tree got a conflict in:
rust/bindings/bindings_helper.h
between commits:
9a69570682b1 ("rust: drm: ioctl: Add DRM ioctl abstraction")
07c9016085f9 ("rust: drm: add driver abstractions")
1e4b8896c0f3 ("rust: drm: add device abstraction")
a98a73be9ee9 ("rust: drm: file: Add File abstraction")
c284d3e42338 ("rust: drm: gem: Add GEM object abstraction")
from the drm tree and commits:
210b81578efb ("rust: xarray: Add an abstraction for XArray")
8cbc95f983bc ("rust: workaround `bindgen` issue with forward references to `enum` types")
from the rust tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc rust/bindings/bindings_helper.h
index a5a6fb45d405,5532bbfd96eb..000000000000
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@@ -6,13 -6,29 +6,35 @@@
* Sorted alphabetically.
*/
+ /*
+ * First, avoid forward references to `enum` types.
+ *
+ * This workarounds a `bindgen` issue with them:
+ * <https://github.com/rust-lang/rust-bindgen/issues/3179>.
+ *
+ * Without this, the generated Rust type may be the wrong one (`i32`) or
+ * the proper one (typically `c_uint`) depending on how the headers are
+ * included, which in turn may depend on the particular kernel configuration
+ * or the architecture.
+ *
+ * The alternative would be to use casts and likely an
+ * `#[allow(clippy::unnecessary_cast)]` in the Rust source files. Instead,
+ * this approach allows us to keep the correct code in the source files and
+ * simply remove this section when the issue is fixed upstream and we bump
+ * the minimum `bindgen` version.
+ *
+ * This workaround may not be possible in some cases, depending on how the C
+ * headers are set up.
+ */
+ #include <linux/hrtimer_types.h>
+
+#include <drm/drm_device.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_file.h>
+#include <drm/drm_gem.h>
+#include <drm/drm_ioctl.h>
#include <kunit/test.h>
+#include <linux/auxiliary_bus.h>
#include <linux/blk-mq.h>
#include <linux/blk_types.h>
#include <linux/blkdev.h>
@@@ -66,4 -78,8 +89,9 @@@ const gfp_t RUST_CONST_HELPER___GFP_ZER
const gfp_t RUST_CONST_HELPER___GFP_HIGHMEM = ___GFP_HIGHMEM;
const gfp_t RUST_CONST_HELPER___GFP_NOWARN = ___GFP_NOWARN;
const blk_features_t RUST_CONST_HELPER_BLK_FEAT_ROTATIONAL = BLK_FEAT_ROTATIONAL;
+const fop_flags_t RUST_CONST_HELPER_FOP_UNSIGNED_OFFSET = FOP_UNSIGNED_OFFSET;
+
+ const xa_mark_t RUST_CONST_HELPER_XA_PRESENT = XA_PRESENT;
+
+ const gfp_t RUST_CONST_HELPER_XA_FLAGS_ALLOC = XA_FLAGS_ALLOC;
+ const gfp_t RUST_CONST_HELPER_XA_FLAGS_ALLOC1 = XA_FLAGS_ALLOC1;
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists