reassign 630593 linux-2.6 forcemerge 630769 630593 retitle 630593 linux-parport: does not detect EPP modes correctly on Intel chipsets found 630593 linux-2.6/2.6.18.dfsg.1-10 found 630593 linux-2.6/2.6.22-6 tags 630593 = upstream quit
Hi Leo, Leopold Palomo-Avellaneda wrote: > A long time ago (~ 10 years), Intel produced a chipset that > included broken EPP support. The Linux parport driver was written to detect > such a chipset and disable EPP support on it. Unfortunately the test that was > written gives false positives for many current chipsets and no-one seems to > know exactly what the problem hardware was, let alone have a sample of it to > see if a better test can be written. After such a long time it is probably > appropriate to just remove the test [...] > I have applied the patch to the standard debian kernel and it compiles and > runs perfectly. Applied to some Dell hardware, now the EPP mode is detected > and, after some initial tests it's working. > > I don't have any hope that it would be solved in the linux kernel I think otherwise: this patch should be a shoe-in, at least via some tree like the mm tree. Based on MAINTAINERS, it looks like there is no one maintaining the Linux parport subsystem. So you (or anyone interested in this) will have to submit to Linus directly. It is not as hard as it sounds; see Documentation/SubmittingPatches for details. The short story: - first, write a quick summary (something like the above would do) of what the patch does and fixes. Use "The canonical patch format" --- i.e., subject line like "[PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets" and body with a clear explanation of the fix followed by the patch, separated by "---". Send it to linux-ker...@vger.kernel.org, cc-ing the linux-parport list and the other interested parties you can think of --- you can get a sense of who's been working on the parport subsystem recently with "git log drivers/parport" (looks like Nicos Gollan, Greg KH, Alan Cox, Alexander Gordeev). - next, listen to their feedback and address it. Send out a [PATCH/RFC v2] and so on. - finally, when the patch seems cooked, send a patch with [PATCH] in the subject line to Linus, cc-ing the same people as before. That's it. Does it sound reasonable to you? Once the patch is accepted upstream, we will be glad to include it. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
