[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-serial
Subject:    Re: g_serial hangs on write when the cable is disconnected
From:       Peter Hurley <peter () hurleysoftware ! com>
Date:       2015-08-06 15:16:25
Message-ID: 55C37A49.3020503 () hurleysoftware ! com
[Download RAW message or body]

[ +cc Felipe ]

Hi Laszlo,

On 08/06/2015 10:03 AM, Laszlo Papp wrote:
> On Thu, Aug 6, 2015 at 2:52 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> On Thu, 6 Aug 2015, Laszlo Papp wrote:
>>> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
>>>> On Wed, 5 Aug 2015, Greg KH wrote:
>>>>
>>>>> hm, wait, is this really the n_gsm line discipline?  Or is it something
>>>>> else?
>>>>>
>>>>> g_serial is the device side of a serial connection, there is no "cable
>>>>> removed" notification that it even knows about, that has to come from
>>>>> the gadget driver somehow, which you should listen for and then kick
>>>>> your userspace program.
>>>>
>>>> There is the gserial_disconnect() callback, which gets invoked when the
>>>> Vbus power (provided by the host) is removed.  It's a pretty good
>>>> indicator that the USB cable has been unplugged.
>>>>
>>>> I don't understand all the stuff that gserial_disconnect() does, but it
>>>> ought to be more or less equivalent to a "hangup" -- as the kerneldoc
>>>> says.  If it doesn't do what users expect, there's probably a bug
>>>> somewhere.
>>>>
>>>> Of course, it's possible that the callback does not get invoked in
>>>> Laszlo's case.  Then the question would be: Why not?
>>>
>>> Hmm, that is a good question. I wonder if there had been any recent
>>> fixes for that lately... I suppose that I will need to skim through
>>> the git log. Thank you for the hints!
>>
>> You should also add a printk statement to the disconnect callback so
>> that you can verify whether it really is getting called.
> 
> Thanks. Should that also be called if I just boot up the board with
> Linux on it while the cable is not attached. In other words, the
> problem that I am also experiencing is that it blocks even when no
> cable is attached to the board and there has been no cable ever
> attached for the last boot.

You have everyone hopelessly confused about what your problem actually is.

Your $subject says that "g_serial hangs on write" and for a reproducer
you provide:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main()
{
    const char buf[] = "Hello World!\n";
    int fd = open("/dev/ttyGS0", O_RDWR | O_NONBLOCK);
    int sent = write(fd, buf, sizeof(buf)-1);
    close(fd);
    return 0;
}

Only a careful reader would have caught this in your subsequent reply:

On Wed, Aug 05, 2015 at 04:40:21PM +0100, Laszlo Papp wrote:
> Wow, I managed to mess it up in my original email! So, this code above
> made it working, but without O_NONBLOCK, it was not working. Using
> O_NONBLOCK is my current nasty workaround.

To answer your original question, yes, the write() is behaving as expected.
If you open a tty without O_NONBLOCK, then both read() and write() to that
tty will _block_ until the operation is successful or the tty is hung up.

Your comparison with how ttyS* ports behave when a cable is not connected
is based on incorrect assumptions. When a ttyS port is in CLOCAL mode
(the default), the cable state is ignored when _opening_. On write(),
without hardware flow control (CRTSCTS), the serial port is successfully
writing the data out without knowing that nothing is listening.

I don't see a bug here.

Regards,
Peter Hurley




--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]