Linux-ARM-Kernel Archive on
 help / color / Atom feed
From: Arnd Bergmann <>
To: Michael Trensch <>
Cc: Ladislav Michl <>,
	Linus Walleij <>,,
	Pengutronix Kernel Team <>,
	Olof Johansson <>,
	Robert Schwebel <>,
	Linux ARM <>
Subject: Re: Hilscher NetX mach-netx refactorings
Date: Tue, 15 Jan 2019 11:11:00 +0100
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jan 15, 2019 at 8:05 AM Michael Trensch <> wrote:
> On 14.01.2019 15:22, Linus Walleij wrote:
> > So a pressing question is whether it is OK with Hilscher that we
> > decomission/delete the current support code for NetX
> > nxdkn, nxdb500 and nxeb500hmi? Or are these products that
> > still see active deployment (new designs) and maintenance
> > in the long term (5-10 years from now)?
> >
> It's ok from Hilscher side. I've talked to our CEO and he is fine with
> dropping it. Those boards are not produced anymore and our new Asics
> (e.g. netX4000 and upcoming) will replace netX100/500 in the long term.
> Our Asics usually have a guaranteed lifecycle of 10 years and netX100
> has been around since 2006, if I remember correctly, so we don't expect
> many new linux projects arising, with the need for the newest kernel.
> Old kernel version will still be working though.

I think we also need to consider any existing installations here that
have already deployed hardware but do require kernel upgrades in
the future, e.g. when systems are connected to public networks
and may be vulnerable to attacks.

I would assume that the 10 year lifecycle is for deploying boards into
the field, not the time that you expect your customers to stop using
the hardware, right?

Some of the SoCs that we support in mainline Linux have been EOLed
by their manufacturers many years ago, but are still deployed in
large numbers and get kernel updates through projects like OpenWRT
or through companies like Pengutronix or Bootlin working directly with
companies using them.

> > OK! But when you have time and resources, please consider to
> > work with the kernel community to get the board support upstream.
> >
> We want to work with the community now and in the future, but for
> netX4000 we first needed to get this SoC working. It took many
> development cycles to get all implementation working and now it seems to
> have settled so we can think about step two. netX4000 Final (with all
> required changes) was released end of last year.
> Main problem would have been the continuous change of the Asic during
> development and more or less constant changes to kernel sources. I think
> this would have caused some laughing on the mailing list if we submit a
> patch one day and do it the complete other way round with the next
> (possibly non-public) stepping of the Asic.

Not at all, in fact our preferred way to operate is to work with hardware
companies as early as possible. We definitely merge drivers for
pre-production SoCs that can end up getting rewritten or even dropped
completely within a short time if it turns out the hardware gets changed
again or never gets sold for reasons that are not our concern.

I usually suggest submitting drivers as soon as you have cleared
any nontechnical obstacles (e.g. unannounced product features)
and have code that looks maintainable, even if you have remaining
bugs and missing features.

Since SoC support is now split into many independent drivers, you
can upstream each driver at its own pace, with the goal of reducing
the number of patches you keep in your own tree compared to
mainline. The ideal case is that all features work in a mainline
kernel on the day that the first hardware gets into your customers'
hands, though more commonly there will be a set of patches that
take a bit longer.


linux-arm-kernel mailing list

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-12  8:35 Linus Walleij
2019-01-12 12:03 ` Arnd Bergmann
2019-01-13 12:14   ` Linus Walleij
2019-01-13 15:50     ` Ladislav Michl
2019-01-13 22:39       ` Linus Walleij
2019-01-14 11:26     ` Michael Trensch
2019-01-14 14:22       ` Linus Walleij
2019-01-15  7:05         ` Michael Trensch
2019-01-15 10:11           ` Arnd Bergmann [this message]
2019-01-15 10:14         ` Arnd Bergmann
2019-01-14 10:35 ` Sascha Hauer

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-ARM-Kernel Archive on

Archives are clonable:
	git clone --mirror linux-arm-kernel/git/0.git
	git clone --mirror linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ \
	public-inbox-index linux-arm-kernel

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox