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: <20210511214605.2937099-1-pgwipeout@gmail.com> <YKOB7y/9IptUvo4k@unreal>
 <CAMdYzYrV0T9H1soxSVpQv=jLCR9k9tuJddo1Kw-c3O5GJvg92A@mail.gmail.com>
 <YKTJwscaV1WaK98z@unreal> <cbfecaf2-2991-c79e-ba80-c805d119ac2f@gmail.com> <YKT7bLjzucl/QEo2@unreal>
In-Reply-To: <YKT7bLjzucl/QEo2@unreal>
From:   Peter Geis <pgwipeout@gmail.com>
Date:   Wed, 19 May 2021 08:45:21 -0400
Message-ID: <CAMdYzYpVYuNuYgZp-sNj4QFbgHH+SoFpffbdCNJST2_KZEhSug@mail.gmail.com>
Subject: Re: [PATCH] net: phy: add driver for Motorcomm yt8511 phy
To:     Leon Romanovsky <leon@kernel.org>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Russell King <linux@armlinux.org.uk>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Kernel Network Developers <netdev@vger.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, May 19, 2021 at 7:50 AM Leon Romanovsky <leon@kernel.org> wrote:
>
> On Wed, May 19, 2021 at 12:37:43PM +0200, Heiner Kallweit wrote:
> > On 19.05.2021 10:18, Leon Romanovsky wrote:
> > > On Tue, May 18, 2021 at 08:20:03PM -0400, Peter Geis wrote:
> > >> On Tue, May 18, 2021 at 4:59 AM Leon Romanovsky <leon@kernel.org> wr=
ote:
> > >>>
> > >>> On Tue, May 11, 2021 at 05:46:06PM -0400, Peter Geis wrote:
> > >>>> Add a driver for the Motorcomm yt8511 phy that will be used in the
> > >>>> production Pine64 rk3566-quartz64 development board.
> > >>>> It supports gigabit transfer speeds, rgmii, and 125mhz clk output.
> > >>>>
> > >>>> Signed-off-by: Peter Geis <pgwipeout@gmail.com>
> > >>>> ---
> > >>>>  MAINTAINERS                 |  6 +++
> > >>>>  drivers/net/phy/Kconfig     |  6 +++
> > >>>>  drivers/net/phy/Makefile    |  1 +
> > >>>>  drivers/net/phy/motorcomm.c | 85 ++++++++++++++++++++++++++++++++=
+++++
> > >>>>  4 files changed, 98 insertions(+)
> > >>>>  create mode 100644 drivers/net/phy/motorcomm.c
> > >>>
> > >>> <...>
> > >>>
> > >>>> +static const struct mdio_device_id __maybe_unused motorcomm_tbl[]=
 =3D {
> > >>>> +     { PHY_ID_MATCH_EXACT(PHY_ID_YT8511) },
> > >>>> +     { /* sentinal */ }
> > >>>> +}
> > >>>
> > >>> Why is this "__maybe_unused"? This *.c file doesn't have any compil=
ation option
> > >>> to compile part of it.
> > >>>
> > >>> The "__maybe_unused" is not needed in this case.
> > >>
> > >> I was simply following convention, for example the realtek.c,
> > >> micrel.c, and smsc.c drivers all have this as well.
> > >
> > > Maybe they have a reason, but this specific driver doesn't have such.
> > >
> >
> > It's used like this:
> > MODULE_DEVICE_TABLE(mdio, <mdio_device_id_tbl>);
> >
> > And MODULE_DEVICE_TABLE is a no-op if MODULE isn't defined:
> >
> > #ifdef MODULE
> > /* Creates an alias so file2alias.c can find device table. */
> > #define MODULE_DEVICE_TABLE(type, name)                                =
       \
> > extern typeof(name) __mod_##type##__##name##_device_table             \
> >   __attribute__ ((unused, alias(__stringify(name))))
> > #else  /* !MODULE */
> > #define MODULE_DEVICE_TABLE(type, name)
> > #endif
> >
> > In this case the table is unused.
>
> Do you see compilation warning for such scenario?

The issue you are describing has been fixed since 2010:

commit cf93c94581bab447a5634c6d737c1cf38c080261
Author: Uwe Kleine-K=C3=B6nig <u.kleine-koenig@pengutronix.de>
Date:   Sun Oct 3 23:43:32 2010 +0000

    net/phy: fix many "defined but unused" warnings

    MODULE_DEVICE_TABLE only expands to something if it's compiled
    for a module.  So when building-in support for the phys, the
    mdio_device_id tables are unused.  Marking them with __maybe_unused
    fixes the following warnings:

There is a strong push to fix all warnings during build, including W=3D1 wa=
rnings.
For fun I rebuilt without module support and confirmed that removing
this does trigger a W=3D1 warning.

>
> Thanks
>
> >
> > > Thanks
> > >
> > >>
> > >>>
> > >>> Thanks
> >
> >