summaryrefslogtreecommitdiffstats
path: root/include/asm-m32r/termios.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* m32r: enable arbitary speed tty rate settingAlan Cox2007-07-161-2/+4
| | | | | | | | | | Add the defines and constants needed for the M32R platform to support the arbitary speed tty ioctls. Signed-off-by: Alan Cox <alan@redhat.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] consolidate line discipline number definitionsTilman Schmidt2007-02-111-18/+0
| | | | | | | | | | | | | | | | | | | The line discipline numbers N_* are currently defined for each architecture individually, but (except for a seeming mistake) identically, in asm/termios.h. There is no obvious reason why these numbers should be architecture specific, nor any apparent relationship with the termios structure. The total number of these, NR_LDISCS, is defined in linux/tty.h anyway. So I propose the following patch which moves the definitions of the individual line disciplines to linux/tty.h too. Three of these numbers (N_MASC, N_PROFIBUS_FDL, and N_SMSBLOCK) are unused in the current kernel, but the patch still keeps the complete set in case there are plans to use them yet. Signed-off-by: Tilman Schmidt <tilman@imap.cc> Cc: <linux-arch@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [PATCH] m32r: cosmetic updates and trivial fixesHirokazu Takata2007-02-111-2/+0
| | | | | | | | | | Cosmetic updates and trivial fixes of m32r arch-dependent files. - Remove RCS ID strings and trailing white lines - Other misc. cosmetic updates Signed-off-by: Hirokazu Takata <takata@linux-m32r.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+109
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!