| 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
| ||
|
Message-ID: <6d5523be-1841-18b9-9b83-6f7e591ed66b@huawei.com>
Date: Tue, 31 Jan 2017 13:32:33 +0000
From: John Garry <john.garry@...wei.com>
To: Alexander Graf <agraf@...e.de>,
"zhichang.yuan" <yuanzhichang@...ilicon.com>,
<catalin.marinas@....com>, <will.deacon@....com>,
<robh+dt@...nel.org>, <frowand.list@...il.com>,
<bhelgaas@...gle.com>, <rafael@...nel.org>, <mark.rutland@....com>,
<brian.starkey@....com>, <olof@...om.net>, <arnd@...db.de>,
<linux-arm-kernel@...ts.infradead.org>
CC: <lorenzo.pieralisi@....com>, <benh@...nel.crashing.org>,
<linux-kernel@...r.kernel.org>, <linuxarm@...wei.com>,
<devicetree@...r.kernel.org>, <linux-pci@...r.kernel.org>,
<linux-serial@...r.kernel.org>, <minyard@....org>,
<liviu.dudau@....com>, <zourongrong@...il.com>,
<gabriele.paoloni@...wei.com>, <zhichang.yuan02@...il.com>,
<kantyzc@....com>, <xuwei5@...ilicon.com>
Subject: Re: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced
On 30/01/2017 17:12, Alexander Graf wrote:
> On 01/24/2017 08:05 AM, zhichang.yuan wrote:
>> Low-pin-count interface is integrated into some SoCs. The accesses to
>> those
>> peripherals under LPC make use of I/O ports rather than the memory
>> mapped I/O.
>>
>> To drive these devices, this patch introduces a method named indirect-IO.
>> In this method the in/out() accessor in include/asm-generic/io.h will be
>> redefined. When upper layer drivers call in/out() with those known
>> legacy port
>> addresses to access the peripherals, the I/O operations will be routed
>> to the
>> right hooks which are registered specific to the host device, such as
>> LPC.
>> Then the hardware relevant manupulations are finished by the
>> corresponding
>> host.
>>
>> According to the comments on V5, this patch adds a common indirect-IO
>> driver
>> which support this I/O indirection to the generic directory.
>>
>> In the later pathches, some host-relevant drivers are implemented to
>> support
>> the specific I/O hooks and register them.
>> Based on these, the upper layer drivers which depend on in/out() can
>> work well
>> without any extra work or any changes.
>>
>> Signed-off-by: zhichang.yuan <yuanzhichang@...ilicon.com>
>> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@...wei.com>
>> Signed-off-by: John Garry <john.garry@...wei.com>
>
> I like the extio idea. That allows us to handle all PIO requests on
> platforms that don't have native PIO support via different routes
> depending on the region they're in. Unfortunately we now we have 2
> frameworks for handling sparse PIO regions: One in extio, one in PCI.
>
> Why don't we just merge the two? Most of the code that has #ifdef
> PCI_IOBASE throughout the code base sounds like an ideal candidate to
> get migrated to extio instead. Then we only have a single framework to
> worry about ...
To be clear, are you suggesting we merge the functionality from
pci_register_io_range(), pci_pio_to_address(), pci_address_to_pio() into
extio, so extio manages all PIO? And having a single type of node to
register PIO ranges, by amalgamating struct extio_node and io_range (as
Bjorn mentioned)?
It would make sense. We would be somewhat decoupling PIO from PCI.
I think that other architectures, like PPC, and other code would need to
be fixed up to handle this.
We need to consider all the other challenges/obstacles to this.
>
>> ---
>> include/asm-generic/io.h | 50 ++++++++++++++++
>> include/linux/extio.h | 85 +++++++++++++++++++++++++++
>> include/linux/io.h | 1 +
>> lib/Kconfig | 8 +++
>> lib/Makefile | 2 +
>> lib/extio.c | 147
>> +++++++++++++++++++++++++++++++++++++++++++++++ xc>> create mode 100644 include/linux/extio.h
>> create mode 100644 lib/extio.c
>>
<snip>
>> + * Copyright (C) 2016 Hisilicon Limited, All Rights Reserved.
>> + * Author: Zhichang Yuan <yuanzhichang@...ilicon.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include <linux/io.h>
>> +#include <linux/spinlock.h>
>> +
>> +static LIST_HEAD(extio_dev_list);
>> +static DEFINE_RWLOCK(extio_list_lock);
>
> Why not just make the list an RCU list? Then you don't need read locks.
> We also wouldn't create potential lock contention between devices that
> could easily have parallel PIO operations (say a PCI device and an LPC
> device).
>
OK
>> +
>> +void register_extio(struct extio_node *node)
>> +{
>> + write_lock(&extio_list_lock);
>> + list_add_tail(&node->list, &extio_dev_list);
>> + write_unlock(&extio_list_lock);
>> +}
>> +
>> +static struct extio_node *find_extio_token(unsigned long addr)
>> +{
>> + struct extio_node *extio_entry;
>> +
>> + read_lock(&extio_list_lock);
>> + list_for_each_entry(extio_entry, &extio_dev_list, list) {
>> + if ((addr < extio_entry->io_start + extio_entry->range_size) &&
>> + (addr >= extio_entry->io_start))
>> + break;
>> + }
>> + read_unlock(&extio_list_lock);
>> + return (&extio_entry->list == &extio_dev_list) ? NULL : extio_entry;
>> +}
>> +
>> +struct extio_node *extio_find_node(struct fwnode_handle *node)
>> +{
>> + struct extio_node *entry;
>> +
>> + read_lock(&extio_list_lock);
>> + list_for_each_entry(entry, &extio_dev_list, list) {
>> + if (entry->fwnode == node)
>> + break;
>> + }
>> + read_unlock(&extio_list_lock);
>> +
>> + return (&entry->list == &extio_dev_list) ? NULL : entry;
>> +}
>> +
>> +unsigned long extio_translate(struct fwnode_handle *node,
>> + unsigned long bus_addr)
>> +{
>> + struct extio_node *entry;
>> + unsigned long port_id = -1;
>> +
>> + read_lock(&extio_list_lock);
>> + list_for_each_entry(entry, &extio_dev_list, list) {
>> + if (entry->fwnode == node &&
>> + bus_addr >= entry->bus_start &&
>> + bus_addr - entry->bus_start < entry->range_size)
>> + port_id = entry->io_start + bus_addr -
>> + entry->bus_start;
>> + }
>> + read_unlock(&extio_list_lock);
>> +
>> + return port_id;
>> +}
>> +
>> +#ifdef PCI_IOBASE
>> +
>> +#define BUILD_EXTIO(bw, type) \
>> +type extio_in##bw(unsigned long addr) \
>> +{ \
>> + struct extio_node *extio_entry = find_extio_token(addr); \
>> + \
>> + if (!extio_entry) \
>> + return read##bw(PCI_IOBASE + addr); \
>> + return extio_entry->ops->pfin ? \
>> + extio_entry->ops->pfin(extio_entry->devpara, \
>> + addr, sizeof(type)) : -1; \
>> +} \
>> + \
>> +void extio_out##bw(type value, unsigned long addr) \
>> +{ \
>> + struct extio_node *extio_entry = find_extio_token(addr); \
>> + \
>> + if (!extio_entry) \
>> + write##bw(value, PCI_IOBASE + addr); \
>
> All of the fallback code would also disappear as a nice side effect of
> making pci pio handling a user of extio :).
Is your idea that PCI IO space will also register accessors, which would
be the same read{b,w,l}/write{b,w,l}?
>
It would be nice to have a quicker way to so the lookup from address to
node, as we loop all nodes in find_extio_token() every single time.
>
> Alex
>
Thanks,
John
>
> .
>
Powered by blists - more mailing lists