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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (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 6B17AC433EF for ; Wed, 22 Jun 2022 14:16:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A3105112B51; Wed, 22 Jun 2022 14:16:41 +0000 (UTC) Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by gabe.freedesktop.org (Postfix) with ESMTPS id BFDA5112B51 for ; Wed, 22 Jun 2022 14:16:39 +0000 (UTC) Received: from maud (206-47-13-26.static.dsl.ncf.ca [206.47.13.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alyssa) by madras.collabora.co.uk (Postfix) with ESMTPSA id D8177660159F; Wed, 22 Jun 2022 15:16:36 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1655907398; bh=5QwPhPn+oUECZJZh74dB84ZBlE2lT7TOgl2zfhKwH3E=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ahWqzDnypBpjQFdGIlmFQiOZu3PDOf9jUQV+CutbzlCR/E5E3rlwLPSetl3W4WS+T sE+da/JL6YT7FMvhvY2ERa91/uZCxeJb+u56MnJFpp+VtKCaZNCOf//9dq6YiqZURP DRSB815q6m25T/ldLKgRa86rlzJRjy0tDQEuPYsjQmbGHLipQOEXRmU23OdjzwqTCA pG23O+N7fAwzd04b3qotdRZbWUTxDiT0y4BjTNZbkF01q3wMzW1gKWhyUdtNXveBE8 /7bpQ7O4rJVTogqe8c2OvpTh8tQICX0U0mqNc6kpC5oCne1lKjo6/VZTFXfABUZF++ dGRUPEv7yMHog== Date: Wed, 22 Jun 2022 10:16:32 -0400 From: Alyssa Rosenzweig To: Adri??n Larumbe Subject: Re: [PATCH v3 1/1] drm/panfrost: Add support for devcoredump Message-ID: References: <20220622015420.1130814-1-adrian.larumbe@collabora.com> <20220622015420.1130814-2-adrian.larumbe@collabora.com> <20220622140058.3oykas4zfxprmv56@sobremesa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220622140058.3oykas4zfxprmv56@sobremesa> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: dri-devel@lists.freedesktop.org, alyssa.rosenzweig@collabora.com, tomeu.vizoso@collabora.com, steven.price@arm.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" > Sorry about this blunder. > > >> + slot = panfrost_job_get_slot(job); > >> + slot = slot ? slot : 0; > > > >`slot = slot ? slot : 0` is a no-op. Delete the line. > > I think what I meant here was 'slot = (slot >= 0) ? slot : 0;' but for some > reason I blundered again. The point of this was ensuring the slot value wouldn't > end up wrapping about the maximum unsigned integer value when using it as an > array offset, in the off-chance that panfrost_job_get_slot() ever returned a > negative value. > > In v4 I've instead rewritten this as a sanity check: > > WARN_ON(slot < 0); No, this doesn't make sense. There at most 3 job slots -- 0, 1, and 2. > Although perhaps in the future panfrost_job_get_slot should return an unsigned > integer instead? Sure. Kernel style doesn't seem big on unsigned, if this were mesa it would return unsigned. Returning u8 or u32 seems reasonable at any rate. > >As a general note, I'd appreciate breaking out the panfrost_regs.h > >changes into a separate patch, as they are a logically separate clean > >up to make room for this patch. Thanks. > > Done in v4. Thanks! Alyssa