[PATCH v2] staging: dgap: fix kernel oops on port open

[Dan Carpenter]

On Thu, Feb 27, 2014 at 03:39:08PM -0500, Mark Hounschell wrote:
> On 02/26/2014 10:30 AM, Dan Carpenter wrote:
> > On Wed, Feb 26, 2014 at 10:18:26AM -0500, Mark Hounschell wrote:
> >> This patch addresses the follow error message followed
> >> by a kernel oops:
> >>
> >> dgap: driver does not set tty->port. This will crash the kernel later. Fix the driver
> >>
> >> It also renames the main function this patch addresses because
> >> its name is misleading.
> >>
> > 
> > Thanks.
> > 
> > regards,
> > dan carpenter
> 
> I'm in the process of running dgap.c through checkpatch and creating
> another patch set. Before I get too far into it I wanted to get
> clarification on a couple of things.
> 
> 1. Should I wait until I know the status of my last patch before I
> post new ones?

Just assume they will be applied.  If not you will have to redo.

> 
> 2. There are MANY "over 80 char lines" warnings. I'm uncertain of the acceptable way to fix some of them. Here is an example of one:
> 
> 	while (tail != head) {
> 		if (reason & IFTLW) {
> 
> 			if (ch->ch_tun.un_flags & UN_LOW) {
> 				ch->ch_tun.un_flags &= ~UN_LOW;
> 
>                                 // everything in this block is over 80 chars
> 
> 				if (ch->ch_tun.un_flags & UN_ISOPEN) {
> 					if ((ch->ch_tun.un_tty->flags &
> 					   (1 << TTY_DO_WRITE_WAKEUP)) &&
> 						ch->ch_tun.un_tty->ldisc->ops->write_wakeup) { // ????
> 						DGAP_UNLOCK(ch->ch_lock, lock_flags2);
> 						DGAP_UNLOCK(bd->bd_lock, lock_flags);
> 						(ch->ch_tun.un_tty->ldisc->ops->write_wakeup)(ch->ch_tun.un_tty);  // ????
> 						DGAP_LOCK(bd->bd_lock, lock_flags);
> 						DGAP_LOCK(ch->ch_lock, lock_flags2);
> 					}
> 					wake_up_interruptible(&ch->ch_tun.un_tty->write_wait);
> 					wake_up_interruptible(&ch->ch_tun.un_flags_wait);
>                                 // end of nasty block
> 
> 				}
> 			}
> 
> I figured I'd leave them for the last patch but there are a few that if I wait will show up in
> one or more of the patches preceding that last one. This one is actually one of them. While
> fixing up bracket errors with "chechpatch -file", chechpatch doesn't like the patch created.
> 

Break it up into separate functions.

regards,
dan carpenter