linux-kernel - Re: [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa

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]

Date:	Wed, 9 Apr 2008 22:37:09 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Dmitry <dbaryshkov@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, haavard.skinnemoen@...el.com,
	lethal@...ux-sh.org, philipp.zabel@...il.com, pavel@....cz,
	tony@...mide.com, paul@...an.com
Subject: Re: [PATCH 5/6] Clocklib: Use correct clock for IrDA on pxa

On Wed, Apr 09, 2008 at 09:52:33PM +0100, Alan Cox wrote:
> > > It's called a line discipline, we've had them for many years. We may need
> > > a way for ldiscs and drivers to co-operate a bit more but these days we
> > > support proper buffering and arbitary baud rates (except on a few
> > > platforms whose maintainers are not paying attention ;)).
> > 
> > I feel that's a "it would be nice if" solution - and something worth
> > aiming for, but the amount of work required to get there is not going
> > to be insignificant.
> 
> The work required to fix up the existing FIR hacks is not insignifcant
> either. Also right now the tty layer is getting a major rework so now is
> actually the time to sort out anything extra that is needed.
> 
> If you want 4MBit please just use an ldisc and do
> 
> 	struct ktermios tmp;
> 	mutex_lock(&tty->termios_mutex);
> 	tmp = *tty->termios;
> 	tty_encode_baud_rate(tty, 4000000, 4000000);
> 	tty->driver->set_termios(tty, &tmp);
> 	mutex_unlock(&tty->termios_mutex);

There's more to FIR than just a baud rate change.  On PXA for instance,
SIR is implemented using the standard UART device in "SIR" mode, but FIR
is a completely separate hardware block with its own IRQs and clocks -
you need to switch the pin muxing from the UART to the FIR device.

So it's not just a matter of setting the baud rate to 4Mbps.

However, you can't just say "have two separate drivers and only use
one or the other" - all IrDA link negotiation is done at SIR at 9600
baud and only when negotiation is complete will the selected rate
become effective - be that SIR or FIR based.

So yes, using a ldisc for SIR (with a hook into the driver to tell the
driver to setup the port for IR) sounds ideal, but we're still going to
need to deal with the FIR device and switch IrDA between that and the
SIR UART ldisc.

Note - there are other reasons for finally sorting this out as well -
there are systems with IR which want to support both IrDA up to FIR
and other uart-based IR applications.  IIRC this came up on the iPAQs.
I forget exactly which applications but I believe lirc might fall into
the "want a serial port not the FIR network device interface" class.
Having SIR always go via ldiscs should sort that out nicely as well.
(I'm thinking maybe we want some control to set a port into IR
transmission/reception mode independent of selecting the IrDA ldisc -
but I'd suggest further research first - I may be just handwaving
about an already solved problem.)

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/