Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201030181822.570402-1-lee.jones@linaro.org> <CAKMK7uFN31B0WNoY5P0hizLCVxVkaFkcYjhgYVo1c2W+1d7jxA@mail.gmail.com>
 <20201102110916.GK4127@dell> <CAKMK7uFhpt5J8TcN4MRMeERE9DtNar+pBAmE6QRvD0zkGR5iNQ@mail.gmail.com>
 <20201102113034.GL4127@dell>
In-Reply-To: <20201102113034.GL4127@dell>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon, 2 Nov 2020 15:50:49 +0100
Message-ID: <CAKMK7uHo2MMmBUic9EiFqcUh8mJeu1+=ZQfH7bWA=zdJTyRyvA@mail.gmail.com>
Subject: Re: [PATCH 1/1] Fonts: font_acorn_8x8: Replace discarded const qualifier
To:     Lee Jones <lee.jones@linaro.org>
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        Peilin Ye <yepeilin.cs@gmail.com>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        stable <stable@vger.kernel.org>,
        Russell King <linux@armlinux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Nov 2, 2020 at 12:30 PM Lee Jones <lee.jones@linaro.org> wrote:
>
> On Mon, 02 Nov 2020, Daniel Vetter wrote:
>
> > On Mon, Nov 2, 2020 at 12:09 PM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > On Mon, 02 Nov 2020, Daniel Vetter wrote:
> > >
> > > > On Fri, Oct 30, 2020 at 7:18 PM Lee Jones <lee.jones@linaro.org> wrote:
> > > > >
> > > > > Commit 09e5b3fd5672 ("Fonts: Support FONT_EXTRA_WORDS macros for
> > > > > built-in fonts") introduced the following error when building
> > > > > rpc_defconfig (only this build appears to be affected):
> > > > >
> > > > >  `acorndata_8x8' referenced in section `.text' of arch/arm/boot/compressed/ll_char_wr.o:
> > > > >     defined in discarded section `.data' of arch/arm/boot/compressed/font.o
> > > > >  `acorndata_8x8' referenced in section `.data.rel.ro' of arch/arm/boot/compressed/font.o:
> > > > >     defined in discarded section `.data' of arch/arm/boot/compressed/font.o
> > > > >  make[3]: *** [/scratch/linux/arch/arm/boot/compressed/Makefile:191: arch/arm/boot/compressed/vmlinux] Error 1
> > > > >  make[2]: *** [/scratch/linux/arch/arm/boot/Makefile:61: arch/arm/boot/compressed/vmlinux] Error 2
> > > > >  make[1]: *** [/scratch/linux/arch/arm/Makefile:317: zImage] Error 2
> > > > >
> > > > > The .data section is discarded at link time.  Reinstating
> > > > > acorndata_8x8 as const ensures it is still available after linking.
> > > > >
> > > > > Cc: <stable@vger.kernel.org>
> > > > > Cc: Russell King <linux@armlinux.org.uk>
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > >
> > > > Shouldn't we add the const to all of them, for consistency?
> > >
> > > The thought did cross my mind.  However, I do not see any further
> > > issues which need addressing.  Nor do I have any visibility into what
> > > issues may be caused by doing so.  The only thing I know for sure is
> > > that this patch fixes the compile error pertained to in the commit
> > > message, and I'd like for this fix to be as atomic as possible, as
> > > it's designed to be routed through the Stable/LTS trees.
> >
> > The trouble is that if we only make one of them const, then it'll take
> > so much longer to hit any issues due to code not handling this
> > correctly. Being consistent with all fonts sounds like the best
> > approach.
> >
> > And the original patch that lost the const for the additional data
> > also went through cc: stable for all fonts together. So that shouldn't
> > be the hold-up.
>
> My plan was to keep the fix as simple as possible.
>
> This is only an issue due to the odd handling of the compressed Arm
> image which exclusively references 'acorndata_8x8' and discards it's
> .data section.
>
> I am happy to go with the majority on this though.
>
> Does anyone else have an opinion?

Oh I don't want to hold up the fix, I'm just semi desperately looking
for people who care beyond "this is the most minimal thing for my use
case" since this entire area is orphaned. With the other things fixed
feel free to smash my ack onto this.

Maybe Peilin is going to include the full re-cosntification in a
cleanup series, dunno.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch