linux-kernel - Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: add MediaTek MT8196 compatible

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] [day] [month] [year] [list]

Message-ID: <20250916153721.5b09e993@fedora>
Date: Tue, 16 Sep 2025 15:37:21 +0200
From: Boris Brezillon <boris.brezillon@...labora.com>
To: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Conor Dooley <conor@...nel.org>, Chia-I Wu <olvaffe@...il.com>, Steven
 Price <steven.price@....com>, Liviu Dudau <liviu.dudau@....com>, David
 Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Maarten
 Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
 <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring
 <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] dt-bindings: gpu: mali-valhall-csf: add MediaTek
 MT8196 compatible

On Tue, 16 Sep 2025 10:58:40 +0200
Nicolas Frattaroli <nicolas.frattaroli@...labora.com> wrote:

> On Tuesday, 16 September 2025 06:21:10 Central European Summer Time Chia-I Wu wrote:
> > On Mon, Sep 15, 2025 at 10:52 AM Conor Dooley <conor@...nel.org> wrote:  
> > >
> > > On Mon, Sep 15, 2025 at 06:51:16PM +0100, Conor Dooley wrote:  
> > > > Acked-by: Conor Dooley <conor.dooley@...rochip.com>  
> > >
> > > Hmm, actually there seems to be a more complete binding proposed here:
> > > https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250912-mt8196-gpufreq-v2-1-779a8a3729d9@collabora.com/  
> > Right. I tried to add the compatible to the binding (this patch)
> > before adding it to the driver (next patch).
> > 
> > If this patch is not a prerequisite for the driver change, I can drop
> > this. Or perhaps there is a better way?
> >   
> 
> Depends on what you want to do with the driver change; I could pull it
> into my patch series (I need it as a prerequisite now anyway, as v3
> will get rid of the clocks for MT8196 in the binding, which means it
> needs to have a flag for this in the soc_data struct you've added)
> 
> I think that would be the easiest solution so that we don't step on
> each other's toes, as long as you think the driver change is
> basically in its final form right now and does not need major
> revisions you'd still like to make yourself without having to
> coordinate submission through me.
> 
> Or, the most roundabout option: I split the bindings I submitted
> into a separate series, and then we can both declare them as deps
> for our driver changes. That might thoroughly confuse maintainers
> though. But then you can declare a dep on the bindings series and
> I can declare a dep on the bindings series and your patch.

The simplest option is probably to merge this series in drm-misc-next
and rebase your GPUEB changes on drm-misc-next.