New: b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter w/ kernel-2.6.31-rc2

Bugme-new Andrew Morton 4 participants 10 messages Jul 20, 2009 – Jul 29, 2009 1 message not in the archive Media (V4L/DVB)

lore

Share & tools

lore

Andrew Morton

author

2009-07-20 20:04 UTC #1 lore raw

In reply to a message not in the archive

(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.

Quoted 67 lines · On Sun, 5 Jul 2009 01:36:31 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        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 ;)
Signature · 3 lines
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.

Trent Piepho

2009-07-20 20:21 UTC #2 lore raw

Quoted 10 lines · Andrew Morton

(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?

Quoted 77 lines

Thanks.
Quoted 59 lines · On Sun, 5 Jul 2009 01:36:31 GMT [email protected] 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: [email protected]
        ReportedBy: [email protected]
        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]
Quoted 8 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Andrew Morton

author

2009-07-20 20:40 UTC #3 lore raw

Quoted 6 lines · On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) Trent Piepho <[email protected]>…

Quoted 5 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 8 lines

Quoted 5 lines
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.

Quoted 1 line

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.

hermann pitton

2009-07-21 03:30 UTC #4 lore raw

Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:

Quoted 41 lines

Quoted 6 lines · On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) Trent Piepho <[email protected]>…
Quoted 5 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
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.

Quoted 9 lines

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

cyber.bogh

2009-07-21 09:21 UTC #5 lore raw

Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:

Quoted 47 lines

Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
Quoted 46 lines
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Quoted 5 lines · Trent Piepho
Quoted 4 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
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.

Quoted 7 lines

Quoted 3 lines
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

Quoted 10 lines

Cheers,
Hermann
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

hermann pitton

2009-07-21 22:21 UTC #6 lore raw

Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:

Quoted 56 lines

Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
Quoted 47 lines
Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
Quoted 46 lines
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Quoted 5 lines · Trent Piepho
Quoted 4 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
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.
Quoted 7 lines
Quoted 3 lines
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.

Quoted 8 lines

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

cyber.bogh

2009-07-22 03:43 UTC #7 lore raw

Am Mittwoch 22 Juli 2009 00:16:54 schrieben Sie:

Quoted 65 lines

Am Dienstag, den 21.07.2009, 11:20 +0200 schrieb cyber.bogh:
Quoted 56 lines
Am Dienstag 21 Juli 2009 05:27:01 schrieben Sie:
Quoted 47 lines
Am Montag, den 20.07.2009, 13:40 -0700 schrieb Andrew Morton:
Quoted 46 lines
On Mon, 20 Jul 2009 13:21:33 -0700 (PDT)
Quoted 5 lines · Trent Piepho
Quoted 4 lines · Andrew Morton
(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 8 lines
Quoted 5 lines
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.
Quoted 1 line
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
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

Quoted 7 lines

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.....

Quoted 9 lines

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

Quoted 4 lines

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

Trent Piepho

2009-07-22 07:19 UTC #8 lore raw

In reply to Andrew Morton

Quoted 7 lines · Andrew Morton

Quoted 3 lines · On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) Trent Piepho <[email protected]>…
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.

Quoted 8 lines

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.

Quoted 2 lines

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.

Quoted 2 lines

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.

Andrew Morton

author

2009-07-22 07:58 UTC #9 lore raw

Quoted 17 lines · On Wed, 22 Jul 2009 00:19:00 -0700 (PDT) Trent Piepho <[email protected]>…

Quoted 7 lines · Andrew Morton
Quoted 3 lines · On Mon, 20 Jul 2009 13:21:33 -0700 (PDT) Trent Piepho <[email protected]>…
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.
Quoted 5 lines
Also, is there any way of avoiding this?
+#define FE_SUPPORTED(fe) (defined(CONFIG_DVB_##fe) || \
+ (defined(CONFIG_DVB_##fe##_MODULE) && defined(MODULE)))

Quoted 6 lines

Quoted 3 lines
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.

Trent Piepho

2009-07-29 23:53 UTC #10 lore raw

Quoted 12 lines · Andrew Morton

Quoted 11 lines
Quoted 8 lines
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.

Quoted 7 lines

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.