Message-ID: <8e799cadb1104714f998fe74e40b3cb052c9c1ed.camel@aosc.io>
Date:   Wed, 02 Mar 2022 21:19:37 +0800
From:   Icenowy Zheng <icenowy@...c.io>
To:     "Maciej W. Rozycki" <macro@...am.me.uk>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, Guo Ren <guoren@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Jeff Dike <jdike@...toit.com>,
        Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Chris Zankel <chris@...kel.net>,
        Max Filippov <jcmvbkbc@...il.com>,
        linux-arm-kernel@...ts.infradead.org, linux-csky@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
        linux-um@...ts.infradead.org, linux-xtensa@...ux-xtensa.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] parport_pc: Also enable driver for PCI systems

在 2022-02-14星期一的 20:16 +0000，Maciej W. Rozycki写道：
> Nowadays PC-style parallel ports come in the form of PCI and PCIe
> option 
> cards and there are some combined parallel/serial option cards as
> well 
> that we handle in the parport subsystem.  There is nothing in
> particular 
> that would prevent them from being used in any system equipped with
> PCI 
> or PCIe connectivity, except that we do not permit the PARPORT_PC
> config 
> option to be selected for platforms for which
> ARCH_MIGHT_HAVE_PC_PARPORT 
> has not been set for.
> 
> The only PCI platforms that actually can't make use of PC-style
> parallel 
> port hardware are those newer PCIe systems that have no support for
> I/O 
> cycles in the host bridge, required by such parallel ports.  Notably,
> this includes the s390 arch, which has port I/O accessors that cause 
> compilation warnings (promoted to errors with `-Werror'), and there
> are 
> other cases such as the POWER9 PHB4 device, though this one has
> variable 
> port I/O accessors that depend on the particular system.  Also it is
> not 
> clear whether the serial port side of devices enabled by
> PARPORT_SERIAL 
> uses port I/O or MMIO.  Finally Super I/O solutions are always either
> ISA or platform devices.

Just spot this patch in linux-riscv mailing list, I think there's a
pending patchset that tries to add a HAS_IOPORT Kconfig option, which
can be used in this situation.

> 
> Make the PARPORT_PC option selectable also for PCI systems then,
> except 
> for the s390 arch, however limit the availability of
> PARPORT_PC_SUPERIO 
> to platforms that enable ARCH_MIGHT_HAVE_PC_PARPORT.  Update
> platforms 
> accordingly for the required <asm/parport.h> header.
> 
> Signed-off-by: Maciej W. Rozycki <macro@...am.me.uk>
> ---
> Hi,
> 
>  I have verified this lightly by booting a kernel with PARPORT_PC and
> PARPORT_SERIAL enabled on a RISC-V HiFive Unmatched system.  While I
> do 
> have a PCIe parallel port option available that I could use with my
> RISC-V 
> machine (based on the OxSemi OXPCIe952 chip) it is currently plugged
> in 
> the wrong system, and both machines are in my remote lab I have
> currently 
> no visit scheduled to in the near future.  For the record the device 
> reports as:
> 
> PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 18
> parport1: PC-style at 0x1000 (0x1008), irq 18, using FIFO
> [PCSPP,TRISTATE,COMPAT,EPP,ECP]
> 
> in the other system.  I'll see if I can verify it with the Unmatched
> at 
> the next opportunity, though it seems like an overkill to me given
> that a 
> PC-style parallel port is a generic PCIe device.  The OXPCIe952
> implements 
> a multifunction device, so it doesn't rely on PARPORT_SERIAL.
> 
>  NB platforms to be updated for <asm/parport.h> generation were
> chosen by 
> the presence of the HAVE_PCI or FORCE_PCI option from ones that do
> not 
> already have or generate that header, except for s390, now excluded. 
> Let 
> me know if I got anything wrong here.
> 
>   Maciej
> 
> Changes from v1:
> 
> - Exclude s390 systems, update the change description accordingly.
> ---
>  arch/arm64/include/asm/Kbuild  |    1 +
>  arch/csky/include/asm/Kbuild   |    1 +
>  arch/riscv/include/asm/Kbuild  |    1 +
>  arch/um/include/asm/Kbuild     |    1 +
>  arch/xtensa/include/asm/Kbuild |    1 +
>  drivers/parport/Kconfig        |    4 ++--
>  6 files changed, 7 insertions(+), 2 deletions(-)
> 
> linux-parport-pc-pci.diff
> Index: linux-macro/arch/arm64/include/asm/Kbuild
> ===================================================================
> --- linux-macro.orig/arch/arm64/include/asm/Kbuild
> +++ linux-macro/arch/arm64/include/asm/Kbuild
> @@ -3,6 +3,7 @@ generic-y += early_ioremap.h
>  generic-y += mcs_spinlock.h
>  generic-y += qrwlock.h
>  generic-y += qspinlock.h
> +generic-y += parport.h
>  generic-y += user.h
>  
>  generated-y += cpucaps.h
> Index: linux-macro/arch/csky/include/asm/Kbuild
> ===================================================================
> --- linux-macro.orig/arch/csky/include/asm/Kbuild
> +++ linux-macro/arch/csky/include/asm/Kbuild
> @@ -4,5 +4,6 @@ generic-y += extable.h
>  generic-y += gpio.h
>  generic-y += kvm_para.h
>  generic-y += qrwlock.h
> +generic-y += parport.h
>  generic-y += user.h
>  generic-y += vmlinux.lds.h
> Index: linux-macro/arch/riscv/include/asm/Kbuild
> ===================================================================
> --- linux-macro.orig/arch/riscv/include/asm/Kbuild
> +++ linux-macro/arch/riscv/include/asm/Kbuild
> @@ -2,5 +2,6 @@
>  generic-y += early_ioremap.h
>  generic-y += flat.h
>  generic-y += kvm_para.h
> +generic-y += parport.h
>  generic-y += user.h
>  generic-y += vmlinux.lds.h
> Index: linux-macro/arch/um/include/asm/Kbuild
> ===================================================================
> --- linux-macro.orig/arch/um/include/asm/Kbuild
> +++ linux-macro/arch/um/include/asm/Kbuild
> @@ -17,6 +17,7 @@ generic-y += mcs_spinlock.h
>  generic-y += mmiowb.h
>  generic-y += module.lds.h
>  generic-y += param.h
> +generic-y += parport.h
>  generic-y += percpu.h
>  generic-y += preempt.h
>  generic-y += softirq_stack.h
> Index: linux-macro/arch/xtensa/include/asm/Kbuild
> ===================================================================
> --- linux-macro.orig/arch/xtensa/include/asm/Kbuild
> +++ linux-macro/arch/xtensa/include/asm/Kbuild
> @@ -4,6 +4,7 @@ generic-y += extable.h
>  generic-y += kvm_para.h
>  generic-y += mcs_spinlock.h
>  generic-y += param.h
> +generic-y += parport.h
>  generic-y += qrwlock.h
>  generic-y += qspinlock.h
>  generic-y += user.h
> Index: linux-macro/drivers/parport/Kconfig
> ===================================================================
> --- linux-macro.orig/drivers/parport/Kconfig
> +++ linux-macro/drivers/parport/Kconfig
> @@ -42,7 +42,7 @@ if PARPORT
>  
>  config PARPORT_PC
>         tristate "PC-style hardware"
> -       depends on ARCH_MIGHT_HAVE_PC_PARPORT
> +       depends on ARCH_MIGHT_HAVE_PC_PARPORT || (PCI && !S390)
>         help
>           You should say Y here if you have a PC-style parallel port.
> All
>           IBM PC compatible computers and some Alphas have PC-style
> @@ -77,7 +77,7 @@ config PARPORT_PC_FIFO
>  
>  config PARPORT_PC_SUPERIO
>         bool "SuperIO chipset support"
> -       depends on PARPORT_PC && !PARISC
> +       depends on ARCH_MIGHT_HAVE_PC_PARPORT && PARPORT_PC &&
> !PARISC
>         help
>           Saying Y here enables some probes for Super-IO chipsets in
> order to
>           find out things like base addresses, IRQ lines and DMA
> channels.  It
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Powered by blists - more mailing lists