lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000001c75853$3e9599f0$294b82ce@stuartm>
Date:	Sat, 24 Feb 2007 15:34:54 -0500
From:	"Stuart MacDonald" <stuartm@...necttech.com>
To:	"'Rob Prowel'" <prowel@...hera.com>,
	<linux-kernel@...r.kernel.org>, <rmk+lkml@....linux.org.uk>
Subject: RE: questions about 8250 uart support for adhoc boards

From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that.  Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your 
> system.  There's
> > absolutely no need to build any of the additional modules.
> >   
> Unfortunately what I'm seeing in 2.6.20.1 seems to differ 
> from this.  If 

PC104 is really an ISA bus. The ISA ports are stored in a table in the
8250 driver (instead of allocated dynamically like PCI ports); the
config option _NR_UARTS just tells the driver how large to make the
table.

> I use the options below:
> 
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_NR_UARTS=32

This makes the internal table be 32 ports big. The first four ports
end up configured for legacy/standard com ports, the rest are
unconfigured. You should be able to see them as unknowns with
setserial.

> CONFIG_SERIAL_8250_RUNTIME_UARTS=16
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> # CONFIG_SERIAL_8250_FOURPORT is not set

All _FOURPORT does is specifically config ports 4-7 in the table to
have specific address/irqs for the FourPort board. What you do with
setserial is then change that config info to match your board.

You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
looks like you don't. As long as _NR_UARTS is big enough, thus making
the internal table big enough, you should be able to configure, with
setserial, any of the ports in the table, including the first four.

> Then I can only access ttyS0 through ttyS3 sith setserial.  
> Only after I add
> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do 
> anything with the 
> additional ports.  I would otherwise get the evil setserial: invalid 
> parameter error.

Very odd. You get this error when doing "setserial /dev/ttySxx", no
configuration? If so, that would imply that the table wasn't made big
enough, and the unconfigured ports haven't been registered with the
serial core.

> OK.  Fair enough.  My question then becomes, how does the driver deal 
> with this now? scan all applicable uarts when any relevant 
> interrupt is 
> detected (as identified in setserial)?

With our boards, the multiport is just a status register; it shows
which port has produced the interrupt, so the driver doesn't have to
loop through all the ports on the board looking for the correct one.
It doesn't actually enable/disable the sharing of the interrupt. The
setting of "irq 12" on multiple ports (from your original post) is
what enables the sharing, from the driver-side view. Maybe your
hardware is unusual and requires this ISR port to be set properly to
enable sharing; more likely is that the board itself has one or more
jumpers to set which interrupt it's using, and that's what enables the
sharing from the hardware-side view.

If I get some time tomorrow, I'll set up 2.6.20.1 and see what the
current options are doing.

If you can't get your board working, we have similar boards that do.

..Stu

-- 
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979

-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ