Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8601188imu; Tue, 4 Dec 2018 10:56:10 -0800 (PST) X-Google-Smtp-Source: AFSGD/VtbJfJmU6bGTloC04DLkdp9jTuvs+Kbx7qa4cJSS2fsoJs5H4Gpzmsjmux2Yc8/uHku7jd X-Received: by 2002:a17:902:7588:: with SMTP id j8mr1835771pll.215.1543949770726; Tue, 04 Dec 2018 10:56:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543949770; cv=none; d=google.com; s=arc-20160816; b=ZShZq/iz68pv04qXk2cir/vuI+FJywHHqqqfu+xQ0eKv8f7wsv0aYdGMCNFk2iVAJD qXsPkpTzxLI3vWWtWVkyxm9MNROntwUyc7hUV+g5H6zUicKMmcWtbOWoFrqRkEgbLUzx VPX4pbn0o5zilIaw2jJlU+GM2oaM+noVG518m9un2xYtFRQjwsVf9KeS3n3hpOyexl+G Vr8uvONr0dIWvoanuO78d6wfUlAMIxvOTroWIo99QieiLpUJOzn/0/2X5mje+zjnk83q WThUFH+b2S/xh3SGP8vTFWBN1QSOF9wF3JIbzM/qCBcZCjJOpFbkaE9xSFgimCyZ959U zxNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=KVdbnxQN/EAigFOsyJ/RDQSseze7WAvrj2qYD4cnbo8=; b=mfR/XqiqawR18s+i0DFjQnvFSMy2iuJ3q2rlQ1uMOQEVqEMoWOpcegAETVKJ8oOJIK +u71kQqIgWcGN2/pPDV8qhFhr0LaLBoivXCYLUc1O5qkR2cyfuYPDAPUJU4UqaP/NVxH H2roND1EVk0CcObc1XbdMRubSXlEKYszZ7scJHYxJ/OEXVvByMygAWulJIXxLnySuTGW sj2HPdtaQgkdUxTwQe0t43sVYRwekuZtm2PpMHWEj2Mkxm9Z90WJ6WLvCWYdtNMfEW16 GjkiU7IHUs1UqqVOsEEvfjkPDaSE7bpEB7xe7jhVjYaCAnC81+6f7ijKNb/Bc+qvbZCI jpjA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Jv7Z8csL; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 15si17953400pfv.38.2018.12.04.10.55.55; Tue, 04 Dec 2018 10:56:10 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=Jv7Z8csL; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726109AbeLDSym (ORCPT + 99 others); Tue, 4 Dec 2018 13:54:42 -0500 Received: from mail-pl1-f169.google.com ([209.85.214.169]:36948 "EHLO mail-pl1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725839AbeLDSyl (ORCPT ); Tue, 4 Dec 2018 13:54:41 -0500 Received: by mail-pl1-f169.google.com with SMTP id b5so8753967plr.4 for ; Tue, 04 Dec 2018 10:54:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KVdbnxQN/EAigFOsyJ/RDQSseze7WAvrj2qYD4cnbo8=; b=Jv7Z8csLlo3zfOvTWWIuE+ZZ1hc2Ao8Ur1wrHRM54aju/ej+duYt2gGZClpWcugLVG j+JpoIy9DYjt33qLYjSRqDvX9s65/yUW3kLK3ArRHd4Ysj9Y1B2JyklifL6waEnp3iFO GZZd8UaVRhPi4TncvxlvGXf1IJCc3oNh17bbsKk2zGhKBD01SGWK/3hVnTvyOaatcHr7 YjK8zWLqRwHUaHv34rmiHfdxePZW8gltDGPVPb3V31xGKMsq47KQ+NNajxEfwkiNCaQZ 0Dd78bzPtxCNaDzGavdnuNXGPUTshOybRsEii0rRT2+O81jcBL7vhiMsJPyGfjpblRgX j6OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KVdbnxQN/EAigFOsyJ/RDQSseze7WAvrj2qYD4cnbo8=; b=WxFKjXjSK4oM1f0RdnlrXghbtbfWl46DjWkj8gvIub6jgNqeVJXzbndWhwJBupfj0q fwefKO0puQPGJ+geIP6d2XxDSD/V/DVYmAtXlxw0MPJolDHx7m2+Qd6VIlxbtWtbakw0 3Vxuvoz1bX3ykpn+beNMhpeD+jdMhpsutYtFJlJuiWjt21nagj8Uv1uG1H6gkxgywmgc P7xhbsMBNR3MnyjC6hqEgYaCMAk2CNWYDy3qvRwuH5qswCSPL1A0EI/B4qwFIyUELYaQ Go0r69UUrM6/rzxcGtgTP/wNGT1jwgzhYju0VJHelKUhP1Bq5rGk9g3ivtIR66ApYIXN ncYA== X-Gm-Message-State: AA+aEWYjZoMjmt0fAQoPtZFwTjwhvgrzH+seTXD27oJB/xFTV3S0+JC3 1YqyqzZbLjqQnHVaKMzWtn9KeKRDk9mKevQ2rSo8Nw== X-Received: by 2002:a17:902:7b88:: with SMTP id w8mr20903350pll.320.1543949679428; Tue, 04 Dec 2018 10:54:39 -0800 (PST) MIME-Version: 1.0 References: <20180915054739.14117-1-natechancellor@gmail.com> <20180917193936.33e90d5a@coco.lan> <20181204102639.3qsvfxrzmsvybiop@gofer.mess.org> <20181204095714.60ee5b95@coco.lan> <20181204133922.aaxvzu3qumbfakzu@gofer.mess.org> In-Reply-To: <20181204133922.aaxvzu3qumbfakzu@gofer.mess.org> From: Nick Desaulniers Date: Tue, 4 Dec 2018 10:54:28 -0800 Message-ID: Subject: Re: [PATCH] [media] dib7000p: Remove dead code To: sean@mess.org Cc: mchehab+samsung@kernel.org, Nathan Chancellor , Mauro Carvalho Chehab , linux-media@vger.kernel.org, LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 4, 2018 at 5:39 AM Sean Young wrote: > > On Tue, Dec 04, 2018 at 09:57:14AM -0200, Mauro Carvalho Chehab wrote: > > Em Tue, 4 Dec 2018 10:26:40 +0000 > > Sean Young escreveu: > > > > > On Mon, Sep 17, 2018 at 07:39:36PM -0300, Mauro Carvalho Chehab wrote: > > > > Em Mon, 17 Sep 2018 10:58:32 -0700 > > > > Nick Desaulniers escreveu: > > > > > > > > > On Fri, Sep 14, 2018 at 10:47 PM Nathan Chancellor > > > > > wrote: > > > > > > > > > > > > Clang warns that 'interleaving' is assigned to itself in this function. > > > > > > > > > > > > drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly > > > > > > assigning value of variable of type 'int' to itself [-Wself-assign] > > > > > > interleaving = interleaving; > > > > > > ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ > > > > > > 1 warning generated. > > > > > > > > > > > > It's correct. Just removing the self-assignment would sufficiently hide > > > > > > the warning but all of this code is dead because 'tmp' is zero due to > > > > > > being multiplied by zero. This doesn't appear to be an issue with > > > > > > dib8000, which this code was copied from in commit 041ad449683b > > > > > > ("[media] dib7000p: Add DVBv5 stats support"). > > > > > > > > > > > > Reported-by: Nick Desaulniers > > > > > > Signed-off-by: Nathan Chancellor > > > > > > --- > > > > > > drivers/media/dvb-frontends/dib7000p.c | 10 ++-------- > > > > > > 1 file changed, 2 insertions(+), 8 deletions(-) > > > > > > > > > > > > diff --git a/drivers/media/dvb-frontends/dib7000p.c b/drivers/media/dvb-frontends/dib7000p.c > > > > > > index 58387860b62d..25843658fc68 100644 > > > > > > --- a/drivers/media/dvb-frontends/dib7000p.c > > > > > > +++ b/drivers/media/dvb-frontends/dib7000p.c > > > > > > @@ -1800,9 +1800,8 @@ static u32 dib7000p_get_time_us(struct dvb_frontend *demod) > > > > > > > > > > Something looks wrong here (with this function). The patch is no > > > > > functional change, since as you point out `interleaving` is > > > > > initialized to 0, then never updated before read, but I think there's > > > > > an underlying bug here that should be fixed differently. Thanks for > > > > > the patch though, as it does raise the question. > > > > > > > > > > dib7000p_get_time_us has this comment above it: > > > > > > > > > > 1798 /* FIXME: may require changes - this one was borrowed from > > > > > dib8000 */ > > > > > > > > The goal of dib7000p_get_time_us() is to estimate how much time it > > > > takes, with current tuning parameters, to have a certain number of > > > > DVB-T packets. This is used for block error count. That's said, > > > > on a quick look, it seems that the code is not right on many ways. > > > > > > > > It should be aligned with the amount of data it is required for > > > > dib7000 to update the block/bit error counters. There are two kinds > > > > of implementation: > > > > > > > > 1) the frontend has an internal counter that it is shifted and made > > > > available to the driver after a certain amount of received data > > > > (usually in the order of 10^5 to 10^7 bits); > > > > > > > > 2) the frontend has an internal timer that shifts the data from its > > > > internal counter after a certain amount of time (usually at the > > > > seconds range). > > > > > > > > Different vendors opt for either one of the strategy. Some updates > > > > a counter with the amount of bits taken. Unfortunately, this is not > > > > the case of those dib* frontends. So, the Kernel has to estimate > > > > it, based on the tuning parameters. > > > > > > > > From the code, it seems that, for block errors, it waits for 1,250,000 > > > > bits to arrive (e. g. about 766 packets), so, it uses type (1) strategy: > > > > > > > > /* Estimate the number of packets based on bitrate */ > > > > if (!time_us) > > > > time_us = dib7000p_get_time_us(demod); > > > > > > > > if (time_us) { > > > > blocks = 1250000ULL * 1000000ULL; // the multiply here is to convert to microsseconds... > > > > do_div(blocks, time_us * 8 * 204); // As here it divides by the time in microsseconds > > > > c->block_count.stat[0].scale = FE_SCALE_COUNTER; > > > > c->block_count.stat[0].uvalue += blocks; > > > > } > > > > > > > > For BER, the logic assumes that the bit error count should be divided > > > > by 10^-8: > > > > > > > > c->post_bit_count.stat[0].uvalue += 100000000; > > > > > > > > and the counter is updated every second. So, it uses (2). > > > > > > > > > > > > > > Wondering if it has the same bug, it seems it does not: > > > > > drivers/media/dvb-frontends/dib8000.c#dib8000_get_time_us():3986 > > > > > > > > > > dib8000_get_time_us() seems to loop over multiple layers, and then > > > > > assigns interleaving to the final layers interleaving (that looks like > > > > > loop invariant code to me). > > > > > > > > > > Mauro, should dib7000p_get_time_us() use c->layer[???].interleaving? > > > > > > > > I don't think that time interleaving would affect the bit rate. > > > > I suspect that the dead code on dib8000 is just a dead code. > > > > > > > > > I don't see a single reference to `layer` in > > > > > drivers/media/dvb-frontends/dib7000p.c. > > > > > > > > Layers are specific for ISDB-T, but I think DVB-T (or at least DVB-T2) > > > > may use time interleaving. > > > > > > > > Yet, as I said, the goal is to estimate the streaming bit rate. > > > > > > > > I don't remember anymore from where the dib8000 formula came. > > > > > > > > My guts tell that time interleaving shouldn't do much changes (if any) > > > > to the bit rate. I suspect that removing the dead code is likely > > > > OK, but I'll try to see if I can find something related to where this > > > > formula came. > > > > > > So we have two issues. One is the clang issue and clearly the code needs > > > fixing up. The second issue is that we're not sure about the algorithm; > > > I've been reading up on mpeg-ts but I'm not anywhere near getting to an > > > answer on this. > > > > > > How about we merge a patch which just fixes the clang issue and leave > > > the rest of the code as-is for now? > > > > I'm ok with that, but it would be better to add a FIXME note somewhere. > > > > > > > > Thanks, > > > > > > Sean > > > > > > --- > > > From c6e4c5f514c38511d2054c69f7b103e98c520af4 Mon Sep 17 00:00:00 2001 > > > From: Sean Young > > > Date: Tue, 4 Dec 2018 09:59:10 +0000 > > > Subject: [PATCH v2] media: dib7000p: Remove dead code > > > > > > Clang warns that 'interleaving' is assigned to itself in this function. > > > > > > drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly > > > assigning value of variable of type 'int' to itself [-Wself-assign] > > > interleaving = interleaving; > > > ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ > > > 1 warning generated. > > > > > > Just remove the self-assign and leave existing code in place for now. > > > > > > Reported-by: Nick Desaulniers > > > Signed-off-by: Sean Young Thanks for taking the time to revisit the warning and clean it up. Reviewed-by: Nick Desaulniers Might be nice to give Nathan some credit when applied: Suggested-by: Nathan Chancellor > > > --- > > > drivers/media/dvb-frontends/dib7000p.c | 2 -- > > > 1 file changed, 2 deletions(-) > > > > > > diff --git a/drivers/media/dvb-frontends/dib7000p.c b/drivers/media/dvb-frontends/dib7000p.c > > > index 58387860b62d..cd84320c61c9 100644 > > > --- a/drivers/media/dvb-frontends/dib7000p.c > > > +++ b/drivers/media/dvb-frontends/dib7000p.c > > > @@ -1871,8 +1871,6 @@ static u32 dib7000p_get_time_us(struct dvb_frontend *demod) > > > break; > > > } > > > > > > - interleaving = interleaving; > > > - > > > denom = bits_per_symbol * rate_num * fft_div * 384; > > > > something like: > > > > /* > > * FIXME: check if the math makes sense. If so, fill the > > * interleaving var. > > */ > > > > > > /* If calculus gets wrong, wait for 1s for the next stats */ > > > > Good point. > > Sean > > From a31c18315830da40561db6443d3b90b8584d5232 Mon Sep 17 00:00:00 2001 > From: Sean Young > Date: Tue, 4 Dec 2018 09:59:10 +0000 > Subject: [PATCH v3] media: dib7000p: Remove dead code > > Clang warns that 'interleaving' is assigned to itself in this function. > > drivers/media/dvb-frontends/dib7000p.c:1874:15: warning: explicitly > assigning value of variable of type 'int' to itself [-Wself-assign] > interleaving = interleaving; > ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~ > 1 warning generated. > > Just remove the self-assign and leave existing code in place for now. > > Reported-by: Nick Desaulniers > Signed-off-by: Sean Young > --- > drivers/media/dvb-frontends/dib7000p.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/dvb-frontends/dib7000p.c b/drivers/media/dvb-frontends/dib7000p.c > index 58387860b62d..2818e8def1b3 100644 > --- a/drivers/media/dvb-frontends/dib7000p.c > +++ b/drivers/media/dvb-frontends/dib7000p.c > @@ -1871,10 +1871,13 @@ static u32 dib7000p_get_time_us(struct dvb_frontend *demod) > break; > } > > - interleaving = interleaving; > - > denom = bits_per_symbol * rate_num * fft_div * 384; > > + /* > + * FIXME: check if the math makes sense. If so, fill the > + * interleaving var. > + */ > + > /* If calculus gets wrong, wait for 1s for the next stats */ > if (!denom) > return 0; > -- > 2.19.2 > -- Thanks, ~Nick Desaulniers