Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Chen Gang
于 2012年12月19日 12:09, Greg KH 写道:
> On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
>> Hello Paul Fulghum:
>>
>> it seems you are very busy,
>>   and can not get your reply for "checking length in function rx_get_buf".
> 
> You should always send patches, long emails like this about "potential"
> issues are hard to handle, patches are best.
> 
> greg k-h
> 
> 

  ok, I will send patch after unit test.


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Greg KH
On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
> Hello Paul Fulghum:
> 
> it seems you are very busy,
>   and can not get your reply for "checking length in function rx_get_buf".

You should always send patches, long emails like this about "potential"
issues are hard to handle, patches are best.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Chen Gang
Hello Paul Fulghum:

it seems you are very busy,
  and can not get your reply for "checking length in function rx_get_buf".

so I suggest:
  design:
to give it additional length checking in function rx_get_buf.
if realy > max_frame_size, will return false (also need call free_rbufs).
  unit test plan:
write a simple driver to integrate relative functions (already modified as 
design).
pass compiling, and can succeed loading.
and then
  call the relative function (rx_get_buf) with intended values
  check the work flow of our modification whether as expected.

at last, I still suggestion Paul Fulghum to provide the patch when he has free 
time.
  for synclink, he is more expert than me.
  for synclink, he can give better test.

  if still get no reply within an additonal week:
I should provide the patch, it is my duty.
I will be according to the patch which Paul Fulghum has already provided.
and then add the "checking length in function rx_get_buf".


  Regards

gchen.

于 2012年12月05日 09:57, Chen Gang 写道:
> by the way:
>   does it also need check the length in function rx_get_buf ? 
>   (it seems not, but I am not quite sure, can you give a confirm ?)
> 
> 4779 /*
> 4780  * pass receive buffer (RAW synchronous mode) to tty layer
> 4781  * return true if buffer available, otherwise false
> 4782  */
> 4783 static bool rx_get_buf(struct slgt_info *info)
> 4784 {
> 4785 unsigned int i = info->rbuf_current;
> 4786 unsigned int count;
> 4787 
> 4788 if (!desc_complete(info->rbufs[i]))
> 4789 return false;
> 4790 count = desc_count(info->rbufs[i]);
> 4791 switch(info->params.mode) {
> 4792 case MGSL_MODE_MONOSYNC:
> 4793 case MGSL_MODE_BISYNC:
> 4794 case MGSL_MODE_XSYNC:
> 4795 /* ignore residue in byte synchronous modes */
> 4796 if (desc_residue(info->rbufs[i]))
> 4797 count--;
> 4798 break;
> 4799 }
> 4800 DBGDATA(info, info->rbufs[i].buf, count, "rx");
> 4801 DBGINFO(("rx_get_buf size=%d\n", count));
> 4802 if (count)
> 4803 ldisc_receive_buf(info->port.tty, info->rbufs[i].buf,
> 4804   info->flag_buf, count);
> 4805 free_rbufs(info, i, i);
> 4806 return true;
> 4807 }


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Chen Gang
Hello Paul Fulghum:

it seems you are very busy,
  and can not get your reply for checking length in function rx_get_buf.

so I suggest:
  design:
to give it additional length checking in function rx_get_buf.
if realy  max_frame_size, will return false (also need call free_rbufs).
  unit test plan:
write a simple driver to integrate relative functions (already modified as 
design).
pass compiling, and can succeed loading.
and then
  call the relative function (rx_get_buf) with intended values
  check the work flow of our modification whether as expected.

at last, I still suggestion Paul Fulghum to provide the patch when he has free 
time.
  for synclink, he is more expert than me.
  for synclink, he can give better test.

  if still get no reply within an additonal week:
I should provide the patch, it is my duty.
I will be according to the patch which Paul Fulghum has already provided.
and then add the checking length in function rx_get_buf.


  Regards

gchen.

于 2012年12月05日 09:57, Chen Gang 写道:
 by the way:
   does it also need check the length in function rx_get_buf ? 
   (it seems not, but I am not quite sure, can you give a confirm ?)
 
 4779 /*
 4780  * pass receive buffer (RAW synchronous mode) to tty layer
 4781  * return true if buffer available, otherwise false
 4782  */
 4783 static bool rx_get_buf(struct slgt_info *info)
 4784 {
 4785 unsigned int i = info-rbuf_current;
 4786 unsigned int count;
 4787 
 4788 if (!desc_complete(info-rbufs[i]))
 4789 return false;
 4790 count = desc_count(info-rbufs[i]);
 4791 switch(info-params.mode) {
 4792 case MGSL_MODE_MONOSYNC:
 4793 case MGSL_MODE_BISYNC:
 4794 case MGSL_MODE_XSYNC:
 4795 /* ignore residue in byte synchronous modes */
 4796 if (desc_residue(info-rbufs[i]))
 4797 count--;
 4798 break;
 4799 }
 4800 DBGDATA(info, info-rbufs[i].buf, count, rx);
 4801 DBGINFO((rx_get_buf size=%d\n, count));
 4802 if (count)
 4803 ldisc_receive_buf(info-port.tty, info-rbufs[i].buf,
 4804   info-flag_buf, count);
 4805 free_rbufs(info, i, i);
 4806 return true;
 4807 }


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Greg KH
On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
 Hello Paul Fulghum:
 
 it seems you are very busy,
   and can not get your reply for checking length in function rx_get_buf.

You should always send patches, long emails like this about potential
issues are hard to handle, patches are best.

greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-18 Thread Chen Gang
于 2012年12月19日 12:09, Greg KH 写道:
 On Wed, Dec 19, 2012 at 10:23:29AM +0800, Chen Gang wrote:
 Hello Paul Fulghum:

 it seems you are very busy,
   and can not get your reply for checking length in function rx_get_buf.
 
 You should always send patches, long emails like this about potential
 issues are hard to handle, patches are best.
 
 greg k-h
 
 

  ok, I will send patch after unit test.


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Consult]: Re: [PATCH] synclink fix ldisc buffer argument

2012-12-09 Thread Chen Gang
Hello Paul Fulghum:

  Firstly, sorry for my mistake:
I am a reporter (not reviewer), and not suitable to review maintainer's 
patch.
when you send relative patch, need not cc to me (I am not reviewer)

  so:
could you send patch again (not need cc to me) ?
  (and also it is better to mark me as Reported-by in your patch)

  sorry for my mistake, again.

gchen.


于 2012年12月07日 10:15, Chen Gang 写道:
> Hello Greg Kroah-Hartman:
> 
> 
> 于 2012年12月04日 01:13, Paul Fulghum 写道:
>> Fix call to line discipline receive_buf by synclink drivers.
>> Dummy flag buffer argument is ignored by N_HDLC line discipline but might
>> be of insufficient size if accessed by a different line discipline
>> selected by mistake. flag buffer allocation now matches max size of data
>> buffer. Unused char_buf buffers are removed.
>>
>> Signed-off-by: Paul Fulghum 
> 
> if no additional questions:
>   is it suitable to let this patch pass checking ?
>   at least for me, it is surely solve an issue, and no negative effect.
> 
> now, maybe Paul Fulghum is busy...
>   the left questions what I have sent seems minor.
>   so they can be delayed, until he has free time.
> 
> when Paul Fulghum has free time.
>   can still check what my left questions whether valid.
>   if they are valid, can send additional patch for them.
> 
> 
>   is it OK ?
> 
>   Regards
> 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[Consult]: Re: [PATCH] synclink fix ldisc buffer argument

2012-12-09 Thread Chen Gang
Hello Paul Fulghum:

  Firstly, sorry for my mistake:
I am a reporter (not reviewer), and not suitable to review maintainer's 
patch.
when you send relative patch, need not cc to me (I am not reviewer)

  so:
could you send patch again (not need cc to me) ?
  (and also it is better to mark me as Reported-by in your patch)

  sorry for my mistake, again.

gchen.


于 2012年12月07日 10:15, Chen Gang 写道:
 Hello Greg Kroah-Hartman:
 
 
 于 2012年12月04日 01:13, Paul Fulghum 写道:
 Fix call to line discipline receive_buf by synclink drivers.
 Dummy flag buffer argument is ignored by N_HDLC line discipline but might
 be of insufficient size if accessed by a different line discipline
 selected by mistake. flag buffer allocation now matches max size of data
 buffer. Unused char_buf buffers are removed.

 Signed-off-by: Paul Fulghum pau...@microgate.com
 
 if no additional questions:
   is it suitable to let this patch pass checking ?
   at least for me, it is surely solve an issue, and no negative effect.
 
 now, maybe Paul Fulghum is busy...
   the left questions what I have sent seems minor.
   so they can be delayed, until he has free time.
 
 when Paul Fulghum has free time.
   can still check what my left questions whether valid.
   if they are valid, can send additional patch for them.
 
 
   is it OK ?
 
   Regards
 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-06 Thread Chen Gang
Hello Greg Kroah-Hartman:


于 2012年12月04日 01:13, Paul Fulghum 写道:
> Fix call to line discipline receive_buf by synclink drivers.
> Dummy flag buffer argument is ignored by N_HDLC line discipline but might
> be of insufficient size if accessed by a different line discipline
> selected by mistake. flag buffer allocation now matches max size of data
> buffer. Unused char_buf buffers are removed.
> 
> Signed-off-by: Paul Fulghum 

if no additional questions:
  is it suitable to let this patch pass checking ?
  at least for me, it is surely solve an issue, and no negative effect.

now, maybe Paul Fulghum is busy...
  the left questions what I have sent seems minor.
  so they can be delayed, until he has free time.

when Paul Fulghum has free time.
  can still check what my left questions whether valid.
  if they are valid, can send additional patch for them.


  is it OK ?

  Regards

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-06 Thread Chen Gang
Hello Greg Kroah-Hartman:


于 2012年12月04日 01:13, Paul Fulghum 写道:
 Fix call to line discipline receive_buf by synclink drivers.
 Dummy flag buffer argument is ignored by N_HDLC line discipline but might
 be of insufficient size if accessed by a different line discipline
 selected by mistake. flag buffer allocation now matches max size of data
 buffer. Unused char_buf buffers are removed.
 
 Signed-off-by: Paul Fulghum pau...@microgate.com

if no additional questions:
  is it suitable to let this patch pass checking ?
  at least for me, it is surely solve an issue, and no negative effect.

now, maybe Paul Fulghum is busy...
  the left questions what I have sent seems minor.
  so they can be delayed, until he has free time.

when Paul Fulghum has free time.
  can still check what my left questions whether valid.
  if they are valid, can send additional patch for them.


  is it OK ?

  Regards

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-04 Thread Chen Gang
于 2012年12月04日 00:03, Paul Fulghum 写道:
> On 12/2/2012 8:20 PM, Chen Gang wrote:
>> pardon (I am just learning)
>>   does 65535 mean HDLC_MAX_FRAME_SIZE ?
>>   why do we need info->max_frame_size >= 4096 ?
>> in drivers/tty/synclink_gt.c:
>> 3550 if (info->max_frame_size < 4096)
>> 3551 info->max_frame_size = 4096;
>> 3552 else if (info->max_frame_size > 65535)
>> 3553 info->max_frame_size = 65535;
>> 3554
>>  ...
>> 3603 info->max_frame_size = 4096;
> 
> The hardware can send and receive HDLC frames up to
> 64K in size. The driver defaults to 4K max frame size
> to save buffer space for the common case
> (line 3603 in alloc_dev()).
> 
> The module parameter max_frame_size can override the default
> in add_device() (lines 3550-3554 are from add_device()
> range checking the module parameter)
> 

  thank you.

  sorry for reply late (yesterday, I have an annual leave for personal things, 
and not connect net).

by the way:
  does it also need check the length in function rx_get_buf ? 
  (it seems not, but I am not quite sure, can you give a confirm ?)

4779 /*
4780  * pass receive buffer (RAW synchronous mode) to tty layer
4781  * return true if buffer available, otherwise false
4782  */
4783 static bool rx_get_buf(struct slgt_info *info)
4784 {
4785 unsigned int i = info->rbuf_current;
4786 unsigned int count;
4787 
4788 if (!desc_complete(info->rbufs[i]))
4789 return false;
4790 count = desc_count(info->rbufs[i]);
4791 switch(info->params.mode) {
4792 case MGSL_MODE_MONOSYNC:
4793 case MGSL_MODE_BISYNC:
4794 case MGSL_MODE_XSYNC:
4795 /* ignore residue in byte synchronous modes */
4796 if (desc_residue(info->rbufs[i]))
4797 count--;
4798 break;
4799 }
4800 DBGDATA(info, info->rbufs[i].buf, count, "rx");
4801 DBGINFO(("rx_get_buf size=%d\n", count));
4802 if (count)
4803 ldisc_receive_buf(info->port.tty, info->rbufs[i].buf,
4804   info->flag_buf, count);
4805 free_rbufs(info, i, i);
4806 return true;
4807 }




-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-04 Thread Chen Gang
于 2012年12月04日 01:13, Paul Fulghum 写道:
> Fix call to line discipline receive_buf by synclink drivers.
> Dummy flag buffer argument is ignored by N_HDLC line discipline but might
> be of insufficient size if accessed by a different line discipline
> selected by mistake. flag buffer allocation now matches max size of data
> buffer. Unused char_buf buffers are removed.
> 
> Signed-off-by: Paul Fulghum 
> 

  thank you very much.


  might we use macro instead of hard code number ? (such as 4096,
65535). it is only an idea, not means need regression.

  thanks.

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-04 Thread Chen Gang
于 2012年12月04日 01:13, Paul Fulghum 写道:
 Fix call to line discipline receive_buf by synclink drivers.
 Dummy flag buffer argument is ignored by N_HDLC line discipline but might
 be of insufficient size if accessed by a different line discipline
 selected by mistake. flag buffer allocation now matches max size of data
 buffer. Unused char_buf buffers are removed.
 
 Signed-off-by: Paul Fulghum pau...@microgate.com
 

  thank you very much.


  might we use macro instead of hard code number ? (such as 4096,
65535). it is only an idea, not means need regression.

  thanks.

-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-04 Thread Chen Gang
于 2012年12月04日 00:03, Paul Fulghum 写道:
 On 12/2/2012 8:20 PM, Chen Gang wrote:
 pardon (I am just learning)
   does 65535 mean HDLC_MAX_FRAME_SIZE ?
   why do we need info-max_frame_size = 4096 ?
 in drivers/tty/synclink_gt.c:
 3550 if (info-max_frame_size  4096)
 3551 info-max_frame_size = 4096;
 3552 else if (info-max_frame_size  65535)
 3553 info-max_frame_size = 65535;
 3554
  ...
 3603 info-max_frame_size = 4096;
 
 The hardware can send and receive HDLC frames up to
 64K in size. The driver defaults to 4K max frame size
 to save buffer space for the common case
 (line 3603 in alloc_dev()).
 
 The module parameter max_frame_size can override the default
 in add_device() (lines 3550-3554 are from add_device()
 range checking the module parameter)
 

  thank you.

  sorry for reply late (yesterday, I have an annual leave for personal things, 
and not connect net).

by the way:
  does it also need check the length in function rx_get_buf ? 
  (it seems not, but I am not quite sure, can you give a confirm ?)

4779 /*
4780  * pass receive buffer (RAW synchronous mode) to tty layer
4781  * return true if buffer available, otherwise false
4782  */
4783 static bool rx_get_buf(struct slgt_info *info)
4784 {
4785 unsigned int i = info-rbuf_current;
4786 unsigned int count;
4787 
4788 if (!desc_complete(info-rbufs[i]))
4789 return false;
4790 count = desc_count(info-rbufs[i]);
4791 switch(info-params.mode) {
4792 case MGSL_MODE_MONOSYNC:
4793 case MGSL_MODE_BISYNC:
4794 case MGSL_MODE_XSYNC:
4795 /* ignore residue in byte synchronous modes */
4796 if (desc_residue(info-rbufs[i]))
4797 count--;
4798 break;
4799 }
4800 DBGDATA(info, info-rbufs[i].buf, count, rx);
4801 DBGINFO((rx_get_buf size=%d\n, count));
4802 if (count)
4803 ldisc_receive_buf(info-port.tty, info-rbufs[i].buf,
4804   info-flag_buf, count);
4805 free_rbufs(info, i, i);
4806 return true;
4807 }




-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] synclink fix ldisc buffer argument

2012-12-03 Thread Paul Fulghum
Fix call to line discipline receive_buf by synclink drivers.
Dummy flag buffer argument is ignored by N_HDLC line discipline but might
be of insufficient size if accessed by a different line discipline
selected by mistake. flag buffer allocation now matches max size of data
buffer. Unused char_buf buffers are removed.

Signed-off-by: Paul Fulghum 

--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-12-03 10:51:40.0 -0600
@@ -210,7 +210,7 @@ typedef struct _mgslpc_info {
char testing_irq;
unsigned int init_error;/* startup error (DIAGS)*/
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -2666,6 +2666,14 @@ static int rx_alloc_buffers(MGSLPC_INFO 
if (info->rx_buf == NULL)
return -ENOMEM;
 
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info->flag_buf = kzalloc(info->max_frame_size, GFP_KERNEL);
+   if (!info->flag_buf) {
+   kfree(info->rx_buf);
+   info->rx_buf = NULL;
+   return -ENOMEM;
+   }
+   
rx_reset_buffers(info);
return 0;
 }
@@ -2674,6 +2682,8 @@ static void rx_free_buffers(MGSLPC_INFO 
 {
kfree(info->rx_buf);
info->rx_buf = NULL;
+   kfree(info->flag_buf);
+   info->flag_buf = NULL;
 }
 
 static int claim_resources(MGSLPC_INFO *info)
--- a/drivers/tty/synclink.c2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink.c2012-12-03 10:51:56.0 -0600
@@ -291,8 +291,7 @@ struct mgsl_struct {
bool lcr_mem_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];   
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
bool loopmode_insert_requested;
@@ -3891,7 +3890,13 @@ static int mgsl_alloc_intermediate_rxbuf
info->intermediate_rxbuffer = kmalloc(info->max_frame_size, GFP_KERNEL 
| GFP_DMA);
if ( info->intermediate_rxbuffer == NULL )
return -ENOMEM;
-
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info->flag_buf = kzalloc(info->max_frame_size, GFP_KERNEL);
+   if (!info->flag_buf) {
+   kfree(info->intermediate_rxbuffer);
+   info->intermediate_rxbuffer = NULL;
+   return -ENOMEM;
+   }
return 0;
 
 }  /* end of mgsl_alloc_intermediate_rxbuffer_memory() */
@@ -3910,6 +3915,8 @@ static void mgsl_free_intermediate_rxbuf
 {
kfree(info->intermediate_rxbuffer);
info->intermediate_rxbuffer = NULL;
+   kfree(info->flag_buf);
+   info->flag_buf = NULL;
 
 }  /* end of mgsl_free_intermediate_rxbuffer_memory() */
 
--- a/drivers/tty/synclinkmp.c  2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclinkmp.c  2012-12-03 10:52:09.0 -0600
@@ -262,8 +262,7 @@ typedef struct _synclinkmp_info {
bool sca_statctrl_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -3544,6 +3543,13 @@ static int alloc_tmp_rx_buf(SLMP_INFO *i
info->tmp_rx_buf = kmalloc(info->max_frame_size, GFP_KERNEL);
if (info->tmp_rx_buf == NULL)
return -ENOMEM;
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info->flag_buf = kzalloc(info->max_frame_size, GFP_KERNEL);
+   if (!info->flag_buf) {
+   kfree(info->tmp_rx_buf);
+   info->tmp_rx_buf = NULL;
+   return -ENOMEM;
+   }
return 0;
 }
 
@@ -3551,6 +3557,8 @@ static void free_tmp_rx_buf(SLMP_INFO *i
 {
kfree(info->tmp_rx_buf);
info->tmp_rx_buf = NULL;
+   kfree(info->flag_buf);
+   info->flag_buf = NULL;
 }
 
 static int claim_resources(SLMP_INFO *info)
--- a/drivers/tty/synclink_gt.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink_gt.c 2012-12-03 11:00:15.0 -0600
@@ -317,8 +317,7 @@ struct slgt_info {
unsigned char *tx_buf;
int tx_count;
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
struct  _input_signal_eventsinput_signal_events;
 
@@ -3355,11 +3354,24 @@ static int block_til_ready(struct tty_st
return retval;
 }
 
+/*
+ * allocate buffers used for calling line discipline receive_buf
+ * directly in synchronous mode
+ * note: add 5 bytes to max frame size to allow appending
+ * 32-bit CRC and status byte when configured to do so
+ */
 static int alloc_tmp_rbuf(struct slgt_info *info)
 {
info->tmp_rbuf = 

Re: [PATCH] synclink fix ldisc buffer argument

2012-12-03 Thread Paul Fulghum
On 12/2/2012 8:20 PM, Chen Gang wrote:
> pardon (I am just learning)
>   does 65535 mean HDLC_MAX_FRAME_SIZE ?
>   why do we need info->max_frame_size >= 4096 ?
> in drivers/tty/synclink_gt.c:
> 3550 if (info->max_frame_size < 4096)
> 3551 info->max_frame_size = 4096;
> 3552 else if (info->max_frame_size > 65535)
> 3553 info->max_frame_size = 65535;
> 3554
>  ...
> 3603 info->max_frame_size = 4096;

The hardware can send and receive HDLC frames up to
64K in size. The driver defaults to 4K max frame size
to save buffer space for the common case
(line 3603 in alloc_dev()).

The module parameter max_frame_size can override the default
in add_device() (lines 3550-3554 are from add_device()
range checking the module parameter)

> if possible:
>   can we move the relative comments (which are inside function) to the
> location just above ldisc_receive_buf ?

The added comment from my first patch described the reuse
of the data buffer as the flag buffer. Alan prefers to use
a zero initialized dummy buffer for the flag buffer argument.
Doing it that way, the comment is not needed.

-- 
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982 (US Sales)
(512)345-7791 x102 (Direct)
(512)343-9046 (Fax)
Central Time Zone (GMT -6h)
www.microgate.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-03 Thread Paul Fulghum
On 12/2/2012 8:20 PM, Chen Gang wrote:
 pardon (I am just learning)
   does 65535 mean HDLC_MAX_FRAME_SIZE ?
   why do we need info-max_frame_size = 4096 ?
 in drivers/tty/synclink_gt.c:
 3550 if (info-max_frame_size  4096)
 3551 info-max_frame_size = 4096;
 3552 else if (info-max_frame_size  65535)
 3553 info-max_frame_size = 65535;
 3554
  ...
 3603 info-max_frame_size = 4096;

The hardware can send and receive HDLC frames up to
64K in size. The driver defaults to 4K max frame size
to save buffer space for the common case
(line 3603 in alloc_dev()).

The module parameter max_frame_size can override the default
in add_device() (lines 3550-3554 are from add_device()
range checking the module parameter)

 if possible:
   can we move the relative comments (which are inside function) to the
 location just above ldisc_receive_buf ?

The added comment from my first patch described the reuse
of the data buffer as the flag buffer. Alan prefers to use
a zero initialized dummy buffer for the flag buffer argument.
Doing it that way, the comment is not needed.

-- 
Paul Fulghum
MicroGate Systems, Ltd.
=Customer Driven, by Design=
(800)444-1982 (US Sales)
(512)345-7791 x102 (Direct)
(512)343-9046 (Fax)
Central Time Zone (GMT -6h)
www.microgate.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] synclink fix ldisc buffer argument

2012-12-03 Thread Paul Fulghum
Fix call to line discipline receive_buf by synclink drivers.
Dummy flag buffer argument is ignored by N_HDLC line discipline but might
be of insufficient size if accessed by a different line discipline
selected by mistake. flag buffer allocation now matches max size of data
buffer. Unused char_buf buffers are removed.

Signed-off-by: Paul Fulghum pau...@microgate.com

--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-12-03 10:51:40.0 -0600
@@ -210,7 +210,7 @@ typedef struct _mgslpc_info {
char testing_irq;
unsigned int init_error;/* startup error (DIAGS)*/
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -2666,6 +2666,14 @@ static int rx_alloc_buffers(MGSLPC_INFO 
if (info-rx_buf == NULL)
return -ENOMEM;
 
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info-flag_buf = kzalloc(info-max_frame_size, GFP_KERNEL);
+   if (!info-flag_buf) {
+   kfree(info-rx_buf);
+   info-rx_buf = NULL;
+   return -ENOMEM;
+   }
+   
rx_reset_buffers(info);
return 0;
 }
@@ -2674,6 +2682,8 @@ static void rx_free_buffers(MGSLPC_INFO 
 {
kfree(info-rx_buf);
info-rx_buf = NULL;
+   kfree(info-flag_buf);
+   info-flag_buf = NULL;
 }
 
 static int claim_resources(MGSLPC_INFO *info)
--- a/drivers/tty/synclink.c2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink.c2012-12-03 10:51:56.0 -0600
@@ -291,8 +291,7 @@ struct mgsl_struct {
bool lcr_mem_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];   
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
bool loopmode_insert_requested;
@@ -3891,7 +3890,13 @@ static int mgsl_alloc_intermediate_rxbuf
info-intermediate_rxbuffer = kmalloc(info-max_frame_size, GFP_KERNEL 
| GFP_DMA);
if ( info-intermediate_rxbuffer == NULL )
return -ENOMEM;
-
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info-flag_buf = kzalloc(info-max_frame_size, GFP_KERNEL);
+   if (!info-flag_buf) {
+   kfree(info-intermediate_rxbuffer);
+   info-intermediate_rxbuffer = NULL;
+   return -ENOMEM;
+   }
return 0;
 
 }  /* end of mgsl_alloc_intermediate_rxbuffer_memory() */
@@ -3910,6 +3915,8 @@ static void mgsl_free_intermediate_rxbuf
 {
kfree(info-intermediate_rxbuffer);
info-intermediate_rxbuffer = NULL;
+   kfree(info-flag_buf);
+   info-flag_buf = NULL;
 
 }  /* end of mgsl_free_intermediate_rxbuffer_memory() */
 
--- a/drivers/tty/synclinkmp.c  2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclinkmp.c  2012-12-03 10:52:09.0 -0600
@@ -262,8 +262,7 @@ typedef struct _synclinkmp_info {
bool sca_statctrl_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -3544,6 +3543,13 @@ static int alloc_tmp_rx_buf(SLMP_INFO *i
info-tmp_rx_buf = kmalloc(info-max_frame_size, GFP_KERNEL);
if (info-tmp_rx_buf == NULL)
return -ENOMEM;
+   /* unused flag buffer to satisfy receive_buf calling interface */
+   info-flag_buf = kzalloc(info-max_frame_size, GFP_KERNEL);
+   if (!info-flag_buf) {
+   kfree(info-tmp_rx_buf);
+   info-tmp_rx_buf = NULL;
+   return -ENOMEM;
+   }
return 0;
 }
 
@@ -3551,6 +3557,8 @@ static void free_tmp_rx_buf(SLMP_INFO *i
 {
kfree(info-tmp_rx_buf);
info-tmp_rx_buf = NULL;
+   kfree(info-flag_buf);
+   info-flag_buf = NULL;
 }
 
 static int claim_resources(SLMP_INFO *info)
--- a/drivers/tty/synclink_gt.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink_gt.c 2012-12-03 11:00:15.0 -0600
@@ -317,8 +317,7 @@ struct slgt_info {
unsigned char *tx_buf;
int tx_count;
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
+   char *flag_buf;
bool drop_rts_on_tx_done;
struct  _input_signal_eventsinput_signal_events;
 
@@ -3355,11 +3354,24 @@ static int block_til_ready(struct tty_st
return retval;
 }
 
+/*
+ * allocate buffers used for calling line discipline receive_buf
+ * directly in synchronous mode
+ * note: add 5 bytes to max frame size to allow appending
+ * 32-bit CRC and status byte when configured to do so
+ */
 static int alloc_tmp_rbuf(struct slgt_info *info)
 {
info-tmp_rbuf = kmalloc(info-max_frame_size + 5, 

Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Chen Gang
于 2012年12月03日 04:05, Paul Fulghum 写道:
> OK, I’ll do that.
> 

pardon (I am just learning)
  does 65535 mean HDLC_MAX_FRAME_SIZE ?
  why do we need info->max_frame_size >= 4096 ?

in drivers/tty/synclink_gt.c:
3550 if (info->max_frame_size < 4096)
3551 info->max_frame_size = 4096;
3552 else if (info->max_frame_size > 65535)
3553 info->max_frame_size = 65535;
3554
 ...
3603 info->max_frame_size = 4096;


if possible:
  can we move the relative comments (which are inside function) to the
location just above ldisc_receive_buf ?


  thanks.

gchen.


> On Dec 2, 2012, at 12:10 PM, Alan Cox  > wrote:
> 
>> On Sun, 2 Dec 2012 10:11:58 -0600
>> Paul Fulghum mailto:pau...@microgate.com>> wrote:
>>
>>> True, in this mode line disciplines other than N_HDLC would not be
>>> functional and N_HDLC ignores the flag buffer.
>>> This change won’t make other line disciplines useful, it will just
>>> prevent the case of a mistakenly selected line discipline accessing
>>> beyond the end of the (dummy) flag buffer.
>>>
>>> I’m fine with or without the change. It is functional now with a
>>> chance to read past then end of a buffer if misconfigured. With the
>>> change, it has the same functionality without the ability to read
>>> past the end of a buffer if misconfigured.
>>
>> With the change its feeding crap in the flags buffer, which may matter in
>> future depending what happens to the other bits.
>>
>> If this is a real issue far better to just kzalloc a blank flag buffer to
>> match the mtu.
>>
> 
> -- 
> Paul Fulghum
> MicroGate Systems, Ltd.
> =Customer Driven, by Design=
> (800)444-1982
> (512)345-7791 (Direct)
> (512)343-9046 (Fax)
> Central Time Zone (GMT -5h)
> www.microgate.com 
> 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Alan Cox
On Sun, 2 Dec 2012 10:11:58 -0600
Paul Fulghum  wrote:

> True, in this mode line disciplines other than N_HDLC would not be functional 
> and N_HDLC ignores the flag buffer.
> This change won’t make other line disciplines useful, it will just prevent 
> the case of a mistakenly selected line discipline accessing beyond the end of 
> the (dummy) flag buffer.
> 
> I’m fine with or without the change. It is functional now with a chance to 
> read past then end of a buffer if misconfigured. With the change, it has the 
> same functionality without the ability to read past the end of a buffer if 
> misconfigured.

With the change its feeding crap in the flags buffer, which may matter in
future depending what happens to the other bits.

If this is a real issue far better to just kzalloc a blank flag buffer to
match the mtu.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Alan Cox
> +  * If a different line discipline is selected 
> by mistake it
> +  * will have valid memory for both arguments.
> +  */
> + ldisc_receive_buf(tty, buf->data, buf->data, 
> framesize);

But not valid content it seems 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Alan Cox
 +  * If a different line discipline is selected 
 by mistake it
 +  * will have valid memory for both arguments.
 +  */
 + ldisc_receive_buf(tty, buf-data, buf-data, 
 framesize);

But not valid content it seems 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Alan Cox
On Sun, 2 Dec 2012 10:11:58 -0600
Paul Fulghum pau...@microgate.com wrote:

 True, in this mode line disciplines other than N_HDLC would not be functional 
 and N_HDLC ignores the flag buffer.
 This change won’t make other line disciplines useful, it will just prevent 
 the case of a mistakenly selected line discipline accessing beyond the end of 
 the (dummy) flag buffer.
 
 I’m fine with or without the change. It is functional now with a chance to 
 read past then end of a buffer if misconfigured. With the change, it has the 
 same functionality without the ability to read past the end of a buffer if 
 misconfigured.

With the change its feeding crap in the flags buffer, which may matter in
future depending what happens to the other bits.

If this is a real issue far better to just kzalloc a blank flag buffer to
match the mtu.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] synclink fix ldisc buffer argument

2012-12-02 Thread Chen Gang
于 2012年12月03日 04:05, Paul Fulghum 写道:
 OK, I’ll do that.
 

pardon (I am just learning)
  does 65535 mean HDLC_MAX_FRAME_SIZE ?
  why do we need info-max_frame_size = 4096 ?

in drivers/tty/synclink_gt.c:
3550 if (info-max_frame_size  4096)
3551 info-max_frame_size = 4096;
3552 else if (info-max_frame_size  65535)
3553 info-max_frame_size = 65535;
3554
 ...
3603 info-max_frame_size = 4096;


if possible:
  can we move the relative comments (which are inside function) to the
location just above ldisc_receive_buf ?


  thanks.

gchen.


 On Dec 2, 2012, at 12:10 PM, Alan Cox a...@lxorguk.ukuu.org.uk
 mailto:a...@lxorguk.ukuu.org.uk wrote:
 
 On Sun, 2 Dec 2012 10:11:58 -0600
 Paul Fulghum pau...@microgate.com mailto:pau...@microgate.com wrote:

 True, in this mode line disciplines other than N_HDLC would not be
 functional and N_HDLC ignores the flag buffer.
 This change won’t make other line disciplines useful, it will just
 prevent the case of a mistakenly selected line discipline accessing
 beyond the end of the (dummy) flag buffer.

 I’m fine with or without the change. It is functional now with a
 chance to read past then end of a buffer if misconfigured. With the
 change, it has the same functionality without the ability to read
 past the end of a buffer if misconfigured.

 With the change its feeding crap in the flags buffer, which may matter in
 future depending what happens to the other bits.

 If this is a real issue far better to just kzalloc a blank flag buffer to
 match the mtu.

 
 -- 
 Paul Fulghum
 MicroGate Systems, Ltd.
 =Customer Driven, by Design=
 (800)444-1982
 (512)345-7791 (Direct)
 (512)343-9046 (Fax)
 Central Time Zone (GMT -5h)
 www.microgate.com http://www.microgate.com/
 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] synclink fix ldisc buffer argument

2012-11-30 Thread Paul Fulghum
Fix call to line discipline receive_buf by synclink drivers.
Dummy flag buffer argument is ignored by N_HDLC line discipline but might
be of insufficient size if accessed by a different line discipline
selected by mistake. Calls are changed to use data buffer argument for
both data and flag buffer so valid memory is provided if the wrong
line discipline is used. Unused char_buf and flag_buf are removed.

Signed-off-by: Paul Fulghum 


--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-11-30 12:50:23.0 -0600
@@ -210,7 +210,6 @@ typedef struct _mgslpc_info {
char testing_irq;
unsigned int init_error;/* startup error (DIAGS)*/
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -3707,7 +3706,16 @@ static bool rx_get_frame(MGSLPC_INFO *in
hdlcdev_rx(info, buf->data, framesize);
else
 #endif
-   ldisc_receive_buf(tty, buf->data, 
info->flag_buf, framesize);
+   {
+   /*
+* Call N_HDLC line discipline directly to 
maintain
+* frame boundaries. Reuse the data buffer 
argument for the
+* flag buffer argument. The flag buffer is 
ignored by N_HDLC.
+* If a different line discipline is selected 
by mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, buf->data, buf->data, 
framesize);
+   }
}
}
 
--- a/drivers/tty/synclink.c2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink.c2012-11-30 12:59:29.0 -0600
@@ -291,8 +291,6 @@ struct mgsl_struct {
bool lcr_mem_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];   
bool drop_rts_on_tx_done;
 
bool loopmode_insert_requested;
@@ -6661,7 +6659,17 @@ static bool mgsl_get_rx_frame(struct mgs

hdlcdev_rx(info,info->intermediate_rxbuffer,framesize);
else
 #endif
-   ldisc_receive_buf(tty, 
info->intermediate_rxbuffer, info->flag_buf, framesize);
+   {
+   /*
+* Call N_HDLC line discipline directly to 
maintain
+* frame boundaries. Reuse the data buffer 
argument for the
+* flag buffer argument. The flag buffer is 
ignored by N_HDLC.
+* If a different line discipline is selected 
by mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, 
info->intermediate_rxbuffer,
+ info->intermediate_rxbuffer, 
framesize);
+   }
}
}
/* Free the buffers used by this frame. */
@@ -6833,7 +6841,15 @@ static bool mgsl_get_raw_rx_frame(struct
memcpy( info->intermediate_rxbuffer, 
pBufEntry->virt_addr, framesize);
info->icount.rxok++;
 
-   ldisc_receive_buf(tty, info->intermediate_rxbuffer, 
info->flag_buf, framesize);
+   /*
+* Call N_HDLC line discipline directly to maintain
+* block boundaries. Reuse the data buffer argument for 
the
+* flag buffer argument. The flag buffer is ignored by 
N_HDLC.
+* If a different line discipline is selected by 
mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, info->intermediate_rxbuffer,
+  info->intermediate_rxbuffer, 
framesize);
}
 
/* Free the buffers used by this frame. */
--- a/drivers/tty/synclinkmp.c  2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclinkmp.c  2012-11-30 13:01:36.0 -0600
@@ -262,8 +262,6 @@ typedef struct _synclinkmp_info {
bool sca_statctrl_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -4979,8 +4977,17 @@ CheckAgain:
hdlcdev_rx(info,info->tmp_rx_buf,framesize);
else
 #endif
-  

[PATCH] synclink fix ldisc buffer argument

2012-11-30 Thread Paul Fulghum
Fix call to line discipline receive_buf by synclink drivers.
Dummy flag buffer argument is ignored by N_HDLC line discipline but might
be of insufficient size if accessed by a different line discipline
selected by mistake. Calls are changed to use data buffer argument for
both data and flag buffer so valid memory is provided if the wrong
line discipline is used. Unused char_buf and flag_buf are removed.

Signed-off-by: Paul Fulghum pau...@microgate.com


--- a/drivers/char/pcmcia/synclink_cs.c 2012-11-26 14:15:45.0 -0600
+++ b/drivers/char/pcmcia/synclink_cs.c 2012-11-30 12:50:23.0 -0600
@@ -210,7 +210,6 @@ typedef struct _mgslpc_info {
char testing_irq;
unsigned int init_error;/* startup error (DIAGS)*/
 
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -3707,7 +3706,16 @@ static bool rx_get_frame(MGSLPC_INFO *in
hdlcdev_rx(info, buf-data, framesize);
else
 #endif
-   ldisc_receive_buf(tty, buf-data, 
info-flag_buf, framesize);
+   {
+   /*
+* Call N_HDLC line discipline directly to 
maintain
+* frame boundaries. Reuse the data buffer 
argument for the
+* flag buffer argument. The flag buffer is 
ignored by N_HDLC.
+* If a different line discipline is selected 
by mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, buf-data, buf-data, 
framesize);
+   }
}
}
 
--- a/drivers/tty/synclink.c2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclink.c2012-11-30 12:59:29.0 -0600
@@ -291,8 +291,6 @@ struct mgsl_struct {
bool lcr_mem_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];   
bool drop_rts_on_tx_done;
 
bool loopmode_insert_requested;
@@ -6661,7 +6659,17 @@ static bool mgsl_get_rx_frame(struct mgs

hdlcdev_rx(info,info-intermediate_rxbuffer,framesize);
else
 #endif
-   ldisc_receive_buf(tty, 
info-intermediate_rxbuffer, info-flag_buf, framesize);
+   {
+   /*
+* Call N_HDLC line discipline directly to 
maintain
+* frame boundaries. Reuse the data buffer 
argument for the
+* flag buffer argument. The flag buffer is 
ignored by N_HDLC.
+* If a different line discipline is selected 
by mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, 
info-intermediate_rxbuffer,
+ info-intermediate_rxbuffer, 
framesize);
+   }
}
}
/* Free the buffers used by this frame. */
@@ -6833,7 +6841,15 @@ static bool mgsl_get_raw_rx_frame(struct
memcpy( info-intermediate_rxbuffer, 
pBufEntry-virt_addr, framesize);
info-icount.rxok++;
 
-   ldisc_receive_buf(tty, info-intermediate_rxbuffer, 
info-flag_buf, framesize);
+   /*
+* Call N_HDLC line discipline directly to maintain
+* block boundaries. Reuse the data buffer argument for 
the
+* flag buffer argument. The flag buffer is ignored by 
N_HDLC.
+* If a different line discipline is selected by 
mistake it
+* will have valid memory for both arguments.
+*/
+   ldisc_receive_buf(tty, info-intermediate_rxbuffer,
+  info-intermediate_rxbuffer, 
framesize);
}
 
/* Free the buffers used by this frame. */
--- a/drivers/tty/synclinkmp.c  2012-11-26 14:15:45.0 -0600
+++ b/drivers/tty/synclinkmp.c  2012-11-30 13:01:36.0 -0600
@@ -262,8 +262,6 @@ typedef struct _synclinkmp_info {
bool sca_statctrl_requested;
 
u32 misc_ctrl_value;
-   char flag_buf[MAX_ASYNC_BUFFER_SIZE];
-   char char_buf[MAX_ASYNC_BUFFER_SIZE];
bool drop_rts_on_tx_done;
 
struct  _input_signal_eventsinput_signal_events;
@@ -4979,8 +4977,17 @@ CheckAgain:
hdlcdev_rx(info,info-tmp_rx_buf,framesize);
else
 #endif
-