- 16 Aug, 2012 8 commits
-
-
Russ Gorby authored
gsm_data_kick was recently modified to allow messages on the tx queue bound for DLCI0 to flow even during FCOFF conditions. Unfortunately we introduced a bug discovered by code inspection where subsequent list traversers can access freed memory if the DLCI0 messages were not all at the head of the list. Replaced singly linked tx list w/ a list_head and used provided interfaces for traversing and deleting members. Signed-off-by:
Russ Gorby <russ.gorby@intel.com> Tested-by:
Yin, Fengwei <fengwei.yin@intel.com> Signed-off-by:
Alan Cox <alan@linux.intel.com> Cc: Riding School <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Russ Gorby authored
There were some locking holes in the management of the MUX's message queue for 2 code paths: 1) gsmld_write_wakeup 2) receipt of CMD_FCON flow-control message In both cases gsm_data_kick is called w/o locking so it can collide with other other instances of gsm_data_kick (pulling messages tx_tail) or potentially other instances of __gsm_data_queu (adding messages to tx_head) Changed to take the tx_lock in these 2 cases Signed-off-by:
-
samix.lebsir authored
The design of uplink flow control in the mux driver is that for constipated channels data will backup into the per-channel fifos, and any messages that make it to the outbound message queue will still go out. Code was added to also stop messages that were in the outbound queue but this requires filtering through all the messages on the queue for stopped dlcis and changes some of the mux logic unneccessarily. The message fiiltering was removed to be in line w/ the original design as the message filtering does not provide any solution. Extra debug messages used during investigation were also removed. Signed-off-by:
samix.lebsir <samix.lebsir@intel.com> Signed-off-by:
-
Frederic Berat authored
- Correcting handling of FCon/FCoff in order to respect 27.010 spec - Consider FCon/off will overide all dlci flow control except for dlci0 as we must be able to send control frames. - Dlci constipated handling according to FC, RTC and RTR values. - Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according to dlci constipated value Signed-off-by:
Frederic Berat <fredericx.berat@intel.com> Signed-off-by:
-
Russ Gorby authored
gsm_dlci_data_kick will not call any output function if tx_bytes > THRESH_LO furthermore it will call the output function only once if tx_bytes == 0 If the size of the IP writes are on the order of THRESH_LO we can get into a situation where skbs accumulate on the outbound list being starved for events to call the output function. gsm_dlci_data_kick now calls the sweep function when tx_bytes==0 Signed-off-by:
Kappel, LaurentX <laurentx.kappel@intel.com> Signed-off-by:
-
xiaojin authored
In 3GPP27.010 5.8.1, it defined: The TE multiplexer initiates the establishment of the multiplexer control channel by sending a SABM frame on DLCI 0 using the procedures of clause 5.4.1. Once the multiplexer channel is established other DLCs may be established using the procedures of clause 5.4.1. This patch implement 5.8.1 in MUX level, it make sure DLC0 is the first channel to be setup. [or for those not familiar with the specification: it was possible to try and open a data connection while the control channel was not yet fully open, which is a spec violation and confuses some modems] Signed-off-by:
xiaojin <jin.xiao@intel.com> Tested-by:
-
Stanislav Kozina authored
Change the BUG_ON to WARN_ON and return in case of tty->read_buf==NULL. We want to track a couple of long standing reports of this but at the same time we can avoid killing the box. Signed-off-by:
Stanislav Kozina <skozina@redhat.com> Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
- 15 Aug, 2012 1 commit
-
-
Julia Lawall authored
Convert a 0 error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e,e1,e2,e3,e4,x; @@ ( if (\(ret != 0\|ret < 0\) || ...) { ... return ...; } | ret = 0 ) ... when != ret = e1 *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...); ... when != x = e2 when != ret = e3 *if (x == NULL || ...) { ... when != ret = e4 * return ret; } // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
- 14 Aug, 2012 2 commits
-
-
David Daney authored
The changes in linux-next removing serial8250_register_port() cause OCTEON to fail to compile. Lets make OCTEON use the new serial8250_register_8250_port() instead. Signed-off-by:
David Daney <david.daney@cavium.com> Cc: Alan Cox <alan@linux.intel.com> Acked-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Jiri Slaby authored
Commit "TTY: synclink_cs, use dynamic tty devices" added a call to tty_port_register_device with a proper device as the last argument. But it was not correct and it causes build failures: synclink_cs.c: In function ‘mgslpc_add_device’: synclink_cs.c:2735:16: error: request for member ‘dev’ in something not a structure or union info->p_dev is a pointer, so act as that. I wonder why my build scripts did not notice. I have to re-check them. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
- 13 Aug, 2012 25 commits
-
-
Jiri Slaby authored
444 means 0674 and we do not definitely want that. Use S_IRUGO which is much more safer. Signed-off-by:
Rusty Russell <rusty@ozlabs.org> Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty >From now on, we only increase the reference count in ->install (and decrease in ->cleanup). Signed-off-by:
-
Jiri Slaby authored
Make the code of hvcs_open a bit more readable by: - moving all assignments out of if's - redoing fail paths so that corresponding pieces are nearby - we need only one of retval and rc Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty Since we take a reference to a port in ->install, we need also ->cleanup to drop that reference. Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty In this case ->install is the only thing we want to do. We do not need ->open at all. See the tty->count > 1 check. And since we take a reference in ->install, we need also ->cleanup to drop the reference to a view. Final note, see that we leave raw3270_find_view in place. It is because views are removed even from module_exit. Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty The "tty->port = port" assignment is not needed anymore since it happens in tty_port_install implicitly. Signed-off-by:
-
Jiri Slaby authored
This has two outcomes: * we give the TTY layer a tty_port * we do not find the info structure every time open is called on that tty Signed-off-by:
-
Jiri Slaby authored
raw3215[line] is set in probe, but not unset in remove. This will lead to random crashes if the device is removed and the corresponding tty opened later. open would dereference freed memory. So set raw3215[line] to NULL in remove to fix that. Signed-off-by:
-
Jiri Slaby authored
Every tty driver needs tty_port for each line. So let us add one to nfcon too. And link it so that the tty layer knows about it. Signed-off-by:
-
Jiri Slaby authored
This allows us to provide the tty layer with information about tty_port for each link. We also provide a tty_port for the service port. For this one we allow only ioctl, so this is pretty ugly. Signed-off-by:
-
Jiri Slaby authored
* use <tab> for indentation * add KERN_* to printks * no more assignments in if's like if ((rc = function())) Signed-off-by:
-
Jiri Slaby authored
This allows us to provide the tty layer with information about tty_port for each link. And it also allows us to get rid of the remove_device loop in synclink_cs_exit because we had to reorder pcmcia and tty driver registration in init. This was because we need to have serial_driver initialized when calling tty_port_register_device from pcmcia ->probe. Signed-off-by:
-
Jiri Slaby authored
We will need to change the order of tty and pcmcia drivers initializations (see the reason later in this series). And the fail path handling is currently performed in a separate function that as well takes care of proper deinitialization in module_exit. It is hard to read and will need to be adjusted by our changes anyway. Instead, get rid of this helper function and do the fail paths handling directly in the init function. (And move the body of the function to module_exit.) Signed-off-by:
-
Jiri Slaby authored
So now for those drivers that can use neither tty_port_install nor tty_port_register_driver but still have tty_port available before tty_register_driver we use newly added tty_port_link_device. The rest of the drivers that still do not provide tty_struct <-> tty_port link will have to be converted to implement tty->ops->install. Signed-off-by:
-
Jiri Slaby authored
This is for those drivers which do not have dynamic device creation (do not call tty_port_register_device) and do not want to implement tty->ops->install (will not call tty_port_install). They still have to provide the link somehow though. And this newly added function is exactly to serve that purpose. Signed-off-by:
-
Jiri Slaby authored
I forgot to document tty_port_register_device and tty_port_install when they were added. Fix it now. Signed-off-by:
-
Jiri Slaby authored
This looks like it was a mistake not to create device nodes for these drivers. Let us create them from now on. It will be necessary to call tty_register_device some way, either by tty_register_driver implicitly or to call tty_register_device proper. Signed-off-by:
-
Jiri Slaby authored
Currently we have no way to assign tty->port while performing tty installation. There are two ways to provide the link tty_struct => tty_port. Either by calling tty_port_install from tty->ops->install or tty_port_register_device called instead of tty_register_device when the device is being set up after connected. In this patch we modify most of the drivers to do the latter. When the drivers use tty_register_device and we have tty_port already, we switch to tty_port_register_device. So we have the tty_struct => tty_port link for free for those. Signed-off-by:
-
Jiri Slaby authored
We need the /dev/ node not to be available before we call tty_register_device. Otherwise we might race with open and tty_struct->port might not be available at that time. This is not an issue now, but would be a problem after "TTY: use tty_port_register_device" is applied. Signed-off-by:
-
Jiri Slaby authored
This allows drivers like ttyprintk to avoid hacks to create an unnumbered node in /dev. It used to set TTY_DRIVER_DYNAMIC_DEV in flags and call device_create on its own. That is incorrect, because TTY_DRIVER_DYNAMIC_DEV may be set only if tty_register_device is called explicitly. Signed-off-by:
-
Jiri Slaby authored
So now, that we have flags and know everything needed, keep a promise and move all the tables and ports allocation from tty_register_driver to tty_alloc_driver. Not only that it makes sense, but we need this for tty_port_link_device which needs tty_driver->ports but is to be called before tty_register_driver. Signed-off-by:
-
Jiri Slaby authored
Switch to the new driver allocation interface, as this is one of the special call-sites. Here, we need TTY_DRIVER_DYNAMIC_ALLOC to not allocate tty_driver->ports, cdevs and potentially other structures because we reserve too many lines in pty. Instead, it provides the tty_port<->tty_struct link in tty->ops->install already. Signed-off-by:
-
- 10 Aug, 2012 4 commits
-
-
Jiri Slaby authored
We need to allow drivers that use neither tty_port_install nor tty_port_register_device to link a tty_port to a tty somehow. To avoid a race with open, this has to be performed before tty_register_device. But currently tty_driver->ports is allocated even in tty_register_device because we do not know whether this is the PTY driver. The PTY driver is special here due to an excessive count of lines it declares to handle. We cannot handle tty_ports there this way. To circumvent this, we start passing tty_driver flags to alloc_tty_driver already and we create tty_alloc_driver for this purpose. There we can allocate tty_driver->ports and do all the magic between tty_alloc_driver and tty_register_device. Later we will introduce tty_port_link_device function for that purpose. All drivers should eventually switch to this new tty driver allocation interface. Signed-off-by:
-
Jiri Slaby authored
On module unload, in tty3270_exit, we forgot to free the tty driver. Add there a call to put_tty_driver. Signed-off-by:
-
Jiri Slaby authored
After tty_register_driver is called, it is too late to initialize a guy with which we operate in open. When a process already called open(2) on that node, the structures may be in use uninitialized. Move the initialization prior to tty_register_driver. Signed-off-by:
-
Jiri Slaby authored
If a user provides a buffer larger than a tty->write_buf chunk and passes '\r' at the end of the buffer, we touch an out-of-bound memory. Add a check there to prevent this. Signed-off-by:
-
