All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
	Richard Weinberger <richard@nod.at>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Paul Cercueil <paul@crapouillou.net>,
	Harvey Hunt <harveyhuntnexus@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v3 2/2] mtd: rawnand: ingenic: Limit MTD_NAND_JZ4780 to architecture only
Date: Mon, 3 Aug 2020 10:36:48 +0200	[thread overview]
Message-ID: <20200803103648.17273c10@xps13> (raw)
In-Reply-To: <CAK8P3a3zM4M2y1shVnUYCArZxxf9FHbOkVCK0yAK8wbfQTVChg@mail.gmail.com>

Hello,

Arnd Bergmann <arnd@arndb.de> wrote on Mon, 27 Jul 2020 19:28:48 +0200:

> On Mon, Jul 27, 2020 at 7:03 PM Krzysztof Kozlowski <krzk@kernel.org> 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')?

Thanks,
Miquèl

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
	Paul Cercueil <paul@crapouillou.net>,
	Harvey Hunt <harveyhuntnexus@gmail.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH v3 2/2] mtd: rawnand: ingenic: Limit MTD_NAND_JZ4780 to architecture only
Date: Mon, 3 Aug 2020 10:36:48 +0200	[thread overview]
Message-ID: <20200803103648.17273c10@xps13> (raw)
In-Reply-To: <CAK8P3a3zM4M2y1shVnUYCArZxxf9FHbOkVCK0yAK8wbfQTVChg@mail.gmail.com>

Hello,

Arnd Bergmann <arnd@arndb.de> wrote on Mon, 27 Jul 2020 19:28:48 +0200:

> On Mon, Jul 27, 2020 at 7:03 PM Krzysztof Kozlowski <krzk@kernel.org> 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')?

Thanks,
Miquèl

  reply	other threads:[~2020-08-03  8:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24 14:53 [PATCH v3 0/2] mips: jz4780: Kconfig cleanup Krzysztof Kozlowski
2020-07-24 14:53 ` Krzysztof Kozlowski
2020-07-24 14:54 ` [PATCH v3 1/2] memory: jz4780-nemc: Limit dependency and compile testing to Ingenic architecture only Krzysztof Kozlowski
2020-07-24 14:54   ` Krzysztof Kozlowski
2020-07-24 14:54 ` [PATCH v3 2/2] mtd: rawnand: ingenic: Limit MTD_NAND_JZ4780 to " Krzysztof Kozlowski
2020-07-24 14:54   ` Krzysztof Kozlowski
2020-07-24 15:19   ` Paul Cercueil
2020-07-24 15:19     ` Paul Cercueil
2020-07-24 15:33     ` Krzysztof Kozlowski
2020-07-24 15:33       ` Krzysztof Kozlowski
2020-07-24 15:50       ` Paul Cercueil
2020-07-24 15:50         ` Paul Cercueil
2020-07-24 15:54         ` Krzysztof Kozlowski
2020-07-24 15:54           ` Krzysztof Kozlowski
2020-07-25 12:17           ` Paul Cercueil
2020-07-25 12:17             ` Paul Cercueil
2020-07-25 18:30             ` Arnd Bergmann
2020-07-25 18:30               ` Arnd Bergmann
2020-07-26 16:06               ` Paul Cercueil
2020-07-26 16:06                 ` Paul Cercueil
2020-07-26 16:06               ` Krzysztof Kozlowski
2020-07-26 16:06                 ` Krzysztof Kozlowski
2020-07-26 16:12                 ` Paul Cercueil
2020-07-26 16:12                   ` Paul Cercueil
2020-07-26 16:15                   ` Krzysztof Kozlowski
2020-07-26 16:15                     ` Krzysztof Kozlowski
2020-07-26 16:20                     ` Paul Cercueil
2020-07-26 16:20                       ` Paul Cercueil
2020-07-27  7:55                       ` Arnd Bergmann
2020-07-27  7:55                         ` Arnd Bergmann
2020-07-27 17:03                         ` Krzysztof Kozlowski
2020-07-27 17:03                           ` Krzysztof Kozlowski
2020-07-27 17:12                           ` Paul Cercueil
2020-07-27 17:12                             ` Paul Cercueil
2020-07-27 17:28                           ` Arnd Bergmann
2020-07-27 17:28                             ` Arnd Bergmann
2020-08-03  8:36                             ` Miquel Raynal [this message]
2020-08-03  8:36                               ` Miquel Raynal
2020-08-03  8:39                               ` Krzysztof Kozlowski
2020-08-03  8:39                                 ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200803103648.17273c10@xps13 \
    --to=miquel.raynal@bootlin.com \
    --cc=arnd@arndb.de \
    --cc=harveyhuntnexus@gmail.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=paul@crapouillou.net \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.