Em Wed, 12 Jun 2019 10:19:29 +0200
Wolfram Sang <wsa@xxxxxxxxxxxxx> escreveu:
> On Tue, Jun 11, 2019 at 10:25:28AM +1000, Stephen Rothwell wrote:
> > Hi Wolfram,
> >
> > After merging the i2c tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> >
> > drivers/media/dvb-frontends/tua6100.c: In function 'tua6100_set_params':
> > drivers/media/dvb-frontends/tua6100.c:71: warning: "_P" redefined
> > #define _P 32
> >
> > In file included from include/acpi/platform/aclinux.h:54,
> > from include/acpi/platform/acenv.h:152,
> > from include/acpi/acpi.h:22,
> > from include/linux/acpi.h:21,
> > from include/linux/i2c.h:17,
> > from drivers/media/dvb-frontends/tua6100.h:22,
> > from drivers/media/dvb-frontends/tua6100.c:24:
> > include/linux/ctype.h:14: note: this is the location of the previous definition
> > #define _P 0x10 /* punct */
> >
> > Exposed by commit
> >
> > 5213d7efc8ec ("i2c: acpi: export i2c_acpi_find_adapter_by_handle")
> >
> > Since that included <linux/acpi.h> from <linux/i2c.h>
> >
> > Originally introduced by commit
> >
> > 00be2e7c6415 ("V4L/DVB (4606): Add driver for TUA6100")
> >
> > The _P in <linux/ctype.h> has existed since before git.
>
> I suggest to fix the driver by adding a TUA6100_ prefix to the defines.
> I can cook up a patch for that.
>
That entire use of _P, _R and _ri looks weird into my eyes. The code there
do things like:
#define _P 32
...
if (_P == 64)
reg1[1] |= 0x40;
It sounds to me that _P and _R are actually some sort of setup
with depends on how the device is wired.
A quick read on its datasheet at page 19 - downloaded from:
http://www.datasheetcatalog.com/datasheets_pdf/T/U/A/6/TUA6100.shtml
Shows that:
P: divide ratio of the prescaler.
R: divide ratio of the R-counter.
ri: reference frequency input (XTAL osc).
IMO, the right fix would be to change struct tua6100_priv, in order to
add those parameters, and initialize them with the current values
at tua6100_attach.
That would allow changing those values during device initialization,
in the case we ever need to support a hardware with the same chipset,
with, for example, a different XTAL.
I'll work on a patch to address it.
Thanks,
Mauro
