diff mbox series

[net] mctp: serial: Fix starting value for frame check sequence

Message ID 20221216034409.27174-1-jk@codeconstruct.com.au (mailing list archive)
State Accepted
Commit 2856a62762c8409e360d4fd452194c8e57ba1058
Delegated to: Netdev Maintainers
Headers show
Series [net] mctp: serial: Fix starting value for frame check sequence | expand

Checks

Context Check Description
netdev/tree_selection success Clearly marked for net
netdev/fixes_present success Fixes tag present in non-next series
netdev/subject_prefix success Link
netdev/cover_letter success Single patches do not need cover letters
netdev/patch_count success Link
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/cc_maintainers success CCed 7 of 7 maintainers
netdev/build_clang success Errors and warnings before: 0 this patch: 0
netdev/module_param success Was 0 now: 0
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes fail Problems with Fixes tag: 1
netdev/build_allmodconfig_warn success Errors and warnings before: 0 this patch: 0
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 24 lines checked
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Jeremy Kerr Dec. 16, 2022, 3:44 a.m. UTC
RFC1662 defines the start state for the crc16 FCS to be 0xffff, but
we're currently starting at zero.

This change uses the correct start state. We're only early in the
adoption for the serial binding, so there aren't yet any other users to
interface to.

Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding")

Reported-by: Harsh Tyagi <harshtya@google.com>
Tested-by: Harsh Tyagi <harshtya@google.com>
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
---
 drivers/net/mctp/mctp-serial.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Alexander Duyck Dec. 16, 2022, 4:41 p.m. UTC | #1
On Fri, 2022-12-16 at 11:44 +0800, Jeremy Kerr wrote:
> RFC1662 defines the start state for the crc16 FCS to be 0xffff, but
> we're currently starting at zero.
> 
> This change uses the correct start state. We're only early in the
> adoption for the serial binding, so there aren't yet any other users to
> interface to.
> 
> Fixes: a0c2ccd9b5ad ("mctp: Add MCTP-over-serial transport binding")
> 
> Reported-by: Harsh Tyagi <harshtya@google.com>
> Tested-by: Harsh Tyagi <harshtya@google.com>
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
> ---
>  drivers/net/mctp/mctp-serial.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/mctp/mctp-serial.c b/drivers/net/mctp/mctp-serial.c
> index 7cd103fd34ef..9f9eaf896047 100644
> --- a/drivers/net/mctp/mctp-serial.c
> +++ b/drivers/net/mctp/mctp-serial.c
> @@ -35,6 +35,8 @@
>  #define BYTE_FRAME		0x7e
>  #define BYTE_ESC		0x7d
>  
> +#define FCS_INIT		0xffff
> +
>  static DEFINE_IDA(mctp_serial_ida);
>  
>  enum mctp_serial_state {
> @@ -123,7 +125,7 @@ static void mctp_serial_tx_work(struct work_struct *work)
>  		buf[2] = dev->txlen;
>  
>  		if (!dev->txpos)
> -			dev->txfcs = crc_ccitt(0, buf + 1, 2);
> +			dev->txfcs = crc_ccitt(FCS_INIT, buf + 1, 2);
>  
>  		txlen = write_chunk(dev, buf + dev->txpos, 3 - dev->txpos);
>  		if (txlen <= 0) {
> @@ -303,7 +305,7 @@ static void mctp_serial_push_header(struct mctp_serial *dev, unsigned char c)
>  	case 1:
>  		if (c == MCTP_SERIAL_VERSION) {
>  			dev->rxpos++;
> -			dev->rxfcs = crc_ccitt_byte(0, c);
> +			dev->rxfcs = crc_ccitt_byte(FCS_INIT, c);
>  		} else {
>  			dev->rxstate = STATE_ERR;
>  		}

Since the starting value isn't unique would it possibly be worthwhile
to look at adding a define to include/linux/crc-ccitt.h to be used to
handle the cases where the initial value is 0xffff? I notice there
seems to only be two starting values 0 and 0xffff for all callers so it
might make sense to centralize it in one place.

Otherwise the code itself looks good.

Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
Jeremy Kerr Dec. 17, 2022, 6:44 a.m. UTC | #2
Hi Alexander.

> Since the starting value isn't unique would it possibly be worthwhile
> to look at adding a define to include/linux/crc-ccitt.h to be used to
> handle the cases where the initial value is 0xffff? I notice there
> seems to only be two starting values 0 and 0xffff for all callers so
> it might make sense to centralize it in one place.

Yep, that would make sense if they're commonly used values, but I'm not
sure that would be suitable to include that in this fix, as it would
just add disruption to any backport work.

Cheers,


Jeremy
Alexander Duyck Dec. 17, 2022, 8:59 p.m. UTC | #3
On Fri, Dec 16, 2022 at 10:44 PM Jeremy Kerr <jk@codeconstruct.com.au> wrote:
>
>
> Hi Alexander.
>
> > Since the starting value isn't unique would it possibly be worthwhile
> > to look at adding a define to include/linux/crc-ccitt.h to be used to
> > handle the cases where the initial value is 0xffff? I notice there
> > seems to only be two starting values 0 and 0xffff for all callers so
> > it might make sense to centralize it in one place.
>
> Yep, that would make sense if they're commonly used values, but I'm not
> sure that would be suitable to include that in this fix, as it would
> just add disruption to any backport work.

Sorry, I didn't intend that for this patch. I was suggesting it as
possible follow-on work.

Thanks,

- Alex
Jeremy Kerr Dec. 18, 2022, 1:32 a.m. UTC | #4
Hi Alexander,

> 
> > Yep, that would make sense if they're commonly used values, but I'm
> > not sure that would be suitable to include that in this fix, as it
> > would just add disruption to any backport work.
> 
> Sorry, I didn't intend that for this patch. I was suggesting it as
> possible follow-on work.

Ah, cool! Yep, definitely a contender for a future change.

(this might be a good opportunity as a starter item for someone wanting
to get familiar with the development/review process, if you know of
anyone?)

Cheers,


Jeremy
patchwork-bot+netdevbpf@kernel.org Dec. 19, 2022, 12:50 p.m. UTC | #5
Hello:

This patch was applied to netdev/net.git (master)
by David S. Miller <davem@davemloft.net>:

On Fri, 16 Dec 2022 11:44:09 +0800 you wrote:
> RFC1662 defines the start state for the crc16 FCS to be 0xffff, but
> we're currently starting at zero.
> 
> This change uses the correct start state. We're only early in the
> adoption for the serial binding, so there aren't yet any other users to
> interface to.
> 
> [...]

Here is the summary with links:
  - [net] mctp: serial: Fix starting value for frame check sequence
    https://git.kernel.org/netdev/net/c/2856a62762c8

You are awesome, thank you!
diff mbox series

Patch

diff --git a/drivers/net/mctp/mctp-serial.c b/drivers/net/mctp/mctp-serial.c
index 7cd103fd34ef..9f9eaf896047 100644
--- a/drivers/net/mctp/mctp-serial.c
+++ b/drivers/net/mctp/mctp-serial.c
@@ -35,6 +35,8 @@ 
 #define BYTE_FRAME		0x7e
 #define BYTE_ESC		0x7d
 
+#define FCS_INIT		0xffff
+
 static DEFINE_IDA(mctp_serial_ida);
 
 enum mctp_serial_state {
@@ -123,7 +125,7 @@  static void mctp_serial_tx_work(struct work_struct *work)
 		buf[2] = dev->txlen;
 
 		if (!dev->txpos)
-			dev->txfcs = crc_ccitt(0, buf + 1, 2);
+			dev->txfcs = crc_ccitt(FCS_INIT, buf + 1, 2);
 
 		txlen = write_chunk(dev, buf + dev->txpos, 3 - dev->txpos);
 		if (txlen <= 0) {
@@ -303,7 +305,7 @@  static void mctp_serial_push_header(struct mctp_serial *dev, unsigned char c)
 	case 1:
 		if (c == MCTP_SERIAL_VERSION) {
 			dev->rxpos++;
-			dev->rxfcs = crc_ccitt_byte(0, c);
+			dev->rxfcs = crc_ccitt_byte(FCS_INIT, c);
 		} else {
 			dev->rxstate = STATE_ERR;
 		}