Jiri Slaby writes:
>
> On 03/20/2013 01:51 PM, Bill Pemberton wrote:
> > Jiri Slaby writes:
> >>
> >>> drivers/usb/serial/quatech2.c: In function 'qt2_process_read_urb':
> >>> drivers/usb/serial/quatech2.c:661:18: error: 'struct
> >>> qt2_port_private' has no member named 'is_open'
> >>> drivers/usb/serial/quatech2.c:705:15: error: 'struct
> >>> qt2_port_private' has no member named 'is_open'
> >>>
> >>> Caused by commit e4408ce3c23f ("TTY: quatech2, remove unneeded
> >>> is_open"). grep is your friend (or searching while editting the
> >>> file).
> >>
> >> I think this is caused by another commit. Bill added a check for
> >> is_open meanwhile I removed that member completely. Bill, could you
> >> fix that up, please?
> >>
> >
> > Is it legal to call tty_flip_buffer_push() without an open tty? If
> > so, I can get rid of the is_open logic completely. Otherwise, I need
> > to either keep is_open or otherwise check for a valid tty before
> > calling tty_flip_buffer_push().
>
> Yeah, it is legal to call that, as long as you have a valid tty_port.
> Now, the data are queued and later flushed. The plan is to throw the
> data directly on ingress in a way the drivers don't need to care.
>
Ok, for the unopened ports there *should* never be any actual data to
push so the push is really doing nothing anyhow in these cases. It's
coming from the device sending an initial change port command.
Anyhow, so my patch adding more is_open logic can be dropped and then
yours will apply fine. What's the best way for me to handle this?
Send a revert for my patch so yours will apply or send an updated
version of your patch that removes my additions?
--
Bill
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
