From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f42.google.com (mail-pj2-f42.google.com [74.125.227.170]) (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 462834B8294 for ; Wed, 16 Sep 2026 16:46:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789577179; cv=none; b=jKSHRk8ubC8P/0keCOjHL64hkDIPBHkDP4NoDUqhhLYEhQBmTEj8hAcD4iVj3DDap1ul7wNQWX87BCOqHlPB9RBrmo4fxqLtNxHORbb7GnJ3DjD+ZevfP+w8Fr82xb4dgvfbwfSZRvVhox8n3FjD89PvHfavHiU37YV0EIsdDRE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789577179; c=relaxed/simple; bh=1fs5/9PJdlbuBhTs0ZxkDNW+v2WItpOPk3QzGFWOdbk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=bh9AlcQUXycwawDls4ya3aO7HiPWJBfo5lLxkoMiHmMsyGk6E85BYtxfuFlpBTimHZAUAcZ98ZDOFLyIb8CPzfdt6M+PHBB8Sk4rzvfEHgTJTc7RH031ybi1AjlrqPq63l0/bEgJAYW61AaooPCX/cWAwMhFcILkcmBrzQnE6ec= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=QMSLSCTc; arc=none smtp.client-ip=74.125.227.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QMSLSCTc" Received: by mail-pj2-f42.google.com with SMTP id 98e67ed59e1d1-39d654f02baso949122a91.3 for ; Wed, 16 Sep 2026 09:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789577171; x=1790181971; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=1fs5/9PJdlbuBhTs0ZxkDNW+v2WItpOPk3QzGFWOdbk=; b=QMSLSCTcLtJ+AiMJ6XECO+C16YHQOAZXJqddh+1hwfr5SVCU4HFWiTSJa1dhNOAfge pfYOyTxgh+G7+nYzG29DcTK0mbanmL4Ki5CnnFA1nBDvUO6vmqKWePAB+FZ5FpUy7ybf NvpmQd8hmW1D58fLfNxQ2IO4hTT5eo54DBnXZzh2iajCO69bt2cf5NtANoLSgFqyO5/A 9LEmXnDntVcj3+khqajRkChzL+EBb5PV7pHymXnMoVk6pz3eKRz4jysRegqRDLaw73Fi qXC75IwpNB6FudUN9Cqwzv40xMcW2rJfnS4fRbIUZsdSRYywhbx5SH4WUeYfZTSmmPUN 0lKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789577171; x=1790181971; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1fs5/9PJdlbuBhTs0ZxkDNW+v2WItpOPk3QzGFWOdbk=; b=yc3xyZ/9Fx0KQ1JmP5VvJExnKtMuRxC97glokDwUvPDdrdczijA97Irluc8s+FDlWl VIx+ryVs0macPkaE+uaMX0TJ9JlUg88V+2FXddqRwJJCEC5psK8bgY8qwiVzXJm4naC9 Pz1BpzEUW4frEYoLlc7rZKTMWzRhH3FSH3BhYKodd5zP3sUB5vO/1u/fAALT8OXUY+Ad L1UZX3XlgU24N4wG0JId3PkUQ891N0C4jYocJVvXXBnYlO3RfeWFChmujzSHsavU0pKl OFx33leE8xn1mjKuxUtMp683pOMQYICNg9wgauGWzNrQVbevE+X/R2STBIFhA2rz5aD9 rlyw== X-Forwarded-Encrypted: i=1; AKwUvBw9vnY+S/w5TSQy8gLi0ep8cSMbb0i9WtM7vBkLARB09tDZxqDrcBZnF9nE3tbbuOiRDSwcu9CO6xWAHu8=@vger.kernel.org X-Gm-Message-State: AFuF++kYBCOvi9o4tXqstugmHHEsL4qO+/zJUkd3gB6rL7vvM6V2LPcj jRVk9fX4h6LkYP2+jf7zopLYwFY+TrylqG8XTAAoDP+4DYAA/O42BR49 X-Gm-Gg: AYBFou21GI0kLEZn6fHp7hPjUWQppo2xAh5mg4Pypg+jxD8xc8jAoyMBmm9I7MKoEgl 3c9lBgRPXMDlmWtS6mgdPTlIDuIwKie7YjWnFioGO2kSM11s9aJtYpxyHM5T+CLsq2H4h7JO8DX NkPYg88qF/hlH6tfYiyvC18Mn5FjEJbH0/uFy3xCP09/NZ/yjofB3w1FU6MLLHRUfzFePyjbxbO LexSoVUaye6sJMd19DakmTOZFVqxC1O2emStjQVGMhjOSILzAltWZmeJCLHqrWhBx0saytoBLXK c/8ginX8C5Naoix5/OpfPqo/lrry4HwTJFUPpb4H95/QyZDNsvSj/3iVaYAQ0SbCgCYpYFnKVTn O7Oge/H7K4t0ozNHsTYYObdxxHs36Pox7EWtLwMSszHzSQl68EA5gDLmHXo+7BGgpqpA0GSnQA/ TE4iMFLmhuFy7X2+khyMrGKYVRTKywFui1HARUDpsg3Zng0JBmmgGS1jIw0ur5Vs557w== X-Received: by 2002:a17:90b:560d:b0:39b:3109:10ce with SMTP id 98e67ed59e1d1-39e1e45cbaemr7258907a91.16.1789577170531; Wed, 16 Sep 2026 09:46:10 -0700 (PDT) Received: from jm-X870 ([2001:e60:20dd:7c28:de1c:fff7:d3a4:d8c7]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-39e3617443asm292100a91.9.2026.09.16.09.46.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 09:46:09 -0700 (PDT) From: Jaemyung Lee X-Google-Original-From: Jaemyung Lee To: Bean Huo Cc: Jaemyung Lee , Andreas Hindborg , Miguel Ojeda , Boqun Feng , Gary Guo , bjorn3_gh@protonmail.com, Benno Lossin , Alice Ryhl , Trevor Gross , Danilo Krummrich , Daniel Almeida , Tamir Duberstein , Alexandre Courbot , work@onurozkan.dev, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH RFC] drivers/rufs: add Rust UFS host controller driver Date: Thu, 17 Sep 2026 01:46:01 +0900 Message-ID: <20260916164601.2562349-1-jaemyung.lee@samsung.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <4c38f13af8f75020fefc35827463e9bc643b99f4.camel@iokpp.de> References: <20260912-rufs-private-v1-1-716db733e655@samsung.com> <4c38f13af8f75020fefc35827463e9bc643b99f4.camel@iokpp.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Fri, 2026-09-11 at 23:44 +0200, Bean Huo wrote: > You still use scsi everywhere in your implementation protocol/scsi.rs > builds READ_10/16, WRITE_10/16, SYNCHRONIZE_CACHE and UNMAP CDB, so > "decouple UFS from SCSI" really means "copy a small part of sd and the > SCSI error handling into a UFS driver." while JEDEC defines the UFS > application layer as SCSI, the SCSI work doesn't go away, you just move > somewhere else, and it has to be written again. I agree. By "decouple" I meant independence from the Linux SCSI mid-layer, not removal of the SCSI command set from UFS. The current RFC has CDB construction and only a small part of completion disposition. It does not yet implement enough sense, retry, recovery, and disk behavior to show that the complete UFS-specific version is smaller or simpler. The cover letter stated that conclusion too early. > The "friction" claim is weak. SCSI has already been changed to fit UFS. > Two examples: UFS now uses SCSI simple copy, group number in scsi write > command. > > I doubt how far this can go. do we really need to pay effort for a new > RUST UFS driver, I am not very confident, unless SCSI is removed from the > UFS spec and JEDEC defines native UFS commands, or we talk to the device > directly with UPIU. please name the JEDEC feature that the SCSI midlayer > really blocked, or that was historial issue which has been fixed. Also fair. I cannot currently name a public JEDEC feature that was shown to be impossible to implement because of the SCSI mid-layer. One of my main motivations was the amount of cross-layer reasoning needed for product EH and PM problems. In product work, I often had to follow UFS state, generic SCSI recovery state, block queue state, and device-PM state together. That experience is a reason to investigate another design, but private product experience is not proof that the upstream architecture is wrong. > I would also like to see the heavy and hard parts, because they are the > parts that decide if this design worrks: > > 1, error handling: abort, LU reset, retries with limits, sense decoding, > this is the very hard part of UFS driver. > > 2, user-space tools interface: SG_IO and bsg (sg3_utils, ufs-utils, FFU > with WRITE BUFFER), and the UFS sysfs tree.. I agree. These are architecture requirements, not small follow-up features. Before claiming that standalone is useful, the design needs to cover timeout, abort, LU and host recovery, bounded retries, sense and Unit Attention, late completion, DMA safety, PM-aware recovery, and request disposition. I think the next step should be to document these responsibilities and compare the standalone design with improving `ufshcd` before completing a second implementation. If RUFS only reproduces the same behavior and complexity, the standalone design would need to be reconsidered. > Did any AI tool help write this code? If so, please add the Assisted-by: > tag. Yes. An LLM helped during reviewing, testing and preparation of the submission. I will add the tag required by the current kernel documentation in the next revision: Assisted-by: LLM Regards, Jaemyung