From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC0A820ED for ; Mon, 23 Feb 2026 00:01:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771804892; cv=none; b=OErEofxGR/l1VAYTVpfKta/iyKCIzhKWyQm7co3y17J+nRjxuXc1R3ev5ZED/m3wWy0rNGvrOmP/11XCsfVBo5dMaowNY6twrNUNqt8wJmEgP1zfIJ7A8qczswmvOWnhQdMflS1eqyR8ZWXuB47WTmiZmT93y6g9IFymzA7X8bY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771804892; c=relaxed/simple; bh=ZFV4pbi0wIK53693SAmlhLcWSmpe3LjzqEIO8JvTwJg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MrlOJl7clc2Q3SQETrOdfJFnVJ8X7mUFiZoDcGMRKy/uMIMqwrxTVOH/091CoLQMyCmhRbdEa7MgkAWuZ2+lGvf1ivfVmfQ89J8vx1cx0Le3FhY5t+4VdoDpT6ZcvYy4Pk4y7hwgP/YfhZ5Xz7JfA7oGA+Ql/eXFEapGEWOisI4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=Ik7jGYFq; arc=none smtp.client-ip=209.85.210.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="Ik7jGYFq" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7d4c1d2123dso3709347a34.2 for ; Sun, 22 Feb 2026 16:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1771804889; x=1772409689; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nf3cd3Ow7fpmhEaunFtWMxQ62yJiyFWj+ZVPMJhUhgs=; b=Ik7jGYFqTM4+khw6hpzqzXxtFwhZAA/ywCMgTyy7NDk+yywW0F1TCl9QwFMwI9OlO3 pLbmX7CsKxadj9nnsJBn6MIxZYGi+rp9RhOgPMeauIB6TkDeJznCb5f5a1BIvk/kaK1d 8qD9ebpWWwPWjEhry/hJAoMFyTC9+J6t57IVfmQUz8lVJ9i6TCPay8cyDMQZP9FXyJmH O9N0ugbrXOq3uZlfH0oKoD+NAbR4STO77FCxdJ/+MwXJwIEYuVHhCSThYJnjocnLvFWY k99ajGXZSgzS17WVyl/k2wr1gRNdnA8McKBTF8jgZQgMrmPbssKUXtT8VE7r1Zs8armD zktg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771804889; x=1772409689; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nf3cd3Ow7fpmhEaunFtWMxQ62yJiyFWj+ZVPMJhUhgs=; b=KkN7a1f+dwuDA8PooqZAzoWHwmhgY+Qqq6+fQErUh06qlVDZiQ+E0Pv0PMJ0gaGDm7 sMAH3yPZr7wzrhvfX/HWl6WFrEvKF2NL85KRt22ngWsbevH+RJpV1vPkthSA7dfPUqmM 80f2RbmVG/kkG0Mej4DD6wGeaWGMzk6vhg4U4a33FxW+0l7W/WUspuVf4AEM5s52Yexq c/mCy6ApKszLvYUiFGIrcZ+vRk5Sr/qJ7AuOTd53fprjb2Nu9sorxewo8aJ2i6LdW2eX e0keWI+v4BQw1kCmv8nerBd7rQFhoOlpUfSIWINRW/dZPdaTvVE/QWXCTHpiCyBpsy2C b13A== X-Forwarded-Encrypted: i=1; AJvYcCVJ7D1Xii++Bp7w8Qp7I//q8T+ARCvOK+zpyCwZeBMr4mdPyPCFpRsJ0pu8pXBXIKGKdAqgitIo8BixXSs=@vger.kernel.org X-Gm-Message-State: AOJu0YzJxXJyPfZ1jgncEH1ME0WcrfGiPM5tYRvijvXIkZNpb0X1yLiS tA2o6sJD+5Tr0/nWnm/CBw6zIQVYnhz4UjY8tLV/q7x61eEe900BtdMKo2Ku6Fpj+T4= X-Gm-Gg: AZuq6aJFhrN0Zfmdh5A0m5bpu6knRnqRosLbaUjfzTIVBBYseV+P7x3YH4QsOlRCknr s0voBLlO5D2vlrsFvbaO3HhzTO40/CynCNZ2WkJhbQKR4XFB36J1oX4Wr3mj8fZKlqksTbdZ8s5 A6oAqallSCxLVSEnLxXsRmBzeX9LkzClp/uzecQVo2MKYGE4aP/epIQ04Bus/pVrYeVVvN+5i4V Df3UMD7L2roLcFg4OhuquilE4RBnmIqxRHjFsiGAHdj90i89C0CLCnyclxJTKKE1Dz5AoC91b6X 7IzsVeClFyutwroR62XMoy/VndiHu6ZSxtt1m0aISaAkgnu5rTFn4NgACYDXNj784HzfZov/ty2 x1uTFXtaliw6hSAgQg9HEics5IJSfufaR1VdRYknsPMZMcKLR1nyZwOZkWiEEpNORSorPHH747k wah1zRzQ+9NPxPcpDkYz0x+0jeTPvT3DkKOhwAYDKmY6Mu00vrxAiQrUdYM1wicNAlyIyTrNo= X-Received: by 2002:a05:6830:82dc:b0:7cf:d213:7ecf with SMTP id 46e09a7af769-7d52bf5324bmr3724174a34.32.1771804889597; Sun, 22 Feb 2026 16:01:29 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:e37:2309:3937:4469? ([2600:8803:e7e4:500:e37:2309:3937:4469]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7d52d038804sm5803026a34.18.2026.02.22.16.01.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 22 Feb 2026 16:01:29 -0800 (PST) Message-ID: Date: Sun, 22 Feb 2026 18:01:28 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 6/6] OPP: Use mutex locking guards To: Viresh Kumar , Viresh Kumar , Nishanth Menon , Stephen Boyd Cc: linux-pm@vger.kernel.org, Vincent Guittot , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org References: Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/24/25 5:36 AM, Viresh Kumar wrote: > Use mutex locking guard in the OPP core. > > No intentional functional impact. There is an unintentional functional change here. > > Signed-off-by: Viresh Kumar > --- ... > @@ -2660,17 +2632,16 @@ struct dev_pm_opp *dev_pm_opp_xlate_required_opp(struct opp_table *src_table, > return ERR_PTR(-EBUSY); > > for (i = 0; i < src_table->required_opp_count; i++) { > - if (src_table->required_opp_tables[i] == dst_table) { > - mutex_lock(&src_table->lock); > + if (src_table->required_opp_tables[i] != dst_table) > + continue; > > + scoped_guard(mutex, &src_table->lock) { > list_for_each_entry(opp, &src_table->opp_list, node) { > if (opp == src_opp) { > dest_opp = dev_pm_opp_get(opp->required_opps[i]); > break; > } > } > - > - mutex_unlock(&src_table->lock); > break; > } > } scoped_guard() is implemented as a for loop. So now this break statement breaks out out the scoped_guard() and not out of the outer for loop. Now the outer loop always iterates to completion. Assuming each item in src_table->required_opp_tables is unique, this doesn't look like a bug. Rather it is just doing unnecessary extra iterations. To preserve the logic, the break should be moved out of the scoped_guard().