linux-kernel - Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue a PHB reset

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: <98200d15-41f9-e376-b870-472f78971735@linux.vnet.ibm.com>
Date:   Sun, 15 Oct 2017 19:51:59 -0200
From:   "Guilherme G. Piccoli" <gpiccoli@...ux.vnet.ibm.com>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        paulus@...ba.org, maurosr@...ux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/powernv: Enable reset_devices parameter to issue
 a PHB reset

On 10/14/2017 06:13 AM, Benjamin Herrenschmidt wrote:
> No, he's saying this is useful for the developers when debugging the
> kernel driver (or for asking users to "test" something as part of
> debugging a driver problem).
> 
> It's common to have various command line options affecting PCIe
> behaviour. I don't see a fundamental problem with this one.

Thanks Ben, very well explained.

> 
> One could argue in fact that we should always PERST everything, the
> main reason for not doing so is that on "normal" boot, OPAL has already
> done it and it would slow the boot process down.
> 
> My only objection here is the actual name of the argument. We've had a
> number of pci options so far, it makes sense to make sure we still have
> "pci" in the name.

I just wanted to take advantage of the already existing argument,
reset_devices. And..in fact, the PERST is a reset right?
But if you prefer, we can change it - pci_force_reset?
Suggestions are welcome.

> 
> Also having the driver do a "reset" is not always simple, we don't
> always have full control of PERST on a per-device basis. The patch
> proposed will PERST top level PHBs which will propagate as hot reset
> down switches, not 100% PERST but still useful.
> 

Exactly, this reset happens on early arch stage of PCI initialization,
not trivial to drivers perform it.

Anyway, let me know if you want a V2 with improvements or to drop it..I
still see use cases for this.

Thanks,


Guilherme

> Cheers,
> Ben.
>