Re: linux-next: build warning after merge of the i2c tree

[Mauro Carvalho Chehab]

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