From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752895AbbAVIRu (ORCPT ); Thu, 22 Jan 2015 03:17:50 -0500 Received: from mail-ig0-f177.google.com ([209.85.213.177]:45279 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbbAVIRk (ORCPT ); Thu, 22 Jan 2015 03:17:40 -0500 MIME-Version: 1.0 In-Reply-To: <4078818.ecVtLF3hjd@vostro.rjw.lan> References: <1418890998-23811-1-git-send-email-heikki.krogerus@linux.intel.com> <4078818.ecVtLF3hjd@vostro.rjw.lan> Date: Thu, 22 Jan 2015 09:17:38 +0100 Message-ID: Subject: Re: [RFC PATCH] gpio: support for GPIO forwarding From: Linus Walleij To: "Rafael J. Wysocki" Cc: Alexandre Courbot , Heikki Krogerus , "Rafael J. Wysocki" , Darren Hart , Arnd Bergmann , Andy Shevchenko , Mika Westerberg , "linux-gpio@vger.kernel.org" , "linux-kernel@vger.kernel.org" , ACPI Devel Maling List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 20, 2015 at 10:25 PM, Rafael J. Wysocki wrote: > Yes, it can (in principle). In fact, we have a plan to refine it, but it is > going to take some time. Once we've done that, we'll see how painful it is to > "patch" ACPI tables this way in practice. > > Also there is an ecosystem problem related to distributing such "patches". > Today, distributions don't need to worry about patching buggy platform > firmware, because they get workarounds in the kernel, but if we switch over > to the model in which platform firmware "overlays" need to be provided in > addition to it, then suddenly questions arise about who should be responsible > for making them available, how to avoid duplication of efforts between > distributions etc. > > All of that needs to be clarified before we start making hard statements like > "No in-kernel workarounds for that!" OK so why can't the patching happen in the kernel? If the kernel anyway has to supply some kind of workaround for the issue, it is more a question of where to place it. Whether it does so by patching the ACPI tables or by detecting a bad ACPI thing and working around it at runtime in a certain driver doesn't really matter, does it? They are both in-kernel ACPI fixes, just that one of the mechanisms is generic. I don't understand why this obsession with userspace having to do the ACPI table patching - if kernels should "just work" then put this stuff behind Kconfig and have it in the kernel. Yours, Linus Walleij