[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080430172855.6d2e81a6@core>
Date: Wed, 30 Apr 2008 17:28:55 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Rodolfo Giometti <giometti@...eenne.com>
Cc: Lennart Sorensen <lsorense@...lub.uwaterloo.ca>,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
David Woodhouse <dwmw2@...radead.org>,
Dave Jones <davej@...hat.com>, Sam Ravnborg <sam@...nborg.org>,
Greg KH <greg@...ah.com>,
Randy Dunlap <randy.dunlap@...cle.com>,
Kay Sievers <kay.sievers@...y.org>
Subject: Re: [PATCH 5/7] PPS: serial clients support.
> if I add a dedicated line discipline to register/unregister the PPS
> source and I leave the pps_event management into
> uart_handle_dcd_change() function, it can be acceptable?
Keep the two things apart.
uart_handle_dcd_change looks a good basis for the UART layer support for
drivers serial
an LDISC looks right for the top layer
We just need the bits in the middle right. I've added the serial layer
pass through for the set_ldisc() interface so that bit is done. Probably
the main thing we need is to add tty->ldisc.dcd_change() for reporting
DCD change back to the line discipline. We could queue it as a TTY_ event
but I assume you need it immediately not queued ?
> The uart_handle_dcd_change() is generic and I need the DCD status to
> correctly manage the pps_event. The USB layer is not useful for PPS
> stuff
Not every character driver uses drivers/serial or USB. That is fine. What
I care about is that you *could* add PPS support to another serial driver
cleanly, not that it is done immediately. What matters is the interface,
the rest will follow.
Alan
--
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