[Buildroot] [PATCH 3/7] package/freescale-imx/kernel-module-imx-gpu-viv: bump to version 6.4.3.p4.2

[Yann E. MORIN]

Gary, All,

On 2022-08-29 14:51 +0200, Gary Bisson spake thusly:
> On Sun, Aug 28, 2022 at 05:44:32PM +0200, Yann E. MORIN wrote:
> > On 2022-08-24 12:26 -0700, Chris Dimich spake thusly:
> > > To match NXP 5.15.32-2.0.0 release.
[--SNIP--]
> > I also have some relatively minor concerns with this package (not
> > specifically due to your change, but prompted by it):
[--SNIP--]
> > So, basically, we are using the commits on the master branch, but all
> > that differs from the corresponding tag is (by running:  git diff -p
> > c897a6c..82c6cb6):
> >   - there is an added 'fscl' (or variation thereof, like '+fscl') in 4
> >     locations, all appended to the version string;
> 'fslc' means that it is maintained by the community (fsl community) so
> the purpose of that tag is to show we're building from the external
> module source code from github/freescale (which is entirely maintained
> by the community).

Arf, and of course, I could not copy a 4-word acronym without making yet
another typo... :-/

> >   - there are two macros that are removed (specifically by ae0f3be).
> Yes this is for Yocto builds in order not to break reproducibiliy of the
> build/module.

Ah, but they are also nice for Buildroot, for the same reason! We also
want to be able to do reproducible builds, which is the reason I
suggested backporting that patch.

> > So, can't we use the tag instead of a sha1, and carry the patch from
> > ae0f3be localy?
> 
> We could but this approach considers there's only that patch that
> matters.
> In the past, the community-maintained module had more features than the
> driver from NXP, for instance it was supporting PREEMPT_RT when NXP
> didn't [1]. But I agree both branches are now very close.
> I don't have any strong feelings to be honest, whatever you think is
> better for BR will do.

OK, so using the master branch is the best solution overall, then.

> > Otherwise, Chris and Gary: could you add tags on the master branch,
> > maybe?
> We could add a tag on master if needed. Would need to run it by the
> project maintainer (Otavio). Just let me know if you want to go that
> route.

Given that there is a tag for the upstream import, it would be nice to
also have a tag for the community-merged result, but I can't impose that
burden, now that the reason for the master branch is better explained.
Thanks!

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'