On Mon, Aug 29, 2016 at 4:46 PM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Mon, Aug 29, 2016 at 02:49:23PM +0530, Malith Yapa wrote:
>> On Thu, Jul 14, 2016 at 9:14 AM, Malith Yapa <malithy...@gmail.com> wrote:
>> > On Thu, Jul 14, 2016 at 2:14 AM, Greg KH <gre...@linuxfoundation.org>
>> > wrote:
>> >> On Wed, Jul 13, 2016 at 10:59:10AM +0530, Malith Yapa wrote:
>> >>> I think i am.
>> >>>
>> >>> int readDword(int addr) {
>> >>>
>> >>> uint16_t reg[1];// will store read registers values
>> >>>
>> >>> int num = modbus_read_registers(ctx, addr, 1, reg); //16386 = X2
>> >>>
>> >>> usleep(5);
>> >>>
>> >>> if (num != 1) {
>> >>> fprintf(stderr, "Failed(%i) to read: %s\n", num,
>> >>> modbus_strerror(errno));
>> >>> modbus_close(ctx);
>> >>> modbus_free(ctx);
>> >>> sleep(5);
>> >>> int wait = 1;
>> >>> while(initModbus()) {
>> >>> cerr << "Waiting for PLC.. SLEEP[" << wait*20 << "]" << endl;
>> >>> sleep(wait*20);
>> >>> wait++;
>> >>> }
>> >>> }
>> >>>
>> >>> return reg[0];
>> >>> }
>> >>>
>> >>> according to modbus documentation, "The modbus_close() function shall
>> >>> close the connection established with the backend set in the context."
>> >>>
>> >>> Even if not. Shouldn't the minor number's go upto 512 (as Johan
>> >>> pointed out) before giving up?
>> >>
>> >> Yes it should.
>> >>
>> >>> The system is an Olimex A20-micro,
>> >>> Linux version 3.4.90+ (gcc version 4.7.1 (Debian 4.7.1-7) )
>> >>
>> >> Ugh, 3.4 is a very old, and obsolete kernel version. Please get support
>> >> for it from the vendor that is forcing you to use such a thing, as you
>> >> are already paying for it from them.
>> >>
>> >> We can help you out if you can reproduce this on 4.6, have you tried
>> >> that?
>> >>
>> >> thanks,
>> >>
>> >> greg k-h
>> >
>> > Looks like sunxi only provides a 3.4 kernel. I lack the expertise to
>> > try to build 4.6 for this board so I'll try reporting it to them.
>> >
>> > Thanks,
>> > Malith
>>
>> Hope it's ok to reply on the old thread.
>>
>> I have since compiled 4.8.0_rc1. And just as you guys suggested a part
>> of problem is solved. The minor number now definitely goes up to 512
>> before giving no more free serial devices. But it still doesn't reuse
>> the minors after disconnecting.
>>
>> In my code I'm calling modbus_close and modbus_free which in turn call
>> close() and free() on the file descriptor. Shouldn't this make the
>> minor reusable?
>>
>> >From what i understand minor numbers are allocated and freed by the
>> driver. So how does the driver know to release the minor number after
>> the file descriptor is closed?
>
> The USB serial driver core code handles this for you automatically after
> the last reference goes away. Are you sure that userspace is properly
> releasing the device properly?
>
> thanks,
>
> greg k-h
>From my understanding it is, but let me double check. If i compile the
kernel with some print statements in usb-serial.c, will i get the
output in stdout?
In the userspace is it sufficient to just call close() on the file
descriptor in /dev ? Is it possible that udev has already replaced
/dev/ttyUSBx with /dev/ttyUSBx+1 by the time the program calls close()
on it?
It's very likely that i'm making a silly mistake somewhere. Please
bare with me :/
Would appreciate any pointers you can give to help me understand the
usb serial core better.
Thanks!
Malith
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
