mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: Alex Shi <alex.shi@linaro.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	stable@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/29] arm meltdown fix backporting review for lts 4.9
Date: Mon, 5 Mar 2018 12:46:38 +0000	[thread overview]
Message-ID: <20180305124638.GG8588@sirena.org.uk> (raw)
In-Reply-To: <20180302165415.GB8704@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2455 bytes --]

On Fri, Mar 02, 2018 at 05:54:15PM +0100, Greg KH wrote:
> On Fri, Mar 02, 2018 at 05:14:50PM +0800, Alex Shi wrote:
> > On 03/01/2018 11:24 PM, Greg KH wrote:

> > > And why are you making this patchset up?  What is wrong with the patches
> > > in the android-common tree for this?

> > We believe the LTS is the base kernel for android/lsk, so the fixing
> > patches should get it first and then merge to other tree.

> But you know that android-common is already fine here, the needed
> patches are all integrated into there, so no additional work is needed
> for android devices.  So what devices do you expect to use this 4.9
> backport?

See below...

> What is "lsk"?

The Linaro Stable Kernel, it's LTS plus some feature backports.

> But really, I don't see this need as all ARM devices that I know of that
> are stuck on 4.9.y are already using the android-common tree.  Same for
> 4.4.y.  Do you know of any that are not, and that can not just use
> 4.14.y instead?

There's way more to ARM than just Android systems, assuming that getting
things into the Android kernel is enough is like assuming that x86 is
covered since the distros have their own backports - it covers a lot of
users but not everyone.  Off the top of my head there's things like
routers, NASs, cameras, IoT, radio systems, industrial appliances, set
top boxes and these days even servers.  Most of these segments are just
as conservative about taking new kernel versions on shipping product as
the phone vendors are, the practices that make people relucant to take
bigger updates in production are general engineering practices common
across industry.

I mostly talk to chip vendors so I can't off the top of my head name
specific end products with particular kernel versions.  What I can tell
you is that many of the chip vendors care deeply about LTS because their
customers demand it - off the top of my head at least Atmel, ST and TI
ship vanilla LTS kernels with no Android at all into large market
segments.  Some of these chips couldn't usefully run Android so there's
just no Android support, some also have Android available as an
alternative.  Some of them even have very complete upstream support
available with barely any vendor patch required at all (none in some
applications).

Things that are functioning well will inevitably be less visible -
that's good, that means there's less of a pain point there but it
doesn't mean there's not still a support need.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-03-05 12:46 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28  3:56 Alex Shi
2018-02-28  3:56 ` [PATCH 01/29] arm64: mm: Use non-global mappings for kernel space Alex Shi
2018-02-28 12:08   ` Greg KH
2018-03-01 11:53     ` Alex Shi
2018-02-28  3:56 ` [PATCH 02/29] arm64: mm: Move ASID from TTBR0 to TTBR1 Alex Shi
2018-02-28  3:56 ` [PATCH 03/29] arm64: mm: Allocate ASIDs in pairs Alex Shi
2018-02-28  3:56 ` [PATCH 04/29] arm64: mm: Add arm64_kernel_unmapped_at_el0 helper Alex Shi
2018-02-28  3:56 ` [PATCH 05/29] arm64: mm: Invalidate both kernel and user ASIDs when performing TLBI Alex Shi
2018-02-28  3:56 ` [PATCH 06/29] arm64: factor out entry stack manipulation Alex Shi
2018-02-28  3:56 ` [PATCH 07/29] arm64: entry.S: move SError handling into a C function for future expansion Alex Shi
2018-02-28  3:56 ` [PATCH 08/29] module: extend 'rodata=off' boot cmdline parameter to module mappings Alex Shi
2018-02-28  3:56 ` [PATCH 09/29] arm64: entry: Add exception trampoline page for exceptions from EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 10/29] arm64: mm: Map entry trampoline into trampoline and kernel page tables Alex Shi
2018-02-28  3:56 ` [PATCH 11/29] arm64: entry: Explicitly pass exception level to kernel_ventry macro Alex Shi
2018-02-28  3:56 ` [PATCH 12/29] arm64: entry: Hook up entry trampoline to exception vectors Alex Shi
2018-02-28  3:56 ` [PATCH 13/29] arm64: tls: Avoid unconditional zeroing of tpidrro_el0 for native tasks Alex Shi
2018-02-28  3:56 ` [PATCH 14/29] arm64: entry: Add fake CPU feature for unmapping the kernel at EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 15/29] arm64: kaslr: Put kernel vectors address in separate data page Alex Shi
2018-02-28  3:56 ` [PATCH 16/29] arm64: use RET instruction for exiting the trampoline Alex Shi
2018-02-28  3:56 ` [PATCH 17/29] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0 Alex Shi
2018-02-28  3:56 ` [PATCH 18/29] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry Alex Shi
2018-02-28  3:56 ` [PATCH 19/29] arm64: Take into account ID_AA64PFR0_EL1.CSV3 Alex Shi
2018-02-28  3:56 ` [PATCH 20/29] arm64: Allow checking of a CPU-local erratum Alex Shi
2018-02-28  3:56 ` [PATCH 21/29] arm64: capabilities: Handle duplicate entries for a capability Alex Shi
2018-02-28  3:56 ` [PATCH 22/29] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 Alex Shi
2018-02-28  3:56 ` [PATCH 23/29] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs Alex Shi
2018-02-28  3:56 ` [PATCH 24/29] arm64: Turn on KPTI only on CPUs that need it Alex Shi
2018-02-28  3:56 ` [PATCH 25/29] arm64: kpti: Make use of nG dependent on arm64_kernel_unmapped_at_el0() Alex Shi
2018-02-28  3:56 ` [PATCH 26/29] arm64: kpti: Add ->enable callback to remap swapper using nG mappings Alex Shi
2018-02-28  3:56 ` [PATCH 27/29] arm64: Force KPTI to be disabled on Cavium ThunderX Alex Shi
2018-02-28  3:56 ` [PATCH 28/29] arm64: entry: Reword comment about post_ttbr_update_workaround Alex Shi
2018-02-28  3:56 ` [PATCH 29/29] arm64: idmap: Use "awx" flags for .idmap.text .pushsection directives Alex Shi
2018-02-28  4:02 ` [PATCH 0/29] arm meltdown fix backporting review for lts 4.9 Alex Shi
2018-03-01 15:24 ` Greg KH
2018-03-02  9:14   ` Alex Shi
2018-03-02 10:32     ` Marc Zyngier
2018-03-02 16:54     ` Greg KH
2018-03-05 12:46       ` Mark Brown [this message]
2018-03-05 13:08         ` Greg KH
2018-03-06 14:26           ` Mark Brown
2018-03-06 17:25             ` Greg KH
2018-03-06 21:31               ` Mark Brown
2018-03-13 10:03                 ` Greg KH
2018-03-07  4:43               ` Alex Shi
2018-03-07  3:27           ` Alex Shi
2018-03-07 18:24       ` Ard Biesheuvel
2018-03-13 10:04         ` Greg KH
2018-03-13 10:13           ` Ard Biesheuvel
2018-03-13 10:38             ` Greg KH
2018-03-13 13:01               ` Ard Biesheuvel
2018-03-13 13:25                 ` Greg KH

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=20180305124638.GG8588@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alex.shi@linaro.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=greg@kroah.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®