Jeff Gustafson | 28 Dec 23:22 2015

Add wch382_2s PCI ID

Hi all,
I purchased a two port PCIe serial board. Linux didn't seem to notice
it. I dug into the parport and tty/serial/8250 and added the PCI ID's.
Now the ports are working just fine. 

I am also sending this patch to the linux-serial list since it touches
files in both locations.

...Jeff

From ec862041a8c5cafda8b4f2eb7442a86e184d6294 Mon Sep 17 00:00:00 2001
From: Jeff Gustafson <ncjeffgus <at> zimage.com>
Date: Tue, 22 Dec 2015 17:12:00 -0800
Subject: [PATCH] Add wch382_2s PCI ID

---
 drivers/parport/parport_serial.c   | 10 ++++++++++
 drivers/tty/serial/8250/8250_pci.c | 10 ++++++++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/parport/parport_serial.c
b/drivers/parport/parport_serial.c
index e15b484..65bb759 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
 <at>  <at>  -65,6 +65,7  <at>  <at>  enum parport_pc_pci_cards {
 	wch_ch353_1s1p,
 	wch_ch353_2s1p,
 	wch_ch382_2s1p,
+	wch_ch382_2s,
(Continue reading)

Jeff Gustafson | 28 Dec 23:26 2015

Add wch382_2s PCI ID

Hi all,
I purchased a two port PCIe serial board. Linux didn't seem to notice
it. I dug into the parport and tty/serial/8250 and added the PCI ID's.
Now the ports are working just fine. 

I am also sending this patch to the linux-serial list since it touches
files in both locations.

...Jeff

From ec862041a8c5cafda8b4f2eb7442a86e184d6294 Mon Sep 17 00:00:00 2001
From: Jeff Gustafson <ncjeffgus <at> zimage.com>
Date: Tue, 22 Dec 2015 17:12:00 -0800
Subject: [PATCH] Add wch382_2s PCI ID

---
 drivers/parport/parport_serial.c   | 10 ++++++++++
 drivers/tty/serial/8250/8250_pci.c | 10 ++++++++++
 2 files changed, 20 insertions(+)

diff --git a/drivers/parport/parport_serial.c
b/drivers/parport/parport_serial.c
index e15b484..65bb759 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
 <at>  <at>  -65,6 +65,7  <at>  <at>  enum parport_pc_pci_cards {
 	wch_ch353_1s1p,
 	wch_ch353_2s1p,
 	wch_ch382_2s1p,
+	wch_ch382_2s,
(Continue reading)

Matwey V. Kornilov | 14 Dec 15:09 2014
Picon

OxPCIe952 EPP

Hi,

I've faced strange behavior of OXPCIE952 when EPP is used. The following
PCIe board is equipped with this chipset.

00:08.0 Parallel controller [0701]: Oxford Semiconductor Ltd Device
[1415:c110] (prog-if 02 [ECP])

Namely, I can not read in reverse mode. The interruptions at incoming
data happen, but when I try to read the data, EPP timeout always occurs.

Reverse mode is set up as the following (see
parport_pc_ecpepp_read_data() for the reference):

ECR control (base_hi+2) register is filled with the 0b100 in highest
three bits, and it is 0x81 after this,
EPP control (base+2) register is ORed by 0x20 and then is filled with
0bXXXX0100 to reset (it my case it becomes 0x34 after this).

EPP status (base+1) register is 0xce inside interrupt handler and
becomes 0xcf (EPP timeout flag is set) after the first attempt to read
from EPP data (base+4).

EPP works with the same code and peripheral at motherboard integrated
chipsets. Does anybody have ideas what is going on here?
matwey | 27 Aug 10:07 2014
Picon

[PATCHv5 0/2] parport: parport_pc: Fix false-positives at checking for Intel bug

From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>

Hi,

The following patch series is to deal with the issue on false-positives
of Intel EPP bug check [1].

More than a decade ago, the check was introduced in order to prevent EPP
operation on the some Intel LPT chipsets. The main issue to defence from
was CPU hang at EPP operation on broken chipsets. It is mentioned that
affected chipsets are Intel 82091. However, it is not known whether
there are others.

The check was implemented in strange manner. Now, there is no explanations
why. The check itself now leads to the false-positives, disabling EPP on
many PC-s (Dell OptiPlex series for instance). The latter is an issue.

Here is new version of the patches supposed to shrink the set of the false-positives.
We know that the initial problem arises on x86 with motherboard LPT controller.
The patches following are to enable initial check only for x86 and non-PCI based devices.
It is hard to correctly determine which CPUs could be installed into PentiumPro-compatible
socket, so I postponed initial Alan's suggestion.

For those who want to check theirs hardware, there's prebuilt usb-stick image available:
https://susestudio.com/a/OdbKqm/opensuse-13-1-parport_pc

The patches organized as following:

1. Introduce-intel_bug_present-function

(Continue reading)

Michael Schwingen | 21 Jul 12:23 2014

Patch for parport_serial.c / netmos 9845

Hi,

is this the right place to submit patches for
drivers/parport/parport_serial.c?

I have a Netmos 9845-based PCI card with 4 serial and 1 parallel port, where
the parallel port is not detected by the kernel, because the parallel port
is at BAR 5 instead of BAR 2 as the generic netmos_9xx5_combo entry assumes.

The attached patch adds a fixed entry for this configuration - this works
and should have minimal impact on other 9845-based cards, however, I wonder
if there is a way to auto-detect the correct PCI BARs for one or two
parallel ports.

cu
Michael

Netmos 9845-based card with 4 serial and 1 parallel port is
mis-detected, because the parallel port is at BAR 5 instead of BAR 2
as netmos_9xx5_combo entry assumes.

Signed-off-by: Michael Schwingen <michael <at> schwingen.org>
---

diff -ur linux-3.15.6-orig/drivers/parport/parport_serial.c linux-3.15.6/drivers/parport/parport_serial.c
--- linux-3.15.6-orig/drivers/parport/parport_serial.c	2014-07-18 01:23:31.000000000 +0200
+++ linux-3.15.6/drivers/parport/parport_serial.c	2014-07-21 11:33:54.004069286 +0200
 <at>  <at>  -31,6 +31,7  <at>  <at> 
 	titan_110l = 0,
 	titan_210l,
(Continue reading)

Matwey V. Kornilov | 7 Jul 09:01 2014
Picon

[PATCHv3 2/2] Add force_epp module option for parport_pc.

From cf37d0cc4d51da5c0b368e1f5ab05082c041d1e1 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey.kornilov <at> gmail.com>
Date: Wed, 25 Jun 2014 01:08:45 +0400
Subject: [PATCHv3 2/2] Add force_epp module option for parport_pc.

The detection of Intel EPP bug is known to produce much false positives.
The new option is introduced to force enable EPP in spite of the test result.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index a6eaafb..fb7530d 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -105,6 +105,9  <at>  <at>  static int user_specified;
         (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
  static int verbose_probing;
  #endif
+#ifdef CONFIG_PARPORT_1284
+static int force_epp;
+#endif
  static int pci_registered_parport;
  static int pnp_registered_parport;

 <at>  <at>  -1764,7 +1767,7  <at>  <at>  static int parport_EPP_supported(struct parport *pb)
  		return 0;  /* No way to clear timeout */
(Continue reading)

Matwey V. Kornilov | 7 Jul 09:00 2014
Picon

[PATCHv3 1/2] Introduce intel_bug_present function.

From c89138e2c968c07dd11b3c6bfc05a803d0c5434d Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey.kornilov <at> gmail.com>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv3 1/2] Introduce intel_bug_present function.

Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 38 ++++++++++++++++++++++++++------------
  1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..a6eaafb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -1702,6 +1702,30  <at>  <at>  static int parport_ECP_supported(struct parport *pb)
  }
  #endif

+static int intel_bug_present(struct parport *pb)
+{
+	const struct parport_pc_private *priv = pb->private_data;
+	int bug_present = 0;
+
+	if (priv->ecr) {
+		/* store value of ECR */
(Continue reading)

Matwey V. Kornilov | 7 Jul 08:59 2014
Picon

[PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug

From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCHv3 0/2] parport: parport_pc: Introduce option to disable checking for Intel bug

Hi,

The following patch series is to deal with the issue on false-positives
of Intel EPP bug check [1].

More than a decade ago, the check was introduced in order to prevent EPP
operation on the some Intel LPT chipsets. The main issue to defence from
was CPU hang at EPP operation on broken chipsets. It is mentioned that
affected chipsets are Intel 82091. However, it is not known whether
there are others.

The check was implemented in strange manner. Now, there is no explanations
why. The check itself now leads to the false-positives, disabling EPP on
many PC-s (Dell OptiPlex series for instance). The latter is an issue.

Given that our knowledge of the initial problem is quite limited now,
I introduce special option for parport_pc, allowing user to disable check.
This won't introduce regressions.

The patches organized as following:

1. Introduce-intel_bug_present-function.

The transparent refactoring of the check is performed.
Make the check be immutable regarding to ECR register.

(Continue reading)

Matwey V. Kornilov | 30 Jun 10:48 2014
Picon

[PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.

From f5384f47688c116ac765b18bfb01e28b4233b97f Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 01:08:45 +0400
Subject: [PATCH 2/2] parport: parport_pc: Add force_epp module option for parport_pc.

The detection of Intel EPP bug is known to produce much false positives.
The new option is introduced to force enable EPP in spite of the test result.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 9 ++++++++-
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 4b851bb..1a15b9c 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -105,6 +105,9  <at>  <at>  static int user_specified;
         (defined(CONFIG_PARPORT_1284) && defined(CONFIG_PARPORT_PC_FIFO))
  static int verbose_probing;
  #endif
+#ifdef CONFIG_PARPORT_1284
+static int force_epp;
+#endif
  static int pci_registered_parport;
  static int pnp_registered_parport;

 <at>  <at>  -1765,7 +1768,7  <at>  <at>  static int parport_EPP_supported(struct parport *pb)
  		return 0;  /* No way to clear timeout */
(Continue reading)

Matwey V. Kornilov | 30 Jun 10:48 2014
Picon

[PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.

From 28bb276ff858caecddfde78133f6b5b261c40a59 Mon Sep 17 00:00:00 2001
From: "Matwey V. Kornilov" <matwey <at> sai.msu.ru>
Date: Wed, 25 Jun 2014 00:53:54 +0400
Subject: [PATCH 1/2] parport: parport_pc: Introduce intel_bug_present function.

Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.

Tested-by: Heiko Andreas Sommer <hsommer <at> eso.org>
Signed-off-by: Matwey V. Kornilov <matwey <at> sai.msu.ru>
---
  drivers/parport/parport_pc.c | 35 +++++++++++++++++++++++++----------
  1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..4b851bb 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
 <at>  <at>  -1702,6 +1702,29  <at>  <at>  static int parport_ECP_supported(struct parport *pb)
  }
  #endif

+static int intel_bug_present(struct parport *pb)
+{
+	int bug_present = 0;
+
+	if (priv->ecr) {
+		/* store value of ECR */
+		unsigned char ecr = inb(ECONTROL(pb));
(Continue reading)

kuba | 23 Jan 19:11 2014
Picon

Auto detection vs specifying ports

  Hi,

I have a pci parallel port card based on CH353L chip and built in 
parallel port. When I load parport_pc, It sucessfully finds built in 
parallel port but does not recognize the card. If I specify ports for 
the card and built in pport, It successfully finds my card but not the 
built in pport.

When I look at parport_pc_init function:

3296         if (io[0]) {
3297                 int i;
3298                 /* Only probe the ports we were given. */
3299                 user_specified = 1;
3300                 for (i = 0; i < PARPORT_PC_MAX_PORTS; i++) {
3301                         if (!io[i])
3302                                 break;
3303                         if (io_hi[i] == PARPORT_IOHI_AUTO)
3304                                 io_hi[i] = 0x400 + io[i];
3305                         parport_pc_probe_port(io[i], io_hi[i],
3306                                         irqval[i], dmaval[i], NULL, 0);
3307                 }
3308         } else
3309                 parport_pc_find_ports(irqval[0], dmaval[0])

it is autodetecting only if i don't specify ports. Why not search for 
specified ports and do autodetect?

if I do something like this:

(Continue reading)


Gmane