Bug 13709

Summary: b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2
Product: v4l-dvb Reporter: boris64 (bugzilla.kernel.org)
Component: dvb-frontendAssignee: dvb-frontend (v4l-dvb_dvb-frontend)
Status: CLOSED CODE_FIX    
Severity: normal CC: rjw
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31-rc1 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 13615    
Attachments: lspci output
dmesg output (kernel-2.6.30.1) with working dvb adapter
dmesg output (kernel-2.6.31-rc2)
lspci -vnn
Kernel-2.6.30.1 config with working adapter
Kernel-2.6.31-rc2 config

Description boris64 2009-07-05 01:36:30 UTC
Hi kernel people!

Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't
working anymore, because no frontend driver is found.
The frontend 'ST STV0299 DVB-S' is compiled into the kernel
and _did_ work fine in pre-2.6.31 kernels.


[lspci]
...
05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
[/lspci]

[dmesg]
Working kernel-2.6.30.1:
------------------------
...
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully
b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
b2c2-flexcop: found 'ST STV0299 DVB-S' .
b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation (HD5000)' at the 'PCI' bus controlled by a 'FlexCopIIb' complete
...

Non-working kernel-2.6.31-rc:
------------------------
...
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully
b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled
...
[/dmesg]


I'll attach full dmesg+lspci.
Please feel free to contact me if you need more infos.
Thank you in advance ;)
Comment 1 boris64 2009-07-05 01:37:26 UTC
Created attachment 22211 [details]
lspci output
Comment 2 boris64 2009-07-05 01:38:26 UTC
Created attachment 22212 [details]
dmesg output (kernel-2.6.30.1) with working dvb adapter
Comment 3 boris64 2009-07-05 01:39:10 UTC
Created attachment 22213 [details]
dmesg output (kernel-2.6.31-rc2)
Comment 4 boris64 2009-07-11 13:08:35 UTC
FYI: There is no difference if i compile _all_ dvb frontends 
in the kernel or only the "ST STV0299 DVB-S" frontend(working in pre 2.6.31).
Comment 5 boris64 2009-07-12 13:10:29 UTC
Created attachment 22321 [details]
lspci -vnn

more verbose output of lspci
Comment 6 boris64 2009-07-12 13:53:24 UTC
Created attachment 22322 [details]
Kernel-2.6.30.1 config with working adapter
Comment 7 boris64 2009-07-12 13:54:06 UTC
Created attachment 22323 [details]
Kernel-2.6.31-rc2 config
Comment 8 Andrew Morton 2009-07-20 20:04:18 UTC
(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).


Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
add it to the regression tracking list.

btw, does the flexcop driver have a regular maintainer?  Or someone who
wants to volunteer?  MAINTAINERS is silent about it..

Thanks.

On Sun, 5 Jul 2009 01:36:31 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=13709
> 
>            Summary: b2c2-flexcop: no frontend driver found for this
>                     B2C2/FlexCop adapter w/ kernel-2.6.31-rc2
>            Product: v4l-dvb
>            Version: unspecified
>     Kernel Version: 2.6.31-rc1
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: dvb-frontend
>         AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org
>         ReportedBy: bugzilla.kernel.org@boris64.net
>         Regression: Yes
> 
> 
> Hi kernel people!
> 
> Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't
> working anymore, because no frontend driver is found.
> The frontend 'ST STV0299 DVB-S' is compiled into the kernel
> and _did_ work fine in pre-2.6.31 kernels.
> 
> 
> [lspci]
> ...
> 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB
> chip
> / Technisat SkyStar2 DVB card (rev 02)
> [/lspci]
> 
> [dmesg]
> Working kernel-2.6.30.1:
> ------------------------
> ...
> b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> successfully
> b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> b2c2-flexcop: found 'ST STV0299 DVB-S' .
> b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation
> (HD5000)'
> at the 'PCI' bus controlled by a 'FlexCopIIb' complete
> ...
> 
> Non-working kernel-2.6.31-rc:
> ------------------------
> ...
> b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> successfully
> b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
> b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled
> ...
> [/dmesg]
> 
> 
> I'll attach full dmesg+lspci.
> Please feel free to contact me if you need more infos.
> Thank you in advance ;)
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
Comment 9 Trent Piepho 2009-07-20 20:21:35 UTC
On Mon, 20 Jul 2009, Andrew Morton wrote:
>
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
>
> Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
> add it to the regression tracking list.
>
> btw, does the flexcop driver have a regular maintainer?  Or someone who
> wants to volunteer?  MAINTAINERS is silent about it..

I produced a patch that fixed this problem over a month ago,
http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e

Maybe it should go into 2.6.31?

> Thanks.
>
> On Sun, 5 Jul 2009 01:36:31 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=13709
> >
> >            Summary: b2c2-flexcop: no frontend driver found for this
> >                     B2C2/FlexCop adapter w/ kernel-2.6.31-rc2
> >            Product: v4l-dvb
> >            Version: unspecified
> >     Kernel Version: 2.6.31-rc1
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: dvb-frontend
> >         AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org
> >         ReportedBy: bugzilla.kernel.org@boris64.net
> >         Regression: Yes
> >
> >
> > Hi kernel people!
> >
> > Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't
> > working anymore, because no frontend driver is found.
> > The frontend 'ST STV0299 DVB-S' is compiled into the kernel
> > and _did_ work fine in pre-2.6.31 kernels.
> >
> >
> > [lspci]
> > ...
> > 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB
> chip
> > / Technisat SkyStar2 DVB card (rev 02)
> > [/lspci]
> >
> > [dmesg]
> > Working kernel-2.6.30.1:
> > ------------------------
> > ...
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> > successfully
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> > b2c2-flexcop: found 'ST STV0299 DVB-S' .
> > b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation
> (HD5000)'
> > at the 'PCI' bus controlled by a 'FlexCopIIb' complete
> > ...
> >
> > Non-working kernel-2.6.31-rc:
> > ------------------------
> > ...
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> > successfully
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> > b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled
> > ...
> > [/dmesg]
> >
> >
> > I'll attach full dmesg+lspci.
> > Please feel free to contact me if you need more infos.
> > Thank you in advance ;)
> >
> > --
> > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are on the CC list for the bug.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Comment 10 Trent Piepho 2009-07-20 20:21:43 UTC
On Mon, 20 Jul 2009, Andrew Morton wrote:
>
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
>
> Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
> add it to the regression tracking list.
>
> btw, does the flexcop driver have a regular maintainer?  Or someone who
> wants to volunteer?  MAINTAINERS is silent about it..

I produced a patch that fixed this problem over a month ago,
http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e

Maybe it should go into 2.6.31?

> Thanks.
>
> On Sun, 5 Jul 2009 01:36:31 GMT
> bugzilla-daemon@bugzilla.kernel.org wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=13709
> >
> >            Summary: b2c2-flexcop: no frontend driver found for this
> >                     B2C2/FlexCop adapter w/ kernel-2.6.31-rc2
> >            Product: v4l-dvb
> >            Version: unspecified
> >     Kernel Version: 2.6.31-rc1
> >           Platform: All
> >         OS/Version: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: dvb-frontend
> >         AssignedTo: v4l-dvb_dvb-frontend@kernel-bugs.osdl.org
> >         ReportedBy: bugzilla.kernel.org@boris64.net
> >         Regression: Yes
> >
> >
> > Hi kernel people!
> >
> > Since kernel-2.6.31-rc1 my Technisat SkyStar2 DVB card isn't
> > working anymore, because no frontend driver is found.
> > The frontend 'ST STV0299 DVB-S' is compiled into the kernel
> > and _did_ work fine in pre-2.6.31 kernels.
> >
> >
> > [lspci]
> > ...
> > 05:02.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB
> chip
> > / Technisat SkyStar2 DVB card (rev 02)
> > [/lspci]
> >
> > [dmesg]
> > Working kernel-2.6.30.1:
> > ------------------------
> > ...
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> > successfully
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> > b2c2-flexcop: found 'ST STV0299 DVB-S' .
> > b2c2-flexcop: initialization of 'Air2PC/AirStar 2 ATSC 3rd generation
> (HD5000)'
> > at the 'PCI' bus controlled by a 'FlexCopIIb' complete
> > ...
> >
> > Non-working kernel-2.6.31-rc:
> > ------------------------
> > ...
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
> > successfully
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> > b2c2-flexcop: MAC address = 00:d0:d7:0f:30:58
> > b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter
> > b2c2_flexcop_pci 0000:05:02.0: PCI INT A disabled
> > ...
> > [/dmesg]
> >
> >
> > I'll attach full dmesg+lspci.
> > Please feel free to contact me if you need more infos.
> > Thank you in advance ;)
> >
> > --
> > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> > ------- You are receiving this mail because: -------
> > You are on the CC list for the bug.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Comment 11 Andrew Morton 2009-07-20 20:40:30 UTC
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Mon, 20 Jul 2009, Andrew Morton wrote:
> >
> > (switched to email.  Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> >
> >
> > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
> > add it to the regression tracking list.
> >
> > btw, does the flexcop driver have a regular maintainer?  Or someone who
> > wants to volunteer?  MAINTAINERS is silent about it..
> 
> I produced a patch that fixed this problem over a month ago,
> http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e

Where is that patch now?  It isn't present in linux-next.

If it needs to be resent, please cc me on it?


Also, is there any way of avoiding this?

+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+ (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))

That's just way too tricky.  It expects all versions of the
preprocessor to be correctly implemented (unlikely) and there are other
tools like unifdef which want to parse kernel #defines.

otoh the trick does produce a nice result and doing it any other way
(which I can think of) would make a mess.

> Maybe it should go into 2.6.31?

It depends on the seriousness of the regression (number of people
affected, whether there's a workaround, etc) and upon the riskiness of
the patch.

But sure, we don't want regressions and letting one be released when we
already know about it and have a fix would be bad!

If the patch is judged too risky at this time, there might be a simpler
one, perhaps.

Or just revert whichever patch broke things.  Your changelog describes
this as simply "A recent patch" (bad changelog!) so I am unable to judge this.
Comment 12 Mauro Carvalho Chehab 2009-07-21 00:31:46 UTC
Em Mon, 20 Jul 2009 20:40:30 GMT
bugzilla-daemon@bugzilla.kernel.org escreveu:

> > > btw, does the flexcop driver have a regular maintainer?  Or someone who
> > > wants to volunteer?  MAINTAINERS is silent about it..

> > I produced a patch that fixed this problem over a month ago,
> > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> 
> Where is that patch now?  It isn't present in linux-next.

No, this patch is inside a series of 8 patches. They aren't at linux-next yet,
since I was waiting for some tests before applying it.

As there's a regression that is likely fixed by one of those patches, I'll add
it today.



Cheers,
Mauro
Comment 13 Anonymous Emailer 2009-07-21 03:30:12 UTC
Reply-To: hermann-pitton@arcor.de

Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> Trent Piepho <xyzzy@speakeasy.org> wrote:
> 
> > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > >
> > > (switched to email.  Please respond via emailed reply-to-all, not via the
> > > bugzilla web interface).
> > >
> > >
> > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael to
> > > add it to the regression tracking list.
> > >
> > > btw, does the flexcop driver have a regular maintainer?  Or someone who
> > > wants to volunteer?  MAINTAINERS is silent about it..
> > 
> > I produced a patch that fixed this problem over a month ago,
> > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> 
> Where is that patch now?  It isn't present in linux-next.
> 
> If it needs to be resent, please cc me on it?
> 
> 
> Also, is there any way of avoiding this?
> 
> +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> 
> That's just way too tricky.  It expects all versions of the
> preprocessor to be correctly implemented (unlikely) and there are other
> tools like unifdef which want to parse kernel #defines.
> 
> otoh the trick does produce a nice result and doing it any other way
> (which I can think of) would make a mess.
> 
> > Maybe it should go into 2.6.31?
> 
> It depends on the seriousness of the regression (number of people
> affected, whether there's a workaround, etc) and upon the riskiness of
> the patch.
> 
> But sure, we don't want regressions and letting one be released when we
> already know about it and have a fix would be bad!
> 
> If the patch is judged too risky at this time, there might be a simpler
> one, perhaps.
> 
> Or just revert whichever patch broke things.  Your changelog describes
> this as simply "A recent patch" (bad changelog!) so I am unable to judge
> this.
> 

Just revert it and let's wait for the next better attempt.

We might get a lot of noise, but the patch was wrong.

Cheers,
Hermann
Comment 14 Anonymous Emailer 2009-07-21 09:21:24 UTC
Reply-To: cyber.bogh@gmx.de

Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
> Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> >
> > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > (switched to email.  Please respond via emailed reply-to-all, not via
> > > > the bugzilla web interface).
> > > >
> > > >
> > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael
> > > > to add it to the regression tracking list.
> > > >
> > > > btw, does the flexcop driver have a regular maintainer?  Or someone
> > > > who wants to volunteer?  MAINTAINERS is silent about it..
> > >
> > > I produced a patch that fixed this problem over a month ago,
> > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> >
> > Where is that patch now?  It isn't present in linux-next.
> >
> > If it needs to be resent, please cc me on it?
> >
> >
> > Also, is there any way of avoiding this?
> >
> > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> >
> > That's just way too tricky.  It expects all versions of the
> > preprocessor to be correctly implemented (unlikely) and there are other
> > tools like unifdef which want to parse kernel #defines.
> >
> > otoh the trick does produce a nice result and doing it any other way
> > (which I can think of) would make a mess.
> >
> > > Maybe it should go into 2.6.31?
> >
> > It depends on the seriousness of the regression (number of people
> > affected, whether there's a workaround, etc) and upon the riskiness of
> > the patch.
> >
> > But sure, we don't want regressions and letting one be released when we
> > already know about it and have a fix would be bad!
> >
> > If the patch is judged too risky at this time, there might be a simpler
> > one, perhaps.
> >
> > Or just revert whichever patch broke things.  Your changelog describes
> > this as simply "A recent patch" (bad changelog!) so I am unable to judge
> > this.
>
> Just revert it and let's wait for the next better attempt.
>
> We might get a lot of noise, but the patch was wrong.

Absolutely nothing was wrong.
Your pure existance here is wrong if there is something wrong here!
As long as you do not have any clue about the subject I advise you to simply 
shut up, Pitton!
Is that clear, Pitton???

cyber.bogh

> Cheers,
> Hermann
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Comment 15 Anonymous Emailer 2009-07-21 09:21:31 UTC
Reply-To: cyber.bogh@gmx.de

Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
> Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> >
> > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > (switched to email.  Please respond via emailed reply-to-all, not via
> > > > the bugzilla web interface).
> > > >
> > > >
> > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael
> > > > to add it to the regression tracking list.
> > > >
> > > > btw, does the flexcop driver have a regular maintainer?  Or someone
> > > > who wants to volunteer?  MAINTAINERS is silent about it..
> > >
> > > I produced a patch that fixed this problem over a month ago,
> > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> >
> > Where is that patch now?  It isn't present in linux-next.
> >
> > If it needs to be resent, please cc me on it?
> >
> >
> > Also, is there any way of avoiding this?
> >
> > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> >
> > That's just way too tricky.  It expects all versions of the
> > preprocessor to be correctly implemented (unlikely) and there are other
> > tools like unifdef which want to parse kernel #defines.
> >
> > otoh the trick does produce a nice result and doing it any other way
> > (which I can think of) would make a mess.
> >
> > > Maybe it should go into 2.6.31?
> >
> > It depends on the seriousness of the regression (number of people
> > affected, whether there's a workaround, etc) and upon the riskiness of
> > the patch.
> >
> > But sure, we don't want regressions and letting one be released when we
> > already know about it and have a fix would be bad!
> >
> > If the patch is judged too risky at this time, there might be a simpler
> > one, perhaps.
> >
> > Or just revert whichever patch broke things.  Your changelog describes
> > this as simply "A recent patch" (bad changelog!) so I am unable to judge
> > this.
>
> Just revert it and let's wait for the next better attempt.
>
> We might get a lot of noise, but the patch was wrong.

Absolutely nothing was wrong.
Your pure existance here is wrong if there is something wrong here!
As long as you do not have any clue about the subject I advise you to simply 
shut up, Pitton!
Is that clear, Pitton???

cyber.bogh

> Cheers,
> Hermann
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Comment 16 Anonymous Emailer 2009-07-21 13:26:25 UTC
Reply-To: patrick.boettcher@desy.de

Hi all,

On Mon, 20 Jul 2009, Mauro Carvalho Chehab wrote:

> Em Mon, 20 Jul 2009 20:40:30 GMT
> bugzilla-daemon@bugzilla.kernel.org escreveu:
>
>>>> btw, does the flexcop driver have a regular maintainer?  Or someone who
>>>> wants to volunteer?  MAINTAINERS is silent about it..
>
>>> I produced a patch that fixed this problem over a month ago,
>>> http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
>>
>> Where is that patch now?  It isn't present in linux-next.
>
> No, this patch is inside a series of 8 patches. They aren't at linux-next
> yet,
> since I was waiting for some tests before applying it.
>
> As there's a regression that is likely fixed by one of those patches, I'll
> add
> it today.

Please go ahead committing this patch as it fixes a bug. Full validation 
is not yet done and not so easily possible - seems to become an indirect 
validation.

thanks,
Patrick.

--
   Mail: patrick.boettcher@desy.de
   WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
Comment 17 Anonymous Emailer 2009-07-21 22:21:40 UTC
Reply-To: hermann-pitton@arcor.de

Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
> Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
> > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> > >
> > > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > > (switched to email.  Please respond via emailed reply-to-all, not via
> > > > > the bugzilla web interface).
> > > > >
> > > > >
> > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask Rafael
> > > > > to add it to the regression tracking list.
> > > > >
> > > > > btw, does the flexcop driver have a regular maintainer?  Or someone
> > > > > who wants to volunteer?  MAINTAINERS is silent about it..
> > > >
> > > > I produced a patch that fixed this problem over a month ago,
> > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> > >
> > > Where is that patch now?  It isn't present in linux-next.
> > >
> > > If it needs to be resent, please cc me on it?
> > >
> > >
> > > Also, is there any way of avoiding this?
> > >
> > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > >
> > > That's just way too tricky.  It expects all versions of the
> > > preprocessor to be correctly implemented (unlikely) and there are other
> > > tools like unifdef which want to parse kernel #defines.
> > >
> > > otoh the trick does produce a nice result and doing it any other way
> > > (which I can think of) would make a mess.
> > >
> > > > Maybe it should go into 2.6.31?
> > >
> > > It depends on the seriousness of the regression (number of people
> > > affected, whether there's a workaround, etc) and upon the riskiness of
> > > the patch.
> > >
> > > But sure, we don't want regressions and letting one be released when we
> > > already know about it and have a fix would be bad!
> > >
> > > If the patch is judged too risky at this time, there might be a simpler
> > > one, perhaps.
> > >
> > > Or just revert whichever patch broke things.  Your changelog describes
> > > this as simply "A recent patch" (bad changelog!) so I am unable to judge
> > > this.
> >
> > Just revert it and let's wait for the next better attempt.
> >
> > We might get a lot of noise, but the patch was wrong.
> 
> Absolutely nothing was wrong.
> Your pure existance here is wrong if there is something wrong here!
> As long as you do not have any clue about the subject I advise you to simply 
> shut up, Pitton!
> Is that clear, Pitton???
> 
> cyber.bogh
> 

As always and as expected ;)

Uwe, use at least your real name, if you say you are not trolling this
time and serious about it. Bad enough, that you always have to come with
new names and addresses.

The way you dealt with Boris reporting his trouble was disgusting.

Started here.
http://www.spinics.net/lists/linux-media/msg07746.html

Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue
either ???

Trent's patches converting the tuners to dvb-pll later are not yet in
rc3 and the above fix attempt also not, but are all in mercurial
v4l-dvb. All not needed?

Why you don't provide Andrew with the information he is asking for?

Cheers,
Hermann
Comment 18 Anonymous Emailer 2009-07-22 03:43:23 UTC
Reply-To: cyber.bogh@gmx.de

Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie:
> Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
> > Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
> > > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> > > >
> > > > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > > > (switched to email.  Please respond via emailed reply-to-all, not
> > > > > > via the bugzilla web interface).
> > > > > >
> > > > > >
> > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask
> > > > > > Rafael to add it to the regression tracking list.
> > > > > >
> > > > > > btw, does the flexcop driver have a regular maintainer?  Or
> > > > > > someone who wants to volunteer?  MAINTAINERS is silent about it..
> > > > >
> > > > > I produced a patch that fixed this problem over a month ago,
> > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> > > >
> > > > Where is that patch now?  It isn't present in linux-next.
> > > >
> > > > If it needs to be resent, please cc me on it?
> > > >
> > > >
> > > > Also, is there any way of avoiding this?
> > > >
> > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > > >
> > > > That's just way too tricky.  It expects all versions of the
> > > > preprocessor to be correctly implemented (unlikely) and there are
> > > > other tools like unifdef which want to parse kernel #defines.
> > > >
> > > > otoh the trick does produce a nice result and doing it any other way
> > > > (which I can think of) would make a mess.
> > > >
> > > > > Maybe it should go into 2.6.31?
> > > >
> > > > It depends on the seriousness of the regression (number of people
> > > > affected, whether there's a workaround, etc) and upon the riskiness
> > > > of the patch.
> > > >
> > > > But sure, we don't want regressions and letting one be released when
> > > > we already know about it and have a fix would be bad!
> > > >
> > > > If the patch is judged too risky at this time, there might be a
> > > > simpler one, perhaps.
> > > >
> > > > Or just revert whichever patch broke things.  Your changelog
> > > > describes this as simply "A recent patch" (bad changelog!) so I am
> > > > unable to judge this.
> > >
> > > Just revert it and let's wait for the next better attempt.
> > >
> > > We might get a lot of noise, but the patch was wrong.
> >
> > Absolutely nothing was wrong.
> > Your pure existance here is wrong if there is something wrong here!
> > As long as you do not have any clue about the subject I advise you to
> > simply shut up, Pitton!
> > Is that clear, Pitton???
> >
> > cyber.bogh
>
> As always and as expected ;)
>
> Uwe, use at least your real name, if you say you are not trolling this
> time and serious about it. Bad enough, that you always have to come with
> new names and addresses.
>
> The way you dealt with Boris reporting his trouble was disgusting.

As long as idiots do not start to think they should be smashed right into 
their faces.....

> Started here.
> http://www.spinics.net/lists/linux-media/msg07746.html
>
> Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue
> either ???
>
> Trent's patches converting the tuners to dvb-pll later are not yet in
> rc3 and the above fix attempt also not, but are all in mercurial
> v4l-dvb. All not needed?

The question is:
Why is this crap in Mercurial?

The answer is: Chehab policy!

What does "Chehab policy" mean?
Well, it means that if you're Trent Piepho your stuff will be pulled in, even 
if it is the biggest thinkable crap that one ever can imagine.
For every other person really investigating and bringing in substantially 
better stuff there will be a public request whether there are objections or not 
(plus other possible hindrances of the more unfair kind), while people owing a 
repo at linuxtv.org are being trusted blindly.

This policy I would compare to the functionality of a small reactionary 
village of petit bourgeois small brains (i. e. IQ extremely limited - 
somewhere in the Southern states of the US perhaps?).

In other and thus quite non-misunderstanding words:

It's definitely NOT the task of Andrew Morton to take care that crap like this 
never reaches any relevant tree, may it be kernel or may it be Mercurial:

+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+ (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))

It's Chehab's task and noone else's. Basta!

And shall I tell you what the biggest pain about it all is?

Chehab is no single example.
So-called "maintainers" more and more degenerate to gatekeepers and patch 
samplers that wink through untested crap and thus produce unusable kernels.
"Responsible and honest behaviour" does not seem to exist in those no brains.

But:
Sorry if I overestimated your real IQ capabilities, Pitton!

cyber.bogh

> Why you don't provide Andrew with the information he is asking for?
>
> Cheers,
> Hermann
Comment 19 Anonymous Emailer 2009-07-22 03:43:31 UTC
Reply-To: cyber.bogh@gmx.de

Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie:
> Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
> > Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
> > > Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
> > > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> > > >
> > > > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > > > (switched to email.  Please respond via emailed reply-to-all, not
> > > > > > via the bugzilla web interface).
> > > > > >
> > > > > >
> > > > > > Guys, this is reportedly a post-2.6.30 regression - I'll ask
> > > > > > Rafael to add it to the regression tracking list.
> > > > > >
> > > > > > btw, does the flexcop driver have a regular maintainer?  Or
> > > > > > someone who wants to volunteer?  MAINTAINERS is silent about it..
> > > > >
> > > > > I produced a patch that fixed this problem over a month ago,
> > > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> > > >
> > > > Where is that patch now?  It isn't present in linux-next.
> > > >
> > > > If it needs to be resent, please cc me on it?
> > > >
> > > >
> > > > Also, is there any way of avoiding this?
> > > >
> > > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > > >
> > > > That's just way too tricky.  It expects all versions of the
> > > > preprocessor to be correctly implemented (unlikely) and there are
> > > > other tools like unifdef which want to parse kernel #defines.
> > > >
> > > > otoh the trick does produce a nice result and doing it any other way
> > > > (which I can think of) would make a mess.
> > > >
> > > > > Maybe it should go into 2.6.31?
> > > >
> > > > It depends on the seriousness of the regression (number of people
> > > > affected, whether there's a workaround, etc) and upon the riskiness
> > > > of the patch.
> > > >
> > > > But sure, we don't want regressions and letting one be released when
> > > > we already know about it and have a fix would be bad!
> > > >
> > > > If the patch is judged too risky at this time, there might be a
> > > > simpler one, perhaps.
> > > >
> > > > Or just revert whichever patch broke things.  Your changelog
> > > > describes this as simply "A recent patch" (bad changelog!) so I am
> > > > unable to judge this.
> > >
> > > Just revert it and let's wait for the next better attempt.
> > >
> > > We might get a lot of noise, but the patch was wrong.
> >
> > Absolutely nothing was wrong.
> > Your pure existance here is wrong if there is something wrong here!
> > As long as you do not have any clue about the subject I advise you to
> > simply shut up, Pitton!
> > Is that clear, Pitton???
> >
> > cyber.bogh
>
> As always and as expected ;)
>
> Uwe, use at least your real name, if you say you are not trolling this
> time and serious about it. Bad enough, that you always have to come with
> new names and addresses.
>
> The way you dealt with Boris reporting his trouble was disgusting.

As long as idiots do not start to think they should be smashed right into 
their faces.....

> Started here.
> http://www.spinics.net/lists/linux-media/msg07746.html
>
> Likely Matthias giving the hint with the #ifdef MODULE stuff has no clue
> either ???
>
> Trent's patches converting the tuners to dvb-pll later are not yet in
> rc3 and the above fix attempt also not, but are all in mercurial
> v4l-dvb. All not needed?

The question is:
Why is this crap in Mercurial?

The answer is: Chehab policy!

What does "Chehab policy" mean?
Well, it means that if you're Trent Piepho your stuff will be pulled in, even 
if it is the biggest thinkable crap that one ever can imagine.
For every other person really investigating and bringing in substantially 
better stuff there will be a public request whether there are objections or not 
(plus other possible hindrances of the more unfair kind), while people owing a 
repo at linuxtv.org are being trusted blindly.

This policy I would compare to the functionality of a small reactionary 
village of petit bourgeois small brains (i. e. IQ extremely limited - 
somewhere in the Southern states of the US perhaps?).

In other and thus quite non-misunderstanding words:

It's definitely NOT the task of Andrew Morton to take care that crap like this 
never reaches any relevant tree, may it be kernel or may it be Mercurial:

+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+ (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))

It's Chehab's task and noone else's. Basta!

And shall I tell you what the biggest pain about it all is?

Chehab is no single example.
So-called "maintainers" more and more degenerate to gatekeepers and patch 
samplers that wink through untested crap and thus produce unusable kernels.
"Responsible and honest behaviour" does not seem to exist in those no brains.

But:
Sorry if I overestimated your real IQ capabilities, Pitton!

cyber.bogh

> Why you don't provide Andrew with the information he is asking for?
>
> Cheers,
> Hermann
Comment 20 Trent Piepho 2009-07-22 07:19:02 UTC
On Mon, 20 Jul 2009, Andrew Morton wrote:
> On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> Trent Piepho <xyzzy@speakeasy.org> wrote:
> > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > I produced a patch that fixed this problem over a month ago,
> > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
>
> Where is that patch now?  It isn't present in linux-next.

Mauro has how pulled it from me and so it will probably show up in his tree
soon.

> Also, is there any way of avoiding this?
>
> +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
>
> That's just way too tricky.  It expects all versions of the
> preprocessor to be correctly implemented (unlikely) and there are other
> tools like unifdef which want to parse kernel #defines.

What's so tricky about it?  A quick grep shows hundreds of uses of
## for concatenation.

> otoh the trick does produce a nice result and doing it any other way
> (which I can think of) would make a mess.

This particular kind of test is something that is used many times in the
dvb code.  This isn't the first time someone has gotten it wrong by a long
shot.  Mauro suggested, and I agree, that for the next kernel we should put
FE_SUPPORTED into a dvb header file and convert the many existing tests to
use it.  Maybe this will reduce the number of mistakes.

> Or just revert whichever patch broke things.  Your changelog describes
> this as simply "A recent patch" (bad changelog!) so I am unable to judge
> this.

It was commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, but it was not
committed until five days after I made my patch, so there was no hash to
reference yet.  I suppose I should have used the patch title.
Comment 21 Trent Piepho 2009-07-22 07:19:10 UTC
On Mon, 20 Jul 2009, Andrew Morton wrote:
> On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> Trent Piepho <xyzzy@speakeasy.org> wrote:
> > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > I produced a patch that fixed this problem over a month ago,
> > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
>
> Where is that patch now?  It isn't present in linux-next.

Mauro has how pulled it from me and so it will probably show up in his tree
soon.

> Also, is there any way of avoiding this?
>
> +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
>
> That's just way too tricky.  It expects all versions of the
> preprocessor to be correctly implemented (unlikely) and there are other
> tools like unifdef which want to parse kernel #defines.

What's so tricky about it?  A quick grep shows hundreds of uses of
## for concatenation.

> otoh the trick does produce a nice result and doing it any other way
> (which I can think of) would make a mess.

This particular kind of test is something that is used many times in the
dvb code.  This isn't the first time someone has gotten it wrong by a long
shot.  Mauro suggested, and I agree, that for the next kernel we should put
FE_SUPPORTED into a dvb header file and convert the many existing tests to
use it.  Maybe this will reduce the number of mistakes.

> Or just revert whichever patch broke things.  Your changelog describes
> this as simply "A recent patch" (bad changelog!) so I am unable to judge
> this.

It was commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, but it was not
committed until five days after I made my patch, so there was no hash to
reference yet.  I suppose I should have used the patch title.
Comment 22 Andrew Morton 2009-07-22 07:58:08 UTC
On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org> wrote:

> On Mon, 20 Jul 2009, Andrew Morton wrote:
> > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > I produced a patch that fixed this problem over a month ago,
> > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> >
> > Where is that patch now?  It isn't present in linux-next.
> 
> Mauro has how pulled it from me and so it will probably show up in his tree
> soon.
> 
> > Also, is there any way of avoiding this?
> >
> > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> >
> > That's just way too tricky.  It expects all versions of the
> > preprocessor to be correctly implemented (unlikely) and there are other
> > tools like unifdef which want to parse kernel #defines.
> 
> What's so tricky about it?  A quick grep shows hundreds of uses of
> ## for concatenation.

Not the concatenation, of course.

The worrisomie thing is the macro which expands to preprocessor
statements.  It requires that the preprocessor run itself multiple
times across the same line.  Or something.  I don't recall seeing that
trick used elsewhere in the kernel and I have vague memories of it
causing problems in the past.
Comment 23 Mauro Carvalho Chehab 2009-07-22 13:13:09 UTC
Em Wed, 22 Jul 2009 07:58:08 GMT
bugzilla-daemon@bugzilla.kernel.org escreveu:

> --- Comment #22 from Andrew Morton <akpm@linux-foundation.org>  2009-07-22
> 07:58:08 ---
> On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho <xyzzy@speakeasy.org>
> wrote:
> > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
> > > Trent Piepho <xyzzy@speakeasy.org> wrote:
> > > > On Mon, 20 Jul 2009, Andrew Morton wrote:
> > > > I produced a patch that fixed this problem over a month ago,
> > > > http://www.linuxtv.org/hg/~tap/v4l-dvb/rev/748c762fcf3e
> > >
> > > Where is that patch now?  It isn't present in linux-next.
> > 
> > Mauro has how pulled it from me and so it will probably show up in his tree
> > soon.

Looking at commit d66b94b4aa2f40e134f8c07c58ae74ef3d523ee0, it is clear that
the case where DVB frontends are builtin into kernel weren't considered. So,
the better is to add this patch or something similar to fix the issue.

Except for that, the patch seems correct. 

Since this is a cleanup patch, reverting it won't cause regressions, but IMO,
now the code looks on a better shape.

> > > Also, is there any way of avoiding this?
> > >
> > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > >
> > > That's just way too tricky.  It expects all versions of the
> > > preprocessor to be correctly implemented (unlikely) and there are other
> > > tools like unifdef which want to parse kernel #defines.
> > 
> > What's so tricky about it?  A quick grep shows hundreds of uses of
> > ## for concatenation.
> 
> Not the concatenation, of course.
> 
> The worrisomie thing is the macro which expands to preprocessor
> statements.  It requires that the preprocessor run itself multiple
> times across the same line.  Or something.  I don't recall seeing that
> trick used elsewhere in the kernel and I have vague memories of it
> causing problems in the past.

Hmm... if the macro shouldn't be used due to gcc preprocessor bugs, we need to seek
to another alternative for doing something similar. 

A simple fix would be to add the check for CONFIG_DVB_foo on all places at
flexcorp. However, as the number of tests like that on DVB is very high and, as
almost all DVB developers use modules only on their tests, it is a common bug
to forget to test for the builtin case. So, I prefer to have an approach that
would avoid regressions.

One alternative would be to create a series of hidden Kconfig boolean items
that is true if a frontend is selected as module or as builtin, like:

config DVB_MT312
        tristate "Zarlink VP310/MT312/ZL10313 based"
        depends on DVB_CORE && I2C
        default m if DVB_FE_CUSTOMISE
        help
          A DVB-S tuner module. Say Y when you want to support this frontend.

config FE_MT312
	boolean
	depends on DVB_MT312

However, this would duplicate all FE Kbuild items (and probably tuners) and
will increase the complexity of Kconfig.

Another alternative would be to use boolean Kconfig items for
enabling/disabling FE/tuners, and a global boolean item to select if fronends
would be built as modules or as builtin. The rationale is that there aren't
much advantage of having parts of the frontends built as modules and others as
builtin, and such patch will reduce the number of possibilities (and the
probability of potential failures) at Kbuild.

A third alternative would be to have a header file that does the trick on an old way, like:

#ifdef CONFIG_MODULE
	#ifdef CONFIG_DVB_MT312_MODULE)
		#define FE_MT312
	#endif
	...
#else
	#ifdef CONFIG_DVB_MT312)
		#define FE_MT312
	#endif
	...
#endif

Finally, a forth alternative would be to change Kbuild to define a macro symbol
that will be true if the driver is either a module or builtin.

IMO, Trent's solution were the clearer one, but, if this won't work with all
supported gcc versions, we need another alternative.

I'm in favor of using a solution that will avoid future regressions like that
by either some concatenation macro or by some other build tricks. 

Andrew, what do you think it would work better?

PS.: It should be noticed that there are other patches at Trent's series that will
use this macro while moving trivial tuner code from flexcop into dvb-pll
(where we handle the trivial tuner cases). So, if we decide to remove it, we'll
need to apply some glue to avoid bisect breakages.



Cheers,
Mauro
Comment 24 Rafael J. Wysocki 2009-07-27 20:52:25 UTC
On Monday 27 July 2009, Boris Cuber wrote:
> Am Sonntag, 26. Juli 2009 schrieben Sie:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> >
> > The following bug entry is on the current list of known regressions
> > from 2.6.30.  Please verify if it still should be listed and let me know
> > (either way).
> >
> >
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13709
> > Subject             : b2c2-flexcop: no frontend driver found for this
> B2C2/FlexCop
> > adapter w/ kernel-2.6.31-rc2 Submitter      : boris64
> > <bugzilla.kernel.org@boris64.net>
> > Date                : 2009-07-05 01:36 (22 days old)
> 
> Compiling the b2c2-flexcop and frontend modules into the kernel 
> still (kernel-2.6.31-rc4) results in a nonworking "Technisat SkyStar2"
> dvb adapter.
Comment 25 boris64 2009-07-27 22:06:51 UTC
This issue is fixed since 2.6.31-rc4-00109-ge00b95d-dirty.
(-> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;f=drivers/media/dvb/b2c2/flexcop-fe-tuner.c;hb=68b7f7616add4b1de0fe75015ba3884d2d9ff796)

Thank you for helping out.
Comment 26 Trent Piepho 2009-07-29 23:53:56 UTC
On Wed, 22 Jul 2009, Andrew Morton wrote:
> > > Also, is there any way of avoiding this?
> > >
> > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > >
> > > That's just way too tricky.  It expects all versions of the
> > > preprocessor to be correctly implemented (unlikely) and there are other
> > > tools like unifdef which want to parse kernel #defines.
> >
> > What's so tricky about it?  A quick grep shows hundreds of uses of
> > ## for concatenation.
>
> Not the concatenation, of course.
>
> The worrisomie thing is the macro which expands to preprocessor
> statements.  It requires that the preprocessor run itself multiple
> times across the same line.  Or something.  I don't recall seeing that
> trick used elsewhere in the kernel and I have vague memories of it
> causing problems in the past.

Well, there is this now:

arch/powerpc/include/asm/cputable.h:#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \
include/drm/drmP.h:#define __OS_HAS_AGP (defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE)))
include/drm/drmP.h:#define __OS_HAS_MTRR (defined(CONFIG_MTRR))

Though I can't find any macros with arguments that use those arguments in
preprocessor directives.
Comment 27 Trent Piepho 2009-07-29 23:54:04 UTC
On Wed, 22 Jul 2009, Andrew Morton wrote:
> > > Also, is there any way of avoiding this?
> > >
> > > +#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
> > > + (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))
> > >
> > > That's just way too tricky.  It expects all versions of the
> > > preprocessor to be correctly implemented (unlikely) and there are other
> > > tools like unifdef which want to parse kernel #defines.
> >
> > What's so tricky about it?  A quick grep shows hundreds of uses of
> > ## for concatenation.
>
> Not the concatenation, of course.
>
> The worrisomie thing is the macro which expands to preprocessor
> statements.  It requires that the preprocessor run itself multiple
> times across the same line.  Or something.  I don't recall seeing that
> trick used elsewhere in the kernel and I have vague memories of it
> causing problems in the past.

Well, there is this now:

arch/powerpc/include/asm/cputable.h:#define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \
include/drm/drmP.h:#define __OS_HAS_AGP (defined(CONFIG_AGP) || (defined(CONFIG_AGP_MODULE) && defined(MODULE)))
include/drm/drmP.h:#define __OS_HAS_MTRR (defined(CONFIG_MTRR))

Though I can't find any macros with arguments that use those arguments in
preprocessor directives.