From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53960C433E0 for ; Mon, 3 Aug 2020 08:40:21 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1FE5020672 for ; Mon, 3 Aug 2020 08:40:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ktDZ0rBx"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="cmjHGTIT" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1FE5020672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=w5JwLpBGIedW++7pbQU9Y3pX0wqnKyoFGSWL5umu5NU=; b=ktDZ0rBxvm2voIb+NTcIyvLqn ptEM/Wjj00gr0Mx4sItl43caZ2C8CqASMEaqU5PTMpVfAGnp26GWka7sZzU4CTMvYXKH/cjQmvyWn MjX+0kMLaLrmV42TyLkuq6N+unud6J+/MgZkrSUeYnHASvVGZRE20N7hy6vnm/36qx7uNgcFGkGHH RyixmxQgJqzLEvmw6JmydKzL7Lo/CBB2aHQ1R8KMcBMXpjG90tw9+i9S7lD5hhkLuIDELUlQjsJ2z C0knBSBgKpJRwzENoANOmCvwkXWx53NMt0ecS488X5WfawJOgE1v5CRF5qrP4auXD5Tr7F9CZrglg ZN1gYSfIA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2W0X-0001dZ-69; Mon, 03 Aug 2020 08:39:45 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k2W0T-0001ct-HT for linux-mtd@lists.infradead.org; Mon, 03 Aug 2020 08:39:42 +0000 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 19C7520719 for ; Mon, 3 Aug 2020 08:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596443979; bh=+w5zCqoN1RmKfzxyGhYb1oNkZP3P3KWt7Fjgfgt3Xng=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=cmjHGTITEeHZo/uDJf7BvmxqLE4JfIpnSS89mkZVd9cQSy+Mt/XrtZNjBSdxgUc7o Vq/RFmthPcuHNp+hcCGbNgZIUiIwVN0ztJcUM6YmJQtk3HhTGROdzvptcUKGwo/Xrw /hRRIJUdbBtPsXz4R8yKxL3rsWhGCyQU8cSZ6JuY= Received: by mail-lj1-f176.google.com with SMTP id g6so26101015ljn.11 for ; Mon, 03 Aug 2020 01:39:39 -0700 (PDT) X-Gm-Message-State: AOAM533B1Duxf+5ptoo/xA6XPQpTz6tnmgSlgoLaDJtXvksPk8LIZu6S 1RsMAj0wg4cC/Ce/ctZaqAtA2HrvANGOeeLAP8M= X-Google-Smtp-Source: ABdhPJxZ/8tSlY3D85xhv5bs91wHng9qol3ObhbPPyjjrcGtC8wf4WJQZjOLxNhfR2d7EuzEod+aWwsAPEAlLD+CfOE= X-Received: by 2002:a2e:85d1:: with SMTP id h17mr5374040ljj.341.1596443978086; Mon, 03 Aug 2020 01:39:38 -0700 (PDT) MIME-Version: 1.0 References: <20200724155436.GA7460@kozik-lap> <20200726160616.GA2662@kozik-lap> <20200726161545.GA6058@kozik-lap> <20200727170302.GA3507@kozik-lap> <20200803103648.17273c10@xps13> In-Reply-To: <20200803103648.17273c10@xps13> From: Krzysztof Kozlowski Date: Mon, 3 Aug 2020 10:39:26 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 2/2] mtd: rawnand: ingenic: Limit MTD_NAND_JZ4780 to architecture only To: Miquel Raynal X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200803_043941_745459_D2238F59 X-CRM114-Status: GOOD ( 27.18 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vignesh Raghavendra , Arnd Bergmann , Richard Weinberger , "linux-kernel@vger.kernel.org" , Paul Cercueil , Harvey Hunt , linux-mtd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org On Mon, 3 Aug 2020 at 10:36, Miquel Raynal wrote: > > Hello, > > Arnd Bergmann wrote on Mon, 27 Jul 2020 19:28:48 +0200: > > > On Mon, Jul 27, 2020 at 7:03 PM Krzysztof Kozlowski wrote: > > > On Mon, Jul 27, 2020 at 09:55:54AM +0200, Arnd Bergmann wrote: > > > > > > > > The way we do it on Arm, the machine Kconfig identifiers stay around > > > > even for multiplatform targets (which now make up basically actively > > > > maintained machines). > > > > > > > > I don't think it makes any sense for a driver to depend on MIPS_GENERIC: > > > > either it is a generic driver that should always be visible or it is specific > > > > to a set of SoCs and should depend on some corresponding vendor > > > > specific identifiers. > > > > > > If support for Ingenic is provided also by MIPS_GENERIC (without > > > selecting MACH_INGENIC), then it makes sense. This would be just a > > > different way than ARM of building multi-platform kernel. > > > > Yes, it would work just as well, my point was just that it is somewhat > > confusing to have every architecture do it differently, and that I > > prefer the way Arm (and also ppc, x86 etc) handles it today. > > > > On MIPS, most platforms are not yet part of MIPS_GENERIC, so > > they are fairly free to pick whatever method works best and is > > consistent with the rest of the kernel. > > In the end, shall I apply Krzysztof patch or shall I wait for an update > (eg. without 'default y')? No, this patch should be dropped as we decided to leave it as is. At least that was my understanding. The other similar changes - relating to memory driver - were already applied: https://lore.kernel.org/lkml/20200728104503.23655-2-krzk@kernel.org/ Best regards, Krzysztof ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/