Re: Hilscher NetX mach-netx refactorings

[Arnd Bergmann <arnd@arndb.de>]

On Tue, Jan 15, 2019 at 8:05 AM Michael Trensch <MTrensch@hilscher.com> 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.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel