linux-kernel - RE: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <EE11001F9E5DDD47B7634E2F8A612F2E1F9FC04A@lhreml507-mbx>
Date:   Wed, 1 Feb 2017 12:29:39 +0000
From:   Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:     Alexander Graf <agraf@...e.de>, John Garry <john.garry@...wei.com>,
        Yuanzhichang <yuanzhichang@...ilicon.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "frowand.list@...il.com" <frowand.list@...il.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "brian.starkey@....com" <brian.starkey@....com>,
        "olof@...om.net" <olof@...om.net>, "arnd@...db.de" <arnd@...db.de>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
CC:     "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "minyard@....org" <minyard@....org>,
        "liviu.dudau@....com" <liviu.dudau@....com>,
        "zourongrong@...il.com" <zourongrong@...il.com>,
        "zhichang.yuan02@...il.com" <zhichang.yuan02@...il.com>,
        "kantyzc@....com" <kantyzc@....com>,
        "xuwei (O)" <xuwei5@...ilicon.com>
Subject: RE: [PATCH V6 1/5] LIB: Indirect ISA/LPC port IO introduced

Hi Alex

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@...e.de]

[...]

> >>
> >> 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?
> 
> Yes, I guess so.
> 
> > And having a single type of node to
> > register PIO ranges, by amalgamating struct extio_node and io_range
> (as
> > Bjorn mentioned)?
> 
> I'm not quite sure I follow you here. Basically I think you want a
> generic "non-x86 PIO" framework that PCI just plugs into.
> 
> I don't think that necessarily means you want to statically allocate
> regions of that PIO space to separate (pseudo-)devices. Instead,
> everyone shares that space and should be able to fail gracefully if
> some
> space is already occupied.
> 
> > It would make sense. We would be somewhat decoupling PIO from PCI.
> 
> Yes :).
> 
> > I think that other architectures, like PPC, and other code would need
> to
> > be fixed up to handle this.
> 
> I think only PPC, Microblaze and ARM are using this. Grep for
> PCI_IOBASE. It's not that many.
> 
> > We need to consider all the other challenges/obstacles to this.
> 
> Well, getting our abstraction levels right to me sounds like it's worth
> the obstacles.
> 

I have had a quick look and I think it should not be too difficult to
unify the two frameworks.

I'll follow up soon on this thread with a code sketch

Thanks
Gab

[...]