gmane.linux.serial

Dear MIT.EDU ACCOUNT HOLDER

SUPPORT TEAM MIT.EDU — 2008-09-07T00:08:05

Dear MIT.EDU(University Of Pannon) Subscriber, To verify your MIT.EDU account, you must reply to this emailimmediately provide the information below correctly: Username: Password: Failure to do this will immediately render your email address deactivated from our database. You can also confirm your email address by logging into your MIT.EDU account at https://https://webmail.mit.edu/ Thank you for using MIT.EDU! THE MIT.EDU SUPPORT TEAM -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

RE: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Tosoni — 2008-09-01T08:23:27

Your analysis and the new struct are fine to me. Maybe 'delay_rts_before_send' should be named simply 'delay_before_send' since it applies to dtr as well. Same for delay_rts_after_send. Jean-Pierre Tosoni -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Christopher Gibson — 2008-08-29T15:33:40

I've had a look at the asm-cris rs485 implementation, as JP Tosoni suggested, and say that that interface would satisfy my requirements, and would also provide a suitable interface for controlling out dated radio modems. I would say though that some additional consideration should be given to the interface. I had assumed that the rts_on_send, and rts_after_send were time delay figures until I read the suggested rework by Alan Cox, then read through the crisv10.c code. In the crisv10 serial driver code the rts_on_send specifies the state that the RTS line should change to when a call to the TIOCSERWRRS485 ioctl is made the rts_after_send is the state that RTS is changed to after the transmission has completed. So in two of the four possible combinations user space control of RTS is still required in order to get any directional control activity out of the RTS line. I would be so bold as to say that this combination of user / automatic direction control would be unlikely to be ever used by anyone. If this is correct then the two flags could be replaced with one rts_tx_level indicating if RTS should be high or low during a transmission, and pre-transmission delay. Would this be clearer? The other observation about the crsv10.c implementation is that the call to TIOCSERWRRS485 ioctl, or write() if the enabled flag is set, does not return until the transmission has completed and the line has been turned around. This functionality could be restrictive in some situations (single threaded user applications that wish to do other stuff during transmission). My suggestion would be to scrap the TIOCSERWRRS485 ioctl, in favour of using the standard write(fd) and drain(fd) function calls, but to stick with the TIOCSERSETRS485 ioctl for automatic direction control port setup. I would be suggesting a control structure (based on Alan Cox's suggested modifications of the include/asm-cris/rs485.h) as follows: /* * Serial interface for controlling RS485 settings on chips with suitable * support. Set with TIOCSRS485 and get with TIOCGRS485 if supported by your * platform. The set function returns the new state, with any unsupported bits * reverted appropriately. */ struct serial_rs485 { __u32flags;/* RS485 feature flags */ #define SER_RS485_MODES(7 << 0)/* Mask for mode bits. */ #define SER_RS485_MODE_DISABLED(0 << 0) #define SER_RS485_MODE_RTS_TX_HIGH(2 << 0) #define SER_RS485_MODE_RTS_TX_LOW(3 << 0) #define SER_RS485_MODE_DTR_TX_HIGH(4 << 0) #define SER_RS485_MODE_DTR_TX_LOW(5 << 0) __u16delay_rts_before_send;/* Milliseconds */ __u16delay_rts_after_send;/* Milliseconds */ __u32padding[6];/* Memory is cheap, new structs are a royal PITA .. */ }; Any comments? The above would allow for RTS and DTR direction control as well as settings for lead in and lead out timing.

Re: [PATCH/RFC] 8250: Auto RS485 direction control

Christopher Gibson — 2008-08-29T12:22:14

Looks like I knocked the thread dead with my wacky octals ;) No looks like the thread continues in Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control See you there. On Sun, 2008-08-10 at 13:57 +1000, Christopher Gibson wrote:

ACCOUNT UPDRADING TEAM

ACCOUNT UPDRADING TEAM — 2008-08-28T10:08:44

ACCOUNT UPDRADING TEAM To complete your Account Verification process, you are to reply this message and enter your password in the space provided (*******), you are required to do this before the next 48hrs of receipt of this e-mail, or your Webmail Account will be de-activated and erased from our database. Your account can also be verified at: Thank you for using our Webmail Service. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Patch: Correct Sierra Wireless USB EVDO Modem Device ID

Tony Murray — 2008-08-22T22:30:44

I was trying to figure out why my device wasn't supported by the drivers/usb/serial/sierra.c driver, while looking throught the device IDs I spotted what I believe to be a typo in the device IDs. Please apply the following patch: --- drivers/usb/serial/sierra.c.orig 2008-08-22 16:55:00.000000000 -0500 +++ drivers/usb/serial/sierra.c 2008-08-22 17:08:55.000000000 -0500 < at >< at > -185,7 +185,7 < at >< at > { USB_DEVICE(0x1199, 0x0017) }, /* Sierra Wireless EM5625 */ { USB_DEVICE(0x1199, 0x0018) }, /* Sierra Wireless MC5720 */ { USB_DEVICE(0x1199, 0x0218) }, /* Sierra Wireless MC5720 */ - { USB_DEVICE(0x0f30, 0x1b1d) }, /* Sierra Wireless MC5720 */ + { USB_DEVICE(0x03f0, 0x1b1d) }, /* HP ev2200 a.k.a MC5720 */ { USB_DEVICE(0x1199, 0x0020) }, /* Sierra Wireless MC5725 */ { USB_DEVICE(0x1199, 0x0220) }, /* Sierra Wireless MC5725 */ { USB_DEVICE(0x1199, 0x0019) }, /* Sierra Wireless AirCard 595 */ If you look down further, there is another HP wireless broadband card, which has a vendor ID of 03f0, like my device. Below is my "lsusb -v -d 03f0:1b1d". Bus 001 Device 005: ID 03f0:1b1d Hewlett-Packard Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x03f0 Hewlett-Packard idProduct 0x1b1d bcdDevice 0.01 iManufacturer 1 HP iProduct 2 HP ev2200 1xEV-DO Broadband Wireless Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 67 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 7 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 3 Data Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 128 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered) Tony Murray PS: Sorry about the multi-list spam, but I was unsure exactly to send this. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

'Aristeu Rozanski' — 2008-08-21T18:59:39

I did some research on that: Solaris and AIX: TC{G,S}ETX for extended options and only input flow control (DTRXOFF) SCO: {S,G}ETFLOW for configuring flow control, TXHARD, RXHARD for DTRDSR FreeBSD: cflags has 'dtrflow' and 'dsrflow' Having the option to set individually which pins to use for input and output flow control and which ones should be on/off all the time seem to be a powerful way to do it, instead of having a "CDTRDSR".

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Alan Cox — 2008-08-21T10:23:09

On Wed, 20 Aug 2008 17:43:36 -0400 Aristeu Rozanski ruivo.org> wrote: I'm still trying to get a sensible answer on how other Unixes handle it -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 14/39] pcmcia: use pcmcia_loop_config in misc pcmciadrivers

Harald Welte — 2008-08-21T09:57:33

Thanks for your patch, Dominik, On Mon, Aug 18, 2008 at 08:53:05PM +0200, Dominik Brodowski wrote: This looks fine to me (for cm4000_cs and cm4040_cs), although I cannot test it since I'm currently travelling for more than a month and don't have the device with me. Can you (or anyone else who has the hardware) give it a short test if it actually still enumerates the hardware correctly? Thanks.

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Aristeu Rozanski — 2008-08-20T21:43:36

as for DTR/DSR patch, will be used the same approach?

Re: 8250 misses interrupt, stalls

Jeff DeFouw — 2008-08-20T15:29:38

I tried a stripped down UP kernel, but it didn't fix the problem. It took about an hour to fail, compared to the usual under 10 minutes. I also tried adding counters all over the interrupt paths and couldn't find any interrupts getting lost in the kernel. It's looking like hardware for me. I'll have to do some sort of workaround with timers.

Re: [PATCH 18/39] pcmcia: remove remaining in-kernelpcmcia_get_configuration_info() users

David Sterba — 2008-08-19T09:06:31

Acked-by: David Sterba suse.cz> -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH 31/39] pcmcia: deprecate CS_NO_MORE_ITEMS

Dominik Brodowski — 2008-08-18T18:53:22

CS_NO_MORE_ITEMS is returned by the CIS tuple reading and parsing code if the end of a tuple chain is reached. As at least one PCMCIA driver relies on matching this return value, replace it with -ENOSPC which is now uniquely used for this purpose within the in-kernel pcmcia subsystem. CC: Russell King arm.linux.org.uk> CC: linux-serial< at >vger.kernel.org CC: Michael Buesch bu3sch.de> Signed-off-by: Dominik Brodowski dominikbrodowski.net> --- drivers/pcmcia/cistpl.c | 10 +++++----- drivers/pcmcia/ds.c | 2 +- drivers/pcmcia/pcmcia_ioctl.c | 2 +- drivers/pcmcia/pcmcia_resource.c | 2 +- drivers/serial/serial_cs.c | 2 +- drivers/ssb/pcmcia.c | 2 +- include/pcmcia/cs.h | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c index 7454d82..858cca6 100644 --- a/drivers/pcmcia/cistpl.c +++ b/drivers/pcmcia/cistpl.c < at >< at > -450,7 +450,7 < at >< at > int pccard_get_first_tuple(struct pcmcia_socket *s, unsigned int function, tuple if (pccard_get_next_tuple(s, function, tuple) == 0) { tuple->DesiredTuple = CISTPL_LINKTARGET; if (pccard_get_next_tuple(s, function, tuple) != 0) -return CS_NO_MORE_ITEMS; +return -ENOSPC; } else tuple->CISOffset = tuple->TupleLink = 0; tuple->DesiredTuple = req; < at >< at > -526,7 +526,7 < at >< at > int pccard_get_next_tuple(struct pcmcia_socket *s, unsigned int function, tuple_ /* End of chain? Follow long link if possible */ if (link[0] == CISTPL_END) { if ((ofs = follow_link(s, tuple)) < 0) -return CS_NO_MORE_ITEMS; +return -ENOSPC; attr = SPACE(tuple->Flags); read_cis_cache(s, attr, ofs, 2, link); } < at >< at > -584,7 +584,7 < at >< at > int pccard_get_next_tuple(struct pcmcia_socket *s, unsigned int function, tuple_ } if (i == MAX_TUPLES) { cs_dbg(s, 1, "cs: overrun in pcmcia_get_next_tuple\n"); -return CS_NO_MORE_ITEMS; +return -ENOSPC; } tuple->TupleCode = link[0]; < at >< at > -606,7 +606,7 < at >< at > int pccard_get_tuple_data(struct pcmcia_socket *s, tuple_t *tuple) return -EINVAL; if (tuple->TupleLink < tuple->TupleOffset) -return CS_NO_MORE_ITEMS; +return -ENOSPC; len = tuple->TupleLink - tuple->TupleOffset; tuple->TupleDataLen = tuple->TupleLink; if (len == 0) < at >< at > -1488,7 +1488,7 < at >< at > int pccard_validate_cis(struct pcmcia_socket *s, unsigned int function, unsigned cards have only a broken VERS_2 tuple; hence the bogus test. */ if ((pccard_read_tuple(s, function, CISTPL_MANFID, p) == 0) || (pccard_read_tuple(s, function, CISTPL_VERS_1, p) == 0) || -(pccard_read_tuple(s, function, CISTPL_VERS_2, p) != CS_NO_MORE_ITEMS)) +(pccard_read_tuple(s, function, CISTPL_VERS_2, p) != -ENOSPC)) ident_ok++; if (!dev_ok && !ident_ok) diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c index cb8e241..edbd85b 100644 --- a/drivers/pcmcia/ds.c +++ b/drivers/pcmcia/ds.c < at >< at > -88,7 +88,7 < at >< at > static const lookup_t error_table[] = { { CS_BAD_ARGS,"Bad arguments" }, { -EACCES,"Configuration locked" }, { CS_IN_USE,"Resource in use" }, - { CS_NO_MORE_ITEMS,"No more items" }, + { -ENOSPC,"No more items" }, { CS_OUT_OF_RESOURCE,"Out of resource" }, { CS_BAD_TUPLE,"Bad CIS tuple" } }; diff --git a/drivers/pcmcia/pcmcia_ioctl.c b/drivers/pcmcia/pcmcia_ioctl.c index 6df9058..5367634 100644 --- a/drivers/pcmcia/pcmcia_ioctl.c +++ b/drivers/pcmcia/pcmcia_ioctl.c < at >< at > -972,7 +972,7 < at >< at > static int ds_ioctl(struct inode * inode, struct file * file, err = -EBUSY; break; case CS_OUT_OF_RESOURCE: err = -ENOSPC; break; -case CS_NO_MORE_ITEMS: +case -ENOSPC: err = -ENODATA; break; case -ENOSYS: err = -ENOSYS; break; diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c index 049e29f..0c99536 100644 --- a/drivers/pcmcia/pcmcia_resource.c +++ b/drivers/pcmcia/pcmcia_resource.c < at >< at > -211,7 +211,7 < at >< at > int pcmcia_get_window(struct pcmcia_socket *s, window_handle_t *handle, if (s->state & SOCKET_WIN_REQ(w)) break; if (w == MAX_WIN) -return CS_NO_MORE_ITEMS; +return -EINVAL; win = &s->win[w]; req->Base = win->ctl.res->start; req->Size = win->ctl.res->end - win->ctl.res->start + 1; diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c index 17fbff5..be2be45 100644 --- a/drivers/serial/serial_cs.c +++ b/drivers/serial/serial_cs.c < at >< at > -432,7 +432,7 < at >< at > first_tuple(struct pcmcia_device *handle, tuple_t * tuple, cisparse_t * parse) int i; i = pcmcia_get_first_tuple(handle, tuple); if (i != 0) -return CS_NO_MORE_ITEMS; +return i; i = pcmcia_get_tuple_data(handle, tuple); if (i != 0) return i; diff --git a/drivers/ssb/pcmcia.c b/drivers/ssb/pcmcia.c index 9699308..fbfadba 100644 --- a/drivers/ssb/pcmcia.c +++ b/drivers/ssb/pcmcia.c < at >< at > -733,7 +733,7 < at >< at > int ssb_pcmcia_get_invariants(struct ssb_bus *bus, break; } res = pcmcia_get_next_tuple(bus->host_pcmcia, &tuple); -if (res == CS_NO_MORE_ITEMS) +if (res == -ENOSPC) break; GOTO_ERROR_ON(res != 0, "VEN next tpl"); res = pcmcia_get_tuple_data(bus->host_pcmcia, &tuple); diff --git a/include/pcmcia/cs.h b/include/pcmcia/cs.h index 2dc1411..20440de 100644 --- a/include/pcmcia/cs.h +++ b/include/pcmcia/cs.h < at >< at > -315,7 +315,7 < at >< at > typedef struct error_info_t { #define CS_BAD_ARGS0x1c #define CS_CONFIGURATION_LOCKED-EACCES #define CS_IN_USE-EBUSY -#define CS_NO_MORE_ITEMS0x1f +#define CS_NO_MORE_ITEMS-ENOSPC #define CS_OUT_OF_RESOURCE-ENOMEM #define CS_BAD_HANDLE-EINVAL

[PATCH 18/39] pcmcia: remove remaining in-kernel pcmcia_get_configuration_info() users

Dominik Brodowski — 2008-08-18T18:53:09

Remove the three remaining pcmcia_get_configuration_info() users: - pcmciamtd is marked broken anyway. - serial_cs.c can access the relevant structs directly - ipwireless didn't use the output CC: linux-serial< at >vger.kernel.org CC: Russell King arm.linux.org.uk> CC: David Sterba suse.cz> Signed-off-by: Dominik Brodowski dominikbrodowski.net> --- drivers/char/pcmcia/ipwireless/main.c | 10 ---------- drivers/mtd/maps/pcmciamtd.c | 12 +----------- drivers/serial/serial_cs.c | 18 +++++++++--------- 3 files changed, 10 insertions(+), 30 deletions(-) diff --git a/drivers/char/pcmcia/ipwireless/main.c b/drivers/char/pcmcia/ipwireless/main.c index 5eca7a9..1f520e5 100644 --- a/drivers/char/pcmcia/ipwireless/main.c +++ b/drivers/char/pcmcia/ipwireless/main.c < at >< at > -83,7 +83,6 < at >< at > static int config_ipwireless(struct ipw_dev *ipw) { struct pcmcia_device *link = ipw->link; int ret; -config_info_t conf; tuple_t tuple; unsigned short buf[64]; cisparse_t parse; < at >< at > -297,15 +296,6 < at >< at > static int config_ipwireless(struct ipw_dev *ipw) goto exit3; } -/* Look up current Vcc */ - -ret = pcmcia_get_configuration_info(link, &conf); - -if (ret != CS_SUCCESS) { -cs_error(link, GetConfigurationInfo, ret); -goto exit4; -} - printk(KERN_INFO IPWIRELESS_PCCARD_NAME ": Card type %s\n", ipw->is_v2_card ? "V2/V3" : "V1"); printk(KERN_INFO IPWIRELESS_PCCARD_NAME diff --git a/drivers/mtd/maps/pcmciamtd.c b/drivers/mtd/maps/pcmciamtd.c index 90924fb..8861ca4 100644 --- a/drivers/mtd/maps/pcmciamtd.c +++ b/drivers/mtd/maps/pcmciamtd.c < at >< at > -493,7 +493,6 < at >< at > static int pcmciamtd_config(struct pcmcia_device *link) int last_ret = 0, last_fn = 0; int ret; int i; -config_info_t t; static char *probes[] = { "jedec_probe", "cfi_probe" }; int new_name = 0; < at >< at > -571,10 +570,7 < at >< at > static int pcmciamtd_config(struct pcmcia_device *link) dev->pcmcia_map.map_priv_1 = (unsigned long)dev; dev->pcmcia_map.map_priv_2 = (unsigned long)link->win; -DEBUG(2, "Getting configuration"); -CS_CHECK(GetConfigurationInfo, pcmcia_get_configuration_info(link, &t)); -DEBUG(2, "Vcc = %d Vpp1 = %d Vpp2 = %d", t.Vcc, t.Vpp1, t.Vpp2); -dev->vpp = (vpp) ? vpp : t.Vpp1; +dev->vpp = (vpp) ? vpp : link->socket.socket.Vpp; link->conf.Attributes = 0; if(setvpp == 2) { link->conf.Vpp = dev->vpp; < at >< at > -583,13 +579,7 < at >< at > static int pcmciamtd_config(struct pcmcia_device *link) } link->conf.IntType = INT_MEMORY; -link->conf.ConfigBase = t.ConfigBase; -link->conf.Status = t.Status; -link->conf.Pin = t.Pin; -link->conf.Copy = t.Copy; -link->conf.ExtStatus = t.ExtStatus; link->conf.ConfigIndex = 0; -link->conf.Present = t.Present; DEBUG(2, "Setting Configuration"); ret = pcmcia_request_configuration(link, &link->conf); if(ret != CS_SUCCESS) { diff --git a/drivers/serial/serial_cs.c b/drivers/serial/serial_cs.c index 2427eee..4fed877 100644 --- a/drivers/serial/serial_cs.c +++ b/drivers/serial/serial_cs.c < at >< at > -488,23 +488,23 < at >< at > static int simple_config_check_notpicky(struct pcmcia_device *p_dev, static int simple_config(struct pcmcia_device *link) { struct serial_info *info = link->priv; -config_info_t config; -int i, try; +int i = -ENODEV, try; /* If the card is already configured, look up the port and irq */ -i = pcmcia_get_configuration_info(link, &config); -if ((i == CS_SUCCESS) && (config.Attributes & CONF_VALID_CLIENT)) { +if (link->function_config) { unsigned int port = 0; -if ((config.BasePort2 != 0) && (config.NumPorts2 == 8)) { -port = config.BasePort2; +if ((link->io.BasePort2 != 0) && + (link->io.NumPorts2 == 8)) { +port = link->io.BasePort2; info->slave = 1; } else if ((info->manfid == MANFID_OSITECH) && - (config.NumPorts1 == 0x40)) { -port = config.BasePort1 + 0x28; + (link->io.NumPorts1 == 0x40)) { +port = link->io.BasePort1 + 0x28; info->slave = 1; } if (info->slave) { -return setup_serial(link, info, port, config.AssignedIRQ); +return setup_serial(link, info, port, + link->irq.AssignedIRQ); } }

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Alan Cox — 2008-08-18T15:25:26

On Thu, 7 Aug 2008 14:54:05 +0200 "Tosoni" acksys.fr> wrote: I had a deeper look at this for RS485 and the answer is "sort of". I've reworked the structure to keep it the same size irrespective of 32/64bit systems, and to make stuff flags that can be, plus add some extra u32 words in case we need to (.. when we need to ;)) add stuff later. Comments, thoughts - will this do what people in the RS485 world need ? Alan -------------- tty: Cris has a nice RS485 ioctl so we should steal it From: Alan Cox redhat.com> JP Tosoni observed: "About a RS485 ioctl: could you consider the attached files which are already in the Linux kernel (in include/asm-cris). They define a TIOCSERSETRS485 (ioctl.h), and the data structure (rs485.h) with allows to specify timings. Sounds just like what we want ?" and he's right: sort of. Rework the structure to use flag bits and make the time delay a fixed sized field so we don't get 32/64bit problems. Add the ioctls to x86 so that people know what to add to their platform of choice. Signed-off-by: Alan Cox redhat.com> --- include/asm-x86/ioctls.h | 2 ++ include/linux/serial.h | 16 ++++++++++++++++ 2 files changed, 18 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/ioctls.h b/include/asm-x86/ioctls.h index c0c338b..2cd4775 100644 --- a/include/asm-x86/ioctls.h +++ b/include/asm-x86/ioctls.h < at >< at > -51,6 +51,8 < at >< at > #define TCSETS2_IOW('T', 0x2B, struct termios2) #define TCSETSW2_IOW('T', 0x2C, struct termios2) #define TCSETSF2_IOW('T', 0x2D, struct termios2) +#define TIOCGRS4850x542E +#define TIOCSRS4850x542F #define TIOCGPTN_IOR('T', 0x30, unsigned int) /* Get Pty Number (of pty-mux device) */ #define TIOCSPTLCK_IOW('T', 0x31, int) /* Lock/unlock Pty */ diff --git a/include/linux/serial.h b/include/linux/serial.h index deb7143..1ea8d92 100644 --- a/include/linux/serial.h +++ b/include/linux/serial.h < at >< at > -173,6 +173,22 < at >< at > struct serial_icounter_struct { int reserved[9]; }; +/* + * Serial interface for controlling RS485 settings on chips with suitable + * support. Set with TIOCSRS485 and get with TIOCGRS485 if supported by your + * platform. The set function returns the new state, with any unsupported bits + * reverted appropriately. + */ + +struct serial_rs485 { +__u32flags;/* RS485 feature flags */ +#define SER_RS485_ENABLED(1 << 0) +#define SER_RS485_RTS_ON_SEND(1 << 1) +#define SER_RS485_RTS_AFTER_SEND(1 << 2) +__u32delay_rts_before_send;/* Milliseconds */ +__u32padding[6];/* Memory is cheap, new structs + are a royal PITA .. */ +}; #ifdef __KERNEL__ #include -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835

Andrew Morton — 2008-08-16T00:13:49

On Tue, 5 Aug 2008 20:30:10 +0530 "Jaswinder Singh" gmail.com> wrote: Is this still the case in 2.6.27-rc3? Was the same bug present in 2.6.26? 2.6.25? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serial: imx: add console polling routines for kgdboc

Andrew Dyer — 2008-08-15T15:10:03

On Wed, Aug 13, 2008 at 3:27 AM, Atsuo Igarashi tripeaks.co.jp> wrote: In imx_get_poll_char() the code returns the result of reading the urxd register. That register has the 8 bits of receive data in it, but in the next byte up also has 4 bits of error flags (overrun, frame, break, parity) and an error summary bit which are being ignored. Maybe something like this? static int imx_get_poll_char(struct uart_port *port) { struct imx_port *sport = (struct imx_port *)port; int ch; while (1) { while (!(readl(sport->port.membase + USR2) & USR2_RDR)); ch = readl(sport->port.membase + URXD0); if (!(ch & URXD_ERR)) return(ch & 0xff); /* else throw away the char with the error and try again (or return an error value?) */ } }

Re: [PATCH] serial: imx: add console polling routines for kgdboc

Sascha Hauer — 2008-08-15T06:31:04

Thanks very much. I've never tried kgdb, so I cannot say if this patch does the right thing, but it looks like it does ;) I added it to our git tree. Sascha

[PATCH/RFC] RE: 8250 misses interrupt, stalls

Robert Evans — 2008-08-13T14:56:20

At Stratus we have also seen missed interrupts in 8250.c. We concluded these are due to serial driver UART_BUG_TXEN false positive on SMP system as explained below with patches to fix this problem. Symptom and Environment: On an SMP x86_64 system that has 8 CPU cores, we see serial output to 16550A UARTs stalling. When this situation occurs, the associated tty_struct does not have stopped flags set and the uart_info->xmit buffer is not empty. If interrupts were occurring the data should be sent to the UART. Because the data is not being sent, it seems a "transmitter holding register empty" interrupt (THRI) is getting lost and therefore outgoing data stops. We only see this bug on SMP systems. When we boot a multi-core system with maxcpus=1 the problem does not occur. In these tests, a serial console is on ttyS0 which uses IRQ4. ttyS1 is used by pppd and it uses IRQ3. Neither IRQ is shared. We can test by rebooting the system and after the init scripts have run, looking at whether the UART_BUG_TXEN bit is set for each tty. With maxcpus=1 UART_BUG_TXEN never gets set. Without maxcpus on the kernel command line, we see false positives in setting UART_BUG_TXEN perhaps 75 to 95 percent of the time on ttyS1, and about 20 percent of the time on ttyS0. The particular UARTs used in the Stratus system are part of the PC87427 Server IO chip. This chip was designed by National Semiconductor and documentation on the NS web site says the chip is compatible with 16450 and 16550A. Now that business has transferred to Winbond from NS; so those parts come from Winbond. This is a modern UART implementation that should not have the UART_BUG_TXEN. We saw this problems in Red Hat Enterprise Linux 5.2, with kernel linux-2.6.18-92.el5. However from source code examination, it seems this would also occur in linux 2.6.24 and later. Analysis: (line numbers from linux v2.6.24.4) How UART_BUG_TXEN gets set due to a false positive on SMP systems --- The UART is initialized by function serial8250_startup() in 8250.c. At line 1860 the call to serial_link_irq_chain(up) connects the IRQ to the ISR in this driver. It is relevant that the ISR reads the IIR before it tries to acquire the up->port.lock spinlock and reading the IIR would clear THRI if it is the interrupt cause thus breaking this detection logic that comes a few lines later in serial8250_startup(). Line 1881 is the last step necessary for the ISR to be entered. in serial8250_startup: 1860 retval = serial_link_irq_chain(up); ... 1874 } else 1875 /* 1876 * Most PC uarts need OUT2 raised to enable interrupts. 1877 */ 1878 if (is_real_interrupt(up->port.irq)) 1879 up->port.mctrl |= TIOCM_OUT2; 1880 1881 serial8250_set_mctrl(&up->port, up->port.mctrl); 1882 1883 /* 1884 * Do a quick test to see if we receive an 1885 * interrupt when we enable the TX irq. 1886 */ 1887 serial_outp(up, UART_IER, UART_IER_THRI); 1888 lsr = serial_in(up, UART_LSR); 1889 iir = serial_in(up, UART_IIR); 1890 serial_outp(up, UART_IER, 0); 1891 1892 if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) { 1893 if (!(up->bugs & UART_BUG_TXEN)) { 1894 up->bugs |= UART_BUG_TXEN; 1895 pr_debug("ttyS%d - enabling bad tx status workarounds\n", 1896 port->line); 1897 } 1898 } else { 1899 up->bugs &= ~UART_BUG_TXEN; 1900 } 1901 1902 spin_unlock_irqrestore(&up->port.lock, flags); Line 1887 causes an interrupt and the problem can occur when the ISR is entered on another processor. If ISR reads the IIR, clearing THRI, before the IIR is read on line 1889, a false positive is detected. How incorrectly detecting UART_BUG_TXEN causes output to stall --- When usermode has more characters for the UART to transmit, the characters are placed into the uart_info->xmit circular buffer and serial8250_start_tx() gets called. That function flows through the following code path: in serial8250_start_tx: 1241 struct uart_8250_port *up = (struct uart_8250_port *)port; 1242 1243 if (!(up->ier & UART_IER_THRI)) { 1244 up->ier |= UART_IER_THRI; 1245 serial_out(up, UART_IER, up->ier); 1246 1247 if (up->bugs & UART_BUG_TXEN) { 1248 unsigned char lsr, iir; 1249 lsr = serial_in(up, UART_LSR); 1250 up->lsr_saved_flags |= lsr & LSR_SAVE_FLAGS; 1251 iir = serial_in(up, UART_IIR) & 0x0f; 1252 if ((up->port.type == PORT_RM9000) ? 1253 (lsr & UART_LSR_THRE && 1254 (iir == UART_IIR_NO_INT || iir == UART_IIR_THRI)) : 1255 (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT)) 1256 transmit_chars(up); 1257 } 1258 } On NON-buggy UARTs line 1245 causes a THRI interrupt request. If the IIR has not been read by the ISR by the time it is read on line 1251, the value read by line 1251 can indicate that THRI is pending; in this case, reading the IIR would clear the THRI status, causing the interrupt to get lost. This value read from the IIR would not be UART_IIR_NO_INT so that line 1256 would be bypassed; with no characters sent to the transmitter in the UART another THRI interrupt request would not occur. Subsequent calls to this routine do nothing because the UART_IER_THRI bit is already set. This causes output stalls. Proposed fixes --- Here are two patches that are alternatives for fixing this problem: The first patch was tested at Red Hat and Stratus. It has been released to users of Red Hat Enterprise Linux 5.2. This patch takes the port's irq lock when starting up the UART to provide mutual exclusion between the "quick test" in the startup code and the interrupt service routine. --- linux-2.6.18-92-old/drivers/serial/8250.c 2008-08-13 14:07:08.000000000 +0000 +++ linux-2.6.18-92-new/drivers/serial/8250.c 2008-08-13 14:04:12.000000000 +0000 < at >< at > -1749,65 +1749,73 < at >< at > timeout = timeout > 6 ? (timeout / 2 - 2) : 1; up->timer.data = (unsigned long)up; mod_timer(&up->timer, jiffies + timeout); } else { retval = serial_link_irq_chain(up); if (retval) return retval; } /* * Now, initialize the UART */ serial_outp(up, UART_LCR, UART_LCR_WLEN8); - spin_lock_irqsave(&up->port.lock, flags); + if (is_real_interrupt(up->port.irq)) { + spin_lock_irqsave(&irq_lists[up->port.irq].lock, flags); + spin_lock(&up->port.lock); + } else + spin_lock_irqsave(&up->port.lock, flags); if (up->port.flags & UPF_FOURPORT) { if (!is_real_interrupt(up->port.irq)) up->port.mctrl |= TIOCM_OUT1; } else /* * Most PC uarts need OUT2 raised to enable interrupts. */ if (is_real_interrupt(up->port.irq)) up->port.mctrl |= TIOCM_OUT2; serial8250_set_mctrl(&up->port, up->port.mctrl); /* * Do a quick test to see if we receive an * interrupt when we enable the TX irq. */ serial_outp(up, UART_IER, UART_IER_THRI); lsr = serial_in(up, UART_LSR); iir = serial_in(up, UART_IIR); serial_outp(up, UART_IER, 0); if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) { if (!(up->bugs & UART_BUG_TXEN)) { up->bugs |= UART_BUG_TXEN; pr_debug("ttyS%d - enabling bad tx status workarounds\n", port->line); } } else { up->bugs &= ~UART_BUG_TXEN; } - spin_unlock_irqrestore(&up->port.lock, flags); + if (is_real_interrupt(up->port.irq)) { + spin_unlock(&up->port.lock); + spin_unlock_irqrestore(&irq_lists[up->port.irq].lock, flags); + } else + spin_unlock_irqrestore(&up->port.lock, flags); /* * Finally, enable interrupts. Note: Modem status interrupts * are set via set_termios(), which will be occurring imminently * anyway, so we don't enable them here. */ up->ier = UART_IER_RLSI | UART_IER_RDI; serial_outp(up, UART_IER, up->ier); if (up->port.flags & UPF_FOURPORT) { unsigned int icp; /* * Enable interrupts on the AST Fourport board */ icp = (up->port.iobase & 0xfe0) | 0x01f; outb_p(0x80, icp); The second patch blocks the 16550A UART from asserting its IRQ during the quick test in serial8250_startup previously discussed. This patch patch has only had limited testing at Stratus. --- linux-2.6.24.4.old/drivers/serial/8250.c 2008-03-24 18:49:18.000000000 +0000 +++ linux-2.6.24.4.new/drivers/serial/8250.c 2008-04-16 19:40:41.000000000 +0000 < at >< at > -1876,21 +1876,25 < at >< at > * Most PC uarts need OUT2 raised to enable interrupts. */ if (is_real_interrupt(up->port.irq)) up->port.mctrl |= TIOCM_OUT2; - serial8250_set_mctrl(&up->port, up->port.mctrl); + /* Block IRQ to avoid false positive if SMP */ + serial8250_set_mctrl(&up->port, 0); /* * Do a quick test to see if we receive an * interrupt when we enable the TX irq. */ serial_outp(up, UART_IER, UART_IER_THRI); lsr = serial_in(up, UART_LSR); iir = serial_in(up, UART_IIR); serial_outp(up, UART_IER, 0); + /* Enable this UART to assert its IRQ */ + serial8250_set_mctrl(&up->port, up->port.mctrl); + if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) { if (!(up->bugs & UART_BUG_TXEN)) { up->bugs |= UART_BUG_TXEN; pr_debug("ttyS%d - enabling bad tx status workarounds\n", port->line); Robert N. Evans Software Engineer STRATUS TECHNOLOGIES 111 Powdermill Road, Maynard, MA 01754-3409 U.S.A. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] 8250: add support for DTR/DSR hardware flow control

Alan Cox — 2008-08-13T11:39:08

That would make sense for hardware assisted RS485 but we still have to sort out DTR/DSR as well -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo< at >vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

[PATCH] serial: imx: add console polling routines for kgdboc

Atsuo Igarashi — 2008-08-13T08:27:39

Add console polling routines for the imx uart with kgdboc. Signed-off-by Atsuo Igarashi tripeaks.co.jp>