> Strictly speaking, building the media subsystem on older kernels is a job of 
> the media build system.
Yes I agree.

> In general I would thus ask for the fix to be merged in media-build.git.
Which I do mostly, but in this case it is a coding error in mainline. 

> In this specific case, as the mainline code uses both u64 and ktime_t types,
> I'm fine with merging your patch to use explicit conversion functions in
> mainline even if the two types are now equivalent.
We had this already with other drivers and changes for ktime_t. In fact you
should always use the macro accessors. We don't know what will be changed in
the future with ktime_t, so using the macros -- on all places -- is save for
the future also. And using the macro accessors is automatically backward
compatible also.

> However, as this doesn't fix a bug in the mainline kernel, I don't think this
> patch is a candidate for stable releases, and should thus get merged in v4.17.
I am fine with this.

> It can also be included in media-build.git in order to build kernels that
> currently fail.
I just sent a temporary fix for media-build.
media-build works always with the latest media.git. So once it is merged, the
temporary fix can be removed again.


Reply via email to