linux-kernel - Re: [PATCH v15 8/9] HISI LPC: Add ACPI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 06 Mar 2018 13:19:21 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     John Garry <john.garry@...wei.com>,
        mika.westerberg@...ux.intel.com, rafael@...nel.org,
        lorenzo.pieralisi@....com, rjw@...ysocki.net,
        hanjun.guo@...aro.org, robh+dt@...nel.org, bhelgaas@...gle.com,
        arnd@...db.de, mark.rutland@....com, olof@...om.net,
        dann.frazier@...onical.com, andy.shevchenko@...il.com,
        robh@...nel.org
Cc:     joe@...ches.com, benh@...nel.crashing.org,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-acpi@...r.kernel.org, linuxarm@...wei.com, minyard@....org,
        devicetree@...r.kernel.org, linux-arch@...r.kernel.org,
        rdunlap@...radead.org, gregkh@...uxfoundation.org,
        akpm@...ux-foundation.org, frowand.list@...il.com, agraf@...e.de
Subject: Re: [PATCH v15 8/9] HISI LPC: Add ACPI support

On Fri, 2018-03-02 at 10:19 +0000, John Garry wrote:
> On 01/03/2018 19:50, Andy Shevchenko wrote:
> > On Tue, 2018-02-27 at 00:40 +0800, John Garry wrote:

> > Ok, this needs to be thought about a bit more.
> > 
> > I guess I understand what's is the problem with PNP IDs in the
> > driver.
> > 
> > You probe your LPC device quite late.
> > One option is to move from classical probe to a event-driven model,
> > i.e.
> > via registering a notifier (see acpi_lpss.c), preparing necessary
> > stuff
> > at earlier stages and then register devices by their enumeration and
> > appearance.
> > 
> > Though, if I would be you I would seek a opinion from Rafael and
> > Mika
> > (maybe others as well).
> 
> I would like to give a bit more background on this HW. This HW is now 
> for us a legacy device. It will be used in no more chipsets. It is
> only 
> used in hip06 and hip07 chipsets on our D03 and D05 boards, 
> respectively. On these boards we have the following LPC slave devices
> only:
> D03: UART, IPMI
> D05: IPMI
> 
> Supporting IPMI for D05 is required. Supporting legacy D03 and the
> UART 
> is a "nice-to-have". But it is definitely ok for us to not support
> this 
> device.

I see. But it raises another question to the whole series, why do we
introduce a generic indirect IO for only two devices ever?

Can't it be done in the (MFD) driver itself?

Possible another option, is to introduce a specific regmap for that and
use it in the drivers (though it might be not so trivial with existing
ones).

> Our previous ACPI support solution did use a scan handler for this
> host, 
> but there was some sensible pushback on this - please check this if
> not 
> familiar: https://lkml.org/lkml/2018/2/14/532

> Overall it does not make sense to try to move this back to
> drivers/acpi 
> and receive more pushback from that direction,

Ah, I think the ARM people just worried mostly about arm64 in the
pathnames, though your case is very similar to our LPSS for only few
SoCs.

I would rather think if you move it directly to drivers/acpi it would be
fine.

>  and only delay 
> indefinitely upstreaming this driver (which is now running at ~27
> months 
> since v1) to just support a PNP-compatible device which we don't care 
> too much about.

Ouch!

As I suggested before, you would better to get an input from
maintainers.

My personal opinion that the handler approach is cleaner, though it's
still non-generic stuff. I think that this is what Mika referred to in
his mail.

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy