From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AE2F9C2D0C0 for ; Thu, 19 Dec 2019 08:57:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8E7192465E for ; Thu, 19 Dec 2019 08:57:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726712AbfLSI5h (ORCPT ); Thu, 19 Dec 2019 03:57:37 -0500 Received: from mo-csw1515.securemx.jp ([210.130.202.154]:42438 "EHLO mo-csw.securemx.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726591AbfLSI5h (ORCPT ); Thu, 19 Dec 2019 03:57:37 -0500 Received: by mo-csw.securemx.jp (mx-mo-csw1515) id xBJ8vJro018437; Thu, 19 Dec 2019 17:57:19 +0900 X-Iguazu-Qid: 34tKThYsqI7CuVd7ye X-Iguazu-QSIG: v=2; s=0; t=1576745839; q=34tKThYsqI7CuVd7ye; m=O3BnQ2bs5DsNfd7TZPZJZDHDPfXbewPgW32ALy13FeM= Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.securemx.jp (mx-mr1511) id xBJ8vHQN019037; Thu, 19 Dec 2019 17:57:18 +0900 Received: from enc02.toshiba.co.jp ([61.202.160.51]) by imx12.toshiba.co.jp with ESMTP id xBJ8vHvf001484; Thu, 19 Dec 2019 17:57:17 +0900 (JST) Received: from hop101.toshiba.co.jp ([133.199.85.107]) by enc02.toshiba.co.jp with ESMTP id xBJ8vH2O017194; Thu, 19 Dec 2019 17:57:17 +0900 From: Punit Agrawal To: Johan Hovold Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , , "ACPI Devel Maling List" , Linux Kernel Mailing List , , , Stable , Rob Herring , Greg Kroah-Hartman , "Hans de Goede" Subject: Re: [PATCH] serdev: Don't claim unsupported serial devices References: <20191218065646.817493-1-punit1.agrawal@toshiba.co.jp> <20191218085648.GI22665@localhost> <20191219085114.GQ22665@localhost> Date: Thu, 19 Dec 2019 17:58:08 +0900 In-Reply-To: <20191219085114.GQ22665@localhost> (Johan Hovold's message of "Thu, 19 Dec 2019 09:51:14 +0100") X-TSB-HOP: ON Message-ID: <875zicofof.fsf@kokedama.swc.toshiba.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Johan Hovold writes: > On Thu, Dec 19, 2019 at 09:39:57AM +0100, Rafael J. Wysocki wrote: >> On Wed, Dec 18, 2019 at 9:56 AM Johan Hovold wrote: >> > >> > On Wed, Dec 18, 2019 at 03:56:46PM +0900, Punit Agrawal wrote: >> > > Serdev sub-system claims all serial devices that are not already >> > > enumerated. As a result, no device node is created for serial port on >> > > certain boards such as the Apollo Lake based UP2. This has the >> > > unintended consequence of not being able to raise the login prompt via >> > > serial connection. >> > > >> > > Introduce a blacklist to reject devices that should not be treated as >> > > a serdev device. Add the Intel HS UART peripheral ids to the blacklist >> > > to bring back serial port on SoCs carrying them. >> > > >> > > Cc: stable@vger.kernel.org >> > > Signed-off-by: Punit Agrawal >> > > Cc: Rob Herring >> > > Cc: Greg Kroah-Hartman >> > > Cc: Johan Hovold >> > > Cc: Hans de Goede >> > > --- >> > > >> > > Hi, >> > > >> > > The patch has been updated based on feedback recieved on the RFC[0]. >> > > >> > > Please consider merging if there are no objections. >> > >> > Rafael, I vaguely remember you arguing for a white list when we >> > discussed this at some conference. Do you have any objections to the >> > blacklist approach taken here? >> >> As a rule, I prefer whitelisting, because it only enables the feature >> for systems where it has been tested and confirmed to work. >> >> However, if you are convinced that in this particular case the feature >> should work on the vast majority of systems with a few possible >> exceptions, blacklisting is fine too. >> >> It all depends on what the majority is, at least in principle. > > Ok, thanks. I don't have a preference either way in this case simply > because I don't know the distribution you refer to. > > But if Hans thinks blacklisting is the way to go then let's do that. We > haven't had that many reports about this, but if that were to change > down the line, I guess we can always switch to whitelisting. > > Punit, feel free to add my > > Acked-by: Johan Hovold > > after addressing the review comments you've gotten so far. Thanks Johan. I will post a new version with the updates and acks.