lkml.org 
[lkml]   [2019]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: build warning after merge of the i2c tree
Em Wed, 12 Jun 2019 10:19:29 +0200
Wolfram Sang <wsa@the-dreams.de> 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

\
 
 \ /
  Last update: 2019-06-12 13:02    [W:0.091 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site