From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Ruslan Babayev <ruslan@babayev.com>,
Andrew de Quincey <adq_dvb@lidskialf.net>
Subject: Re: linux-next: build warning after merge of the i2c tree
Date: Wed, 12 Jun 2019 08:02:26 -0300 [thread overview]
Message-ID: <20190612080226.45d2115a@coco.lan> (raw)
In-Reply-To: <20190612081929.GA1687@kunai>
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
next prev parent reply other threads:[~2019-06-12 11:02 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 0:25 linux-next: build warning after merge of the i2c tree Stephen Rothwell
2019-06-12 8:19 ` Wolfram Sang
2019-06-12 11:02 ` Mauro Carvalho Chehab [this message]
2019-06-12 11:09 ` Wolfram Sang
2019-06-12 11:48 ` Mauro Carvalho Chehab
2019-06-12 12:04 ` Wolfram Sang
2019-06-12 12:32 ` Mauro Carvalho Chehab
2019-06-12 13:15 ` Stephen Rothwell
2019-06-12 13:24 ` Wolfram Sang
2019-06-12 11:25 ` [PATCH] media: tua6100: Remove some ugly defines Mauro Carvalho Chehab
2019-06-12 12:01 ` Wolfram Sang
2019-06-18 21:38 ` Wolfram Sang
2019-07-08 9:25 ` Wolfram Sang
-- strict thread matches above, loose matches on Subject: below --
2021-08-18 6:29 linux-next: build warning after merge of the i2c tree Stephen Rothwell
2021-08-18 6:54 ` Jie Deng
2021-08-18 7:04 ` Stephen Rothwell
2021-08-18 7:13 ` Jie Deng
2019-08-02 3:21 Stephen Rothwell
2019-08-02 6:04 ` Uwe Kleine-König
2017-06-05 1:11 Stephen Rothwell
2017-06-15 1:34 ` Stephen Rothwell
2017-06-15 7:02 ` Wolfram Sang
2017-06-15 8:48 ` Stephen Rothwell
2014-03-06 2:50 Stephen Rothwell
2010-03-28 23:54 Stephen Rothwell
2010-03-29 13:21 ` Jean Delvare
2010-03-29 14:12 ` Stephen Rothwell
2010-02-17 0:38 Stephen Rothwell
2010-02-17 8:34 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190612080226.45d2115a@coco.lan \
--to=mchehab@infradead.org \
--cc=adq_dvb@lidskialf.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=ruslan@babayev.com \
--cc=sfr@canb.auug.org.au \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).