linux-kernel - Re: [PATCH v7 2/3] PCI: brcmstb: Configure HW CLKREQ# mode appropriate for downstream device

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]

Date:   Fri, 10 Nov 2023 08:39:01 -0600
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Jim Quinlan <james.quinlan@...adcom.com>
Cc:     linux-pci@...r.kernel.org,
        Nicolas Saenz Julienne <nsaenz@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Cyril Brulebois <kibi@...ian.org>,
        Phil Elwell <phil@...pberrypi.com>,
        bcm-kernel-feedback-list@...adcom.com,
        Jim Quinlan <jim2101024@...il.com>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Rob Herring <robh@...nel.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-rpi-kernel@...ts.infradead.org>,
        "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" 
        <linux-arm-kernel@...ts.infradead.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 2/3] PCI: brcmstb: Configure HW CLKREQ# mode
 appropriate for downstream device

On Fri, Nov 10, 2023 at 08:01:23AM -0500, Jim Quinlan wrote:
> On Thu, Nov 9, 2023 at 5:31 PM Bjorn Helgaas <helgaas@...nel.org> wrote:
> >
> > On Thu, Nov 09, 2023 at 05:06:15PM -0500, Jim Quinlan wrote:
> > > ...
> >
> > > BTW, besides the RPi4, I haven't been able to find a Linux platform
> > > where I can do
> > >
> > >         echo $POLICY > /sys/module/pcie_aspm/parameters/policy
> >
> > This sounds like something we should fix.  What exactly happens?  I
> > think this should be handled at pcie_aspm_set_policy(), so:
> 
> Well, I've tried changing the ASPM policy on my x86 Ubuntu system
> and IIRC a Fedora system.  In both cases it says "illegal write
> operation" but I am root and the "policy" file does have rw perms
> for root, so I have no idea how it comes back with that error.  Some
> machines allow one to change the setting in the BIOS, FWIW.

BIOS settings like that are potentially misleading unless the BIOS
*also* retains ownership of ASPM or changes the ASPM features
advertised by devices.  If BIOS grants ASPM ownership to the OS, BIOS
should not assume anything about how the OS will configure ASPM.

> Right now on my CM4, "echo $POLICY  > policy" actually works.
> Perhaps when I was testing this I did not yet apply my commits, or
> perhaps it was with a specific endpoint device.  Regardless, I'll
> let you know with a backtrace if I see this again.

Great, thanks!

Bjorn