From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lorenzo Pieralisi Subject: Re: [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware Date: Tue, 3 Jul 2018 18:12:51 +0100 Message-ID: <20180703171251.GC11614@red-moon> References: <20180628100656.10692-1-james.morse@arm.com> <1530607466.9841.124.camel@debian.org> <1530632871.9841.139.camel@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1530632871.9841.139.camel@debian.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Ian Campbell Cc: Ard Biesheuvel , Geoff Levand , Riku Voipio , Sudeep Holla , ACPI Devel Maling List , James Morse , Hanjun Guo , Mark Salter , linux-arm-kernel List-Id: linux-acpi@vger.kernel.org On Tue, Jul 03, 2018 at 04:47:51PM +0100, Ian Campbell wrote: > On Tue, 2018-07-03 at 17:17 +0200, Ard Biesheuvel wrote: > > On 3 July 2018 at 10:44, Ian Campbell wrote: > > > On Thu, 2018-06-28 at 12:25 +0200, Ard Biesheuvel wrote: > > > > I understand the desire to keep running these M400s as long as they > > > > have some life left in them, but the reality is that they are end of > > > > life already, and not many were manufactured to begin with. > > > > > > Linux has a long history of supporting such devices so long as there is > > > someone around willing to keep them running (witness for example how > > > long x86/voyager lived with just 1 in existence in a motivated > > > developer's basement, probably some number of entire architectures and > > > I bet a not insubstantial chunk of the platform support in arch/arm). > > > > > > > I wonder how many such quirks fall into the 'user cannot be bothered > > to add a kernel command line option' category. > > I don't know the overall picture, but the very first one I happened to > look at in arch/x86/kernel/acpi/boot.c (picked by grepping for quirk > and looking for acpi) just now was half a dozen quirks setting > acpi_skip_timer_override which is also settable on the command line. > There's also a bunch in there which just disable ACPI completely which > is also possible on the command line. > > My gut feeling is that these are the rule not the exception. > > > > So, I think DMI quirks are probably, in reality, inevitable unless > > > you > > > think firmware authors are going to be infaliable or the > > > testing/certification suites never has any gaps in it. > > > > > > > Oh, obviously. But this is exactly my point about flood gates: we know > > we need implement support for them, but that fact alone does not > > justify adding quirks for dead platforms for issues that can be > > trivially worked around. > > Is m400 really dead? There certainly seem to be people around who care > about keeping it running and have access to them. I do not think anybody is preventing that, it is just that we do not see the reason for adding a DMI quirk to the mainline kernel to enable a platform with broken firmware that cripples one of the main feature it is supposed to implement, we can go on forever about this but that's the gist. Thanks, Lorenzo From mboxrd@z Thu Jan 1 00:00:00 1970 From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) Date: Tue, 3 Jul 2018 18:12:51 +0100 Subject: [RFC/RFT PATCH 0/2] disable_hest quirk on HP m400 with bad UEFI firmwware In-Reply-To: <1530632871.9841.139.camel@debian.org> References: <20180628100656.10692-1-james.morse@arm.com> <1530607466.9841.124.camel@debian.org> <1530632871.9841.139.camel@debian.org> Message-ID: <20180703171251.GC11614@red-moon> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jul 03, 2018 at 04:47:51PM +0100, Ian Campbell wrote: > On Tue, 2018-07-03 at 17:17 +0200, Ard Biesheuvel wrote: > > On 3 July 2018 at 10:44, Ian Campbell wrote: > > > On Thu, 2018-06-28 at 12:25 +0200, Ard Biesheuvel wrote: > > > > I understand the desire to keep running these M400s as long as they > > > > have some life left in them, but the reality is that they are end of > > > > life already, and not many were manufactured to begin with. > > > > > > Linux has a long history of supporting such devices so long as there is > > > someone around willing to keep them running (witness for example how > > > long x86/voyager lived with just 1 in existence in a motivated > > > developer's basement, probably some number of entire architectures and > > > I bet a not insubstantial chunk of the platform support in arch/arm). > > > > > > > I wonder how many such quirks fall into the 'user cannot be bothered > > to add a kernel command line option' category. > > I don't know the overall picture, but the very first one I happened to > look at in arch/x86/kernel/acpi/boot.c (picked by grepping for quirk > and looking for acpi) just now was half a dozen quirks setting > acpi_skip_timer_override which is also settable on the command line. > There's also a bunch in there which just disable ACPI completely which > is also possible on the command line. > > My gut feeling is that these are the rule not the exception. > > > > So, I think DMI quirks are probably, in reality, inevitable unless > > > you > > > think firmware authors are going to be infaliable or the > > > testing/certification suites never has any gaps in it. > > > > > > > Oh, obviously. But this is exactly my point about flood gates: we know > > we need implement support for them, but that fact alone does not > > justify adding quirks for dead platforms for issues that can be > > trivially worked around. > > Is m400 really dead? There certainly seem to be people around who care > about keeping it running and have access to them. I do not think anybody is preventing that, it is just that we do not see the reason for adding a DMI quirk to the mainline kernel to enable a platform with broken firmware that cripples one of the main feature it is supposed to implement, we can go on forever about this but that's the gist. Thanks, Lorenzo