On Fri, 2026-03-20 at 09:10 -0400, Nicolas Dufresne wrote:
> Kyrie, Yunfei, Irui,
>
> Le vendredi 20 mars 2026 à 13:59 +0800, Kyrie Wu a écrit :
> >
>
> [...]
> > This series patches dependent on:
> > [1]
> >
https://patchwork.linuxtv.org/project/linux-media/patch/20260211054149.27249-2-yunfei.dong@mediatek.com/
> > [2]
> >
https://patchwork.linuxtv.org/project/linux-media/patch/20260302035244.8994-2-irui.wang@mediatek.com/
>
> While this one is now ready, it still can't be merge, because the
> other series
> it depends one have not been updated to use the pdata properly. In
> fact, its
> quite likely that some of the patches in this serie must be moved up
> the chain.
> This type of linked submission is making my life extremely difficult,
> and causes
> massive delays.
>
> Basically, in a chain of 3 series (and probably 4 since the first one
> does not
> apply), the refactoring that causes all the series to not be accepted
> is
> happening in the third one. Angelo and I have been clear for weeks,
> if you need
> a constant value for a platform, it goes in the platform data. Don't
> do switch
> of strcmp at runtime, these are constants and we already did string
> matching to
> in the probe to find this pdata. Once the missing data is added,
> simply make a
> final patch adding the pdata structure for the platform. Use this v8
> of the
> MT8189 support as reference, it is as I said ready, but it does not
> apply due to
> broken dependencies.
>
> I can't easily fix this, so please work together, synchronize your
> submissions
> so that we can get the MT8196 and MT8189 support finally merged.
>
> regards,
> Nicolas
Dear Nicolas,
Thank you very much for your detailed feedback and patient guidance on
our patch series.
We greatly appreciate the time and effort you have dedicated to
reviewing our submissions.
We fully understand your concerns regarding the dependency and
structural issues between the patch series.
Allow me to explain our current situation and development timeline:
The MT8196 platform development was initiated earlier than MT8189, and
during its development cycle,
several critical bug fixes were implemented in the MT8196 patchset.
These fixes are essential
for the stability and proper functioning of the vcodec driver.
If we were to bypass the MT8196 patches and directly rebase the MT8189
patches for upstream submission,
the vcodec driver would unfortunately inherit these unresolved bugs. On
the other hand,
if we were to incorporate all the bug fixes from MT8196 into the MT8189
patchset,
it would create a mixture of both MT8196 and MT8189 changes, which
would not be a clean
or maintainable solution and goes against proper upstream practices.
Given this dependency chain, we believe the most appropriate path
forward is to prioritize
completing the MT8196 patch upstream work first. Our team is fully
committed to putting our best efforts
into expediting the MT8196 patch series review and revision process.
Once those patches are successfully merged,
the MT8189 series can then proceed cleanly without these structural
concerns.
We sincerely appreciate your expertise and the constructive guidance
you have provided throughout this process.
Your feedback has been invaluable in helping us understand the
expectations and proper upstream practices.
We commit to diligently addressing all review comments and working
closely with you to ensure
our patches meet the required standards.
Thank you once again for your patience and support. We look forward to
continuing our collaboration
and delivering high-quality patches that benefit the community.
Best regards,
Kyrie