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]

Message-ID: <CA+-6iNwhifsRsGwz5Wk3VuECxa1jRg5vxQCuGe-MUr=kn301=w@mail.gmail.com>
Date:   Fri, 10 Nov 2023 08:01:23 -0500
From:   Jim Quinlan <james.quinlan@...adcom.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
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 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.

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.

Regards,
Jim


>
>   /sys/module/pcie_aspm/parameters/policy doesn't exist (seems
>   unlikely)?
>
>   Returns -EPERM (would indicate aspm_disabled)?
>
>   Returns -EINVAL (would indicate $POLICY doesn't match anything in
>   policy_str[])?
>
>   Returns 0 with no action (would indicate $POLICY is the same as the
>   current aspm_policy)?
>
> > It seems that the FW/ACPI typically locks this down.  I did see a
> > comment somewhere that
> > said that the reason it was locked down is because too many devices
> > cannot handle it.
>
> Do you have any details about FW/ACPI locking this down?
> aspm_disabled is set by the kernel "pcie_aspm=off" parameter (I assume
> you're not referring to this), if the FADT has ACPI_FADT_NO_ASPM set,
> or if a host bridge's _OSC is missing or failed (maybe [1] is the
> comment you saw?)
>
> These all *should* be unusual cases, so I'd be surprised if you're
> tripping over one of these.  I would NOT be surprised if we had some
> issue in pcie_config_aspm_link() or pcie_set_clkpm() that meant the
> policy change didn't work as intended, though.
>
> Bjorn
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/pci_root.c?id=v6.6#n617
>

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4210 bytes)