<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/acpi, branch linux-6.5.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.5.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.5.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2023-11-28T17:15:06Z</updated>
<entry>
<title>ACPI: FPDT: properly handle invalid FPDT subtables</title>
<updated>2023-11-28T17:15:06Z</updated>
<author>
<name>Vasily Khoruzhick</name>
<email>anarsoul@gmail.com</email>
</author>
<published>2023-09-27T19:50:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a7c6fa8ecdd349cbff444c00717801417cf61bdc'/>
<id>urn:sha1:a7c6fa8ecdd349cbff444c00717801417cf61bdc</id>
<content type='text'>
commit a83c68a3bf7c418c9a46693c63c638852b0c1f4e upstream.

Buggy BIOSes may have invalid FPDT subtables, e.g. on my hardware:

S3PT subtable:

7F20FE30: 53 33 50 54 24 00 00 00-00 00 00 00 00 00 18 01  *S3PT$...........*
7F20FE40: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
7F20FE50: 00 00 00 00

Here the first record has zero length.

FBPT subtable:

7F20FE50:             46 42 50 54-3C 00 00 00 46 42 50 54  *....FBPT&lt;...FBPT*
7F20FE60: 02 00 30 02 00 00 00 00-00 00 00 00 00 00 00 00  *..0.............*
7F20FE70: 2A A6 BC 6E 0B 00 00 00-1A 44 41 70 0B 00 00 00  **..n.....DAp....*
7F20FE80: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*

And here FBPT table has FBPT signature repeated instead of the first
record.

Current code will be looping indefinitely due to zero length records, so
break out of the loop if record length is zero.

While we are here, add proper handling for fpdt_process_subtable()
failures.

Fixes: d1eb86e59be0 ("ACPI: tables: introduce support for FPDT table")
Cc: All applicable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Vasily Khoruzhick &lt;anarsoul@gmail.com&gt;
[ rjw: Comment edit, added empty code lines ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: resource: Do IRQ override on TongFang GMxXGxx</title>
<updated>2023-11-28T17:15:02Z</updated>
<author>
<name>Werner Sembach</name>
<email>wse@tuxedocomputers.com</email>
</author>
<published>2023-10-16T16:08:28Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3055b7335604d3e97dcf21d9a36c5bc9f737a17e'/>
<id>urn:sha1:3055b7335604d3e97dcf21d9a36c5bc9f737a17e</id>
<content type='text'>
commit 0da9eccde3270b832c059ad618bf66e510c75d33 upstream.

The TongFang GMxXGxx/TUXEDO Stellaris/Pollaris Gen5 needs IRQ overriding
for the keyboard to work.

Adding an entry for this laptop to the override_table makes the internal
keyboard functional.

Signed-off-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Cc: All applicable &lt;stable@vger.kernel.org&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: EC: Add quirk for HP 250 G7 Notebook PC</title>
<updated>2023-11-28T17:14:43Z</updated>
<author>
<name>Jonathan Denose</name>
<email>jdenose@chromium.org</email>
</author>
<published>2023-10-24T14:13:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6a2c311fd0dc90e55cf32d2fb2da757de05907df'/>
<id>urn:sha1:6a2c311fd0dc90e55cf32d2fb2da757de05907df</id>
<content type='text'>
[ Upstream commit 891ddc03e2f4395e24795596e032f57d5ab37fe7 ]

Add GPE quirk entry for HP 250 G7 Notebook PC.

This change allows the lid switch to be identified as the lid switch
and not a keyboard button. With the lid switch properly identified, the
device triggers suspend correctly on lid close.

Signed-off-by: Jonathan Denose &lt;jdenose@google.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: APEI: Fix AER info corruption when error status data has multiple sections</title>
<updated>2023-11-28T17:14:42Z</updated>
<author>
<name>Shiju Jose</name>
<email>shiju.jose@huawei.com</email>
</author>
<published>2023-09-20T18:03:36Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=8d95caf80366408284adc3f04f6e2ade5dccccc0'/>
<id>urn:sha1:8d95caf80366408284adc3f04f6e2ade5dccccc0</id>
<content type='text'>
[ Upstream commit e2abc47a5a1a9f641e7cacdca643fdd40729bf6e ]

ghes_handle_aer() passes AER data to the PCI core for logging and
recovery by calling aer_recover_queue() with a pointer to struct
aer_capability_regs.

The problem was that aer_recover_queue() queues the pointer directly
without copying the aer_capability_regs data.  The pointer was to
the ghes-&gt;estatus buffer, which could be reused before
aer_recover_work_func() reads the data.

To avoid this problem, allocate a new aer_capability_regs structure
from the ghes_estatus_pool, copy the AER data from the ghes-&gt;estatus
buffer into it, pass a pointer to the new struct to
aer_recover_queue(), and free it after aer_recover_work_func() has
processed it.

Reported-by: Bjorn Helgaas &lt;helgaas@kernel.org&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Shiju Jose &lt;shiju.jose@huawei.com&gt;
[ rjw: Subject edits ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: sysfs: Fix create_pnp_modalias() and create_of_modalias()</title>
<updated>2023-11-20T10:56:54Z</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2023-10-23T18:32:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=729c4521d9767c6a32742e05873279e840cd60ac'/>
<id>urn:sha1:729c4521d9767c6a32742e05873279e840cd60ac</id>
<content type='text'>
[ Upstream commit 48cf49d31994ff97b33c4044e618560ec84d35fb ]

snprintf() does not return negative values on error.

To know if the buffer was too small, the returned value needs to be
compared with the length of the passed buffer. If it is greater or
equal, the output has been truncated, so add checks for the truncation
to create_pnp_modalias() and create_of_modalias(). Also make them
return -ENOMEM in that case, as they already do that elsewhere.

Moreover, the remaining size of the buffer used by snprintf() needs to
be updated after the first write to avoid out-of-bounds access as
already done correctly in create_pnp_modalias(), but not in
create_of_modalias(), so change the latter accordingly.

Fixes: 8765c5ba1949 ("ACPI / scan: Rework modalias creation when "compatible" is present")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
[ rjw: Merge two patches into one, combine changelogs, add subject ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: video: Add acpi_backlight=vendor quirk for Toshiba Portégé R100</title>
<updated>2023-11-20T10:56:50Z</updated>
<author>
<name>Ondrej Zary</name>
<email>linux@zary.sk</email>
</author>
<published>2023-09-29T20:20:55Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6fefd3a91f9dd53e96fead1c96d338bc14fbf666'/>
<id>urn:sha1:6fefd3a91f9dd53e96fead1c96d338bc14fbf666</id>
<content type='text'>
[ Upstream commit 35a341c9b25da6a479bd8013bcb11a680a7233e3 ]

Toshiba Portégé R100 has both acpi_video and toshiba_acpi vendor
backlight driver working. But none of them gets activated as it has
a VGA with no kernel driver (Trident CyberBlade XP4m32).

The DMI strings are very generic ("Portable PC") so add a custom
callback function to check for Trident CyberBlade XP4m32 PCI device
before enabling the vendor backlight driver (better than acpi_video
as it has more brightness steps).

Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default")
Signed-off-by: Ondrej Zary &lt;linux@zary.sk&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: property: Allow _DSD buffer data only for byte accessors</title>
<updated>2023-11-20T10:56:50Z</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2023-10-02T13:46:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3c243765ecffeb1cdf1142d0291813dfa257ffa1'/>
<id>urn:sha1:3c243765ecffeb1cdf1142d0291813dfa257ffa1</id>
<content type='text'>
[ Upstream commit 046ece773cc77ef5d2a1431b188ac3d0840ed150 ]

In accordance with ACPI specificication and _DSD data buffer
representation the data there is an array of bytes. Hence,
accessing it with something longer will create a sparse data
which is against of how device property APIs work in general
and also not defined in the ACPI specification (see [1]).
Fix the code to emit an error if non-byte accessor is used to
retrieve _DSD buffer data.

Fixes: 369af6bf2c28 ("ACPI: property: Read buffer properties as integers")
Link: https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html#buffer-declare-buffer-object # [1]
Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
[ rjw: Add missing braces ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI/NUMA: Apply SRAT proximity domain to entire CFMWS window</title>
<updated>2023-11-20T10:56:44Z</updated>
<author>
<name>Alison Schofield</name>
<email>alison.schofield@intel.com</email>
</author>
<published>2023-07-10T20:02:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b776e9161ab642c9bb8b8955f849e1e4ef447d74'/>
<id>urn:sha1:b776e9161ab642c9bb8b8955f849e1e4ef447d74</id>
<content type='text'>
[ Upstream commit 8f1004679987302b155f14b966ca6d4335814fcb ]

Commit fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each
CFMWS not in SRAT") did not account for the case where the BIOS
only partially describes a CFMWS Window in the SRAT. That means
the omitted address ranges, of a partially described CFMWS Window,
do not get assigned to a NUMA node.

Replace the call to phys_to_target_node() with numa_add_memblks().
Numa_add_memblks() searches an HPA range for existing memblk(s)
and extends those memblk(s) to fill the entire CFMWS Window.

Extending the existing memblks is a simple strategy that reuses
SRAT defined proximity domains from part of a window to fill out
the entire window, based on the knowledge* that all of a CFMWS
window is of a similar performance class.

*Note that this heuristic will evolve when CFMWS Windows present
a wider range of characteristics. The extension of the proximity
domain, implemented here, is likely a step in developing a more
sophisticated performance profile in the future.

There is no change in behavior when the SRAT does not describe
the CFMWS Window at all. In that case, a new NUMA node with a
single memblk covering the entire CFMWS Window is created.

Fixes: fd49f99c1809 ("ACPI: NUMA: Add a node and memblk for each CFMWS not in SRAT")
Reported-by: Derick Marks &lt;derick.w.marks@intel.com&gt;
Suggested-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Signed-off-by: Alison Schofield &lt;alison.schofield@intel.com&gt;
Signed-off-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Reviewed-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Tested-by: Derick Marks &lt;derick.w.marks@intel.com&gt;
Link: https://lore.kernel.org/all/eaa0b7cffb0951a126223eef3cbe7b55b8300ad9.1689018477.git.alison.schofield%40intel.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ACPI: bus: Move acpi_arm_init() to the place of after acpi_ghes_init()</title>
<updated>2023-10-25T10:16:22Z</updated>
<author>
<name>Hanjun Guo</name>
<email>guohanjun@huawei.com</email>
</author>
<published>2023-10-10T08:21:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b2c39ae29f2b1bf16944659f0bca999f945b9de0'/>
<id>urn:sha1:b2c39ae29f2b1bf16944659f0bca999f945b9de0</id>
<content type='text'>
commit d5921c460e543228d100daf67dac7a03dfaaa40a upstream.

acpi_agdi_init() in acpi_arm_init() will register a SDEI event, so
it needs the SDEI subsystem to be initialized (which is done in
acpi_ghes_init()) before the AGDI driver probing.

In commit fcea0ccf4fd7 ("ACPI: bus: Consolidate all arm specific
initialisation into acpi_arm_init()"), the acpi_agdi_init() was
called before acpi_ghes_init() and it causes following failure:

| [    0.515864] sdei: Failed to create event 1073741825: -5
| [    0.515866] agdi agdi.0: Failed to register for SDEI event 1073741825
| [    0.515867] agdi: probe of agdi.0 failed with error -5
| ...
| [    0.516022] sdei: SDEIv1.0 (0x0) detected in firmware.

Fix it by moving acpi_arm_init() to the place of after
acpi_ghes_init().

Fixes: fcea0ccf4fd7 ("ACPI: bus: Consolidate all arm specific initialisation into acpi_arm_init()")
Reported-by: D Scott Phillips &lt;scott@os.amperecomputing.com&gt;
Signed-off-by: Hanjun Guo &lt;guohanjun@huawei.com&gt;
Reviewed-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Tested-by: D Scott Phillips &lt;scott@os.amperecomputing.com&gt;
Cc: 6.5+ &lt;stable@vger.kernel.org&gt; # 6.5+
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ACPI: irq: Fix incorrect return value in acpi_register_gsi()</title>
<updated>2023-10-25T10:16:22Z</updated>
<author>
<name>Sunil V L</name>
<email>sunilvl@ventanamicro.com</email>
</author>
<published>2023-10-16T17:09:39Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=14189248711ec47977bd600382eff4d6548d17f7'/>
<id>urn:sha1:14189248711ec47977bd600382eff4d6548d17f7</id>
<content type='text'>
commit 0c21a18d5d6c6a73d098fb9b4701572370942df9 upstream.

acpi_register_gsi() should return a negative value in case of failure.

Currently, it returns the return value from irq_create_fwspec_mapping().
However, irq_create_fwspec_mapping() returns 0 for failure. Fix the
issue by returning -EINVAL if irq_create_fwspec_mapping() returns zero.

Fixes: d44fa3d46079 ("ACPI: Add support for ResourceSource/IRQ domain mapping")
Cc: 4.11+ &lt;stable@vger.kernel.org&gt; # 4.11+
Signed-off-by: Sunil V L &lt;sunilvl@ventanamicro.com&gt;
[ rjw: Rename a new local variable ]
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
