On Fri, Aug 25, 2023 at 7:34 AM Helen Mae Koike Fornazier <helen.koike@xxxxxxxxxxxxx> wrote: > > On Friday, August 25, 2023 11:30 -03, Rob Clark <robdclark@xxxxxxxxx> wrote: > > > On Fri, Aug 25, 2023 at 6:56 AM Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > > > > > > On Fri, 25 Aug 2023, Vignesh Raman <vignesh.raman@xxxxxxxxxxxxx> wrote: > > > > Force db410c to host mode to fix network issue which results in failure > > > > to mount root fs via NFS. > > > > See https://gitlab.freedesktop.org/gfx-ci/linux/-/commit/cb72a629b8c15c80a54dda510743cefd1c4b65b8 > > > > > > > > Since this fix is not sent upstream, add it to build.sh script > > > > before building the kernel and dts. Better approach would be > > > > to use devicetree overlays. > > > > > > > > Signed-off-by: Vignesh Raman <vignesh.raman@xxxxxxxxxxxxx> > > > > --- > > > > drivers/gpu/drm/ci/build.sh | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh > > > > index 7b014287a041..c39834bd6bd7 100644 > > > > --- a/drivers/gpu/drm/ci/build.sh > > > > +++ b/drivers/gpu/drm/ci/build.sh > > > > @@ -70,6 +70,10 @@ if [ -z "$CI_MERGE_REQUEST_PROJECT_PATH" ]; then > > > > fi > > > > fi > > > > > > > > +# Force db410c to host mode to fix network issue which results in failure to mount root fs via NFS. > > > > +# See https://gitlab.freedesktop.org/gfx-ci/linux/-/commit/cb72a629b8c15c80a54dda510743cefd1c4b65b8 > > > > +sed -i '/&usb {/,/status = "okay";/s/status = "okay";/&\n\tdr_mode = "host";/' arch/arm64/boot/dts/qcom/apq8016-sbc.dts > > > > + > > > > > > It seems like a really bad idea to me to have the CI build modify the > > > source tree before building. > > > > > > The kernel being built will have a dirty git repo, and the localversion > > > will have -dirty in it. > > > > > > I think it would be better to do out-of-tree builds and assume the > > > source is read-only. > > > > We have the ${target_branch}-external-fixes mechanism to merge > > necessary changes before building the kernel for CI. Which is > > necessary for a couple of reasons: > > Should we create an official topic/drm-ci-external-fixes branch ? Hmm, maybe.. I guess as we expand this to more driver trees, and want to be able to re-run CI in the drm tree after merges to drm-next/drm-fixes, we maybe want to have central drm-next-external-fixes and drm-fixes-external-fixes. I guess we can keep those based on drm-next and drm-fixes? And if there would be conflicts because, say, ${driver}-next is behind drm-next, then ${driver}-next could be rebased on drm-next? BR, -R > Regards, > Helen > > > > > 1) patches like this which aren't appropriate upstream but necessary > > due to the CI lab setup > > 2) target branch if often based on an early -rc, and it isn't unheard > > of to need some fix for some board or another which isn't appropriate > > to land via drm-next > > > > We should use the -external-fixes branch mechanism for patches like this one. > > > > BR, > > -R > > > > > > for opt in $ENABLE_KCONFIGS; do > > > > echo CONFIG_$opt=y >> drivers/gpu/drm/ci/${KERNEL_ARCH}.config > > > > done > > > > > > Ditto for the config changes in the context here. Those are files in > > > git, don't change them. > > > > > > Shouldn't this use something like 'scripts/config --enable' or > > > 'scripts/config --disable' on the .config file to be used for building > > > instead? > > > > > > > > > BR, > > > Jani. > > > > > > > > > -- > > > Jani Nikula, Intel Open Source Graphics Center >
