From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8834CC433EF for ; Mon, 18 Jul 2022 17:59:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FoQxt3wIKdiQP3X5w9t/GsbKXKFmwgp5AmwtSndVyoE=; b=RKs3sHXO+1/iRH PksI6lG3DMCIBqnJ7vQt44MoGxZR+uabENPGVy1Qb4Zkw5uwW60Wmp9h85mg3lFLtPmAnyYG0s73N L/CxkA4HvcLpT39TQwzGOlOHmN2RT1fO+qCgu6+uQT897IEQ2zmMVH3dsufyOHRFDiB6cWpuFGDqW RzL3pcOTMghhcVo6S+74SON9pq/VWsn0X81IJQi1xI7Mo/0S4y3jqigiyUnfkGaO7cVZpxM5+jKGn cNP6OoKwh+fXa3oTxI730EqbjPQPUgJl8f4EFCp1ajEtLFjqoW3opn8Q2edQ7Zab08xxK4Vec8/At McHaie7xFw+nxQ2ed4rA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDV0P-00HNuH-PP; Mon, 18 Jul 2022 17:58:05 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDV0G-00HNoB-Ep for linux-arm-kernel@lists.infradead.org; Mon, 18 Jul 2022 17:57:58 +0000 Received: by mail-ej1-x62a.google.com with SMTP id bp15so22724519ejb.6 for ; Mon, 18 Jul 2022 10:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7pbvqadJLQpegf3D+q21OLRSwQXILX31lmjWX8Hj/GY=; b=b5g1vKxnKuvfgRtkVJm2ZXoQeRwcrMtRwhAUX6uZINrXGcu1pchJpyVw/M+Hd96mMW hBnhrH90clc05gcS5xguvYuXAGGVTRgb2MtagArPyUBzQMXRRTF3+UeTrgm5aQtc7WH0 gpM0cb86dwOJgcVLHBYBFb3coPCCRYdQMlM1aTMCSDyWF/nXhz45jInNoMz6EDG3RACh /JvFVFUV/xzYNrwmkgRUVSv84j7TfdAn2jVQLe+Y47YxLRDolNTtKYG/JXv4pVdxudRt ogFPFLbj7UZm55bLbrKLKcXoWIwCYWfPAYISmktzpu6AHpzo/yhByLrn7csRxF7QmJhE 5qEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7pbvqadJLQpegf3D+q21OLRSwQXILX31lmjWX8Hj/GY=; b=lKqAF9e4EDDrDDNgHpf+kO5pxDeWwLjfwqVJvZSchip8JEwEDFClZ1N5IQ/LlRZuGG 8bob/0m5zo6SQSn/t9KVGHVvjgOo0vrMiAQx9NBN7htfYpGLVe6nJHv4fQiXzEVV1ikt uT2PDS0VXgoZlzHO2NmrVg+DdlzQLzfBZYhN6UhinyRhFNiQSV+O9nmq7tuaKt6yXZVT Eoy1yUcnb8N9iqrGzEGLnFgJJTUm/3Lz9+wMJ7GkFouqBObYXFC/HpHWeEOihbf/DEu5 +6SUkBonOuy5gOfSjTefvQSYs6jR1/Nnq4uqqFWA8Kbk/qAvY7rsHSM7+BJ70C6KsnEm jLgw== X-Gm-Message-State: AJIora8XsuJ7ytkPZGyTx/aQkBpihRSpjmBwS2E/jEwbBaJJdZA24k+G QGNNFm4aWh6EiImaG5jdA+A= X-Google-Smtp-Source: AGRyM1s2xe9DqszGwO+egWgTy28gEFT166qISo4hJQn4LN8S+JzN/Y/mXSMgNsQz/8KSTLeTxLt8gw== X-Received: by 2002:a17:906:58c9:b0:72f:4646:1f6f with SMTP id e9-20020a17090658c900b0072f46461f6fmr2253952ejs.181.1658167072750; Mon, 18 Jul 2022 10:57:52 -0700 (PDT) Received: from kista.localnet (213-161-3-76.dynamic.telemach.net. [213.161.3.76]) by smtp.gmail.com with ESMTPSA id eg52-20020a05640228b400b0043a6fde6e7bsm8823482edb.19.2022.07.18.10.57.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 10:57:51 -0700 (PDT) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: mripard@kernel.org, paul.kocialkowski@bootlin.com, Nicolas Dufresne Cc: mchehab@kernel.org, gregkh@linuxfoundation.org, wens@csie.org, samuel@sholland.org, hverkuil-cisco@xs4all.nl, ezequiel@vanguardiasur.com.ar, linux-media@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: Re: [PATCH] media: cedrus: hevc: Add check for invalid timestamp Date: Mon, 18 Jul 2022 19:57:49 +0200 Message-ID: <4725382.GXAFRqVoOG@kista> In-Reply-To: References: <20220718165649.16407-1-jernej.skrabec@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220718_105756_522632_CF4E098F X-CRM114-Status: GOOD ( 23.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Dne ponedeljek, 18. julij 2022 ob 19:41:48 CEST je Nicolas Dufresne = napisal(a): > Le lundi 18 juillet 2022 =E0 18:56 +0200, Jernej Skrabec a =E9crit : > > Not all DPB entries will be used most of the time. Unused entries will > > thus have invalid timestamps. They will produce negative buffer index > > which is not specifically handled. This works just by chance in current > > code. It will even produce bogus pointer, but since it's not used, it > > won't do any harm. > > = > > Let's fix that brittle design by skipping writing DPB entry altogether > > if timestamp is invalid. > > = > > Fixes: 86caab29da78 ("media: cedrus: Add HEVC/H.265 decoding support") > > Signed-off-by: Jernej Skrabec > > --- > > = > > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 3 +++ > > 1 file changed, 3 insertions(+) > > = > > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c index > > 1afc6797d806..687f87598f78 100644 > > --- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c > > @@ -147,6 +147,9 @@ static void cedrus_h265_frame_info_write_dpb(struct > > cedrus_ctx *ctx,> = > > dpb[i].pic_order_cnt_val > > = > > }; > > = > > + if (buffer_index < 0) > > + continue; > = > When I compare to other codecs, when the buffer_index does not exist, the > addr 0 is being programmed into the HW. With this implementation is is le= ft > to whatever it was set for the previous decode operation. I think its is > nicer done the other way. It's done the same way as it's done in vendor lib. As I stated in commit = message, actual values don't matter for unused entries. If it is used by = accident, HW reaction on all zero pointers can only be worse than using old= , = but valid entry. Due to no real documentation and Allwinner unwillingness to share details, = we'll probably never know what's best response for each error. Some things = can = be deduced from vendor code, but not all. I would rather not complicate this fix, especially since it's candidate for = backporting. Best regards, Jernej > = > > + > > = > > cedrus_h265_frame_info_write_single(ctx, i, = dpb[i].field_pic, > > = > > = pic_order_cnt, > > = buffer_index); _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel