linux-kernel - Re: [PATCH] [media] dib0090: remove manual configuration system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1409860605.5546.114.camel@x220>
Date:	Thu, 04 Sep 2014 21:56:45 +0200
From:	Paul Bolle <pebolle@...cali.nl>
To:	Mauro Carvalho Chehab <m.chehab@...sung.com>
Cc:	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [media] dib0090: remove manual configuration system

Hi Mauro,

On Thu, 2014-09-04 at 12:36 -0300, Mauro Carvalho Chehab wrote:
> Em Thu, 22 May 2014 14:48:07 +0200
> Paul Bolle <pebolle@...cali.nl> escreveu:
> 
> > dib0900.c has always shipped with its own, manual, configuration
> > system. There a three problems with it.
> > 
> > 1) macros that are defined, but not used:
> >     CONFIG_SYS_DVBT
> >     CONFIG_DIB0090_USE_PWM_AGC
> > 
> > 2) checks for macros that are always true:
> >     CONFIG_SYS_ISDBT
> >     CONFIG_BAND_CBAND
> >     CONFIG_BAND_VHF
> >     CONFIG_BAND_UHF
> > 
> > 3) checks for macros that are never defined and are always false:
> >     CONFIG_BAND_SBAND
> >     CONFIG_STANDARD_DAB
> >     CONFIG_STANDARD_DVBT
> >     CONFIG_TUNER_DIB0090_P1B_SUPPORT
> >     CONFIG_BAND_LBAND
> > 
> > Remove all references to these macros, and, of course, remove the code
> > hidden behind the macros that are never defined too.
> 
> IMHO, it is OK to remove the macros that are always true and
> the ones that aren't used.

I see. I hope to send a v2 that does that one of these days.

> However, I don't like the idea of
> removing the other macros. This is a tuner driver that can be used
> on other bands, and some day we might end implementing analog support
> for the Dibcom driver or to add something that will require the code
> there. So, IMHO, better to keep the code there.

But would you consider a patch that at least moves those macros out of
the CONFIG_* namespace (ie, a patch that prefixes those macros with,
say, DIB0090_)?


Paul Bolle

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/