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 8BE15C98302 for ; Tue, 22 Sep 2026 16:04:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:CC:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=c3raCvzUdaORSD9uUGjoNKyCm+ElImg/ks8kzmr66Z8=; b=I/MmolkxGpxqdNdBZkMZ0uwx1u 6i9fCuv4pbh6Q1yKRqeEQm36Socbq+2w5hY/bQGcULnts4yLg/OYyPiAJlRr0bWQK5FzlRFmeiMET /R0UMzFEXQ6NWblWEeAQfD2E/4jqJqmk+ZWHJ5RTpq61D4n/TEOleKIsh3PMmkbabp/Dd3ejbHZL0 Otg7oDGd/83ooVVR02UovRV43lo4H1mJKjdbmL9m/Q6V0H3BuwIwljX8wnRyEdNzMhsjfzULGi5VO OXzKvepChbNctz4vJ3us82dnKumqH9YSqhSbKo4qkGRZ9M+Cpo56VWhTN/H4i6n1Z3B6KLb1d+1Fs vNiIOZWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1x92ym-00000005zsr-2dJm; Tue, 22 Sep 2026 16:04:24 +0000 Received: from [95.181.193.9] (helo=mail.auroraos.dev) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1x92yi-00000005zq5-3hgV; Tue, 22 Sep 2026 16:04:23 +0000 Received: from [192.168.2.104] (91.79.44.40) by exch16.corp.auroraos.dev (10.189.209.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 22 Sep 2026 19:04:08 +0300 Message-ID: Date: Tue, 22 Sep 2026 19:04:08 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] pmdomain: rockchip: fix domain check in rockchip_pm_add_one_domain() To: Shawn Lin , Ulf Hansson , Heiko Stuebner , , CC: Caesar Wang , Kevin Hilman , References: <20260920175928.42566-1-s.shtylyov@auroraos.dev> <140e4538-d493-40a7-a682-00be091332f0@auroraos.dev> <1d8950b4-315f-44a4-9fc8-fcb35ac33043@rock-chips.com> Content-Language: en-US From: Sergey Shtylyov In-Reply-To: <1d8950b4-315f-44a4-9fc8-fcb35ac33043@rock-chips.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [91.79.44.40] X-ClientProxiedBy: exch16.corp.auroraos.dev (10.189.209.38) To exch16.corp.auroraos.dev (10.189.209.38) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.9.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260922_090420_919483_52D82539 X-CRM114-Status: GOOD ( 14.33 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/22/26 3:47 AM, Shawn Lin wrote: [...] >>>> In rockchip_pm_add_one_domain(), there's the check (most probably for >>>> the case where the "reg" prop has an unexpected value?) which doesn't >>> >>> Agreed that check indeed makes little sense. But "most probably for the >>> case where the reg prop has an unexpected value" does not hold: an >> >>     I tried to guess what the check in question was actually intended for >> (despite making a little sense as it is now)... >> >>> out-of-range reg value is already rejected by the "id >= pmu->info- >>>> num_domains" check above, and num_domains equals >> >>     I noticed. :-) >> >>> ARRAY_SIZE(domain_info) for every SoC, so there are no holes in the >>> table that the new check could catch with the current data. AFAICT, this >> >>     Oh, there are holes! :-) >>     If you look at (and behind) the indexed initializers of *_pm_domains[], >> you'll see that the indexes don't always start at 0, and so the arrays are >> actually sparse... > > Looked more closely by each one, you're right. Perhaps I just should've been more verbose in the patch description... >>> patch does not change any runtime behaviour; it only turns dead code >>> into a defensive check on the match-data tables. >> >>     I hope you see now that this defensive check makes a bit more sense... >> >>>> make much sense as the variable pd_info will be NULL iff pmu->info-> >>>> domain_info is NULL and the variable id is 0.  What does make sense >>>> there is checking pd_info->pwr_mask and pd_info->req_mask which (as >>>> seems to follow from the code) can't both be 0 for a valid domain... >>> >>> That means there is no bug being fixed here, should we drop the fixes tag? >> >>     I'd like to keep it (but that's up to the maintainers, of course)... > > Sure, it's  Ulf's call. Anyway, feel free to add > > Reviewed-by: Shawn Lin Thank you! [...] MBR, Sergey