linux-kernel - Re: [PATCH v7 04/10] accel/rocket: Add job submission IOCTL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAObsKAgmDANvWop-GRAqE6eFRHeQiVHkF1nSwEqyWWY=mdRfg@mail.gmail.com>
Date: Fri, 11 Jul 2025 18:45:46 +0200
From: Tomeu Vizoso <tomeu@...euvizoso.net>
To: Robin Murphy <robin.murphy@....com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>, Oded Gabbay <ogabbay@...nel.org>, 
	Jonathan Corbet <corbet@....net>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, 
	Sumit Semwal <sumit.semwal@...aro.org>, Christian König <christian.koenig@....com>, 
	Sebastian Reichel <sebastian.reichel@...labora.com>, 
	Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, Kever Yang <kever.yang@...k-chips.com>, 
	Daniel Stone <daniel@...ishbar.org>, Da Xue <da@...re.computer>, 
	Jeff Hugo <jeff.hugo@....qualcomm.com>, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	linux-doc@...r.kernel.org, linux-media@...r.kernel.org, 
	linaro-mm-sig@...ts.linaro.org
Subject: Re: [PATCH v7 04/10] accel/rocket: Add job submission IOCTL

On Fri, Jul 11, 2025 at 6:40 PM Robin Murphy <robin.murphy@....com> wrote:
>
> On 11/07/2025 5:00 pm, Tomeu Vizoso wrote:
> > On Tue, Jun 24, 2025 at 3:50 PM Robin Murphy <robin.murphy@....com> wrote:
> >>
> >> On 2025-06-06 7:28 am, Tomeu Vizoso wrote:
> >> [...]
> >>> diff --git a/drivers/accel/rocket/rocket_device.h b/drivers/accel/rocket/rocket_device.h
> >>> index 10acfe8534f00a7985d40a93f4b2f7f69d43caee..50e46f0516bd1615b5f826c5002a6c0ecbf9aed4 100644
> >>> --- a/drivers/accel/rocket/rocket_device.h
> >>> +++ b/drivers/accel/rocket/rocket_device.h
> >>> @@ -13,6 +13,8 @@
> >>>    struct rocket_device {
> >>>        struct drm_device ddev;
> >>>
> >>> +     struct mutex sched_lock;
> >>> +
> >>>        struct mutex iommu_lock;
> >>
> >> Just realised I missed this in the last patch, but iommu_lock appears to
> >> be completely unnecessary now.
> >>
> >>>        struct rocket_core *cores;
> >> [...]
> >>> +static void rocket_job_hw_submit(struct rocket_core *core, struct rocket_job *job)
> >>> +{
> >>> +     struct rocket_task *task;
> >>> +     bool task_pp_en = 1;
> >>> +     bool task_count = 1;
> >>> +
> >>> +     /* GO ! */
> >>> +
> >>> +     /* Don't queue the job if a reset is in progress */
> >>> +     if (atomic_read(&core->reset.pending))
> >>> +             return;
> >>> +
> >>> +     task = &job->tasks[job->next_task_idx];
> >>> +     job->next_task_idx++;
> >>> +
> >>> +     rocket_pc_writel(core, BASE_ADDRESS, 0x1);
> >>> +
> >>> +     rocket_cna_writel(core, S_POINTER, 0xe + 0x10000000 * core->index);
> >>> +     rocket_core_writel(core, S_POINTER, 0xe + 0x10000000 * core->index);
> >>
> >> Those really look like bitfield operations rather than actual arithmetic
> >> to me.
> >>
> >>> +
> >>> +     rocket_pc_writel(core, BASE_ADDRESS, task->regcmd);
> >>
> >> I don't see how regcmd is created (I guess that's in userspace?), but
> >> given that it's explicitly u64 all the way through - and especially
> >> since you claim to support 40-bit DMA addresses - it definitely seems
> >> suspicious that the upper 32 bits never seem to be consumed anywhere :/
> >
> > Yeah, but there's no other register for BASE_ADDRESS address in the TRM.
>
> That only reaffirms the question then - if this value is only ever
> written verbatim to a 32-bit register, why is it 64-bit?

Ah, sure, it will be 32-bit in v8.

Thanks,

Tomeu

> Thanks,
> Robin.