Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Am Sun,  9 Jul 2017 21:42:07 +0200
schrieb Daniel Scheller :

> From: Daniel Scheller 
> 
> Preferrably for Linux 4.14 (to get things done).
> 
> [...]
> 
> Mauro/Media maintainers, this updates drivers/media/pci/ddbridge to
> the very latest code that DD carry in their vendor driver package as
> of version 0.9.29, in the "once, the big-bang-way is ok" way as
> discussed at [2] (compared to the incremental, awkward to do variant
> since that involves dissecting all available release archives and
> having to - try to - build proper commits out of this, which will
> always be inaccurate; a start was done at [3], however - and please
> understand - I definitely don't want to continue doing that...)
> 
> [...]

Feedback from "Dietmar Spingler ", a very
valuable tester, who has a huge share of getting the mainline
patches going, but isn't subscribed to the list, so posting in behalf
of him (added in Cc aswell):

"Running the patches on two Gentoo systems equipped with DD hardware
parts on current kernel versions:

* Digital Devices MaxS8
* Digital Devices MaxA8
* Digital Devices Octopus V3 Bridge, with a DuoFlex S2v4 and a DuoFlex
  CT2 attached
* 2x Digital Devices CI Duo PCIe Bridges

Several CAMs are in use to decrypt DVB-S(2) and DVB-T2 channels.
Running current VDR and minisatip on the userspace side. Everything
running without issues, even with all tuners active in parallel."

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Jasmin J.]

Hi!

Daniel lined out already what the technical differences are.
In fact nothing what the normal user of this very good DVB cards needs.
The Octopus NET has its own distribution provided by DD. So there is no need
to support this in the mainline Kernel at this time.

Also the modulator is something which might be used in central stations at
hotels, but not by the arbitrary user in the public. I guess this stations are
also equipped with the drivers from DD or even provided as a whole system by
this company. I also see no reason to support the modulator card *now*, when we
are in a stage where we need to put in nearly 7 years of improvements of the
DD driver into the Kernel. Yes, we are talking about nearly 7 years!

And there is another thing. The very old driver V 0.5.0 currently existing in
mainline, does not support the DD CI cards, which are an essential addon for
all users in Austria, Switzerland, ... . Without this CI cards it is
*impossible* to see the official TV program! This countries scramble the TS
stream to restrict the access to citizens.
Without bumping the ddbridge to V 0.9.29, we all living in this countries can't
use the Kernel driver, but only the DD version! Sticking to the DD version
means, we can't use other cards in parallel, because the DD version simply
doesn't support to use any other driver together with the DD cards, due to the
API changes and the currently used old DVB core.

In my opinion nearly nobody is using the current mainline driver, due to it's
limitations and the fact, that the DD version provides all the features we
need. So merging the new version will not harm anyone, but help to prevent
using self compiled incompatible drivers.

In my opinion it should have been DD's task to keep the DD version in sync
with mainline. Moreover they should have needed to upstream their changes
in the past in little steps. Instead they changed the API and made it more or
less impossible to merge it without a lot of effort!

As Daniel already mentioned, he spent 1,5 years to understand the driver, to
make it compatible to the Mainline DVB core, to provide patches, to test the
result, to get other people involved to test the new drivers, ... .
When this is not merged *now*, I guess we will lose *the* person who made it
happen! There were other people who tried it, but didn't have the endurance
and energy to meet the target.
Daniel will definitely continue working on this subject to keep the DD
version in sync with the mainline version, even if there are some things still
different.

We are very close to the target and making it now a stopper for the mentioned
little things is the worst thing we can do!

Beside all this organisational issue, I had the chance to use this driver for
a couple of days on my test system:
  DD Cine V 6.5 with a
  DD Duoflex CI (single) and a
  DD Duoflex S2 V4 tuner card
  VDR 2.3.8, ddci2 Plugin 1.5.0

And the productive system:
  DD Octopus CI (dual) with a
  DD Duoflex S2 tuner card
  VDR 2.2.0, ddci2 Plugin 1.5.0

I had no issues, beside small problems with my CAM on the productive system,
which I also had with the upstream DD driver. I am already debugging them, but
need support from Ralph concerning FPGA registers and maybe more. This problem
has nothing to do with the new drivers, so it is no stopper for merging it into
mainline.

With this eMail I add my
  Tested-by: Jasmin Jessich 
for this whole series.

Finally I want to thank Daniel for his effort and I adjure Mauro to merge
this now!

BR,
   Jasmin

*

On 07/20/2017 08:25 PM, Daniel Scheller wrote:
> Hi Mauro,
> 
> Am Thu, 20 Jul 2017 12:24:12 -0300
> schrieb Mauro Carvalho Chehab :
> 
>> Em Tue, 11 Jul 2017 17:30:13 +0200
>> Daniel Scheller  escreveu:
>>
>>> Am Tue, 11 Jul 2017 11:11:27 +0200
>>> schrieb Ralph Metzler :
>>>   
 Daniel Scheller writes:
  > 
  > IIRC this was -main.c, and basically the code split, but no
  > specific file. However, each of the additionals (hw, io, irq)
  > were done with a reason (please also see their commit messages
  > at patches 4-6):
  > [...]

 As I wrote before, changes like this will break other things like
 the OctopusNet build tree. So, I cannot use them like this or
 without changes at other places. And even if I wanted to, I
 cannot pull anything into the public dddvb repository.
>>>
>>> Ok, you probably have seen the PRs I created against dddvb, as they
>>> apply basically the same as is contained in this patchset, and even
>>> fixes a few minors. Thus, lets not declare this as merge-blocker for
>>> this patches, please.  
>>
>> I would prefer if we could spend more time trying to find a way where
>> we can proceed without increasing the discrepancies between upstream
>> and DD tree, but, instead to reduce. 
>>
>> I mean, if we know 

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Hi Mauro,

Am Thu, 20 Jul 2017 12:24:12 -0300
schrieb Mauro Carvalho Chehab :

> Em Tue, 11 Jul 2017 17:30:13 +0200
> Daniel Scheller  escreveu:
> 
> > Am Tue, 11 Jul 2017 11:11:27 +0200
> > schrieb Ralph Metzler :
> >   
> > > Daniel Scheller writes:
> > >  > 
> > >  > IIRC this was -main.c, and basically the code split, but no
> > >  > specific file. However, each of the additionals (hw, io, irq)
> > >  > were done with a reason (please also see their commit messages
> > >  > at patches 4-6):
> > >  > [...]
> > > 
> > > As I wrote before, changes like this will break other things like
> > > the OctopusNet build tree. So, I cannot use them like this or
> > > without changes at other places. And even if I wanted to, I
> > > cannot pull anything into the public dddvb repository.
> > 
> > Ok, you probably have seen the PRs I created against dddvb, as they
> > apply basically the same as is contained in this patchset, and even
> > fixes a few minors. Thus, lets not declare this as merge-blocker for
> > this patches, please.  
> 
> I would prefer if we could spend more time trying to find a way where
> we can proceed without increasing the discrepancies between upstream
> and DD tree, but, instead to reduce. 
> 
> I mean, if we know that some change won't be accepted at DD tree,
> better to change our approach to another one that it is acceptable
> on both upstream and DD trees.

(hopefully not too much language barrier coming up...)

First and foremost (to everyone involved) - I appeal at you all, in
the name of all DD hardware owners, for like six approaches to get the
patches in shape and over 1.5 years of spare time spent, to not make
this a reason to block the patches. And yes, Mauro, I understand
what you're up to.

Rather, this closes the gap between the current dddvb drivers and what
we have in mainline by at least 24 (!!) (plus some minor revisions and
other intermediate versions I couldn't get tar archives for) software
releases. Plus, the only real difference we have after these patches is
support for the DVB-C modulator cards and the OctoNET box support (with
that, support for the aforementioned GTL links, which I even already
have a patch for to add that back), and both are features that are
removed *for now* only due to the API changes involved, which simply is
a tad too much for me right now to add them in and provide reasoning
why they're needed and what exactly they do. Speaking of the modulator
card support, things are even quite simple, see [1] and [2] what I
gathered from the package to have all things API in place. In
addition, the parts in ddbridge can be added back quite easily (some
output-dma things, PCI IDs plus ddbridge-mod[ulator].c). If these two
simple things are acceptable in DVB core, I can even prepare patches
for getting the modulator support back in.

As Ralph mentioned the three additional files -irq, -io and -hw, I do
not insist on them, but rather thought it'd be a good way to further
make things cleaner, by separating things more.

So, again, please do not make this a blocker, but lets rather make this
a start to get things closer to each other, and continue in doing so by
finding agreements in parallel. And: I _WILL_ care about keeping the
mainline version in sync with upstream and NOT diverge further; this is
what the MAINTAINERS entry is meant for at last!

[1]
https://github.com/herrnst/dddvb-linux-kernel/commit/c586db283ef51f43ecb1d1c9e49230184ea02714
[2]
https://github.com/herrnst/dddvb-linux-kernel/commit/f448a8485a24acec7b44ac418ef57b59eb8369cd

All the best,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Mauro Carvalho Chehab]

Em Tue, 11 Jul 2017 17:30:13 +0200
Daniel Scheller  escreveu:

> Am Tue, 11 Jul 2017 11:11:27 +0200
> schrieb Ralph Metzler :
> 
> > Daniel Scheller writes:  
> >  > 
> >  > IIRC this was -main.c, and basically the code split, but no
> >  > specific file. However, each of the additionals (hw, io, irq) were
> >  > done with a reason (please also see their commit messages at
> >  > patches 4-6):
> >  > [...]  
> > 
> > As I wrote before, changes like this will break other things like the
> > OctopusNet build tree. So, I cannot use them like this or without
> > changes at other places. And even if I wanted to, I cannot pull
> > anything into the public dddvb repository.  
> 
> Ok, you probably have seen the PRs I created against dddvb, as they
> apply basically the same as is contained in this patchset, and even
> fixes a few minors. Thus, lets not declare this as merge-blocker for
> this patches, please.

I would prefer if we could spend more time trying to find a way where
we can proceed without increasing the discrepancies between upstream
and DD tree, but, instead to reduce. 

I mean, if we know that some change won't be accepted at DD tree,
better to change our approach to another one that it is acceptable
on both upstream and DD trees.


Thanks,
Mauro

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Richard Scobie]

Daniel Scheller wrote:

From: Daniel Scheller 

Preferrably for Linux 4.14 (to get things done).

Hard-depends on the STV0910/STV6111 driver patchset as the diff and the
updated code depends on the driver and the changes involved with the
glue code of the STV/DDCineS2V7 series [1].

Mauro/Media maintainers, this updates drivers/media/pci/ddbridge to the
very latest code that DD carry in their vendor driver package as of
version 0.9.29, in the "once, the big-bang-way is ok" way as discussed at
[2] (compared to the incremental, awkward to do variant since that
involves dissecting all available release archives and having to - try
to - build proper commits out of this, which will always be inaccurate;
a start was done at [3], however - and please understand - I definitely
don't want to continue doing that...)


-snip

Posting another "tested by" for this patch series, in conjunction with 
the recently posted STV0910/STV6111 set that I've been testing longer term


Have been running this series, since it was posted here, several hours 
daily on a dedicated vdr based PVR with a Digital Devices Cine S2 V7A, 
kernel 4.12 and vdr 2.3.8.


MSI interrupts are enabled and no issues to date.

Thanks to Daniel and the reviewers.

Regards,

Richard

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Am Tue, 11 Jul 2017 11:11:27 +0200
schrieb Ralph Metzler :

> Daniel Scheller writes:
>  > 
>  > IIRC this was -main.c, and basically the code split, but no
>  > specific file. However, each of the additionals (hw, io, irq) were
>  > done with a reason (please also see their commit messages at
>  > patches 4-6):
>  > [...]
> 
> As I wrote before, changes like this will break other things like the
> OctopusNet build tree. So, I cannot use them like this or without
> changes at other places. And even if I wanted to, I cannot pull
> anything into the public dddvb repository.

Ok, you probably have seen the PRs I created against dddvb, as they
apply basically the same as is contained in this patchset, and even
fixes a few minors. Thus, lets not declare this as merge-blocker for
this patches, please.

It'd of course be very valuable if you continue to commit incremental
changes to your drivers, so we can move on with the plan to keep the
in-kernel-driver (if merged) uptodate in a timely manner. After
over 1.5years I believe I know the driver quite well now so I won't get
troubles picking up things by hand.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Ralph Metzler]

Daniel Scheller writes:
 > Am Mon, 10 Jul 2017 10:11:01 +0200
 > schrieb Ralph Metzler :
 > 
 > > Daniel Scheller writes:
 > >  > Stripped functionality compared to dddvb:
 > >  > 
 > >  >  - DVB-C modulator card support removed (requires DVB core API)  
 > > 
 > > not really besides one device name entry.
 > 
 > ... and a header :-) Maybe we should start another thread on this for a
 > probable follow-up project.
 > 
 > >  >  - OctoNET SAT>IP server/box support removed (requires API aswell)
 > >  >  - with this, GT link support was removed (only on OctoNET
 > >  > hardware)  
 > > 
 > > There is other PCIe based hardware which uses/will use this.
 > 
 > Umm, good to know - thus better shouldn't (even accidentally)
 > throw away the remove-revert of the GTL support for future cards.
 > 
 > >  >  drivers/media/pci/ddbridge/ddbridge-core.c | 4242
 > >  > ++--
 > >  > drivers/media/pci/ddbridge/ddbridge-hw.c   |  299 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-hw.h   |   52 +
 > >  > drivers/media/pci/ddbridge/ddbridge-i2c.c  |  310 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-io.h   |   71 +
 > >  > drivers/media/pci/ddbridge/ddbridge-irq.c  |  161 ++
 > >  > drivers/media/pci/ddbridge/ddbridge-main.c |  393 +++
 > >  > drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
 > >  > drivers/media/pci/ddbridge/ddbridge.h  |  355 ++-  
 > > 
 > > I thought we settled on core, i2c, main, (and mod, ns, which you do
 > > not include). This will diverge then from my code.
 > 
 > IIRC this was -main.c, and basically the code split, but no specific
 > file. However, each of the additionals (hw, io, irq) were done with a
 > reason (please also see their commit messages at patches 4-6):
 > 
 > -io.h is there since the comparably complex functions in the original
 > ddbridge.h sort of scared me off and IMHO shouldn't live together with
 > struct definitions and such, so I moved them to a separate object
 > first. With the GTL things removed, the remainder was rather small, and
 > Jasmin pointed me in the "make it static inline in a header instead"
 > direction. When eventually GTL gets added back, it should go into it's
 > own object/module.
 > 
 > -hw.c/h moves all things hardware-definition/info related like regmaps
 > into one single place, currently it's spread out into -main and -core,
 > which might make things difficult to find.
 > 
 > -irq.c gets rid of the need of additional ifdefs related to
 > CONFIG_PCI_MSI, in that "defined but unused function" warnings are
 > generated if this isn't defined. Again, also makes it easier to find,
 > rather than search through ~3800 lines of -core :)
 > 
 > If you're comfortable with this, I will propose it via a GitHub PR as
 > well (alongside the other things I'd like to push out to you). For the
 > in-kernel code, I'd prefer to keep it like this.


As I wrote before, changes like this will break other things like the OctopusNet
build tree. So, I cannot use them like this or without changes at other places.
And even if I wanted to, I cannot pull anything into the public dddvb 
repository.

Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

Am Mon, 10 Jul 2017 10:11:01 +0200
schrieb Ralph Metzler :

> Daniel Scheller writes:
>  > Stripped functionality compared to dddvb:
>  > 
>  >  - DVB-C modulator card support removed (requires DVB core API)  
> 
> not really besides one device name entry.

... and a header :-) Maybe we should start another thread on this for a
probable follow-up project.

>  >  - OctoNET SAT>IP server/box support removed (requires API aswell)
>  >  - with this, GT link support was removed (only on OctoNET
>  > hardware)  
> 
> There is other PCIe based hardware which uses/will use this.

Umm, good to know - thus better shouldn't (even accidentally)
throw away the remove-revert of the GTL support for future cards.

>  >  drivers/media/pci/ddbridge/ddbridge-core.c | 4242
>  > ++--
>  > drivers/media/pci/ddbridge/ddbridge-hw.c   |  299 ++
>  > drivers/media/pci/ddbridge/ddbridge-hw.h   |   52 +
>  > drivers/media/pci/ddbridge/ddbridge-i2c.c  |  310 ++
>  > drivers/media/pci/ddbridge/ddbridge-io.h   |   71 +
>  > drivers/media/pci/ddbridge/ddbridge-irq.c  |  161 ++
>  > drivers/media/pci/ddbridge/ddbridge-main.c |  393 +++
>  > drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
>  > drivers/media/pci/ddbridge/ddbridge.h  |  355 ++-  
> 
> I thought we settled on core, i2c, main, (and mod, ns, which you do
> not include). This will diverge then from my code.

IIRC this was -main.c, and basically the code split, but no specific
file. However, each of the additionals (hw, io, irq) were done with a
reason (please also see their commit messages at patches 4-6):

-io.h is there since the comparably complex functions in the original
ddbridge.h sort of scared me off and IMHO shouldn't live together with
struct definitions and such, so I moved them to a separate object
first. With the GTL things removed, the remainder was rather small, and
Jasmin pointed me in the "make it static inline in a header instead"
direction. When eventually GTL gets added back, it should go into it's
own object/module.

-hw.c/h moves all things hardware-definition/info related like regmaps
into one single place, currently it's spread out into -main and -core,
which might make things difficult to find.

-irq.c gets rid of the need of additional ifdefs related to
CONFIG_PCI_MSI, in that "defined but unused function" warnings are
generated if this isn't defined. Again, also makes it easier to find,
rather than search through ~3800 lines of -core :)

If you're comfortable with this, I will propose it via a GitHub PR as
well (alongside the other things I'd like to push out to you). For the
in-kernel code, I'd prefer to keep it like this.

Best regards,
Daniel Scheller
-- 
https://github.com/herrnst

[PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Ralph Metzler]

Daniel Scheller writes:
 > Stripped functionality compared to dddvb:
 > 
 >  - DVB-C modulator card support removed (requires DVB core API)

not really besides one device name entry.

 >  - OctoNET SAT>IP server/box support removed (requires API aswell)
 >  - with this, GT link support was removed (only on OctoNET hardware)

There is other PCIe based hardware which uses/will use this.


 >  drivers/media/pci/ddbridge/ddbridge-core.c | 4242 
 > ++--
 >  drivers/media/pci/ddbridge/ddbridge-hw.c   |  299 ++
 >  drivers/media/pci/ddbridge/ddbridge-hw.h   |   52 +
 >  drivers/media/pci/ddbridge/ddbridge-i2c.c  |  310 ++
 >  drivers/media/pci/ddbridge/ddbridge-io.h   |   71 +
 >  drivers/media/pci/ddbridge/ddbridge-irq.c  |  161 ++
 >  drivers/media/pci/ddbridge/ddbridge-main.c |  393 +++
 >  drivers/media/pci/ddbridge/ddbridge-regs.h |  138 +-
 >  drivers/media/pci/ddbridge/ddbridge.h  |  355 ++-

I thought we settled on core, i2c, main, (and mod, ns, which you do not 
include).
This will diverge then from my code.


Regards,
Ralph

[PATCH 00/14] ddbridge: bump to ddbridge-0.9.29

[Daniel Scheller]

From: Daniel Scheller 

Preferrably for Linux 4.14 (to get things done).

Hard-depends on the STV0910/STV6111 driver patchset as the diff and the
updated code depends on the driver and the changes involved with the
glue code of the STV/DDCineS2V7 series [1].

Mauro/Media maintainers, this updates drivers/media/pci/ddbridge to the
very latest code that DD carry in their vendor driver package as of
version 0.9.29, in the "once, the big-bang-way is ok" way as discussed at
[2] (compared to the incremental, awkward to do variant since that
involves dissecting all available release archives and having to - try
to - build proper commits out of this, which will always be inaccurate;
a start was done at [3], however - and please understand - I definitely
don't want to continue doing that...)

In patch 14, I add myself to MAINTAINERS. This means I will care about
getting driver updates as they're released by DD into mainline,  starting
from this (0.9.29) version, which is definitely doable in an incremental
way. So, I'll make sure the in-kernel driver won't bit-rot again, and it
will receive new hardware support as it becomes available in a timely
manner.

While the driver code bump looks massive, judging from the diff, there's
mostly a whole lot of refactoring and restructuring of variables, port/
link management and all such stuff in it. Feature-wise, this is most
notable:

 - Support for all (PCIe) CI (single/duo) cards and Flex addons
 - Support for MSI (Message Signaled Interrupts), though disabled by
   default since there were still reports of problems with this
 - TS Loopback support (set up ports to behave as if a CI is connected,
   without decryption of course)
 - As mentioned: Heavy code reordering, and split up into multiple files

Stripped functionality compared to dddvb:

 - DVB-C modulator card support removed (requires DVB core API)
 - OctoNET SAT>IP server/box support removed (requires API aswell)
 - with this, GT link support was removed (only on OctoNET hardware)
 - MaxS8 4/8 DVB-S/S2 card support (temporarily) removed (requires an
   additional Demod driver; subject for another series)

A note on the patches:

The bump starts by aligning the code "order-wise" to the updated driver,
to keep the diff a bit cleaner. Next, the code split is applied, without
actually changing any functionality. Compared to upstream, this isn't done
by moving functions into different C files and then do an include on them,
but we're handling them with the Makefile, building separate objects, and
having proper prototypes in ddbridge.h. After the code bump, further split
up is applied to increase readability and maintainability (also, for the
MaxS8 support, there will be another object with another ~400 LoC, which
originally lives in ddbridge-core aswell). Then, all issues found by W=1
and smatch are resolved, one by one. This is kept separate since those
fixes will be proposed for upstream inclusion. The last thing is the
addition of the MSI default Kconfig options which will mainly inform users
that there's something that might(!) cause issues but is still being
worked on - the default is "off" to provide a proper OotB experience.

To distinguish from the original unchanged vendor driver, "-integrated" is
suffixed to the version code.

Note on checkpatch:

First two patches are solely code-moving, so checkpatch will complain on
them. With the ddbridge code bump, all style issues are resolved.

Yes, you will hate me for this large code drop, but at least we sort-of
discussed this beforehand, and we have to start *somewhere*.

Thanks in advance for reviewing and (optimally) getting this merged and
getting the DD driver dilemma solved hopefully once and for all.

[1] http://www.spinics.net/lists/linux-media/msg117946.html
[2] http://www.spinics.net/lists/linux-media/msg117358.html
[3] 
https://github.com/herrnst/dddvb-linux-kernel/compare/4226861...mediatree/master-ddbupdate

Daniel Scheller (14):
  [media] ddbridge: move/reorder functions
  [media] ddbridge: split code into multiple files
  [media] ddbridge: bump ddbridge code to version 0.9.29
  [media] ddbridge: split I/O related functions off from ddbridge.h
  [media] ddbridge: split off IRQ handling
  [media] ddbridge: split off hardware definitions and mappings
  [media] ddbridge: check pointers before dereferencing
  [media] ddbridge: only register frontends in fe2 if fe is not NULL
  [media] ddbridge: fix possible buffer overflow in ddb_ports_init()
  [media] ddbridge: remove unreachable code
  [media] ddbridge: fix impossible condition warning
  [media] ddbridge: fix dereference before check
  [media] ddbridge: Kconfig option to control the MSI modparam default
  [media] MAINTAINERS: add entry for ddbridge

 MAINTAINERS|8 +
 drivers/media/pci/ddbridge/Kconfig |   15 +
 drivers/media/pci/ddbridge/Makefile|3 +-
 drivers/media/pci/ddbridge/ddbridge-core.c | 4242