From: Krzysztof Kozlowski <krzk@kernel.org>
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>,
Paul Cercueil <paul@crapouillou.net>,
Harvey Hunt <harveyhuntnexus@gmail.com>,
linux-mtd <linux-mtd@lists.infradead.org>,
Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: [PATCH v3 2/2] mtd: rawnand: ingenic: Limit MTD_NAND_JZ4780 to architecture only
Date: Mon, 27 Jul 2020 19:03:02 +0200 [thread overview]
Message-ID: <20200727170302.GA3507@kozik-lap> (raw)
In-Reply-To: <CAK8P3a1r6AMz2wKBEosAqn7qkuJY4LGFYK7o85sO++d+TSVOgQ@mail.gmail.com>
On Mon, Jul 27, 2020 at 09:55:54AM +0200, Arnd Bergmann wrote:
> On Sun, Jul 26, 2020 at 6:20 PM Paul Cercueil <paul@crapouillou.net> wrote:
> > Le dim. 26 juil. 2020 à 18:15, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
> > > On Sun, Jul 26, 2020 at 06:12:27PM +0200, Paul Cercueil wrote:
> > >> Le dim. 26 juil. 2020 à 18:06, Krzysztof Kozlowski <krzk@kernel.org> a écrit
> >
> > > OK, that's true. Anyway, I don't have strong opinion on any of this. I
> > > just followed Arnd's hint.
> > >
> > > For the memory driver (and MTD NAND as well) which one you prefer:
> > > 1. https://lore.kernel.org/lkml/20200724074038.5597-6-krzk@kernel.org/
> > > 2. depends on MACH_INGENIC || MIPS_GENERIC || COMPILE_TEST
> > >
> > > ?
> >
> > I'd say a slightly modified #1. The driver shouldn't be "default y" in
> > the first place, so the patch could be to disable it by default.
>
> If it defaults to 'n' even for MACH_INGENIC, you may have to enable
> it in the four defconfig files for these machines to avoid surprises.
Exactly. Nothing else selects JZ4780_NEMC, so either we keep default y
("if MACH_INGENIC || MIPS_GENERIC"), or you select it directly from
MACH_INGENIC/MIPS_GENERIC.
A related question is how essential are these drivers? At least for ARM
platforms, all essential SoC blocks/IPs are selected by default, if
support for chosen SoC is enabled. Only non-essential stuff is left,
e.g. DRM, cpufreq, devfreq, ADC, crypto, video, USB, eMMC (although one
could argue that it is essential), IOMMU.
> > And when the Ingenic code is merged into the MIPS generic framework, I'll
> > send a set of patches to change all driver dependencies on MIPS to
> > MIPS_GENERIC.
>
> 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.
Best regards,
Krzysztof
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Cercueil <paul@crapouillou.net>,
Harvey Hunt <harveyhuntnexus@gmail.com>,
Miquel Raynal <miquel.raynal@bootlin.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, 27 Jul 2020 19:03:02 +0200 [thread overview]
Message-ID: <20200727170302.GA3507@kozik-lap> (raw)
In-Reply-To: <CAK8P3a1r6AMz2wKBEosAqn7qkuJY4LGFYK7o85sO++d+TSVOgQ@mail.gmail.com>
On Mon, Jul 27, 2020 at 09:55:54AM +0200, Arnd Bergmann wrote:
> On Sun, Jul 26, 2020 at 6:20 PM Paul Cercueil <paul@crapouillou.net> wrote:
> > Le dim. 26 juil. 2020 à 18:15, Krzysztof Kozlowski <krzk@kernel.org> a écrit :
> > > On Sun, Jul 26, 2020 at 06:12:27PM +0200, Paul Cercueil wrote:
> > >> Le dim. 26 juil. 2020 à 18:06, Krzysztof Kozlowski <krzk@kernel.org> a écrit
> >
> > > OK, that's true. Anyway, I don't have strong opinion on any of this. I
> > > just followed Arnd's hint.
> > >
> > > For the memory driver (and MTD NAND as well) which one you prefer:
> > > 1. https://lore.kernel.org/lkml/20200724074038.5597-6-krzk@kernel.org/
> > > 2. depends on MACH_INGENIC || MIPS_GENERIC || COMPILE_TEST
> > >
> > > ?
> >
> > I'd say a slightly modified #1. The driver shouldn't be "default y" in
> > the first place, so the patch could be to disable it by default.
>
> If it defaults to 'n' even for MACH_INGENIC, you may have to enable
> it in the four defconfig files for these machines to avoid surprises.
Exactly. Nothing else selects JZ4780_NEMC, so either we keep default y
("if MACH_INGENIC || MIPS_GENERIC"), or you select it directly from
MACH_INGENIC/MIPS_GENERIC.
A related question is how essential are these drivers? At least for ARM
platforms, all essential SoC blocks/IPs are selected by default, if
support for chosen SoC is enabled. Only non-essential stuff is left,
e.g. DRM, cpufreq, devfreq, ADC, crypto, video, USB, eMMC (although one
could argue that it is essential), IOMMU.
> > And when the Ingenic code is merged into the MIPS generic framework, I'll
> > send a set of patches to change all driver dependencies on MIPS to
> > MIPS_GENERIC.
>
> 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.
Best regards,
Krzysztof
next prev parent reply other threads:[~2020-07-27 17:04 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 [this message]
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
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=20200727170302.GA3507@kozik-lap \
--to=krzk@kernel.org \
--cc=arnd@arndb.de \
--cc=harveyhuntnexus@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--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.