[PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi again,

sorry for the noise and my mistake. The patch...

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam Baker said [1] :

<quote>
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 (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.
</quote>

I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471


Signed-off-by: Adam Baker <linux at baker-net.org.uk>
Signed-off-by: Leopold Palomo-Avellaneda <leo@alaxarxa.net>


---

[-- Attachment #2: patch_parport_bug.patch --]
[-- Type: text/x-patch, Size: 627 bytes --]

--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-				/* Phony EPP in ECP. */
-				return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 02:41:14PM +0200, Leopold Palomo-Avellaneda wrote:
> Hi again,
> 
> sorry for the noise and my mistake. The patch...
> 
> there's a bug in the parport module that have been reported (in another 
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
> nobody follow the report and it was closed.
> 
> As Adam Baker said [1] :
> 
> <quote>
> 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 (on average it does more harm than good) 
> however you are correct in asserting the driver is unmaintained so no-one is 
> bothering to fix it.
> </quote>
> 
> I have applied the patch to the standard debian kernel and vanilla kernels and 
> runs perfectly. The patch simply erases a check. Applied to some Dell 
> hardware, now the EPP mode is detected and, after some initial tests it's 
> working.
> 
> Please, apply the patch.
> 
> Best regards,
> 
> Leo
> 
> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
> 
> 
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>

You can not add someone else's signed-off-by: line to a patch, please go
re-read Documentation/SubmittingPatches as to why.

And did Adam originally write this patch?  Or did you?  If Adam, please
set the authorship information properly.

Oh, and please spell out email addresses properly in signed-off-by
lines, it doesn't hide anything when you do that :)

Third time's a charm?

greg k-h

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Jonathan Nieder]

Hi,

Greg KH wrote:

> You can not add someone else's signed-off-by: line to a patch, please go
> re-read Documentation/SubmittingPatches as to why.
>
> And did Adam originally write this patch?  Or did you?  If Adam, please
> set the authorship information properly.

>From a quick Google search:

http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html

It looks like this one does have Adam Baker's sign-off (and it is sad
how long this patch seems to have sat without being submitted to
mainline).

I don't know who originally had the idea of removing that code.  See
[1], [2], [3], and [4] for some early discussions.

The current "intel parport bug" test this patch removes seems to have
been introduced between 2.3.10pre5 and 2.3.10 (thanks to Dave Jones
for the git tree that makes such searches easy!).  That means some
time around June or July, 1999.  At the time, the parport maintainers
according to MAINTAINERS were Phil Blundell, Tim Waugh, David
Campbell, and Andrea Arcangeli.  From the patch "[PATCH] parport is an
orphan", 2007-03-05, I infer that not all of them are still interested
in the driver and whoever _is_ interested is probably subscribed to
the (low-volume) linux-parport list.

I'd say, why not get this patch in linux-next or -mm somehow and see
if anyone screams?  It would be _very_ useful to find an actual
instance of the "intel parport bug" so we could see what that code was
supposed to do and do it better.

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.linux.parport/322/focus=326
[2] http://thread.gmane.org/gmane.linux.parport/324/focus=327
[3] http://thread.gmane.org/gmane.linux.parport/806
[4] http://thread.gmane.org/gmane.linux.parport/925/focus=929

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Adam Baker]

On Thursday 15 September 2011, Jonathan Nieder wrote:
> Hi,
> 
> Greg KH wrote:
> > You can not add someone else's signed-off-by: line to a patch, please go
> > re-read Documentation/SubmittingPatches as to why.
> > 
> > And did Adam originally write this patch?  Or did you?  If Adam, please
> > set the authorship information properly.
> 
> From a quick Google search:
> 
> http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> 
> It looks like this one does have Adam Baker's sign-off (and it is sad
> how long this patch seems to have sat without being submitted to
> mainline).

The code has sat around for a long time because when I first posted the patch 
I got no feedback to indicate if anyone else was suffering from the bug and if 
anyone else had hardware that exhibited the bug it was supposed to fix so I 
didn't want to pursue submitting it. Over the years I have seen occasional 
reports of users suffering from the problem but I no longer have any EPP 
hardware to test it on.

That's why I posted the mail that said if someone else can verify the patch is 
still useful I'm happy for it to be submitted with my signed off by on it (and 
the original mail did use an @ sign, the word at got added by an email 
obfuscator in a mailing list archive along the way.)

> 
> I don't know who originally had the idea of removing that code.  See
> [1], [2], [3], and [4] for some early discussions.
> 
> The current "intel parport bug" test this patch removes seems to have
> been introduced between 2.3.10pre5 and 2.3.10 (thanks to Dave Jones
> for the git tree that makes such searches easy!).  That means some
> time around June or July, 1999.  At the time, the parport maintainers
> according to MAINTAINERS were Phil Blundell, Tim Waugh, David
> Campbell, and Andrea Arcangeli.  From the patch "[PATCH] parport is an
> orphan", 2007-03-05, I infer that not all of them are still interested
> in the driver and whoever _is_ interested is probably subscribed to
> the (low-volume) linux-parport list.
> 
> I'd say, why not get this patch in linux-next or -mm somehow and see
> if anyone screams?  It would be _very_ useful to find an actual
> instance of the "intel parport bug" so we could see what that code was
> supposed to do and do it better.
> 
> Thanks,
> Jonathan
> 
> [1] http://thread.gmane.org/gmane.linux.parport/322/focus=326
> [2] http://thread.gmane.org/gmane.linux.parport/324/focus=327
> [3] http://thread.gmane.org/gmane.linux.parport/806
> [4] http://thread.gmane.org/gmane.linux.parport/925/focus=929

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Jonathan Nieder]

Adam Baker wrote:

> The code has sat around for a long time because when I first posted the patch 
> I got no feedback to indicate if anyone else was suffering from the bug and if 
> anyone else had hardware that exhibited the bug it was supposed to fix so I 
> didn't want to pursue submitting it. Over the years I have seen occasional 
> reports of users suffering from the problem but I no longer have any EPP 
> hardware to test it on.
>
> That's why I posted the mail that said if someone else can verify the patch is 
> still useful I'm happy for it to be submitted with my signed off by on it

Makes sense.  Thanks for explaining and thanks for your work, Adam.
Actually I think 3 years before a patch gets the attention it deserves
is not so bad --- it was mostly that the problem has been known since
1999 that bothered me. :)

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

A Dijous, 15 de setembre de 2011, Jonathan Nieder va escriure:
> Adam Baker wrote:
> 
> > The code has sat around for a long time because when I first posted the 
patch 
> > I got no feedback to indicate if anyone else was suffering from the bug 
and if 
> > anyone else had hardware that exhibited the bug it was supposed to fix so 
I 
> > didn't want to pursue submitting it. Over the years I have seen occasional 
> > reports of users suffering from the problem but I no longer have any EPP 
> > hardware to test it on.
> >
> > That's why I posted the mail that said if someone else can verify the 
patch is 
> > still useful I'm happy for it to be submitted with my signed off by on it
> 
> Makes sense.  Thanks for explaining and thanks for your work, Adam.
> Actually I think 3 years before a patch gets the attention it deserves
> is not so bad --- it was mostly that the problem has been known since
> 1999 that bothered me. :)
> 

Well, 

seems that the questions be clarified. I would like to point some details. 
First of all I would like to say that I didn't make this patch. It was done by 
Adam Baker, as I have posted in all the mails with the link to the original 
post.

I put a bug report the the debian bug tracking system [1] with a copy to the  
linux-parport list. The debian guys ( Jonathan Nieder) proposed me to send 
this patch directly to the linux kernel system.

I have send this patch as I could, maybe I didn't pay so attention as I must. 
I send the patch because Adam Baker said:

<quote>
As the parport driver is currently orphaned you need to post a patch to the 
LKML if you want to get it included in mainline but if your prepared to do 
some testing that would be the best solution for everyone.
</quote>

I submitted the patch because it seemed impolite to ask Adam Baker that he did 
it. In the end it was I who had interest in it to be included in the kernel 
tree.

And as I was who had to answer the mails of the kernel list and make the whole 
procedure of the kernel patches, so I signed it. 

To me is perfect that this patch goes to the kernel and I could answer any 
question of it, or make any test. I have several Dell boxes and a PCI with an 
extra parport.

Best regards,

Leo

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593
-- 
--
Linux User 152692
Catalonia

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Bastien ROUCARIES]

On Thu, Sep 15, 2011 at 2:41 PM, Leopold Palomo-Avellaneda
<leo@alaxarxa.net> wrote:
> Hi again,
>
> sorry for the noise and my mistake. The patch...
>
> there's a bug in the parport module that have been reported (in another
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but
> nobody follow the report and it was closed.
>
> As Adam Baker said [1] :
>
> <quote>
> A long time ago (~ 10 years), Intel produced a chipset that

Why not check dmi years for this test and do the test only for board
before 2000 ? Better safe than sorry

Bastien



> 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 (on average it does more harm than good)
> however you are correct in asserting the driver is unmaintained so no-one is
> bothering to fix it.
> </quote>
>
> I have applied the patch to the standard debian kernel and vanilla kernels and
> runs perfectly. The patch simply erases a check. Applied to some Dell
> hardware, now the EPP mode is detected and, after some initial tests it's
> working.
>
> Please, apply the patch.
>
> Best regards,
>
> Leo
>
> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
>
>
> Signed-off-by: Adam Baker <linux at baker-net.org.uk>
> Signed-off-by: Leopold Palomo-Avellaneda <leo@alaxarxa.net>
>
>
> ---
>

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Bastien ROUCARIES]

On Thu, Sep 15, 2011 at 3:41 PM, Bastien ROUCARIES
<roucaries.bastien@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 2:41 PM, Leopold Palomo-Avellaneda
> <leo@alaxarxa.net> wrote:
>> Hi again,
>>
>> sorry for the noise and my mistake. The patch...
>>
>> there's a bug in the parport module that have been reported (in another
>> places) some time ago [1]. Also, this bug was reported at Redhat [2], but
>> nobody follow the report and it was closed.

Moreover they are more detail about this bug here you should contact
davbid campell

http://lists.infradead.org/pipermail/linux-parport/2004-March/000048.html

Bastien

>> As Adam Baker said [1] :
>>
>> <quote>
>> A long time ago (~ 10 years), Intel produced a chipset that
>
> Why not check dmi years for this test and do the test only for board
> before 2000 ? Better safe than sorry
>
> Bastien
>
>
>
>> 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 (on average it does more harm than good)
>> however you are correct in asserting the driver is unmaintained so no-one is
>> bothering to fix it.
>> </quote>
>>
>> I have applied the patch to the standard debian kernel and vanilla kernels and
>> runs perfectly. The patch simply erases a check. Applied to some Dell
>> hardware, now the EPP mode is detected and, after some initial tests it's
>> working.
>>
>> Please, apply the patch.
>>
>> Best regards,
>>
>> Leo
>>
>> [1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
>>
>>
>> Signed-off-by: Adam Baker <linux at baker-net.org.uk>
>> Signed-off-by: Leopold Palomo-Avellaneda <leo@alaxarxa.net>
>>
>>
>> ---
>>
>

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

A Dijous, 15 de setembre de 2011, Bastien ROUCARIES va escriure:
> On Thu, Sep 15, 2011 at 3:41 PM, Bastien ROUCARIES
> <roucaries.bastien@gmail.com> wrote:
> > On Thu, Sep 15, 2011 at 2:41 PM, Leopold Palomo-Avellaneda
> > <leo@alaxarxa.net> wrote:
> >> Hi again,
> >>
> >> sorry for the noise and my mistake. The patch...
> >>
> >> there's a bug in the parport module that have been reported (in another
> >> places) some time ago [1]. Also, this bug was reported at Redhat [2], but
> >> nobody follow the report and it was closed.
> 
> Moreover they are more detail about this bug here you should contact
> davbid campell
> 
> http://lists.infradead.org/pipermail/linux-parport/2004-March/000048.html

I think that this is a good approach, but it seems that this patch go to 
nowhere.... also solves another question of timeouts.

Leo



> Bastien
> 
> >> As Adam Baker said [1] :
> >>
> >> <quote>
> >> A long time ago (~ 10 years), Intel produced a chipset that
> >
> > Why not check dmi years for this test and do the test only for board
> > before 2000 ? Better safe than sorry
> >
> > Bastien
> >
> >
> >
> >> 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 (on average it does more harm than 
good)
> >> however you are correct in asserting the driver is unmaintained so no-one 
is
> >> bothering to fix it.
> >> </quote>
> >>
> >> I have applied the patch to the standard debian kernel and vanilla 
kernels and
> >> runs perfectly. The patch simply erases a check. Applied to some Dell
> >> hardware, now the EPP mode is detected and, after some initial tests it's
> >> working.
> >>
> >> Please, apply the patch.
> >>
> >> Best regards,
> >>
> >> Leo
> >>
> >> [1] http://lists.infradead.org/pipermail/linux-parport/2008-
March/000628.html
> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=284471
> >>
> >>
> >> Signed-off-by: Adam Baker <linux at baker-net.org.uk>
> >> Signed-off-by: Leopold Palomo-Avellaneda <leo@alaxarxa.net>
> >>
> >>
> >> ---
> >>
> >
> 


-- 
--
Linux User 152692
Catalonia

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Jonathan Nieder]

Bastien ROUCARIES wrote:

> Why not check dmi years for this test and do the test only for board
> before 2000 ? Better safe than sorry

That would just leave the code broken on boards before 2000.

Here's a reference to the problem the test was supposed to fix:

 http://lkml.indiana.edu/hypermail/linux/kernel/9901.2/1285.html

It says:

| A small number of IO chipsets do not have the EPP timeout function hence if 
| there is no EPP device then the CPU is permantly in the HALT state and nothing 
| happens LITERALLY! <CNTL><ALT><DEL> does not even function! The bulk (if not 
| all) the IO chipsets in this category fail the bug check test, as a result it 
| is assumed there is no EPP (or to dangerous to use). This may prevent some 
| valid chipsets working properly.

It sounds like the test removed by [1] has false positives and false
negatives.

Jan Axelson's "Parallel Port Complete" recommends:

 - first check for ECP as described in Microsoft's "Extended
   Capabilities Port Protocol and ISA Interface Standard" document:

   . First check for the presence of the ECR register, by checking
     that bits 0 and 1 act like "empty" and "full" bits (so they
     start out set and cleared respectively and after writing 0x34 you
     can read back 0x35).

     parport_ECR_present() does this and save the result to priv->ecr.

   . Put the port in configuration mode by writing 0xf4 to the ECR,
     etc (parport_ECP_supported() does these checks).

 - if the above fails, then check for EPP.  There are a couple of
   choices suggested for that:

   A) Write some values to one of the EPP registers and then read them
      back.  If nothing is plugged in there, that should provoke a
      timeout; the spec doesn't say what you read back, but she found
      that it would always read back what you wrote and that in practice
      it worked for discovering EPP ports.

   B) Check that the timeout bit (ECR bit 0) is set when a timeout occurs,
      and then clear it.  On some ports, just trying a transfer with
      nothing plugged in will provoke a timeout, while on others ECR bit 7
      needs to be set first.  And of course there's more than one way to
      clear it.

      Intel's 82091 data sheet does not mention the timeout bit at all.
      Maybe it doesn't implement it.

      http://www.lvr.com/jansfaq.htm also mentions "Beware #1: on
      SMC's chips (& maybe others), a set timeout bit can make the
      port unusable in any mode, until a hard reset (or clearing the
      bit)!"  So one does have to make sure to clear the bit.

Would it make sense to switch to doing (A)?  If not, is there some
test that can be used to detect an 82091 specifically (or are there
other chipsets that don't have the timeout bit)?  Cc-ing Jan for
advice (thanks for your work in documenting what makes parallel ports
tick, Jan!).

Thanks,
Jonathan

[1] http://thread.gmane.org/gmane.linux.kernel/1191591

[PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]

Hi again,

sorry for the noise and my mistake. The patch...

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam Baker said [1] :

<quote>
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 (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.
</quote>

I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471


Signed-off-by: Adam Baker <linux at baker-net.org.uk>
Signed-off-by: Leopold Palomo-Avellaneda <leo@alaxarxa.net>


---

[-- Attachment #2: patch_parport_bug.patch --]
[-- Type: text/x-patch, Size: 627 bytes --]

--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-				/* Phony EPP in ECP. */
-				return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

[PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Leopold Palomo-Avellaneda]

[-- Attachment #1: Type: Text/Plain, Size: 1282 bytes --]

Hi,

there's a bug in the parport module that have been reported (in another 
places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
nobody follow the report and it was closed.

As Adam baked said [1] :

<quote>
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 (on average it does more harm than good) 
however you are correct in asserting the driver is unmaintained so no-one is 
bothering to fix it.
</quote>

I have applied the patch to the standard debian kernel and vanilla kernels and 
runs perfectly. The patch simply erases a check. Applied to some Dell 
hardware, now the EPP mode is detected and, after some initial tests it's 
working.

Please, apply the patch.

Best regards,

Leo

[1] http://lists.infradead.org/pipermail/linux-parport/2008-March/000628.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=284471

[-- Attachment #2: patch_parport_bug.patch --]
[-- Type: text/x-patch, Size: 627 bytes --]

--- linux-2.6-3.0.0/drivers/parport/parport_pc.c.orig	2011-09-13 16:29:54.333048437 +0200
+++ linux-2.6-3.0.0/drivers/parport/parport_pc.c	2011-09-13 16:30:39.933451659 +0200
@@ -2018,18 +2018,6 @@ static int parport_EPP_supported(struct
 	if (!clear_epp_timeout(pb))
 		return 0;  /* No way to clear timeout */
 
-	/* Check for Intel bug. */
-	if (priv->ecr) {
-		unsigned char i;
-		for (i = 0x00; i < 0x80; i += 0x20) {
-			ECR_WRITE(pb, i);
-			if (clear_epp_timeout(pb)) {
-				/* Phony EPP in ECP. */
-				return 0;
-			}
-		}
-	}
-
 	pb->modes |= PARPORT_MODE_EPP;
 
 	/* Set up access functions to use EPP hardware. */

Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that disables EPP support on many chipsets

[Greg KH]

On Thu, Sep 15, 2011 at 11:33:18AM +0200, Leopold Palomo-Avellaneda wrote:
> Hi,
> 
> there's a bug in the parport module that have been reported (in another 
> places) some time ago [1]. Also, this bug was reported at Redhat [2], but 
> nobody follow the report and it was closed.
> 
> As Adam baked said [1] :
> 
> <quote>
> 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 (on average it does more harm than good) 
> however you are correct in asserting the driver is unmaintained so no-one is 
> bothering to fix it.
> </quote>
> 
> I have applied the patch to the standard debian kernel and vanilla kernels and 
> runs perfectly. The patch simply erases a check. Applied to some Dell 
> hardware, now the EPP mode is detected and, after some initial tests it's 
> working.
> 
> Please, apply the patch.

Please resend it with the proper Signed-off-by: line, as described by
Documentation/SubmittingPatches and we will be glad to consider it.

thanks,

greg k-h