linux-kernel - [RFC PATCH 0/2] HISI LPC: Add PNP device 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-next>] [day] [month] [year] [list]

Message-ID: <1524218846-169934-1-git-send-email-john.garry@huawei.com>
Date:   Fri, 20 Apr 2018 18:07:24 +0800
From:   John Garry <john.garry@...wei.com>
To:     <rjw@...ysocki.net>, <andriy.shevchenko@...ux.intel.com>,
        <linux-acpi@...r.kernel.org>, <lenb@...nel.org>,
        <mika.westerberg@...ux.intel.com>, <lorenzo.pieralisi@....com>
CC:     <linux-kernel@...r.kernel.org>, <arnd@...db.de>,
        <graeme.gregory@...aro.org>, <helgaas@...nel.org>,
        <linuxarm@...wei.com>, <z.liuxinliang@...ilicon.com>,
        John Garry <john.garry@...wei.com>
Subject: [RFC PATCH 0/2] HISI LPC: Add PNP device support

This patchset adds support for creating PNP devices
for devices attached to the HiSilicon LPC host bus.

Currently an mfd-cell (platform device) is created per
device on the bus for using ACPI-based firmware. As
such, we need require a platform driver for these
devices.

However for PNP-compatible devices, it would be better
to create a PNP device so that we may use the existing
PNP driver.

The PNP-compatible device we are interested in is the
8250-compatible UART on the Huawei D03 development
board. This uart has the following profile:
- IO space iotype
- no interrupt, so polling mode required
- 16550 compatible

Currently no platform driver exists for this. I did
send an RFC to add support to the 8250_dw driver, but
Andy Shevchenko suggested adding PNP support to the
host driver instead so we may use the appropriate PNP
driver (8250_pnp) without modification, see here:
https://lkml.org/lkml/2018/2/26/354

As for the implementation in this patchset, to avoid
the PNP scan from creating and adding the device,
we reuse the "enumeration_by_parent" flag to hold off
adding the PNP device, so the parent driver can modify
the IO resources to translate from the bus address
to the logical PIO address, and then add the device
for probing.

This solution is not good - hence the RFC. But I am
looking for suggestions on how to solve this.

Any opinions or ideas?

Thanks!

John Garry (2):
  ACPI / PNP: Don't add "enumeration_by_parent" devices
  HISI LPC: Add PNP device support

 drivers/bus/hisi_lpc.c     | 38 +++++++++++++++++++++++++++++++++++++-
 drivers/pnp/pnpacpi/core.c | 12 ++++++++----
 2 files changed, 45 insertions(+), 5 deletions(-)

-- 
1.9.1