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;
From:   Jerome Pouiller <Jerome.Pouiller@silabs.com>
To:     Arnd Bergmann <arnd@arndb.de>
CC:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jules Irenge <jbi.octave@gmail.com>,
        =?iso-8859-2?Q?Micha=B3_Miros=B3aw?= <mirq-linux@rere.qmqm.pl>,
        "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] staging: wfx: avoid compiler warning on empty array
Thread-Topic: [PATCH] staging: wfx: avoid compiler warning on empty array
Thread-Index: AQHWHjF5vlfoO7puXUWgUhn1WHjUDaiQQ0QAgABLogCAAMtAgA==
Date:   Thu, 30 Apr 2020 08:42:24 +0000
Message-ID: <3063047.NHY2raB2sq@pc-42>
References: <20200429142119.1735196-1-arnd@arndb.de>
 <3943343.tW1xmJHsB6@pc-42>
 <CAK8P3a1e=-H_b8_GPJW5-uufye5_6OJ6f+ZWErjKPWkxSRSigw@mail.gmail.com>
In-Reply-To: <CAK8P3a1e=-H_b8_GPJW5-uufye5_6OJ6f+ZWErjKPWkxSRSigw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <DC950E9F6F97BF43BF18998A290B3C60@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c70ee467-daf5-4bcc-834a-08d7ece267c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2020 08:42:24.3548
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 54dbd822-5231-4b20-944d-6f4abcd541fb
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hgIAjaych58pblB2dsP+1hSGCpQk5jkUhuts/owEH4jLLFtFuC0eTTDbyEJr1qy0dASIOYotseX1cHEihzoGgg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1392
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wednesday 29 April 2020 22:34:56 CEST Arnd Bergmann wrote:
>=20
> On Wed, Apr 29, 2020 at 6:04 PM Jerome Pouiller
> <Jerome.Pouiller@silabs.com> wrote:
> > On Wednesday 29 April 2020 16:21:09 CEST Arnd Bergmann wrote:
> > >
> > > -static const struct of_device_id wfx_sdio_of_match[];
> > > +static const struct of_device_id wfx_sdio_of_match[] =3D {
> > > +       { .compatible =3D "silabs,wfx-sdio" },
> > > +       { .compatible =3D "silabs,wf200" },
> > > +       { },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, wfx_sdio_of_match);
> >
> > I suggest to keep the '#ifdef CONFIG_OF' around this definition. If
> > CONFIG_OF is undefined, of_match_ptr() and of_match_node() will be NULL
> > and it should compile.
>=20
> I would generally always go for fewer #ifdef instead of more when the res=
ult
> is the same. Are you worried about wasting 600 bytes of object code size =
for
> the array on systems that need this driver but not CONFIG_OF, or somethin=
g
> else?

I am not very concerned about the size of the object. However, I think
that all the modules should apply the same policy regarding the device
tables. With a few greps, I found 3954 struct of_device_id. About 500 are
inside #ifdef and about 1000 use of_match_ptr().

Should we consider that the structs of_device_id have to be defined even
if CONFIG_OF is not defined? And In this case, should we drop
of_match_ptr()?

Or in contrary, when kernel is compiled without CONFIG_OF, no modules
should contains OF entries in its device table?

--=20
J=E9r=F4me Pouiller