Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp1194514rwb; Thu, 10 Nov 2022 12:33:04 -0800 (PST) X-Google-Smtp-Source: AMsMyM4D+HdvUsnGgxfJLq3894Od8/CzfoG0oxgc+BQA2VqNYkO658dQIU2agGODHwXTNQJyoOfb X-Received: by 2002:a63:d74b:0:b0:458:6f51:ff7b with SMTP id w11-20020a63d74b000000b004586f51ff7bmr3243122pgi.153.1668112383908; Thu, 10 Nov 2022 12:33:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668112383; cv=none; d=google.com; s=arc-20160816; b=SIS464iKrOIPV7yGE8VHohySqFBcKbogKSuXk9+g39Xli8wT5b4TCvBJoBPJyrVcPl aDsgr5qfc7WxtuoolGRjk1JyFRzrFN7j1ZKXwYQUGZbcLVuSSPr+C0wVua34AXR21L5j PzQAjLAVs+KH2bKFkOPWMaeLyxERhmTcdIM1O/t2fP0Z7vxufvapU9C6AsJ1uGUR0laC ZjUp6aUi7TDahDSUV/WbQL+uzvjymLXNs4rsJ8Yfj7z37evrXsukThVY7Ls+MJf8UPFx rqbgrTuSB7feP2J50t5VaueY3kWicQVufG+4/Zk9VecPtXdswjdH+Ava/4XUCGDA5CdM +TQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=4fFjC1FoShhuW1R9VE2UR5OMyrd6p73yM5KdDuieLcw=; b=gClBBpTCut1UccMFIxRaR81yrDWDe76h7GhYijFc/3NMFKdaHWIca5Et1mff1HJ9Ge MFdGHadWFp2cjWiTmgOHVhy5XmSafiWM8vhdtFKbvlq0ilM9Dfp/bBtGfMi0ZI3IzgT2 Zk2fgMD1dSKVs23yWxO+epcE1ufGcnZY1anKnn1sayfhQNE0pqgyZFeMBESrjJ1/tgMG jog8ZASArsDc6W6BDkw6OJKQMBhhiCmUFSSJYXLVjLH5tEU/64G9pGpgDg8XBJsxmrT/ 3SVjJinbklTvaDjtkDiffMIX3da7XSVZbuNC4hAom9mwBPsrox+Qsx4pStCLFN7mnvCk 4/8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a12-20020a63d40c000000b0046fb03051d1si175520pgh.296.2022.11.10.12.32.44; Thu, 10 Nov 2022 12:33:03 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231401AbiKJUFM (ORCPT + 93 others); Thu, 10 Nov 2022 15:05:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230407AbiKJUFL (ORCPT ); Thu, 10 Nov 2022 15:05:11 -0500 Received: from fudo.makrotopia.org (fudo.makrotopia.org [IPv6:2a07:2ec0:3002::71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C6CD2C65C; Thu, 10 Nov 2022 12:05:10 -0800 (PST) Received: from local by fudo.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.94.2) (envelope-from ) id 1otDn6-0005Xu-LQ; Thu, 10 Nov 2022 21:04:48 +0100 Date: Thu, 10 Nov 2022 20:04:45 +0000 From: Daniel Golle To: Richard Weinberger Cc: Jens Axboe , Miquel Raynal , Vignesh Raghavendra , Davidlohr Bueso , Matthew Wilcox , "Martin K. Petersen" , Chaitanya Kulkarni , Ming Lei , linux-block , linux-kernel , linux-mtd , linux-efi Subject: Re: [PATCH v4 4/5] mtd_blkdevs: add option to enable scanning for partitions Message-ID: References: <1691046252.219046.1668109493753.JavaMail.zimbra@nod.at> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1691046252.219046.1668109493753.JavaMail.zimbra@nod.at> X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD, SPF_HELO_NONE,SPF_PASS autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 10, 2022 at 08:44:53PM +0100, Richard Weinberger wrote: > ----- Urspr?ngliche Mail ----- > > Von: "Daniel Golle" > > + > > + if (!IS_ENABLED(CONFIG_MTD_BLOCK_PARTITIONS) || mtd_type_is_nand(new->mtd)) > > + gd->flags |= GENHD_FL_NO_PART; > > I know that NAND should not get used with mtdblock because lack of wearleveling and > in general too many writes. But what exactly is the rationale to deny part scanning for NAND? As UBI should be used on NAND, partition scanning should be enabled for ubiblock devices to have uImage.FIT filesystem subimages mapped by the partition parser. If not skipping partition scanning on NAND-backed mtdblock devices the scanning itself will already trigger multiple warnings which now happen every time when a NAND-backed mtdblock device is being opened since commit 96a3295c ("mtdblock: warn if opened on NAND").