Re: [PATCH 51/69] TTY: 68328serial, remove serial_state and friends
[ Added Greg as this is m68knommu territory, but I guess he go all 12 patches
through linux-m68k anyway ]
On Mon, Apr 2, 2012 at 13:54, Jiri Slaby jsl...@suse.cz wrote:
serial_state in 68328serial.h is a duplicated structure. One is
defined in linux/serial.h. So let us use that instead. And since the
serial flags are identical, use ones from there too.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Geert Uytterhoeven ge...@linux-m68k.org
Cc: linux-m...@lists.linux-m68k.org
---
drivers/tty/serial/68328serial.c | 55 +++
drivers/tty/serial/68328serial.h | 76
--
2 files changed, 22 insertions(+), 109 deletions(-)
diff --git a/drivers/tty/serial/68328serial.c
b/drivers/tty/serial/68328serial.c
index 5ce7825..bf5f811 100644
--- a/drivers/tty/serial/68328serial.c
+++ b/drivers/tty/serial/68328serial.c
@@ -17,6 +17,7 @@
#include asm/dbg.h
#include linux/module.h
#include linux/errno.h
+#include linux/serial.h
#include linux/signal.h
#include linux/sched.h
#include linux/timer.h
@@ -79,18 +80,6 @@ struct m68k_serial *m68k_consinfo = 0;
struct tty_driver *serial_driver;
-/* number of characters left in xmit buffer before we ask for more */
-#define WAKEUP_CHARS 256
-
-/* Debugging... DEBUG_INTR is bad to use when one of the zs
- * lines is your console ;(
- */
-#undef SERIAL_DEBUG_INTR
-#undef SERIAL_DEBUG_OPEN
-#undef SERIAL_DEBUG_FLOW
-
-#define RS_ISR_PASS_LIMIT 256
-
static void change_speed(struct m68k_serial *info);
/*
@@ -363,7 +352,7 @@ static int startup(struct m68k_serial * info)
m68328_uart *uart = uart_addr[info-line];
unsigned long flags;
- if (info-flags S_INITIALIZED)
+ if (info-flags ASYNC_INITIALIZED)
return 0;
if (!info-xmit_buf) {
@@ -404,7 +393,7 @@ static int startup(struct m68k_serial * info)
change_speed(info);
- info-flags |= S_INITIALIZED;
+ info-flags |= ASYNC_INITIALIZED;
local_irq_restore(flags);
return 0;
}
@@ -419,7 +408,7 @@ static void shutdown(struct m68k_serial * info)
unsigned long flags;
uart-ustcnt = 0; /* All off! */
- if (!(info-flags S_INITIALIZED))
+ if (!(info-flags ASYNC_INITIALIZED))
return;
local_irq_save(flags);
@@ -432,7 +421,7 @@ static void shutdown(struct m68k_serial * info)
if (info-tty)
set_bit(TTY_IO_ERROR, info-tty-flags);
- info-flags = ~S_INITIALIZED;
+ info-flags = ~ASYNC_INITIALIZED;
local_irq_restore(flags);
}
@@ -835,11 +824,11 @@ static int set_serial_info(struct m68k_serial * info,
if ((new_serial.baud_base != info-baud_base) ||
(new_serial.type != info-type) ||
(new_serial.close_delay != info-close_delay) ||
- ((new_serial.flags ~S_USR_MASK) !=
- (info-flags ~S_USR_MASK)))
+ ((new_serial.flags ~ASYNC_USR_MASK) !=
+ (info-flags ~ASYNC_USR_MASK)))
return -EPERM;
- info-flags = ((info-flags ~S_USR_MASK) |
- (new_serial.flags S_USR_MASK));
+ info-flags = ((info-flags ~ASYNC_USR_MASK) |
+ (new_serial.flags ASYNC_USR_MASK));
info-custom_divisor = new_serial.custom_divisor;
goto check_and_exit;
}
@@ -853,8 +842,8 @@ static int set_serial_info(struct m68k_serial * info,
*/
info-baud_base = new_serial.baud_base;
- info-flags = ((info-flags ~S_FLAGS) |
- (new_serial.flags S_FLAGS));
+ info-flags = ((info-flags ~ASYNC_FLAGS) |
+ (new_serial.flags ASYNC_FLAGS));
info-type = new_serial.type;
info-close_delay = new_serial.close_delay;
info-closing_wait = new_serial.closing_wait;
@@ -1022,13 +1011,13 @@ static void rs_close(struct tty_struct *tty, struct
file * filp)
local_irq_restore(flags);
return;
}
- info-flags |= S_CLOSING;
+ info-flags |= ASYNC_CLOSING;
/*
* Now we wait for the transmit buffer to clear; and we notify
* the line discipline to only process XON/XOFF characters.
*/
tty-closing = 1;
- if (info-closing_wait != S_CLOSING_WAIT_NONE)
+ if (info-closing_wait != ASYNC_CLOSING_WAIT_NONE)
tty_wait_until_sent(tty, info-closing_wait);
/*
* At this point we stop accepting input. To do this, we
@@ -1064,7 +1053,7 @@ static void rs_close(struct tty_struct *tty, struct
file * filp)
}
wake_up_interruptible(info-open_wait);
}
- info-flags = ~(S_NORMAL_ACTIVE|S_CLOSING);
+ info-flags = ~(ASYNC_NORMAL_ACTIVE|ASYNC_CLOSING);
[git pull] m68k updates for 3.4-rc2
Hi Linus,
Here are a few fixes for the m68k architecture. Nothing fancy this time, just
a build fix for the asm/system.h disintegration, and two fixes for missing
platform checks (one got in during last merge window), which can cause crashes
in multi-platform kernels.
Thanks for pulling!
The following changes since commit dd775ae2549217d3ae09363e3edb305d0fa19928:
Linus Torvalds (1):
Linux 3.4-rc1
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git for-linus
Geert Uytterhoeven (2):
m68k/mac: Add missing platform check before registering platform devices
m68k/q40: Add missing platform check before registering platform devices
Greg Ungerer (1):
m68k: include asm/cmpxchg.h in our m68k atomic.h
arch/m68k/include/asm/atomic.h |1 +
arch/m68k/mac/config.c |3 +++
arch/m68k/q40/config.c |3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-m68k in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] m68k/atari: EtherNAT - change number of Atari interrupts to make room for EtherNAT interrupts
Hi Geert,
The definition of NUM_ATARI_SOURCES will need to be changed again;
we'd best hardcode it to 140:
For one, allowing for 152 VME interrupts will exceed the boundaries of
the allocated bitmap (i.e. trash other memory).
We won't need the full 200 either (I seem to have got the EtherNAT
source numbers wrong in my earlier patch).
See attached - the 3.3.0-ethernat patches implement switching over to
the mainstream 91Cx driver (card detected on my Falcon, link brought up
but not detected by the driver due to hardware problems). The
3.3.0-atari-cleanup-num-irqs.diff sets the number of interrupt sources
to 141 on Atari, setting the number of VME sources back to 16 so we
don't accidentially trash memory contiguous with the free_vme_irq bitmap.
For some reason, I have to set NUM_ATARI_SOURCES to 141 to actually get
interrupt source 140 to register. Off-by-one error somewhere in the
generic interrupt code I'd think, but I've not been able to spot it.
(Just increasing the number of interrupts that are registered by
atari_init_IRQ results in 'unexpected interrupt from 112' until the cows
come home. And yes, it happens in ARAnyM, too.)
That pretty much wraps it up for EtherNEC and EtherNAT - EtherNEC is
fully tested by me, EtherNAT needs testing on Christian's Falcon or by
someone else with fully functional hardware. Next project : SCSI, SCC
serial, or what?...
Cheers,
Michael
diff --git a/arch/m68k/include/asm/atariints.h b/arch/m68k/include/asm/atariints.h
index 4e82683..9229626 100644
--- a/arch/m68k/include/asm/atariints.h
+++ b/arch/m68k/include/asm/atariints.h
@@ -30,9 +30,9 @@
#define TTMFP_SOURCE_BASE 24
#define SCC_SOURCE_BASE40
#define VME_SOURCE_BASE56
-#define VME_MAX_SOURCES152
+#define VME_MAX_SOURCES16
-#define NUM_ATARI_SOURCES (VME_SOURCE_BASE+VME_MAX_SOURCES-STMFP_SOURCE_BASE)
+#define NUM_ATARI_SOURCES 141
/* convert vector number to int source number */
#define IRQ_VECTOR_TO_SOURCE(v) ((v) - ((v) 0x20 ? 0x18 : (0x40-8)))
diff --git a/arch/m68k/include/asm/irq.h b/arch/m68k/include/asm/irq.h
index e905b3f..8bd9c7f 100644
--- a/arch/m68k/include/asm/irq.h
+++ b/arch/m68k/include/asm/irq.h
@@ -9,8 +9,10 @@
*/
#if defined(CONFIG_COLDFIRE)
#define NR_IRQS 256
-#elif defined(CONFIG_VME) || defined(CONFIG_SUN3) || defined(CONFIG_SUN3X) || defined(CONFIG_ATARI)
+#elif defined(CONFIG_VME) || defined(CONFIG_SUN3) || defined(CONFIG_SUN3X)
#define NR_IRQS 200
+#elif defined(CONFIG_ATARI)
+#define NR_IRQS 141
#elif defined(CONFIG_MAC)
#define NR_IRQS 72
#elif defined(CONFIG_Q40)
diff --git a/arch/m68k/atari/config.c b/arch/m68k/atari/config.c
index 6cff09f..af273d9 100644
--- a/arch/m68k/atari/config.c
+++ b/arch/m68k/atari/config.c
@@ -695,7 +695,7 @@ static struct platform_device *atari_ethernec_devices[] __initdata = {
#define ATARI_ETHERNAT_PHYS_ADDR 0x8000
-#define ATARI_ETHERNAT_IRQ 196
+#define ATARI_ETHERNAT_IRQ 140
static struct resource smc91x_resources[] = {
[0] = {
@@ -721,7 +721,7 @@ static struct platform_device smc91x_device = {
#define ATARI_USB_PHYS_ADDR 0x8010
-#define ATARI_USB_IRQ 195
+#define ATARI_USB_IRQ 139
static struct resource isp1160_resources[] = {
[0] = {
diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
index 01893aa..c34f5ac 100644
--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -29,6 +29,22 @@ config ATARI_ETHERNAT
CT/60 extension port. The driver works by polling instead of
interrupts, so it is quite slow.
+ To compile this driver as a module, choose M here. The module
+ will be called smc91x.
+
+config ATARI_ETHERNAT_OLD
+ tristate Atari EtherNAT Ethernet support - obsolete driver
+ select CRC32
+ select MII
+ depends on ATARI
+ help
+ Say Y to include support for the EtherNAT network adapter for the
+ CT/60 extension port. The driver works by polling instead of
+ interrupts, so it is quite slow.
+
+ To compile this driver as a module, choose M here. The module
+ will be called atari_91C111.
+
config SMC9194
tristate SMC 9194 support
depends on (ISA || MAC BROKEN)
diff --git a/drivers/net/ethernet/smsc/Makefile b/drivers/net/ethernet/smsc/Makefile
index ef228db..ac30abb 100644
--- a/drivers/net/ethernet/smsc/Makefile
+++ b/drivers/net/ethernet/smsc/Makefile
@@ -2,7 +2,8 @@
# Makefile for the SMSC network device drivers.
#
-obj-$(CONFIG_ATARI_ETHERNAT) += atari_91C111.o
+obj-$(CONFIG_ATARI_ETHERNAT) += smc91x.o
+obj-$(CONFIG_ATARI_ETHERNAT_OLD) += atari_91C111.o
obj-$(CONFIG_SMC9194) += smc9194.o
obj-$(CONFIG_SMC91X) += smc91x.o
obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o
diff --git a/drivers/net/ethernet/smsc/smc91x.h b/drivers/net/ethernet/smsc/smc91x.h
index 987755c..36c17c1 100644
--- a/drivers/net/ethernet/smsc/smc91x.h
+++ b/drivers/net/ethernet/smsc/smc91x.h
@@ -231,7 +231,7 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg)
#include unit/smc9.h
Re: [PATCH 1/5] m68k/atari: EtherNAT - change number of Atari interrupts to make room for EtherNAT interrupts
Michael Schmitz dixit: For some reason, I have to set NUM_ATARI_SOURCES to 141 to actually get interrupt source 140 to register. Off-by-one error somewhere in the generic interrupt code I'd think, but I've not been able to spot it. (Just increasing I think 141 interrupt sources covers sources #0 to #140, no? Next project : SCSI, SCC serial, or what?... PCI bus. Then radeonfb. I got someone asking for that. ☺ They actually took Linux’ radeonfb and ported that to the other Atari OSes, so only the PCI bridge should remain. #atari-home on OFTC, talk to ragnar76. bye, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] m68k/atari: EtherNAT - change number of Atari interrupts to make room for EtherNAT interrupts
Thorsten, For some reason, I have to set NUM_ATARI_SOURCES to 141 to actually get interrupt source 140 to register. Off-by-one error somewhere in the generic interrupt code I'd think, but I've not been able to spot it. (Just increasing I think 141 interrupt sources covers sources #0 to #140, no? What's interrupt #0? #1 to #7 are level 1 to 7 autovector interrupts. #8 to #140 are the vectored ones starting with the ST-MFP. Next project : SCSI, SCC serial, or what?... PCI bus. Then radeonfb. I got someone asking for that. ☺ Throw hardware my way ... PCI bridge should not be that difficult really. Seriously - at this stage I don't know whether my EtherNAT or the CT60's bus drivers are shot. So _don't_ throw hardware. They actually took Linux’ radeonfb and ported that to the other Atari OSes, so only the PCI bridge should remain. #atari-home on OFTC, talk to ragnar76. ragnar rings a bell, is that rag...@chaosdorf.de? Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] m68k/atari: EtherNEC - rewrite to use mainstream ne.c, take two
From: Michael Schmitz schmitz...@googlemail.com Date: Sun, 01 Apr 2012 20:49:52 +1200 Hi Paul, Geert, And on re-reading the comments in the other part of the patch, i.e. ...emulates the card interrupt via a timer --perhaps the driver should be just fixed to support generic netpoll, instead of adding an arch specific thing that amounts to netpoll. Then anyone can attempt to limp along and use one of these ancient relics w/o IRQ. Here's take two of my patch to convert the m68k Atari ROM port Ethernet driver to use mainstream ne.c, with minimal changes to the core NE2000 code. Please fix your email client, it corrupts your outgoing patches by breaking up long lines with newlines amongst other things. -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] m68k/atari: EtherNAT - change number of Atari interrupts to make room for EtherNAT interrupts
Thorsten, I think 141 interrupt sources covers sources #0 to #140, no? What's interrupt #0? #1 to #7 are level 1 to 7 autovector interrupts. #8 to I was just guessing. An all-uppercase identifier in a C context that expands to an integer and has NUMber in its name might just be used in the declarartion of a C array, that’s why. It's a bit more complicated - autovector 1-7 are vector numbers 25 to 31, user vectors start from 64 so there's a gap between them. No simple array. ragnar rings a bell, is that rag...@chaosdorf.de? Chaosdorf yes, so, probably yes. Ping? Does anyone have technical specs on the PCI bridge in question? Cheers, Michael -- To unsubscribe from this list: send the line unsubscribe linux-m68k in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
