From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) (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 1AB0A282F1E for ; Wed, 19 Aug 2026 02:35:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787106935; cv=none; b=TvuGpiNTxSJJO4tuIDm7TmwrHV6FoVJa3PgZ75viVv48UuMTAATg9hT4RF0GeAfkKAX5ANIHZm2hSHP9X6yAeeC7n1Tj6bojtcbD9jH5gPcapIgLPTc4QMGnnbI5t/KfO8BufIf7q/miw8dRnGuYHGblwvhJwT+bqNdf6D9HDT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787106935; c=relaxed/simple; bh=nWj4zNzPerC3DV9aSIIoB1Z1Asykf3vTYS8sZuDsVGk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k5o+X/maGOrek6QMfEd1BFxIvzPEJ1MNR4Awifv95dbF5ySZTKzRJORVUGgu7x9UT1cZ0R/VzCWn2Ia3Djce4SwnZkmkhlkxNs1nqjb5N+tW5s/xr3XfLbDr/Cu7l/5frn4e4sRjoYjnfiDLGvq7wSbv0xQtydh1vmL60VgwMGs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net; spf=pass smtp.mailfrom=minyard.net; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b=Nc3/8nct; arc=none smtp.client-ip=209.85.214.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=minyard.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=minyard.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=minyard.net header.i=@minyard.net header.b="Nc3/8nct" Received: by mail-pl1-f179.google.com with SMTP id d9443c01a7336-2cf27856f9cso4112035ad.2 for ; Tue, 18 Aug 2026 19:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=minyard.net; s=google; t=1787106933; x=1787711733; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:reply-to:message-id:subject:cc:to:from:date:from:to:cc :subject:date:message-id:reply-to:content-type; bh=1d3yxeQbPrq6cSWvRvSjEdmIeaM7OAutBrFdc9ZXf9g=; b=Nc3/8nctHH81kQuXZi0dHoqhvBtvdzViYObh/k8AlozLHSOl0yJZYR0ya4bqbs95rQ yw2hpulbVHC/K3LodEr/MQcFLN/BRI8y8fMknmOpKHPqMgFltrW00kHq5aa6DBbQ7yDq bfz0dT8rayUDONA/5ZwNWvklUGVECZAvU49F2JeH1QkQo2OFzI11hdBh9fgTynX+uuG9 yv7IyTv71EIobezIKkeB7V63ardRx+cCYv2aIn3AtQJ4QsrJA6iPv6G+uyMrCiSESZQp E//210ewFm/hJnoVUlcVnUwwBU+avRVQsIb8vWF6k6d3xlxI64bNmBJMkzMOFsqCEbF4 R52g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787106933; x=1787711733; h=in-reply-to:content-disposition:content-type:mime-version :references:reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=1d3yxeQbPrq6cSWvRvSjEdmIeaM7OAutBrFdc9ZXf9g=; b=j8aj3qPRTS2V+9+LU/KZPdZMw/ngvcBW6bjhvvPw5wKosV7Xb0bsICvn2CuACpILYC wxlZz5R08TxReI7Y4dYulc/r0LwAvEQvVk6ip7WyEqmlOC0tqhW+ysSsX1lkX5ztj1QJ b7nk/OhAfyU1i4t2+IBfQmqfl4MOFocCZ40e6LrIH9X5s+kD7DczFYHDqQcHTQdJjq1Y rRbt/EkhPxYBQevmpEK9IRULno4R2o1jPvmOLXIVGCde1dxDdXyj6BJhfL/FJbGLrtVb Vs0neTTc4s0F57Yr0Y8ryqnQqKo9cox+YJ/Zkn9WpbZjBWJyUnknQwgaWWsynvCj9w1P NCZA== X-Forwarded-Encrypted: i=1; AHgh+Roj7ey59xOz1nQgw6W7eUcczBgnycjrwYd+0vvgZfwVIGiWTBDwoZGA416wlvLbIYH/HhtaQvVUFtEaz90=@vger.kernel.org X-Gm-Message-State: AOJu0Ywk57Ja5uO1t9zf6KSXdhDGro8mwU5sA/2HOUixVf9j+uGoaYiv bUKewm7FKPkxVtXVlIyHqFKHmCm8Ldk+zDm7DCM9CTwJw7O61t1ekFgeTMTmuneqaSU= X-Gm-Gg: AR+sD12KJziHQCCajiukOfrufVBhQZ805DQFSg6qR5LUDguVbaUYSk3gmjwd0+XDNQw nNQe1T7H+XVkk9UmgJUpqPjZbw1Y/sH6rOw9ip0oZdZtppOsOMBF8CZ88ni8op1aYxlezP+L82U JfQeG5slwzP4W6oboM9GbHRlzV4QnVOP1H4FxnmBh+dl7GBybpvfI+WKDGusveLvyYkwgmFnpK9 +vUFwE6hiH4NgVPBwo2tsMwyfmDi+TKmCho3vy1AXn3U/LCpNQ1VRcNEYS5UzD6obvhC+lYQ2Cm +Qn2Fdi2TDSI0iNfnWFTaUTWXblymSrRZ8LcYsSl3Cfn2u51GOUF/2cbrhDU26kbyVZZuj3DJyk etShfSWbdnEumHiS4ne40ZCrWI3LdZeFY7FzFsCTrPQtwU7YOvQSia314/+rC6RCfYlTLxxE2oh rKd0kghrU24HTEepUWRDEGfzIi98GZcUJdW3KF7U+Azr6rnoI0Ya0qzbK9MAzdrzDhgFiRb4J3u cY/gsgkEY/Y3n06r3AxUS0s7b9wY0Pl+/8BVZ9YR9z3eYUUCjwE1CYYzcej4TZuGY/GDAfCY8O3 D0Gq49YWAw== X-Received: by 2002:a17:90b:5105:b0:37f:fb1d:63fa with SMTP id 98e67ed59e1d1-39581070da4mr2570755a91.15.1787106933300; Tue, 18 Aug 2026 19:35:33 -0700 (PDT) Received: from mail.minyard.net ([2001:470:b8f6:1b:38a4:6159:b0cf:3eef]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-327bef3bb51sm1513050eec.6.2026.08.18.19.35.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 19:35:32 -0700 (PDT) Date: Tue, 18 Aug 2026 21:35:26 -0500 From: Corey Minyard To: Bui Duc Phuc Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] ipmi: bt-bmc: Handle -ENXIO from optional IRQ lookup Message-ID: Reply-To: corey@minyard.net References: <20260817105041.63224-1-phucduc.bui@gmail.com> <20260817105041.63224-2-phucduc.bui@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Wed, Aug 19, 2026 at 09:22:28AM +0700, Bui Duc Phuc wrote: > Hi Corey, > > Thank you for your feedback. > > > Yes, ignoring errors is the right thing to do in this case. Printing a > > warning log about incorrect configuration is ok, but breaking systems > > that have incorrect configuration is not ok. > > > > If that's the case, then perhaps platform_get_irq() would be a better fit than > platform_get_irq_optional(). platform_get_irq() already prints an error message > internally and only requires the caller to distinguish between success > and failure. > This seems to match the behavior you are looking for. No, it is optional. Some systems don't have interrupts. But they may be misconfigured in this case. For instance, they may put "0" for the interrupt if they don't support it. These things can't always be easily fixed. The big thing is we can't change behaviour without a really compelling reasons. > > > It is common for these systems to not have interrupts. I think it's a > > bad idea, but I didn't design the hardware or the specifciations. And > > it's common for configuration to have issues :-( > > > > > Hardware configuration is handled by software, so if the software configures > the hardware incorrectly but ignores the error, the problem may go undetected. > Could this allow the same driver bug to persist when the driver is used > with newer generations of chips? > > Also, if software silently ignores errors, it can hide a problem in > the hardware or > in how the hardware is being used. This can make the problem harder to detect > and potentially allow it to persist when the design is reused in > subsequent chip generations. I'm not going to argue with any of this. But I also have to live inside the parameters of the real world. It doesn't have to be silent, you can print a warning. But it can't return an error in this case. > > > Anyway, I think you have the parameters now, looking forward to the next > > patch. > > My goal is to ensure that the correct error code is returned to the caller. > Although I could implement it by ignoring the errors as you suggested, > I will not do so because that goes against the goal of this series. Ok, that's fine. This isn't critical. Thanks, -corey > > Best regards, > Phuc