From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f173.google.com (mail-dy1-f173.google.com [74.125.82.173]) (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 3D2123B19BF for ; Thu, 30 Apr 2026 21:07:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777583264; cv=none; b=A0mS3TvOl3Sbi0CcKxJjUbpKB6HWUcllCiEboJnAcnQAXNPvcLFCst2gqrHJzd8OdAoS7dw4X4O57/t2jeQNdmdPEFdNeiiaxGSdg8sMI6CI6MBM1jgvmMbiz/8PbzU+5h5k3F1oPMKpqd9+XaHHWGVumlhI3Af89HsqRx/cPV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777583264; c=relaxed/simple; bh=DouYV3cwHePuFWweNW9bP7Q1lNZ6ouwNwSyn6KjSbOQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=g3qQTRWgstjC/NsDN0pB69jX7h582CP8zmRIEkMw7I+roY+zaesbF9mGVBYNjOl7jz0PXS8DRD2bBlJ7DGeiG6mFR2zlTkaecIvCY4Sv3mSfKMkN2/4NjF3MrDL5uaYtaUFgpbzhj9yuRBGtZO7QGJCPXX4jOvd+7svpowNsv4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=SUW3GDxE; arc=none smtp.client-ip=74.125.82.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="SUW3GDxE" Received: by mail-dy1-f173.google.com with SMTP id 5a478bee46e88-2c156c4a9efso2724793eec.1 for ; Thu, 30 Apr 2026 14:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1777583261; x=1778188061; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=UfJUJ6g+9z3UYoIeCIn2UEeSSxJoLa8pfn80kdiBpvU=; b=SUW3GDxE675gPeRQiF6nTO4Tj1tPCtS/n+2r8PTVcCHcc19V8ek7hK6Sujkw3NgADV D5p8od1F0m4scLqzH1yOijgse4sxl87mmKz2UNHVYmKHTRCf3O+4ZgnpNa1SmW6x4kNK KzhUsvoBVy+LLd8u6m8RZ1n+eg4d/6dW6DVVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777583261; x=1778188061; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UfJUJ6g+9z3UYoIeCIn2UEeSSxJoLa8pfn80kdiBpvU=; b=ofenWV5jFeWz7T0plI6ZxvfUTsd2S8YfSAq5OaNaoVAY90JAfBq6x5233bhJVXgMzt 2lTkJxo7SLJ7BzazwCoaVPF8wtGUkMEjbbWy2jC9nJG3cURSlAqGG4QMDpGNLxVNOR9r lVEswjq9C0f1QQrVf47O5BBmoyjJzcohyS5DVzcSbI9Nz6arJ4jW5aPjo6Lrpu2oJIG0 RzniOxneLqPs/w8kK0cO/4yXXOI9xzxLJFIMJiaNu6FweR3Sq93oJ1czDs7yBJGq6+xc 5sif/4CLApE/3f0GrL5b8ZN8R3BDvj05wXxjAhwfiLAHX9R1EMNaJIRieWzHQa8PGCug 1MKw== X-Forwarded-Encrypted: i=1; AFNElJ8D2NILEq4qJCG+dFmcqsDv6hDjRd0FMCxMHfcsolO/iY258sMu+htE6xGgRzjmTuEulbPEYmOdnMntxxw=@vger.kernel.org X-Gm-Message-State: AOJu0Yza8UMoehpMEaPofUk5DO8VHD8y1ONlVmF2lvg7otyJY9gYlU72 I3xomy4vDIMNUKb9R30p7REOn8gCsh2X2sPKbwed4Gn26gkBI0XGIZc+9M3qhA40mQ== X-Gm-Gg: AeBDieve1vY1B80QcE8rOVlQwXjmFuSa5bzSrrdKzwpG7Df2wxLrk3Rpm0gY+HrVBGx gBbSY1EOmiVGXfTJRoPPE7KVTE8eNZ2bHlt0s8boA/wam0Sa7W1jDiip1IZcXGLOyGrt1bGwvGc /EjX5CtJUbYc9eoh4n+XlErI6MkYxi1RMYOp2+Ck5oUKcFfInsp6QDee5S0IsxFaulnPAgkXaOC +QmseT1c/kKU2oldgM7MWYyt8LYa7yPV7gNHrqL6AGINost3T9LI1lg+NOQGZG36XkEWUSyCbKE UrXqJ/0M/Qntg1p7E+HRaG7TxDkV8LFNq9BWFxg0ZBsk1kTnaxEEW8d2caM2N96LO0d2wJkKQPO OHiMkjNnTK8KqoFAJGAqbOEpIJrrOn2u2jEjIoXsqhu5nb2NAJzvZ9HXICOGm28n/w7iq5/ywWZ 3b/UUno9jl6nf5JOyy54EaIWto83iSv/jU1Xq352jfVlkCdA2d2Zzq7MmFxbt73y8Cot7BhRth X-Received: by 2002:a05:7301:388a:b0:2d8:8c38:8cec with SMTP id 5a478bee46e88-2ed3bdf9adcmr2094063eec.2.1777583260697; Thu, 30 Apr 2026 14:07:40 -0700 (PDT) Received: from localhost ([2a00:79e0:2e7c:8:5c94:298e:dc77:f6a4]) by smtp.gmail.com with UTF8SMTPSA id 5a478bee46e88-2ee3bc6a79esm1930197eec.26.2026.04.30.14.07.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Apr 2026 14:07:39 -0700 (PDT) Date: Thu, 30 Apr 2026 14:07:38 -0700 From: Brian Norris To: Titouan Ameline de Cadeville Cc: jwerner@chromium.org, tzungbi@kernel.org, chrome-platform@lists.linuxfoundation.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] coreboot_table: skip failing entries instead of aborting populate Message-ID: References: <20260430202305.121680-1-titouan.ameline@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: <20260430202305.121680-1-titouan.ameline@gmail.com> On Thu, Apr 30, 2026 at 10:23:05PM +0200, Titouan Ameline de Cadeville wrote: > coreboot_table_populate() registers devices one by one. If > device_register() fails for one entry, the current code returns > immediately, leaving previously registered devices orphaned on the > coreboot bus with no cleanup path. > > Since coreboot table entries are independent of each other, a failure > on one entry should not prevent the others from being registered. > This mirrors the strategy used by of_platform_populate(), which skips > individual failures rather than aborting. > > Log a warning and continue the loop on device_register() failure. > > Signed-off-by: Titouan Ameline de Cadeville > --- > v2: continue the loop on failure instead of unregistering all devices > (suggested by Julius Werner, with reference to of_platform_populate() > from Brian Norris) > > drivers/firmware/google/coreboot_table.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/firmware/google/coreboot_table.c b/drivers/firmware/google/coreboot_table.c > index c769631ea15d..82be21434be4 100644 > --- a/drivers/firmware/google/coreboot_table.c > +++ b/drivers/firmware/google/coreboot_table.c > @@ -150,8 +150,9 @@ static int coreboot_table_populate(struct device *dev, void *ptr) > > ret = device_register(&device->dev); > if (ret) { > + dev_warn(dev, "failed to register coreboot device: %d\n", ret); > put_device(&device->dev); > - return ret; > + continue; > } > > ptr_entry += entry->size; Isn't it important to still increment ptr_entry on failure/continue? Otherwise, you may re-populate a new device with the same contents, and you may not actually register all devices. (You'll be off-by-1, at least.) To fix this, you could either drop the 'continue' (let it fall through) or else move this line up. Brian > -- > 2.44.2 >