On Thu, Aug 6, 2015 at 4:16 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> [ +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@xxxxxxxxxxxxxxxxxxx> wrote:
>>> On Thu, 6 Aug 2015, Laszlo Papp wrote:
>>>> On Wed, Aug 5, 2015 at 7:15 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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.
Yes, of course. I made a mistake with that and I apologise.
> 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.
Yes, you are right with that. There is no way to detect errors without
some handshaking on the serial port.
For now, O_NONBLOCK, it is, until I find a better example to work with.
> I don't see a bug here.
It is very likely just a missing example in the documentation. I do
not think that there is a bug in here.
> Regards,
> Peter Hurley
>
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
