Message ID | 20231115165915.2936349-1-brgl@bgdev.pl |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp2672453vqg; Wed, 15 Nov 2023 08:59:29 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsjOoowen/UpycXEXzejk32r3nlLpUBFDJjOQRbYR8nZRG071C2iIzRWlTE95u+x0n0+Fe X-Received: by 2002:a17:90b:1b09:b0:268:808:8e82 with SMTP id nu9-20020a17090b1b0900b0026808088e82mr9031596pjb.1.1700067569365; Wed, 15 Nov 2023 08:59:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700067569; cv=none; d=google.com; s=arc-20160816; b=REOIEUKNKczOkJHnz7aELHn5MRAqnKx4sWz25n3TPRvOLuh5PxInlkdrTT76b5Bb1p Il2L46VHgmGOYdhCp+Nbx2W5wt0tN6eNiUvsPPXfrC8lQqhg6vUlDkvIfOyIycr8lzjG VWPIRdz8K7JXpYBDfHNkinWgwQski5HuA7BbNmqws63RSDr1yCpG0qN2+9DpIV4EJexG tBf99xBwQsZAA6PmJTr3ArwBws7As8fD84v2PetgMXMfrJekCT19dodj9mbkJrgx+voB GiQh8/9REPLE7cN/T7eF2VsYOJl+f1mC62h11EDXtlSlTXzh3Og5FT0lx2cirxgPiKwu 3+DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=XNv5c7iU2hI6ghC00LRA79XwFr7LnW8ceDW1TiDNSy0=; fh=El7U+Cg75FrEsqBKE0pb+XSRaZD7UUWlPElNZyAnAj8=; b=BFNUtM2Q1HSeHmfsxD+LLWvYzc6OBf/JUSXhBFBrWVJCjxJJGRXDaYZ9JgG6ByZbT3 jCVWthjdREShmiCYA5F2yG3q92Gld3dKncwumRTPS3n3gsVOuWoCyvsEsnPAaed80IPW gQoZHrDkRQ/zZizwBQtNiSm+AAIJ3kSQIIORNY2HpO9rQP1d7WGazftkL8CMmSV9uzql SczNdTeW+ZCjRmhJ/N31xflX79Vovx8w3w7gsT2DoK6K8JWHKgXlR9rDXw3PhGzaRsYB wg4fD8FpfsRVc8f69YMfWdDDdEN29yOMRiFWbu3xv9g052kwML4H/RgovCLPDadNx+uc bnwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=pZMEMauy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id pt10-20020a17090b3d0a00b0027ffe9d16b8si140258pjb.1.2023.11.15.08.59.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 08:59:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@bgdev-pl.20230601.gappssmtp.com header.s=20230601 header.b=pZMEMauy; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 8D3D48216935; Wed, 15 Nov 2023 08:59:28 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232210AbjKOQ72 (ORCPT <rfc822;lhua1029@gmail.com> + 29 others); Wed, 15 Nov 2023 11:59:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229497AbjKOQ71 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Nov 2023 11:59:27 -0500 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B72318D for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 08:59:24 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-77bac408851so90961585a.1 for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 08:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1700067563; x=1700672363; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=XNv5c7iU2hI6ghC00LRA79XwFr7LnW8ceDW1TiDNSy0=; b=pZMEMauyBQev6kw2y3HygaW++nXr1Wg5OK7I9eIa74p059UUSMsnK4g3hHjEwwtDdh oK9Evz+D7rorv81RhJ+dCIMZ2qW7aqdmILba8rlTertIA8VtJdD7n0vBoWWcAzPdNC4n 58A8CBe5AqNCj0GPXQljYLH2xGOmWgjzrwGFkee4Y0hv2Fac7gfFeh2EkhFgcp3tHpKL jvL8CILAffDLcRlieMXw0CLSdNQlDZ4PpCkGUlrT7PFOttVSgA3GEFm6sHs0GMSZ9SqI DE7uJB9X6xBvCQIcWMUodVXe/Rriu5Rpb8xrkES7mNSEdvXlzm/M0Li0YMimQm0o/XoF TneQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700067563; x=1700672363; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XNv5c7iU2hI6ghC00LRA79XwFr7LnW8ceDW1TiDNSy0=; b=ak8+gDLeFEZGQ2a7n63k0Hhc+wFTjATqUYu24N5rz2rjXDhfZWhtVY+4KyEiLX1Fyu bc2LZJejFX+zYkTzHH/p6fdwnfkBnhnWzZLi5aL/pYCuUvF9lC+JxbNP3UtcsdnTxdUm iN/+oosFPyBvviFqV7C/+dX2SbnCTU7snow5BCW/uRbOY5ucRQEEnBMh4eUYIR9WaAjE y8lKKMLvI7czsn66qxyAom0nZtTCFhb3dU/ZtBMEaQ82RNt13iRXFxD+145AuibLAJVZ 4JIDzNXnIjDa4hKSR0xp36C9rkKfWXg2dQP4ttgXTB/9/Xn5B2VuOU6uBVcK7oUuiAx9 PuMw== X-Gm-Message-State: AOJu0Yzi7hhpa9n5XPmOVnXURjWppKLRLqRaxOzbtyX5S71T5kyVCeeg f9u6GJBc/+0TOyySi2ymdPjOpBgzXt8tFHOKCPxMWQ== X-Received: by 2002:a05:620a:304:b0:778:8f26:6846 with SMTP id s4-20020a05620a030400b007788f266846mr7192148qkm.37.1700067563410; Wed, 15 Nov 2023 08:59:23 -0800 (PST) Received: from brgl-uxlite.. ([12.186.190.2]) by smtp.gmail.com with ESMTPSA id x19-20020a05620a449300b0077772296f9dsm3572219qkp.126.2023.11.15.08.59.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 08:59:23 -0800 (PST) From: Bartosz Golaszewski <brgl@bgdev.pl> To: Yury Norov <yury.norov@gmail.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Thomas Gleixner <tglx@linutronix.de>, Marc Zyngier <marc.zyngier@arm.com>, Peter Zijlstra <peterz@infradead.org> Cc: linux-kernel@vger.kernel.org, Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Subject: [RESEND PATCH v2 0/4] genirq/irq_sim: misc updates Date: Wed, 15 Nov 2023 17:59:11 +0100 Message-Id: <20231115165915.2936349-1-brgl@bgdev.pl> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Wed, 15 Nov 2023 08:59:28 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782650051679724463 X-GMAIL-MSGID: 1782650051679724463 |
Series |
genirq/irq_sim: misc updates
|
|
Message
Bartosz Golaszewski
Nov. 15, 2023, 4:59 p.m. UTC
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Here are a couple of updates to the interrupt simulator. Two are minor:
remove an unused field and reorder includes for readability. The third
one simplifies the error paths by using new cleanup macros. To that end
we also add a cleanup definition for dynamic bitmaps.
Resending rebased on top of v6.7-rc1 and with tags collected.
v1 -> v2:
- add a NULL-pointer check to the bitmap cleanup macro as advised by
Peter Zijlstra
- initialize managed pointers when declaring them to create a clear pairing
between the type and the cleanup action
Bartosz Golaszewski (4):
bitmap: define a cleanup function for bitmaps
genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx
genirq/irq_sim: order headers alphabetically
genirq/irq_sim: shrink code by using cleanup helpers
include/linux/bitmap.h | 3 +++
kernel/irq/irq_sim.c | 30 ++++++++++++------------------
2 files changed, 15 insertions(+), 18 deletions(-)
Comments
On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Here are a couple of updates to the interrupt simulator. Two are minor: > remove an unused field and reorder includes for readability. The third > one simplifies the error paths by using new cleanup macros. To that end > we also add a cleanup definition for dynamic bitmaps. > > Resending rebased on top of v6.7-rc1 and with tags collected. > > v1 -> v2: > - add a NULL-pointer check to the bitmap cleanup macro as advised by > Peter Zijlstra > - initialize managed pointers when declaring them to create a clear pairing > between the type and the cleanup action > > Bartosz Golaszewski (4): > bitmap: define a cleanup function for bitmaps > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > genirq/irq_sim: order headers alphabetically > genirq/irq_sim: shrink code by using cleanup helpers > > include/linux/bitmap.h | 3 +++ > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > 2 files changed, 15 insertions(+), 18 deletions(-) > > -- > 2.40.1 > It's been two weeks since this submission and ~2.5 months since the first one so I guess, a gentle ping is in order. This is not a very controversial series - can this be applied? Bart
On Wed, Nov 29, 2023 at 10:18:15AM +0100, Bartosz Golaszewski wrote: > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > Here are a couple of updates to the interrupt simulator. Two are minor: > > remove an unused field and reorder includes for readability. The third > > one simplifies the error paths by using new cleanup macros. To that end > > we also add a cleanup definition for dynamic bitmaps. > > > > Resending rebased on top of v6.7-rc1 and with tags collected. > > > > v1 -> v2: > > - add a NULL-pointer check to the bitmap cleanup macro as advised by > > Peter Zijlstra > > - initialize managed pointers when declaring them to create a clear pairing > > between the type and the cleanup action > > > > Bartosz Golaszewski (4): > > bitmap: define a cleanup function for bitmaps > > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > > genirq/irq_sim: order headers alphabetically > > genirq/irq_sim: shrink code by using cleanup helpers > > > > include/linux/bitmap.h | 3 +++ > > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > > 2 files changed, 15 insertions(+), 18 deletions(-) > > > > -- > > 2.40.1 > > > > It's been two weeks since this submission and ~2.5 months since the > first one so I guess, a gentle ping is in order. This is not a very > controversial series - can this be applied? Hi Bartosz, I'm the first in the list for this series, but really only 1st patch is related to bitmaps, and I already acked it. If you prefer that, I can pull it in the bitmap tree. Thanks, Yury
On Wed, Nov 29, 2023 at 8:59 PM Yury Norov <yury.norov@gmail.com> wrote: > > On Wed, Nov 29, 2023 at 10:18:15AM +0100, Bartosz Golaszewski wrote: > > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > Here are a couple of updates to the interrupt simulator. Two are minor: > > > remove an unused field and reorder includes for readability. The third > > > one simplifies the error paths by using new cleanup macros. To that end > > > we also add a cleanup definition for dynamic bitmaps. > > > > > > Resending rebased on top of v6.7-rc1 and with tags collected. > > > > > > v1 -> v2: > > > - add a NULL-pointer check to the bitmap cleanup macro as advised by > > > Peter Zijlstra > > > - initialize managed pointers when declaring them to create a clear pairing > > > between the type and the cleanup action > > > > > > Bartosz Golaszewski (4): > > > bitmap: define a cleanup function for bitmaps > > > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > > > genirq/irq_sim: order headers alphabetically > > > genirq/irq_sim: shrink code by using cleanup helpers > > > > > > include/linux/bitmap.h | 3 +++ > > > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > > > 2 files changed, 15 insertions(+), 18 deletions(-) > > > > > > -- > > > 2.40.1 > > > > > > > It's been two weeks since this submission and ~2.5 months since the > > first one so I guess, a gentle ping is in order. This is not a very > > controversial series - can this be applied? > > Hi Bartosz, > > I'm the first in the list for this series, but really only 1st patch > is related to bitmaps, and I already acked it. If you prefer that, I > can pull it in the bitmap tree. > > Thanks, > Yury If there's a risk it will conflict then you can apply it and provide Thomas with an immutable branch against the irq tree, otherwise I think Thomas can pick up all the patches. Bartosz
On Wed, Nov 29, 2023 at 10:18 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > Here are a couple of updates to the interrupt simulator. Two are minor: > > remove an unused field and reorder includes for readability. The third > > one simplifies the error paths by using new cleanup macros. To that end > > we also add a cleanup definition for dynamic bitmaps. > > > > Resending rebased on top of v6.7-rc1 and with tags collected. > > > > v1 -> v2: > > - add a NULL-pointer check to the bitmap cleanup macro as advised by > > Peter Zijlstra > > - initialize managed pointers when declaring them to create a clear pairing > > between the type and the cleanup action > > > > Bartosz Golaszewski (4): > > bitmap: define a cleanup function for bitmaps > > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > > genirq/irq_sim: order headers alphabetically > > genirq/irq_sim: shrink code by using cleanup helpers > > > > include/linux/bitmap.h | 3 +++ > > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > > 2 files changed, 15 insertions(+), 18 deletions(-) > > > > -- > > 2.40.1 > > > > It's been two weeks since this submission and ~2.5 months since the > first one so I guess, a gentle ping is in order. This is not a very > controversial series - can this be applied? > > Bart Another ping... Bartosz
On Mon, Dec 4, 2023 at 9:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Wed, Nov 29, 2023 at 10:18 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > Here are a couple of updates to the interrupt simulator. Two are minor: > > > remove an unused field and reorder includes for readability. The third > > > one simplifies the error paths by using new cleanup macros. To that end > > > we also add a cleanup definition for dynamic bitmaps. > > > > > > Resending rebased on top of v6.7-rc1 and with tags collected. > > > > > > v1 -> v2: > > > - add a NULL-pointer check to the bitmap cleanup macro as advised by > > > Peter Zijlstra > > > - initialize managed pointers when declaring them to create a clear pairing > > > between the type and the cleanup action > > > > > > Bartosz Golaszewski (4): > > > bitmap: define a cleanup function for bitmaps > > > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > > > genirq/irq_sim: order headers alphabetically > > > genirq/irq_sim: shrink code by using cleanup helpers > > > > > > include/linux/bitmap.h | 3 +++ > > > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > > > 2 files changed, 15 insertions(+), 18 deletions(-) > > > > > > -- > > > 2.40.1 > > > > > > > It's been two weeks since this submission and ~2.5 months since the > > first one so I guess, a gentle ping is in order. This is not a very > > controversial series - can this be applied? > > > > Bart > > Another ping... > > Bartosz Thomas, Is there any formal reason why this cannot be processed? Bartosz
On Mon, Dec 11, 2023 at 10:14 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Mon, Dec 4, 2023 at 9:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Nov 29, 2023 at 10:18 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > Here are a couple of updates to the interrupt simulator. Two are minor: > > > > remove an unused field and reorder includes for readability. The third > > > > one simplifies the error paths by using new cleanup macros. To that end > > > > we also add a cleanup definition for dynamic bitmaps. > > > > > > > > Resending rebased on top of v6.7-rc1 and with tags collected. > > > > > > > > v1 -> v2: > > > > - add a NULL-pointer check to the bitmap cleanup macro as advised by > > > > Peter Zijlstra > > > > - initialize managed pointers when declaring them to create a clear pairing > > > > between the type and the cleanup action > > > > > > > > Bartosz Golaszewski (4): > > > > bitmap: define a cleanup function for bitmaps > > > > genirq/irq_sim: remove unused field from struct irq_sim_irq_ctx > > > > genirq/irq_sim: order headers alphabetically > > > > genirq/irq_sim: shrink code by using cleanup helpers > > > > > > > > include/linux/bitmap.h | 3 +++ > > > > kernel/irq/irq_sim.c | 30 ++++++++++++------------------ > > > > 2 files changed, 15 insertions(+), 18 deletions(-) > > > > > > > > -- > > > > 2.40.1 > > > > > > > > > > It's been two weeks since this submission and ~2.5 months since the > > > first one so I guess, a gentle ping is in order. This is not a very > > > controversial series - can this be applied? > > > > > > Bart > > > > Another ping... > > > > Bartosz > > Thomas, > > Is there any formal reason why this cannot be processed? > > Bartosz Ping. Bartosz
On Tue, Dec 19, 2023 at 09:17:38PM +0100, Bartosz Golaszewski wrote: > On Mon, Dec 11, 2023 at 10:14 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > On Mon, Dec 4, 2023 at 9:47 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > On Wed, Nov 29, 2023 at 10:18 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > On Wed, Nov 15, 2023 at 5:59 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: ... > > > > It's been two weeks since this submission and ~2.5 months since the > > > > first one so I guess, a gentle ping is in order. This is not a very > > > > controversial series - can this be applied? > > > > > > Another ping... > > > > Is there any formal reason why this cannot be processed? > > Ping. Instead you can now just say that you are going to apply this via your tree, if there won't be objections, e.g., within a week (or two as it's a holiday season). In the PR to Linus you can explain why it's taken like this.