Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FA59C05027 for ; Tue, 14 Feb 2023 16:16:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230113AbjBNQP7 (ORCPT ); Tue, 14 Feb 2023 11:15:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58372 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229513AbjBNQP5 (ORCPT ); Tue, 14 Feb 2023 11:15:57 -0500 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F390EB6 for ; Tue, 14 Feb 2023 08:15:56 -0800 (PST) Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.96) (envelope-from ) id 1pRxyE-0005lS-0D; Tue, 14 Feb 2023 17:15:54 +0100 Date: Tue, 14 Feb 2023 16:15:50 +0000 From: Daniel Golle To: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Vignesh Raghavendra , Miquel Raynal , Richard Weinberger Subject: Re: [PATCH 0/2] ubi: wire up parent device Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! I've only recently noticed that this series is marked as 'Accepted' in patchwork. However, I fail to find the commits in any public linux tree, nor has patchwork sent the usual notification email informing me about it being accepted. Can it be that it has slipped under the table (or even the carpet) somehow? Please let me know if there is anything wrong with this series and/or if I should re-submit it, or if I shall just wait for it to surface in linux-mtd or linux-next. Thank you! Best regards Daniel On Thu, Dec 22, 2022 at 07:32:46PM +0000, Daniel Golle wrote: > Wire up device parents of UBI devices and ubiblock devices (UBI volume > devices are already correctly wired to their parent UBI device). This > makes more sense than having UBI devices free-standing in > /sys/devices/virtual/ubi/ without any connection to their parent MTD > device, and ubiblock devices in /sys/devices/virtual/block/ which would > be better hosted by the UBI volume device they belong to. > > The purpose of these changes is to allow downstream tools to more > easily identify UBI<->hardware relationship, and potentially also > improve power management and scheduling performance in future. > > Daniel Golle (2): > mtd: ubi: wire-up parent MTD device > mtd: ubi: block: wire-up device parent > > drivers/mtd/ubi/block.c | 2 +- > drivers/mtd/ubi/build.c | 1 + > drivers/mtd/ubi/kapi.c | 1 + > include/linux/mtd/ubi.h | 1 + > 4 files changed, 4 insertions(+), 1 deletion(-) > > > base-commit: e45fb347b630ee76482fe938ba76cf8eab811290 > -- > 2.39.0 > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/