Resend since I received bad-mail-address bounces, sorry for any duplicated email. Am Mon, 26 Jun 2017 11:59:20 +0200 schrieb Ralph Metzler <rjkm@xxxxxxxxxxxxxx>: > Mauro Carvalho Chehab writes: > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > to > [...] > > change the makefile to: > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > The only detail is that "ddbridge.c" should be renamed to > > ddbridge-core.c (or something similar) and some *.h files will > > be needed. > > Hmm, ddbridge -> ddbridge-main would be fine. Funny, that's exactly the naming I had in mind when thinking about this in the past :) So, I'll propose a rough todo (commit list) for me (I will do and care about this) then: - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved reordering the functions in the code, this will be repeated with the current mainline driver (helps keeping the diff with the actual code bump cleaner) - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do it by having multiple objects in the makefile, adding header files with prototypes where required - 3/4: Bump the driver code with what is already there (means, the pre-cleaned variant w/o modulator and netstream/octonet stuff) - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by default Kconf opt, marked EXPERIMENTAL" thing I did to work around the still problematic MSI IRQ stuff to let users have a better experience) When done, I'll post the patches for early review, but they'll have a hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel like ripping this out since we want that support anyway). Additionally,I can do this for dddvb and submit it to the DigitalDevices dddvb repository (GitHub Pull Request) so we're at least in-sync wrt building the driver. Ralph, Mauro, are you ok with this? Mauro, in the meantime a decision should be made if the current in-kernel ddbridge should be kept somewhere or not (ie. as legacy driver). IMHO this is not absolutely neccessary since both driver variants (dddvb directly and the "castrated" one) are in use by people all around and besides MSI (which we can workaround until fixed finally) I don't know of any complaints at all. Best regards, Daniel Scheller -- https://github.com/herrnst