From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 F306434A797 for ; Thu, 30 Jul 2026 08:04:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785398653; cv=none; b=W8Y4ysYQPeAQ4ZBXdzuM4tGxnQq1k/mdYFbFFGKNRt1Zm80SmiD4WB8xv3Y9Ouv4f8tuy0fCBEfgpIQ4O+fYVawX3TnaczgCkvI2rpCAuyz/2W21bKfQO9WCZCjtJ03QNeRiKX7hGZEEVzYe/+Pevz0bBcc3vhRhKc3qQCC4X1Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785398653; c=relaxed/simple; bh=3gGgZqrUjViXixDKgu2n+X+ucwddusIdUEaNS5CyQYI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iGGDnmPlTRNmaAgV85pYVjxhInbcw0Rp8vrMuUNOU0wGgBO3g62zjVKQ8OsabBIAdUOBa/4Qu/h3XfxiWiVTtiQQRvkgwoq0PZCHvJrcGCZyYei78N2wQzNk9AE+wDLIwj1j1fdH71i3Uswgj+bIR9Vh6rcx179ekMAhBLDuZac= 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=SxADENaF; arc=none smtp.client-ip=209.85.221.52 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="SxADENaF" Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47f706438c3so129589f8f.3 for ; Thu, 30 Jul 2026 01:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785398650; x=1786003450; 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:content-type; bh=cYZOW4+rPj/CMFn0uRjVqgsz7yPpvLWpF6+UtZMyKrk=; b=SxADENaFp3WynM14lRvoK9XWK87Om2J+x/KGiMNxelvJTSxkCsgWjd0KNSCh7iLBCx QM6W3qJx1BWFzxh528utBlDnNpXAwPw59Ty+lQ+oEU0zK4W+CdXHkRieGowY8/zcnrQr TRYYpNHGmg+jnSBv1OL0y2IRIiiZCiq3uB18rsuz1CW0aU62i4kCgQJZ93Km+/MTuKXJ nj+dIvw1sZhPu9Fsbb5R1aRtkzQN6otxj2gstbvaWjfExQHnffMs7olk+32snQYXrMA+ t52boaKrcUCEdLY8ho6fzn5dqKjwEgCbH4JUtZhGqtUfmJvKczG5A8HvPov4o238sgQs t0rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785398650; x=1786003450; 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:content-type; bh=cYZOW4+rPj/CMFn0uRjVqgsz7yPpvLWpF6+UtZMyKrk=; b=MMX6+imlRI8FK3XqMr6q6oqDvF5baeUBrYjSb+X4dPEI15rrX5tHT/hNkRzRLpxT6k JIj9fCUBvCxNTTza0hoh/trEkWsRTv3RzerBZov8jhmMvr6VzAnm1jE9+cnNVRr3fTlM bUapqyJKZtYAtvahff3T6vMoYnmKbPmPxF3yautqc6kxJ3J92JzXP1Gpv9r4OykZnqBd 5uyec0Ng0Lg56G1DLz4zv/cDq0kJGVe615J/hH26BXZl19KEi6YghovHZ9GL9iDLP8I7 LZuCBChOGqDbbEJoBVaF9osQlfpuTQT8IKcuXJ0Cei8DL1SIw2SHNjwA6EmCQPb/qji5 2pKQ== X-Forwarded-Encrypted: i=1; AHgh+RoVdJvAAhdT5Z0GwDy4COVx5PZRXp/uhvdNPBwnewBcNBH6mhiBRg/99Bh6+LQOCr+W+oXUfQpm9ggsSug=@vger.kernel.org X-Gm-Message-State: AOJu0YzO4VZwlyzHIqBcOW/yHo/TUhKJ69PwqgX8vDBeyWFEBKI0vHjY Xs9jJDjQfmIT0NUAO8tGZ7M+XlxawoCZdZe9GhLFMCLWSq+LBnQxz+Wc X-Gm-Gg: AR+sD12sJm/cNE5PaqRoVExhJKgU6PIV+TH1XW9iLGLww9RVSt+AyD5uhyXBHtCcBZA XkdWqDOXNWuH5DENlSXC3ikprVOjsQMO95ZSrDeZrG1ruG9Hi2uNxeN1TC5/D9uOPr5OSBB7cP5 61RPw7HdkXcKU86bHEIkEIENQ6sdPUX0nfVQU6EIB25s0mxi4srXFPp1vR6T3w4IZQgQav1Dviw 8pPOHD9h4BgG/MeI4JRszJ0t9Cr2ZDfG+Y/ubtrAIrYEbZG4yDASg7y91T7P2LXNf8dPZR25MTQ guVcAHjRmzlw8ICp6I4gSAouOSNN6vK3Q63LDNDPFpQkSX7KJCDpCfpgFUaKbb8SibAK5KG807X KNHdt/KjlTJrUxkedc/+QveLlNld2Juibh/MhmgDw3u3TKY9io+yx4KEgIGOOZbISWDPYcl25kz YC0CdUW9QlOOz06O4tpNyv7tYVeJUbCKN2JBK2WTR5RYd6m2QIw1pfgsrKXar2AQf5AsCFejk80 Zeeoi6dpY+b6lC2Ilc8kHcvShrIpXEUE9EBEv/RIujKlUve3mal0RUPWJuC8BFFInoMqXgDv6Zp cs7J X-Received: by 2002:a05:600c:46cb:b0:495:6274:56bd with SMTP id 5b1f17b1804b1-49800ed4c5cmr19802285e9.4.1785398649931; Thu, 30 Jul 2026 01:04:09 -0700 (PDT) Received: from OrangePi5-Plus.BB-HOME (20014C4E1B8A5A00BF2D55A7591B4173.dsl.pool.telekom.hu. [2001:4c4e:1b8a:5a00:bf2d:55a7:591b:4173]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47fc88e4055sm3347685f8f.13.2026.07.30.01.04.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Jul 2026 01:04:09 -0700 (PDT) From: Igor Paunovic To: Tomeu Vizoso Cc: Oded Gabbay , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, Guangshuo Li , Jiaxing Hu , Igor Paunovic Subject: [PATCH 0/2] accel/rocket: fix shared-device lifecycle on probe failure and unbind Date: Thu, 30 Jul 2026 10:03:52 +0200 Message-ID: <20260730080355.177422-1-royalnet026@gmail.com> X-Mailer: git-send-email 2.53.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The rocket driver keeps a single shared DRM device on a driverless "rknn" platform device: the first core to probe initializes it, the last one to go away tears it down. This series fixes two independent bugs in that lifecycle. Both were flagged by the Sashiko AI review on my clks patch; I verified each by hand against the code and then on hardware before writing the fixes. Patch 1 releases the devres of the shared device on teardown. Today every fini/re-init cycle leaks the previous rocket_device and pins its accel minor - observable as /dev/accel/accel0 coming back as accel1, then accel2, on unbind/rebind cycles of all cores. Patch 2 makes the per-core slot bookkeeping stable across unbind and rebind in any order. Today unbinding a lower-numbered core makes higher-numbered ones unfindable (their runtime PM callbacks start returning -ENODEV), a later unbind of such a core is silently skipped, and a subsequent bind overwrites a slot whose IRQ handler and DRM scheduler are still live. Verified on RK3588 (Orange Pi 5 Plus, all three cores): the unbind/rebind matrix keeps /dev/accel/accel0 stable and every core findable; single-core operation works from the highest slot alone (confirmed via the per-core IRQ counters moving to that core); and a MobileNetV1 inference run via the Teflon TFLite delegate stays bit-identical to the stock driver throughout. The series applies on top of Guangshuo Li's pending fix, on which patch 1 depends textually (reviewed on-list earlier today): https://lore.kernel.org/dri-devel/20260708062845.716487-1-lgs201920130244@gmail.com/ Igor Paunovic (2): accel/rocket: release the shared device's devres on teardown accel/rocket: keep core slots stable across unbind and rebind drivers/accel/rocket/rocket_device.c | 2 ++ drivers/accel/rocket/rocket_device.h | 3 +++ drivers/accel/rocket/rocket_drv.c | 40 ++++++++++++++++++++++++++++++---- drivers/accel/rocket/rocket_job.c | 11 ++++++----- 4 files changed, 47 insertions(+), 9 deletions(-) -- 2.53.0