Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-20 Thread Sergei Shtylyov

Hello.

On 08/20/2014 07:54 PM, Felipe Balbi wrote:


Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
the hardcoded ttyGS string.



This macro was mostly used in a few debug/warning messages and a lot of
hardcoded ttyGS existed beneath. It may have been used for renaming the
tty, but if done so most debug messages would have ignored this because
of the hardcoded strings.



Due to the fact the usage of this PREFIX instead of the hardcoded strings
in all debug calls would have resulted in a hard to read/grep code it
is removed completely.



Signed-off-by: Richard Leitner 



patch looks fine, can you resend with RFC in the subject ?


   s/with/without/?

WBR, Sergei

--
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


Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-20 Thread Felipe Balbi
Hi,

On Fri, Jul 18, 2014 at 11:39:46AM +0200, Richard Leitner wrote:
> Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
> the hardcoded ttyGS string.
> 
> This macro was mostly used in a few debug/warning messages and a lot of
> hardcoded ttyGS existed beneath. It may have been used for renaming the
> tty, but if done so most debug messages would have ignored this because
> of the hardcoded strings.
> 
> Due to the fact the usage of this PREFIX instead of the hardcoded strings
> in all debug calls would have resulted in a hard to read/grep code it
> is removed completely.
> 
> Signed-off-by: Richard Leitner 

patch looks fine, can you resend with RFC in the subject ?

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-11 Thread Felipe Balbi
Hi,

On Mon, Aug 11, 2014 at 04:52:38PM +0200, Richard Leitner wrote:
> On Mon, 11 Aug 2014 08:50:34 -0500
> Felipe Balbi  wrote:
> 
> > On Mon, Aug 11, 2014 at 03:04:35PM +0200, Richard Leitner wrote:
> > > Hi,
> > > this patch was lying around for some time...
> > > are there any comments or objections on this?
> > 
> > you realise we're still in the middle of the merge window, right ?
> > 
> 
> yeah I know, but I didn't knew that I shouldn't ask for the status of
> my patches during merge windows...

well, usually during merge windows most maintainers take a "break", if
you will. For many, it's the only time we have to sit back and enjoy the
show.

> Sorry for that, this was one of my first patches submitted, so I hope
> you'll be clement with beginners like me ;-)

hehe, no problem.

> I'll come back to you when the merge window is closed.

sure thing. Once v3.17-rc1 is tagged, I'll start queueing patches. Once
they are in my final branches (fixes or next) you'll get an automated
email. Until then you can, if you wish, poll my testing branches
(testing/fixes and testing/next) to check the status of your patches.

cheers

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-11 Thread Richard Leitner
Hi,

On Mon, 11 Aug 2014 08:50:34 -0500
Felipe Balbi  wrote:

> On Mon, Aug 11, 2014 at 03:04:35PM +0200, Richard Leitner wrote:
> > Hi,
> > this patch was lying around for some time...
> > are there any comments or objections on this?
> 
> you realise we're still in the middle of the merge window, right ?
> 

yeah I know, but I didn't knew that I shouldn't ask for the status of my
patches during merge windows...

Sorry for that, this was one of my first patches submitted, so I hope you'll be
clement with beginners like me ;-)

I'll come back to you when the merge window is closed.

thanks & regards,
richard
--
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


Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-11 Thread Felipe Balbi
On Mon, Aug 11, 2014 at 03:04:35PM +0200, Richard Leitner wrote:
> Hi,
> this patch was lying around for some time...
> are there any comments or objections on this?

you realise we're still in the middle of the merge window, right ?

-- 
balbi


signature.asc
Description: Digital signature


Re: [RFC] usb: gadget: serial: remove PREFIX macro

2014-08-11 Thread Richard Leitner
Hi,
this patch was lying around for some time...
are there any comments or objections on this?

regards,
richard

On Fri, 18 Jul 2014 11:39:46 +0200
Richard Leitner  wrote:

> Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
> the hardcoded ttyGS string.
> 
> This macro was mostly used in a few debug/warning messages and a lot of
> hardcoded ttyGS existed beneath. It may have been used for renaming the
> tty, but if done so most debug messages would have ignored this because
> of the hardcoded strings.
> 
> Due to the fact the usage of this PREFIX instead of the hardcoded strings
> in all debug calls would have resulted in a hard to read/grep code it
> is removed completely.
> 
> Signed-off-by: Richard Leitner 
> ---
> note: previous discussion was at https://lkml.org/lkml/2014/6/27/193
> ---
>  drivers/usb/gadget/u_serial.c |   21 +
>  1 file changed, 9 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
> index ad0aca8..7e7a6b0 100644
> --- a/drivers/usb/gadget/u_serial.c
> +++ b/drivers/usb/gadget/u_serial.c
> @@ -55,11 +55,8 @@
>   * for a telephone or fax link.  And ttyGS2 might be something that just
>   * needs a simple byte stream interface for some messaging protocol that
>   * is managed in userspace ... OBEX, PTP, and MTP have been mentioned.
> - */
> -
> -#define PREFIX   "ttyGS"
> -
> -/*
> + *
> + *
>   * gserial is the lifecycle interface, used by USB functions
>   * gs_port is the I/O nexus, used by the tty driver
>   * tty_struct links to the tty/filesystem framework
> @@ -385,7 +382,7 @@ __acquires(&port->port_lock)
>   list_del(&req->list);
>   req->zero = (gs_buf_data_avail(&port->port_write_buf) == 0);
>  
> - pr_vdebug(PREFIX "%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
> + pr_vdebug("ttyGS%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
>   port->port_num, len, *((u8 *)req->buf),
>   *((u8 *)req->buf+1), *((u8 *)req->buf+2));
>  
> @@ -503,12 +500,12 @@ static void gs_rx_push(unsigned long _port)
>   switch (req->status) {
>   case -ESHUTDOWN:
>   disconnect = true;
> - pr_vdebug(PREFIX "%d: shutdown\n", port->port_num);
> + pr_vdebug("ttyGS%d: shutdown\n", port->port_num);
>   break;
>  
>   default:
>   /* presumably a transient fault */
> - pr_warning(PREFIX "%d: unexpected RX status %d\n",
> + pr_warn("ttyGS%d: unexpected RX status %d\n",
>   port->port_num, req->status);
>   /* FALLTHROUGH */
>   case 0:
> @@ -537,7 +534,7 @@ static void gs_rx_push(unsigned long _port)
>   if (count != size) {
>   /* stop pushing; TTY layer can't handle more */
>   port->n_read += count;
> - pr_vdebug(PREFIX "%d: rx block %d/%d\n",
> + pr_vdebug("ttyGS%d: rx block %d/%d\n",
>   port->port_num,
>   count, req->actual);
>   break;
> @@ -569,7 +566,7 @@ static void gs_rx_push(unsigned long _port)
>   if (do_push)
>   tasklet_schedule(&port->push);
>   else
> - pr_warning(PREFIX "%d: RX not scheduled?\n",
> + pr_warn("ttyGS%d: RX not scheduled?\n",
>   port->port_num);
>   }
>   }
> @@ -985,7 +982,7 @@ static void gs_unthrottle(struct tty_struct *tty)
>* read queue backs up enough we'll be NAKing OUT packets.
>*/
>   tasklet_schedule(&port->push);
> - pr_vdebug(PREFIX "%d: unthrottle\n", port->port_num);
> + pr_vdebug("ttyGS%d: unthrottle\n", port->port_num);
>   }
>   spin_unlock_irqrestore(&port->port_lock, flags);
>  }
> @@ -1295,7 +1292,7 @@ static int userial_init(void)
>   return -ENOMEM;
>  
>   gs_tty_driver->driver_name = "g_serial";
> - gs_tty_driver->name = PREFIX;
> + gs_tty_driver->name = "ttyGS";
>   /* uses dynamically assigned dev_t values */
>  
>   gs_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
--
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


[RFC] usb: gadget: serial: remove PREFIX macro

2014-07-18 Thread Richard Leitner
Remove the ttyGS PREFIX macro from u_serial.c and replace all occurences with
the hardcoded ttyGS string.

This macro was mostly used in a few debug/warning messages and a lot of
hardcoded ttyGS existed beneath. It may have been used for renaming the
tty, but if done so most debug messages would have ignored this because
of the hardcoded strings.

Due to the fact the usage of this PREFIX instead of the hardcoded strings
in all debug calls would have resulted in a hard to read/grep code it
is removed completely.

Signed-off-by: Richard Leitner 
---
note: previous discussion was at https://lkml.org/lkml/2014/6/27/193
---
 drivers/usb/gadget/u_serial.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index ad0aca8..7e7a6b0 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -55,11 +55,8 @@
  * for a telephone or fax link.  And ttyGS2 might be something that just
  * needs a simple byte stream interface for some messaging protocol that
  * is managed in userspace ... OBEX, PTP, and MTP have been mentioned.
- */
-
-#define PREFIX "ttyGS"
-
-/*
+ *
+ *
  * gserial is the lifecycle interface, used by USB functions
  * gs_port is the I/O nexus, used by the tty driver
  * tty_struct links to the tty/filesystem framework
@@ -385,7 +382,7 @@ __acquires(&port->port_lock)
list_del(&req->list);
req->zero = (gs_buf_data_avail(&port->port_write_buf) == 0);
 
-   pr_vdebug(PREFIX "%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
+   pr_vdebug("ttyGS%d: tx len=%d, 0x%02x 0x%02x 0x%02x ...\n",
port->port_num, len, *((u8 *)req->buf),
*((u8 *)req->buf+1), *((u8 *)req->buf+2));
 
@@ -503,12 +500,12 @@ static void gs_rx_push(unsigned long _port)
switch (req->status) {
case -ESHUTDOWN:
disconnect = true;
-   pr_vdebug(PREFIX "%d: shutdown\n", port->port_num);
+   pr_vdebug("ttyGS%d: shutdown\n", port->port_num);
break;
 
default:
/* presumably a transient fault */
-   pr_warning(PREFIX "%d: unexpected RX status %d\n",
+   pr_warn("ttyGS%d: unexpected RX status %d\n",
port->port_num, req->status);
/* FALLTHROUGH */
case 0:
@@ -537,7 +534,7 @@ static void gs_rx_push(unsigned long _port)
if (count != size) {
/* stop pushing; TTY layer can't handle more */
port->n_read += count;
-   pr_vdebug(PREFIX "%d: rx block %d/%d\n",
+   pr_vdebug("ttyGS%d: rx block %d/%d\n",
port->port_num,
count, req->actual);
break;
@@ -569,7 +566,7 @@ static void gs_rx_push(unsigned long _port)
if (do_push)
tasklet_schedule(&port->push);
else
-   pr_warning(PREFIX "%d: RX not scheduled?\n",
+   pr_warn("ttyGS%d: RX not scheduled?\n",
port->port_num);
}
}
@@ -985,7 +982,7 @@ static void gs_unthrottle(struct tty_struct *tty)
 * read queue backs up enough we'll be NAKing OUT packets.
 */
tasklet_schedule(&port->push);
-   pr_vdebug(PREFIX "%d: unthrottle\n", port->port_num);
+   pr_vdebug("ttyGS%d: unthrottle\n", port->port_num);
}
spin_unlock_irqrestore(&port->port_lock, flags);
 }
@@ -1295,7 +1292,7 @@ static int userial_init(void)
return -ENOMEM;
 
gs_tty_driver->driver_name = "g_serial";
-   gs_tty_driver->name = PREFIX;
+   gs_tty_driver->name = "ttyGS";
/* uses dynamically assigned dev_t values */
 
gs_tty_driver->type = TTY_DRIVER_TYPE_SERIAL;
-- 
1.7.10.4
--
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