Re: Request to backport KERNEL_DTC_FLAGS to Dunfell

["Mark Jonas" <mark.jonas@de.bosch.com>]

Hi Bruce and Steve,

> Von: Bruce Ashfield <bruce.ashfield@gmail.com>

> On Fri, Jun 4, 2021 at 11:09 AM Steve Sakoman <steve@sakoman.com> wrote:
> >
> > On Fri, Jun 4, 2021 at 2:45 AM Jonas Mark (BT-FIR/ENG1-Grb)
> > <Mark.Jonas@de.bosch.com> wrote:
> > >
> > > Hi,
> > >
> > > We are using DT overlays and have the need to pass the -@ parameter
> > > in DTC_FLAGS to Linux' make. The patch
> > >
> > > "kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags"

[cut out web links messed up by Outlook]

> > > makes that possible in a nice way. Would it be reasonable to request
> backporting of this patch to Dunfell?
> >
> > This is sort of in the grey area between feature and bug fix.  It does
> > seem relatively safe, so I would consider taking the patch if there
> > are no objections from the community.
> >
> > Added Bruce to the cc list to get his opinion.
> 
> Good timing, I happened to notice this earlier and was thinking about it.
> 
> While I also wouldn't call it a bug, I agree it is a small/standalone change that
> shouldn't break anything.
> 
> A quick scan of the dunfell tested kernels shows unchanged Makefile handling of
> the option, so there's little risk there.
> 
> I'd say that it would be fine for backport.

Can I help with the backport in any way?

My colleague Tingquan gave it a try and the patch from Hardknott applies cleanly on Dunfell.

The documentation patch for Poky proposed by Quentin does not apply though. But it is just that ref-variables.rst was renamed to variables.rst.

> 
> Bruce
> 
> >
> > > We were also wondering what could be an alternative approach for getting
> this or a similar functionality. Patching a bbclass using a bbappend is not
> possible, is it?
> >
> > No, there is no equivalent of bbappend for classes.
> >
> > Other solutions are possible, but taking this patch would be the
> > cleanest solution to your problem.  Let's see what others think before
> > we go there :-)
> >
> > Steve

Cheers,
Mark