From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 C66C13783AE for ; Sat, 14 Mar 2026 13:24:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773494683; cv=none; b=AJ2LEwm/Kbqwos24y6Y1FZ4EARWWtpLLHxVwcefyyVsi6nLHLN7/73YWeYYYHXlimECz4p7+yICq0dajy/h3dLROL4zQnoymfYRwZxZ9OnQN95h0XvWUjtRLzQt0WPbQhfmCmderp25let9jUFR5n3N6DZCa2Kckw7b568WLcPY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773494683; c=relaxed/simple; bh=pDh0iEx46jMmrLE1oovTz9VyKt8aN4TLMUcZAAJgaaU=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ltV5OpkRaWDyBURCKlChj5z05M7nPvgV4jeHQiGPB4vDJVGNcPYncOJd46LGdXcg6bGV5e6hDAAFIMdiMOYz7dHT1irijKSThF4aV6SqXGtZhjhWy5RY5fD4U4U/XCL/mK3d5n5g0TDSK3XBokbGKuwwOUUQ5v3MnoqVjs3Dp7Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=L/LnnH27; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="L/LnnH27" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-439b50320a0so2663208f8f.1 for ; Sat, 14 Mar 2026 06:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1773494679; x=1774099479; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=HELqxrOQ/OwUFnReaSfuYgQk+nnNmP4iYE5u5YV1ltw=; b=L/LnnH27pMxgKSit445WYEXzEa4v/cRUXoQQsgvvz0QEavNgSpJoURxVMUnpERnglt ga8Y9NYU5ew7ryGIo3+My9ilTVOFg43zYpsRQk5gDJWTTA7h5ZNF3CBtT7ihLxA1rGvq ZWBeILYuRjH0ts1rIn66O2umNZVdsGylCpXzq/7HqxPGCQWBuRg0tdXJsCM7qr92WYy4 8MQpUcFk6OIMpak7LUHU39/we4GjYFHwK1G/01C2eHbej1jFb94w44JR35eyombDsPdF TwPQIsVue15Qlx7bzulEIrmI4VYhakGWlQCNsktX5oKmbMJchwS9Yc2Cgd1HNNh79X4s hkrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773494679; x=1774099479; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HELqxrOQ/OwUFnReaSfuYgQk+nnNmP4iYE5u5YV1ltw=; b=X/l/cUoEellAmVwmmDCYxaYdt+jXw+0ZFoftPQ53WaWnGKjA4960KdxUqVYwLHY4E/ w3gd2w7ilVhCJs5uY9i+tMM3WJokFtCo7gGlh9MbUUa1tPDcm3uyaLasqJB1ahdfHbIF 8rIjj9bLEzre46E3rjLxWJFiz1vBDRqC1C+mJjxDYI+j/iyL+y9Z+ifVEZHyaa1vXpNR 1Go8Hu99M1SudChPS8bzmZYR2l3oluGkdZPJX/y0eeAen3fTxRUFFU6Wxt1YUptQgjqG Bk3t9D93aaycV7PdPB3oksdJdCByRfaFVGLra/mnmyKgR5y8Zr9tD9g/VovItdLmM2Wg vT0Q== X-Forwarded-Encrypted: i=1; AJvYcCWG1+m/ICw6Udyz66pxzU8uJB/xZNeTO3H1cN2uUMuAEKaW8EbxUjTQhyDsiGidUT/eM+nd420YTxPTtNHnMQ==@vger.kernel.org X-Gm-Message-State: AOJu0YyIigabucgEc9GXT56L9NXbTE0VoUwVaiQ+Yo8ELwGubHC8OXwY pp96pxSw8QjVPcZfhT5Juq53MGPQWWX4G8AIXRUyRX0Mx5BHHl52ptBgFdz3Ei2nqLj1dLx85cP PIDu/RenRKg9FReO2Ag== X-Received: from wrxk10.prod.google.com ([2002:a05:6000:4a:b0:439:d5c0:336d]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a5d:64a2:0:b0:43a:4e0:1774 with SMTP id ffacd0b85a97d-43a04e01813mr8786099f8f.16.1773494678748; Sat, 14 Mar 2026 06:24:38 -0700 (PDT) Date: Sat, 14 Mar 2026 13:24:37 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260313-rust_serdev-v3-0-c9a3af214f7f@posteo.de> <20260313-rust_serdev-v3-2-c9a3af214f7f@posteo.de> <2026031402-absence-graph-af5d@gregkh> <2026031422-shaded-matchbook-5078@gregkh> Message-ID: Subject: Re: [PATCH v3 2/4] serdev: add rust private data to serdev_device From: Alice Ryhl To: Markus Probst Cc: Greg Kroah-Hartman , Rob Herring , Jiri Slaby , Miguel Ojeda , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , Kari Argillander , "Rafael J. Wysocki" , Viresh Kumar , Boqun Feng , David Airlie , Simona Vetter , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-pm@vger.kernel.org, driver-core@lists.linux.dev, dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="utf-8" On Sat, Mar 14, 2026 at 12:08:09PM +0000, Markus Probst wrote: > On Sat, 2026-03-14 at 12:52 +0100, Greg Kroah-Hartman wrote: > > On Sat, Mar 14, 2026 at 11:42:02AM +0000, Markus Probst wrote: > > > On Sat, 2026-03-14 at 09:07 +0100, Greg Kroah-Hartman wrote: > > > > On Fri, Mar 13, 2026 at 06:12:31PM +0000, Markus Probst wrote: > > > > > Add rust private data to `struct serdev_device`, as it is required by the > > > > > rust abstraction added in the following commit > > > > > (rust: add basic serial device bus abstractions). > > > > > > > > why is rust "special" here? What's wrong with the existing private > > > > pointer in this structure? Why must we add another one? > > > Because in rust, the device drvdata will be set after probe has run. In > > > serdev, once the device has been opened, it can receive data. It must > > > be opened either inside probe or before probe, because it can only be > > > configured (baudrate, flow control etc.) and data written to after it > > > has been opened. Because it can receive data before drvdata has been > > > set yet, we need to ensure it waits on data receival for the probe to > > > be finished. Otherwise this would be a null pointer dereference. To do > > > this, we need to store a `Completion` for it to wait and a `bool` in > > > case the probe exits with an error. We cannot store this data in the > > > device drvdata, because this is where the drivers drvdata goes. We also > > > cannot create a wrapper of the drivers drvdata, because > > > `Device::drvdata::()` would always fail in that case. That is why we > > > need a "rust_private_data" for this abstraction to store the > > > `Completion` and `bool`. > > > > So why is this any different from any other bus type? I don't see the > > "uniqueness" here that has not required this to happen for PCI or USB or > > anything else. > > > > What am I missing? > In Short: > In serdev, we have to handle incoming device data (serdev calls on a > function pointer we provide in advance), even in the case that the > driver hasn't completed probe yet. Why can the function pointers be called during probe? Alice