[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0h-bhg4+kwTci5_wZhn9rYN=YXoCbSTVs4vPRzRFOjU8A@mail.gmail.com>
Date: Thu, 19 Dec 2019 09:39:57 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Punit Agrawal <punit1.agrawal@...hiba.co.jp>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
linux-serial@...r.kernel.org,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
nobuhiro1.iwamatsu@...hiba.co.jp, shrirang.bagul@...onical.com,
Stable <stable@...r.kernel.org>, Rob Herring <robh@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH] serdev: Don't claim unsupported serial devices
On Wed, Dec 18, 2019 at 9:56 AM Johan Hovold <johan@...nel.org> 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@...r.kernel.org
> > Signed-off-by: Punit Agrawal <punit1.agrawal@...hiba.co.jp>
> > Cc: Rob Herring <robh@...nel.org>
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Cc: Johan Hovold <johan@...nel.org>
> > Cc: Hans de Goede <hdegoede@...hat.com>
> > ---
> >
> > 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.
Powered by blists - more mailing lists