Message-ID: <20110915194348.GC19450@elie>
Date:	Thu, 15 Sep 2011 14:43:48 -0500
From:	Jonathan Nieder <jrnieder@...il.com>
To:	Bastien ROUCARIES <roucaries.bastien@...il.com>
Cc:	Leopold Palomo-Avellaneda <leo@...xarxa.net>,
	linux-kernel@...r.kernel.org, Adam Baker <linux@...er-net.org.uk>,
	linux-parport@...ts.infradead.org,
	Nicos Gollan <gollan@...ormatik.uni-kl.de>,
	Greg KH <greg@...ah.com>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alexander Gordeev <lasaine@....cs.msu.su>, jan@....com
Subject: Re: [PATCH/RFC] parport_pc: remove ancient, overeager quirk that
 disables EPP support on many chipsets

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists