rust: i2c: fix I2cAdapter refcount double increment

When `I2cAdapter::get` executes, it first calls
`bindings::i2c_get_adapter()` which increments the device and module
reference counts. It then takes a reference to the raw pointer and
converts it to an `ARef` via `.into()`.

The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted`
unconditionally calls `T::inc_ref()`. This leads to a second increment
to the reference counts.

Since the returned `ARef` will only release a single reference when
dropped via `dec_ref()`, this leaks one device and module reference count
on every call.

This fix was suggested by sashiko.dev.

Link: https://sashiko.dev/#/patchset/20260521190937.248904-1-nico.antinori.7@gmail.com
Signed-off-by: Nicolás Antinori <nico.antinori.7@gmail.com>
Reviewed-by: Igor Korotin <igor.korotin@linux.dev>
Signed-off-by: Igor Korotin <igor.korotin@linux.dev>

Commit 47ac2a4b5cd8 ("rust: kvec: implement shrink_to for KVVec")
introduced a call to bindings::is_vmalloc_addr(). However, this
fails to compile on architectures where CONFIG_MMU is disabled,
resulting in the following build error:

    error[E0425]: cannot find function `is_vmalloc_addr` in crate `bindings`
       --> rust/kernel/alloc/kvec.rs:781:32
        |
    781 |         if !unsafe { bindings::is_vmalloc_addr(self.ptr.as_ptr().cast()) } {
        |                                ^^^^^^^^^^^^^^^ not found in `bindings`

When CONFIG_MMU is not set, is_vmalloc_addr() is defined as a
static inline function in <linux/mm.h> that unconditionally
returns false. Because bindgen skips static inline functions
when generating bindings, the symbol is completely missing from
the Rust bindings crate.

Fix this by providing a C helper wrapper, rust_helper_is_vmalloc_addr(),
in rust/helpers/vmalloc.c. This ensures the function is reliably
exposed to Rust regardless of the MMU configuration. On NOMMU builds,
this allows KVVec::shrink_to() to successfully compile and correctly
route all allocations through the kmalloc realloc path.

Fixes: 47ac2a4b5cd8 ("rust: kvec: implement shrink_to for KVVec")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202605220811.LRplxeBR-lkp@intel.com/
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20260523-is-vmalloc-addr-build-fix-v1-1-73c919440c41@zohomail.in
[ Pasted exact compiler output and expanded it. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Pull Rust fixes from Miguel Ojeda:
 "Toolchain and infrastructure:

    - Add 'bindgen' target to make UML 32-bit builds work with GCC

    - Disable two Clippy warnings ('collapsible_{if,match}')

  'pin-init' crate:

    - Fix unsoundness issue that created &'static references"

* tag 'rust-fixes-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
  rust: allow `clippy::collapsible_if` globally
  rust: allow `clippy::collapsible_match` globally
  rust: pin-init: fix incorrect accessor reference lifetime
  rust: pin-init: internal: move alignment check to `make_field_check`
  rust: arch: um: Fix building 32-bit UML with GCC

If pinned initialization of drm::Device::Data fails, it calls
drm::Device::release via drm_dev_put. This materializes a reference to
&drm::Device, but it's not fully constructed yet, because initializing
`data` failed. It should not be dropped either. Instead, if pinned
initialization fails, make sure drm::Device::release isn't called.

Fixes: 2e9fdbe5ec7a ("rust: drm: device: drop_in_place() the drm::Device in release()")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260501-fix-drm-1-v2-1-5c4f681837bc@nvidia.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

Currently, if `drm_gem_object_init` fails, the object is freed without
any cleanup. Perform the cleanup in that case.

Cc: stable@vger.kernel.org
Fixes: c284d3e42338 ("rust: drm: gem: Add GEM object abstraction")
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Link: https://patch.msgid.link/20260423-fix-gem-1-v1-1-e12e35f7bba9@nvidia.com
[ Move safety comment closer to unsafe block to avoid a clippy warning.
  - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>

When a field has been initialized, `init!`/`pin_init!` create a reference
or pinned reference to the field so it can be accessed later during the
initialization of other fields. However, the reference it created is
incorrectly `&'static` rather than just the scope of the initializer.

This means that you can do

    init!(Foo {
        a: 1,
        _: {
            let b: &'static u32 = a;
        }
    })

which is unsound.

This is caused by `&mut (*#slot).#ident`, which actually allows arbitrary
lifetime, so this is effectively `'static`. Somewhat ironically, the safety
justification of creating the accessor is.. "SAFETY: TODO".

Fix it by adding `let_binding` method on `DropGuard` to shorten lifetime.
This results in exactly what we want for these accessors. The safety and
invariant comments of `DropGuard` have been reworked; instead of reasoning
about what caller can do with the guard, express it in a way that the
ownership is transferred to the guard and `forget` takes it back, so the
unsafe operations within the `DropGuard` can be more easily justified.

Fixes: 42415d163e5d ("rust: pin-init: add references to previously initialized fields")
Cc: stable@vger.kernel.org
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260427-pin-init-fix-v3-2-496a699674dd@garyguo.net
[ Reworded for missing word. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Instead of having the reference creation serving dual-purpose as both for
let bindings and alignment check, detangle them so that the alignment check
is done explicitly in `make_field_check`. This is more robust against
refactors that may change the way let bindings are created.

Cc: stable@vger.kernel.org
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260427-pin-init-fix-v3-1-496a699674dd@garyguo.net
[ Reworded for typo. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

32-bit UML builds can be configured either by setting CONFIG_64BIT=n or
with SUBARCH=i386. Both work with Rust-for-Linux when clang is the
compiler, but when SUBARCH=i386, we don't set a bindgen target correctly if
gcc is the compiler.

Add the appropriate bindgen target configuration for i386, as is done in
Makefile.clang.

[ For reference, the errors look like:

        BINDGEN rust/bindings/bindings_generated.rs
      error: unsupported option '-mno-sse' for target ''
      ...
      error: unknown target triple 'unknown'
      panicked at .../bindgen-0.72.1/ir/context.rs:562:15:
      libclang error; possible causes include:
      ...

    - Miguel ]

Fixes: ab0f4cedc355 ("arch: um: rust: Add i386 support for Rust")
Signed-off-by: David Gow <david@davidgow.net>
Link: https://patch.msgid.link/20260425034125.53866-1-david@davidgow.net
[ Added space in title. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

ARef is defined in sync and is getting used from types causing the
build to fail.

Fix this by using ARef from sync module.

Fixes: 80df573af9ef ("rust: drm: gem: shmem: Add DRM shmem helper abstraction")
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
Link: https://patch.msgid.link/20260426094725.2188668-2-mkchauras@gmail.com
[ Add missing Fixes: tag. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>