linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Mathieu Malaterre <malat@debian.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Michael Schmitz <schmitzmic@gmail.com>,
	linux-m68k@lists.linux-m68k.org,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 01/11] macintosh/via-pmu: Fix section mismatch warning
Date: Mon, 2 Jul 2018 22:07:29 +1000 (AEST)	[thread overview]
Message-ID: <alpine.LNX.2.21.1807022143570.13@nippy.intranet> (raw)
In-Reply-To: <CA+7wUsyfkC3FvbFyt9JRdBas3s+52tp7OH8h2jiJM9z+ynoyyw@mail.gmail.com>

On Mon, 2 Jul 2018, Mathieu Malaterre wrote:

> On Mon, Jul 2, 2018 at 10:25 AM Finn Thain <fthain@telegraphics.com.au> 
> wrote:
> >
> > The pmu_init() function has the __init qualifier, but the ops struct 
> > that holds a pointer to it does not. This causes a build warning. The 
> > driver works fine because the pointer is only dereferenced early.
> >
> > The function is so small that there's negligible benefit from using 
> > the __init qualifier. Remove it to fix the warning, consistent with 
> > the other ADB drivers.
> 
> Would you mind copy/pasting the warning you are seeing.
> 
> Make sure you have:
> 
> 58935176ad17 powerpc/via-pmu: Fix section mismatch warning
> 
> Thanks
> 

It's true, the section mismatch warning from 'make' has disappeared since 
I wrote this patch, but that doesn't mean it is wrong.

Before this patch:

$ powerpc-linux-gnu-objdump -xda vmlinux |egrep -w "via_pmu_driver|pmu_init"
c0711c84 l     F .init.text     0000001c pmu_init
c05eb408 g     O .rodata        00000028 via_pmu_driver
c0711c84 <pmu_init>:
$ 

After:

$ powerpc-linux-gnu-objdump -xda vmlinux |egrep -w "via_pmu_driver|pmu_init"
c038e42c l     F .text  0000001c pmu_init
c05e1e58 g     O .rodata        00000028 via_pmu_driver
c038e42c <pmu_init>:
$

I gather that commit 58935176ad17 ("powerpc/via-pmu: Fix section mismatch 
warning") has moved via_pmu_driver from .data to .rodata, but I'm afraid I 
don't see the point of that change. The commit log entry doesn't explain 
it either.

If .rodata is not discarded then the dangling pointer remains, right?

-- 

  reply	other threads:[~2018-07-02 12:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-02  8:21 [PATCH v4 00/11] macintosh: Resolve various PMU driver problems Finn Thain
2018-07-02  8:21 ` [PATCH v4 02/11] macintosh/via-pmu: Add missing mmio accessors Finn Thain
2018-07-02  8:21 ` [PATCH v4 05/11] macintosh/via-pmu: Replace via pointer with via1 and via2 pointers Finn Thain
2018-07-02  8:21 ` [PATCH v4 04/11] macintosh/via-pmu: Enhance state machine with new 'uninitialized' state Finn Thain
2018-07-02  8:21 ` [PATCH v4 03/11] macintosh/via-pmu: Don't clear shift register interrupt flag twice Finn Thain
2018-07-02  8:21 ` [PATCH v4 01/11] macintosh/via-pmu: Fix section mismatch warning Finn Thain
2018-07-02 10:35   ` Mathieu Malaterre
2018-07-02 12:07     ` Finn Thain [this message]
2018-08-01  5:23   ` [v4,01/11] " Michael Ellerman
2018-07-02  8:21 ` [PATCH v4 11/11] macintosh/via-pmu: Disambiguate interrupt statistics Finn Thain
2018-07-02  8:21 ` [PATCH v4 06/11] macintosh/via-pmu: Add support for m68k PowerBooks Finn Thain
2018-07-02  8:21 ` [PATCH v4 08/11] macintosh/via-pmu68k: Don't load driver on unsupported hardware Finn Thain
2018-07-30  7:23   ` Geert Uytterhoeven
2018-07-02  8:21 ` [PATCH v4 10/11] macintosh/via-pmu: Clean up interrupt statistics Finn Thain
2018-07-02  8:21 ` [PATCH v4 07/11] macintosh/via-pmu: Explicitly specify CONFIG_PPC_PMAC dependencies Finn Thain
2018-07-02  8:21 ` [PATCH v4 09/11] macintosh/via-pmu: Replace via-pmu68k driver with via-pmu driver Finn Thain
2018-07-30  6:47   ` Michael Ellerman
2018-07-30  7:27     ` Geert Uytterhoeven
2018-07-30 13:32       ` Michael Ellerman
2018-07-30  7:26   ` Geert Uytterhoeven
2018-07-30  7:27     ` Geert Uytterhoeven
2018-07-28  7:08 ` [PATCH v4 00/11] macintosh: Resolve various PMU driver problems Michael Schmitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LNX.2.21.1807022143570.13@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=benh@kernel.crashing.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=malat@debian.org \
    --cc=schmitzmic@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).