All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Johnson CH Chen (陳昭勳)" <JohnsonCH.Chen@moxa.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Jiri Slaby" <jirislaby@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"Victor Yu (游勝義)" <victor.yu@moxa.com>,
	"Danny Lin (林政易)" <danny.lin@moxa.com>
Subject: RE: [PATCH] tty: Add MOXA NPort Real TTY Driver
Date: Wed, 22 Jul 2020 07:04:00 +0000	[thread overview]
Message-ID: <HK2PR01MB32817A21FEDDC410F2822640FA790@HK2PR01MB3281.apcprd01.prod.exchangelabs.com> (raw)
In-Reply-To: <20200716072305.GA970724@kroah.com>

Hi Greg,

Thanks for your response!

> > > > +	unsigned long flag;
> > > > +	unsigned char cmd_buffer[84];
> > > > +	unsigned char rsp_buffer[84];
> > >
> > > You seem to have two "static" buffers here, for your device, that 
> > > you semi-randomly write to all over the place, but I can't find 
> > > any locking or coordination between things that prevents multiple 
> > > commands from not just overwritting each other.
> > >
> > For cmd_buffer[], we use npreal_wait_and_set_command() to make sure 
> > cmd_buffer[] is safe to be written by checking "cmd_buffer[0] == 0".
> 
> And what locks are protecting you there?
> 
> > For rsp_buffer[], we use npreal_wait_command_completed() to make 
> > sure rsp_buffer[] is desired by checking rsp_buffer[0] and rsp_buffer[1].
> > Command_set and command should be checked. Besides, rsp_buffer[] is 
> > got from user space by "NPREAL_NET_CMD_RESPONSE" in 
> > npreal_net_ioctl().
> 
> Again, what locking is really handling this?
> 

It's better to protect cmd_buffer[84] and rsp_buffer[84] by locking completely. They are safe because NPort driver should be worked with NPort daemon before, and NPort daemon is designed to be simple.

> > > Also, how does the data get sent to the hardware at all?  I see 
> > > cmd_buffer[] being written to, but what reads from it and how does 
> > > the hardware get the data?
> >
> > Actually we need to both NPort driver (this driver) and Npreal 
> > daemon
> > (userspace) to let HW work. Npreal daemon can communicate with HW by 
> > socket, and Npreal deamon communicates with Nport driver by 
> > "npreal_net_fops". When commands are ready for driver part, it will 
> > wake up poll event to let Nport daemon know.
> 
> That is not obvious at all, and needs to be really really really documented here.
> Why not put the userspace chunk in the tree too?  At the least, you 
> need to point at it.
> 
> And why is a userspace part needed?  We have tty-over-ethernet drivers 
> that do not require such a thing in the tree somewhere...
>

Because we need hardware serial to Ethernet converter (NPort device server) to manage some serial devices, so we still need to use MOXA Nport's commands and responses between host computer and converter. We will have an internal discussion about release of Nport daemon and related document, or using free tty to Ethernet daemon such as (ser2net/ socat/ remtty) and improved nport driver later. Thanks a lot!

Best regards,
Johnson

  reply	other threads:[~2020-07-22  7:04 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-14  6:24 [PATCH] tty: Add MOXA NPort Real TTY Driver Johnson CH Chen (陳昭勳)
2020-07-14  7:11 ` Greg Kroah-Hartman
2020-07-23 10:54   ` Johnson CH Chen (陳昭勳)
2020-07-14  7:36 ` Greg Kroah-Hartman
2020-07-16  7:19   ` Johnson CH Chen (陳昭勳)
2020-07-16  7:23     ` Greg Kroah-Hartman
2020-07-22  7:04       ` Johnson CH Chen (陳昭勳) [this message]
2020-07-22  7:11         ` Greg Kroah-Hartman
2020-07-14  9:34 ` Jiri Slaby
2020-08-07  9:18   ` Johnson CH Chen (陳昭勳)
2020-08-07  9:48     ` Greg Kroah-Hartman
2020-07-15  8:27 ` kernel test robot
2020-07-15  8:27   ` kernel test robot
2020-07-24  5:32 ` kernel test robot
2020-07-24  5:32   ` kernel test robot
2020-07-28 20:40 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=HK2PR01MB32817A21FEDDC410F2822640FA790@HK2PR01MB3281.apcprd01.prod.exchangelabs.com \
    --to=johnsonch.chen@moxa.com \
    --cc=danny.lin@moxa.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=victor.yu@moxa.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.