[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191219085114.GQ22665@localhost>
Date: Thu, 19 Dec 2019 09:51:14 +0100
From: Johan Hovold <johan@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Johan Hovold <johan@...nel.org>,
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 Thu, Dec 19, 2019 at 09:39:57AM +0100, Rafael J. Wysocki wrote:
> 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.
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 <johan@...nel.org>
after addressing the review comments you've gotten so far.
Johan
Powered by blists - more mailing lists