diff options
| author | Yazen Ghannam <yazen.ghannam@amd.com> | 2026-09-03 10:43:25 -0500 |
|---|---|---|
| committer | Borislav Petkov (AMD) <bp@alien8.de> | 2026-09-10 18:05:43 -0700 |
| commit | 27600805e62f800bacf990354632eae4e487d34c (patch) | |
| tree | e8aec0ddfaa0bc264d79af632e3de3f1b75ae4c8 /Documentation/ABI/testing/sysfs-class-led | |
| download | linux-stable-27600805e62f800bacf990354632eae4e487d34c.tar.gz linux-stable-27600805e62f800bacf990354632eae4e487d34c.zip | |
x86/amd_node: Fix PCI device reference counting in amd_smn_init()grafted
The local "root" pointer is a temporary variable used during the device
search. Therefore, refcount related to the search iterators should be cleaned
up after the search is complete.
Use the __free() cleanup macro to ensure the refcount is decremented when the
temporary pointer goes out of scope.
Additionally, increment the refcount when caching a root pointer. This ensures
the in-use refcount is separate from the temporary search refcounting.
Finally, drop the redundant "root = NULL" before the second search loop. The
pci_get_class() iterator always decrements the refcount of its "from"
argument, so the first loop can only fall through with "root" already NULL.
Fixes: 0a4b61d9c2e4 ("x86/amd_node: Fix AMD root device caching")
Closes: https://sashiko.dev/#/patchset/20260806160159.230453-1-jason.andryuk%40amd.com
Reported-by: Sashiko <sashiko-bot@kernel.org>
Assisted-by: LLM
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/20260903154325.74343-1-yazen.ghannam@amd.com
Diffstat (limited to 'Documentation/ABI/testing/sysfs-class-led')
| -rw-r--r-- | Documentation/ABI/testing/sysfs-class-led | 89 |
1 files changed, 89 insertions, 0 deletions
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led new file mode 100644 index 000000000..d4c918cc1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-led @@ -0,0 +1,89 @@ +What: /sys/class/leds/<led>/brightness +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Set the brightness of the LED. + + Most LEDs don't have hardware brightness support, so will + just be turned on for non-zero brightness settings. + + .. Note:: + + For multicolor LEDs, writing to this file will update all + LEDs within the group to a calculated percentage of what + each color LED intensity is set to. + + The percentage is calculated for each grouped LED via + the equation below:: + + led_brightness = brightness * multi_intensity/max_brightness + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + + The value is between 0 and /sys/class/leds/<led>/max_brightness + and is represented by as a decimal. + + Writing 0 to this file clears active trigger. + + Writing non-zero to this file while trigger is active changes the + top brightness trigger is going to use. + + + +What: /sys/class/leds/<led>/max_brightness +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Maximum brightness level for this LED, default is 255 (LED_FULL). + + If the LED does not support different brightness levels, this + should be 1. + +What: /sys/class/leds/<led>/brightness_hw_changed +Date: January 2017 +KernelVersion: 4.11 +Description: + Last hardware set brightness level for this LED. Some LEDs + may be changed autonomously by hardware/firmware. Only LEDs + where this happens and the driver can detect this, will have + this file. + + This file supports poll() to detect when the hardware changes + the brightness. + + Reading this file will return the last brightness level set + by the hardware, this may be different from the current + brightness. Reading this file when no hw brightness change + event has happened will return an ENODATA error. + +What: /sys/class/leds/<led>/trigger +Date: March 2006 +KernelVersion: 2.6.17 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Set the trigger for this LED. A trigger is a kernel based source + of LED events. + + You can change triggers in a similar manner to the way an IO + scheduler is chosen. Trigger specific parameters can appear in + /sys/class/leds/<led> once a given trigger is selected. For + their documentation see `sysfs-class-led-trigger-*`. + + Writing "none" removes the trigger for this LED. + + Writing "default" sets the trigger to the LED's default trigger + (which would often be configured in the device tree for the + hardware). + +What: /sys/class/leds/<led>/inverted +Date: January 2011 +KernelVersion: 2.6.38 +Contact: Richard Purdie <rpurdie@rpsys.net> +Description: + Invert the LED on/off state. This parameter is specific to + gpio and backlight triggers. In case of the backlight trigger, + it is useful when driving a LED which is intended to indicate + a device in a standby like state. |
