From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (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 BE1A241F7E9 for ; Fri, 10 Jul 2026 12:42:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783687344; cv=none; b=SxsxFje5gM7g6XawPZdF3BiWsNnnAANKSYaFkPceYywKYaP69wOK7sokeUMojXHHusBOU/vwMj48iEH23K08yj+N0KgpJeoc+Tw+8rG7hlNb5L+rLnNr+MCnA3FSRWFZivn+suZlja9+BpVqu7PZQPQobtpJr+RD1ObKEnNaoig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783687344; c=relaxed/simple; bh=DWmNJ5lwsL10oKYuxQDPlcDGajEHoML1G3ab68pBqgk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UK+AAwqjgejRG/O+ZlCihNPAEKeK/PzwVGc++OdkqKuyGDkvFC3ai/TQaluce87YE+obao20dTIdk4X3t++FFvTeNzUWe4tff/fpAbBxidYNAZukapwi+Eg/tS4LvHhHUAnbZ9h3x7qY4fG88oPePq8yc+z2u8ZwAC1AbPiJu4c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com; spf=pass smtp.mailfrom=riscstar.com; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b=leUELaFJ; arc=none smtp.client-ip=209.85.219.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=riscstar.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=riscstar.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=riscstar-com.20251104.gappssmtp.com header.i=@riscstar-com.20251104.gappssmtp.com header.b="leUELaFJ" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-8efbafa1bacso6104616d6.1 for ; Fri, 10 Jul 2026 05:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=riscstar-com.20251104.gappssmtp.com; s=20251104; t=1783687342; x=1784292142; darn=vger.kernel.org; h=content-transfer-encoding:content-type: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 :content-type; bh=YJBwqL8OFuvpdmiP4qvFBor8YyEfp6aV/aiB/sY0dm4=; b=leUELaFJsmYR/5cwOTvjTdqjN1E7PxME7EZSem7Z3OlLTDdGVgwLg3PpDAIIp3eEHA eZ7YRp6SRFXHf4ucsGXYzxP9NeIzLJqVg95cfbjHOuPdseDQj8hmSDKYFzgwOIYdnCGp QFJXEg05+NcLTnNM/Xz0cQo70DITUBBm/TLhGuAL2x+EC8N5bbif6egQP7I3xjNRqnMh SCeNrCiXPcVghmp6sUXtyClzlssNkxeIrJDxDKm8+89YJEfhmZ1eoo04TydPZ49Bwc8g +Kbd77uB/aK3ry7t/93JAXTw07o6kvIMnnAYe6mjz5WF6KUkcxzILwsA76HpH9mzP+N6 +4/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783687342; x=1784292142; h=content-transfer-encoding:content-type: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:content-type; bh=YJBwqL8OFuvpdmiP4qvFBor8YyEfp6aV/aiB/sY0dm4=; b=TtPUiPUg6i2BI+ZcXjT3F1sTMgCzQomOZew8kNI40WPp3pafqeg5MosWKvV4SJuE8e +qOf9RhAnkIfRxA1zn7uitd7vXnKZXW8hkv4ABINgoS6eoo6SjAnh55WdiHihwxwFgWI xC83WCaLT0m2M5r9ox9UMi5G/Q12kYbXzMEYCGeysne0SJWJgOCuRP2HsQf7DNbGRd5a rJaDDV9IB0VJQbs0NH3Xy334M8EUfEzqOglkNH7w1ef/th1jNz1Ix6fyZxMxexlpu+oj h/3lOD8I0fnXH+QQd5IwwkQxAOI4QVMlzRA7NDGbRj5po1jtsvOOjUMWxoekGMj77kAm 6k8Q== X-Forwarded-Encrypted: i=1; AHgh+RqUDRjkqbcjh7PWQdcMMNCzW8RssybX842oLnrphZR95Kl1R/QJZc2sPBIvx32xeWfdHRswR1GLS9+HVDM=@vger.kernel.org X-Gm-Message-State: AOJu0YzJ3Uql+cj3Rj76JMa9SYawKYR9FXxB4datzrHvvGXXGTdOeH3f qT+w2C1j8r3A6QlGgf2ursatWG5XELW2gwwbtJ36lsmPHmzSURi4YJtXlh6WQPLpha4= X-Gm-Gg: AfdE7cn3ABkWCNjqYOr2Pd4Iobl1qyhX8AZ9H8jArd0CDwJKDAKNSikkU5XA2sdbO5k z9w5tUVnjpt1xpA9PrMtlzykxIoBmKbdPKkUQTDa1vhpQN5kskwsrW0f45nRw5YX4K2pp1Z2CiU 3qMv5TqvzCm13yz7Q0bA8Z4hHD5L9N+X7Um3AA/YsBQo9zVbSq1wlNrAW8MESMDG0WlwbNR89CG mlj4KIqtfGmjB1nVOFrp1j4+/WlNxbOyuZE6cDs+VZkbHiB9gTvEEHOnkLI1mIaD2LP0yHkB15S 5mqzJWKSomDBfLUv4VRnixk42gbg3SL5d+7aw8jw44HQJ7AVn2oqJg1uzi8+sy+uYABwRbi7bHq riXZnM/csWStG6AWaWDJ+CsIBia6p/6MmTccjoxhHXDjIm60g9x9ADiITLNkn+O6Ik3awt5J8nB 47q8hgxbhOaE19 X-Received: by 2002:a05:6214:5704:b0:8e9:f5de:d5b5 with SMTP id 6a1803df08f44-8fec3a038a2mr127470696d6.44.1783687341764; Fri, 10 Jul 2026 05:42:21 -0700 (PDT) Received: from [172.22.22.28] ([73.62.185.64]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8ffd7c1d22bsm40069556d6.32.2026.07.10.05.42.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Jul 2026 05:42:21 -0700 (PDT) Message-ID: <3cece33f-375f-4cb2-b07d-e75f065fe5ea@riscstar.com> Date: Fri, 10 Jul 2026 07:42:18 -0500 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 v4 2/6] PCI: spacemit-k1: Add multiple PHY handles support To: Inochi Amaoto , Andy Shevchenko Cc: Jingoo Han , Manivannan Sadhasivam , Bjorn Helgaas , Lorenzo Pieralisi , =?UTF-8?Q?Krzysztof_Wilczy=C5=84ski?= , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Yixun Lan , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Christian Bruel , Frank Li , Nam Cao , Qiang Yu , Krishna Chaitanya Chundru , Xincheng Zhang , Siddharth Vadapalli , Vidya Sagar , Neil Armstrong , Gustavo Pimentel , linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, spacemit@lists.linux.dev, Yixun Lan , Longbin Li References: <20260709040027.958400-1-inochiama@gmail.com> <20260709040027.958400-3-inochiama@gmail.com> Content-Language: en-US From: Alex Elder In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 7/10/26 5:55 AM, Inochi Amaoto wrote: >>>>> + k1->phy_count = i; >>>>> + if (k1->phy_count == 0) >>>>> + return -EINVAL; >>>>> + >>>>> + return 0; >>>> This doesn't seem correct to me, I would expect phy_count to be assigned only >>>> when it's valid. (Yes, perhaps 0 is the same as it was, but semantically it's >>>> different 0 in this case.) >>> I guess you think 0 is a valid number? I can not understand what you thing >>> Assign this to 0 if there is no phy is fine to me, which shows there is 0 >>> vaild phy found. >> Isn't it already 0? Semantically code is wrong in a flow (not in the result). >> > In fact it is already 0 here. But I am not understand why you thing is wrong. > Could you explain it in detail? (Maybe you think it is not good to return > -EINVAL?) What Andy is saying is that assigning the value of phy_count before checking that it is valid is not the expected order of things. The point is about best practice, not about the end result. Best practice would be "don't touch anything if the return value will indicate an error." And therefore, better coding practice would be to check for a bad value, and only after that has been done should you assign the k1->phy_count value. -Alex