Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2969245ybi; Mon, 17 Jun 2019 13:44:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqz/EmdCRirKwI9/8pq1+QUku0l/26IWqkaZiNQlCRk5ZC+rycdvMNXpKFe/Mm/3dBwdFrYP X-Received: by 2002:a17:90a:2ec2:: with SMTP id h2mr898517pjs.119.1560804285779; Mon, 17 Jun 2019 13:44:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560804285; cv=none; d=google.com; s=arc-20160816; b=OQVU/wPBvPuF//nRSsuVeyZbr3clGQE2mVWkvaUzXlrPVwMxY+o98hqFFS8XMBsciJ hi1hLHwE98tdtppwftIfth6Z6ZpOF3KcMjjINKyElG9gd08gFEBdJcz4Q9iUad+Tqjeu OCo5nsCcdr8lovLgLpkfKaq1c7GLJVsqAslRubgDrkLE4mfI8V7Ve2ij5ukJZOIcXYgD gGeGFTEm3E5EjXgDc2KflWXBPZ+BMAge2ohmCtCFCjoHXZmE8HeTrLKUkbLrFuEfsEEd w5BgJ3CkLP6AmLBB3g81yqxkYN+UgrMWJWGxmCQNmRsef9ounLFnUNVLb3mkvNipE3Yr AbQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=dVGu8whRMna60gynk/1O8zescEQey2cqhtBRWKBkxdI=; b=kLPhz11sny/lsBKqeqTp5tAUl30HWFQoJreVrOCa425yOpWPV0XOZvWxUwXXparzqv nhvxl8yHfcSHgTO81QiPTuu8gUpI1JZ3/eSFS2HItZkZoMuhXhxx9ztjMZdBU3HVgdZs nTqu/x7iTsJrrrL229pQStDFzSL5z/5CwbHnUKobS/G8u8POQ/Jb/FEnyEITV+zaTQd+ lNlAMNb5Yd/AYtidz6JTyOrmuMN9VgbQwAsix6WvsUqIGK+XdG1Ss08K5BLG9aFuRFrY O136I1UWtyd+Mns+OaV36iZSysTWQPqGex4EtBDQKqDJpzukhChyY3/rGQ5jwflIEh2f mnNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 70si10953942plc.253.2019.06.17.13.44.30; Mon, 17 Jun 2019 13:44:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727703AbfFQUoZ (ORCPT + 99 others); Mon, 17 Jun 2019 16:44:25 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:45632 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725844AbfFQUoZ (ORCPT ); Mon, 17 Jun 2019 16:44:25 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hcyUI-0004t6-0V; Mon, 17 Jun 2019 22:44:22 +0200 Date: Mon, 17 Jun 2019 22:44:21 +0200 (CEST) From: Thomas Gleixner To: Ferdinand Blomqvist cc: linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 1/7] rslib: Add tests for the encoder and decoder In-Reply-To: <20190330182947.8823-2-ferdinand.blomqvist@gmail.com> Message-ID: References: <20190330182947.8823-1-ferdinand.blomqvist@gmail.com> <20190330182947.8823-2-ferdinand.blomqvist@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ferdinand, On Sat, 30 Mar 2019, Ferdinand Blomqvist wrote: Sorry for the horrible long delay. I'm just drowned in backlog. .... > There are a couple of options for the tests: > > - Verbosity. > > - Whether to test for correct behaviour beyond capacity. Default is to > test beyond capacity. > > - Whether to allow erasures without symbol corruption. Defaults to yes. > > Note that the tests take a couple of minutes to complete. Very well written changelog! > +/* List of codes to test */ > +static struct etab Tab[] = { > + {2, 0x7, 1, 1, 1, 100000 }, > + {3, 0xb, 1, 1, 2, 100000 }, > + {3, 0xb, 1, 1, 3, 100000 }, > + {3, 0xb, 2, 1, 4, 100000 }, > + {4, 0x13, 1, 1, 4, 10000 }, > + {5, 0x25, 1, 1, 6, 1000 }, > + {6, 0x43, 3, 1, 8, 100 }, > + {7, 0x89, 1, 1, 10, 100 }, > + {8, 0x11d, 1, 1, 32, 100 }, > + {8, 0x187, 112, 11, 32, 100 }, > + /* > + * {9, 0x211, 1, 1, 32, 100 }, > + * {10, 0x409, 1, 1, 32, 100 }, > + * {11, 0x805, 1, 1, 32, 100 }, > + * {12, 0x1053 1, 1, 32, 50 }, > + * {12, 0x1053 1, 1, 64, 50 }, > + * {13, 0x201b 1, 1, 32, 20 }, > + * {13, 0x201b 1, 1, 64, 20 }, > + * {14, 0x4443 1, 1, 32, 10 }, > + * {14, 0x4443 1, 1, 64, 10 }, > + * {15, 0x8003 1, 1, 32, 5 }, > + * {15, 0x8003 1, 1, 64, 5 }, > + * {16, 0x1100 1, 1, 32, 5 }, > + */ I assume these are enabled later. We don't do that commented out stuff in general. If it's used later, then add it with a separate patch. If not just leave it alone. > + {0, 0, 0, 0, 0, 0}, > +}; > + > + > +struct estat { > + int dwrong; > + int irv; > + int wepos; > + int nwords; > +}; > + > +struct bcstat { > + int rfail; > + int rsuccess; > + int noncw; > + int nwords; > +}; > + > +struct wspace { > + uint16_t *c; /* sent codeword */ > + uint16_t *r; /* received word */ > + uint16_t *s; /* syndrome */ > + uint16_t *corr; /* correction buffer */ > + int *errlocs; > + int *derrlocs; Pet pieve comment. I generally prefer tabular layout of structs as it's simpler to follow struct wspace { uint16_t *c; /* sent codeword */ uint16_t *r; /* received word */ uint16_t *s; /* syndrome */ uint16_t *corr; /* correction buffer */ int *errlocs; int *derrlocs; Hmm? > + > +static double Pad[] = {0, 0.25, 0.5, 0.75, 1.0}; This is kernel code. You cannot use the FPU without special care. But for that use case doing so would be actually overkill. > + for (i = 0; i < ARRAY_SIZE(Pad); i++) { > + int pad = Pad[i] * max_pad; That can be simply expressed: struct pad { int mult; int shift; }; static struct pad pad[] = { { 0, 0 }, { 1, 2 }, { 1, 1 }, { 3, 2 }, { 1, 0 }, }; for (i = 0; i < ARRAY_SIZE(pad); i++) { int pad = (pad[i].mult * max_pad) >> pad[i].shift; Also note, that I got rid of the CamelCase name. > +static struct wspace *alloc_ws(struct rs_codec *rs) > +{ > + int nn = rs->nn; > + int nroots = rs->nroots; > + struct wspace *ws; Yet another pet pieve comment for readability. Order variables in reverse fir tree order. int nroots = rs->nroots; struct wspace *ws; int nn = rs->nn; > + ws = kzalloc(sizeof(*ws), GFP_KERNEL); > + if (!ws) > + return NULL; > + > + ws->c = kmalloc_array(2 * (nn + nroots), > + sizeof(uint16_t), GFP_KERNEL); > + if (!ws->c) > + goto err; > + > + ws->r = ws->c + nn; > + ws->s = ws->r + nn; > + ws->corr = ws->s + nroots; > + > + ws->errlocs = kmalloc_array(nn + nroots, sizeof(int), GFP_KERNEL); > + if (!ws->c) > + goto err; > + > + ws->derrlocs = ws->errlocs + nn; > + return ws; > + > +err: > + kfree(ws->errlocs); > + kfree(ws->c); > + kfree(ws); If you move free_ws() above this function you can replace this kfree() sequence with free_ws(); > + return NULL; Just nitpicks, except for the FPU issue. Other than that this looks great. Thanks, tglx