tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge branches 'acpi-debug' and 'acpi-docs'
Merge an update related to ACPI debugging and ACPI documentation updates
for 6.17-rc1:
- Enable CONFIG_ACPI_DEBUG by default to make it easier to get ACPI
debug messages from OEM platforms (Mario Limonciello)
- Fix parent device references in ASL examples in the ACPI
documentation and fix spelling and style in the gpio-properties
documentation in firmware-guide (Andy Shevchenko)
* acpi-debug:
ACPI: Enable CONFIG_ACPI_DEBUG by default
* acpi-docs:
Documentation: ACPI: Fix parent device references
Documentation: firmware-guide: gpio-properties: Spelling and style fixes
+20
-19
+15
-15
Documentation/firmware-guide/acpi/gpio-properties.rst
+15
-15
Documentation/firmware-guide/acpi/gpio-properties.rst
···
6
6
7
7
With the release of ACPI 5.1, the _DSD configuration object finally
8
8
allows names to be given to GPIOs (and other things as well) returned
9
-
by _CRS. Previously, we were only able to use an integer index to find
9
+
by _CRS. Previously we were only able to use an integer index to find
10
10
the corresponding GPIO, which is pretty error prone (it depends on
11
11
the _CRS output ordering, for example).
12
12
···
49
49
pin
50
50
Pin in the GpioIo()/GpioInt() resource. Typically this is zero.
51
51
active_low
52
-
If 1, the GPIO is marked as active_low.
52
+
If 1, the GPIO is marked as active-low.
53
53
54
54
Since ACPI GpioIo() resource does not have a field saying whether it is
55
-
active low or high, the "active_low" argument can be used here. Setting
56
-
it to 1 marks the GPIO as active low.
55
+
active-low or active-high, the "active_low" argument can be used here.
56
+
Setting it to 1 marks the GPIO as active-low.
57
57
58
58
Note, active_low in _DSD does not make sense for GpioInt() resource and
59
59
must be 0. GpioInt() resource has its own means of defining it.
···
231
231
available to the driver can be used to identify the device and that is supposed
232
232
to be sufficient to determine the meaning and purpose of all of the GPIO lines
233
233
listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words,
234
-
the driver is supposed to know what to use the GpioIo()/GpioInt() resources for
235
-
once it has identified the device. Having done that, it can simply assign names
234
+
the driver is supposed to know what to use from the GpioIo()/GpioInt() resources
235
+
for once it has identified the device. Having done that, it can simply assign names
236
236
to the GPIO lines it is going to use and provide the GPIO subsystem with a
237
237
mapping between those names and the ACPI GPIO resources corresponding to them.
238
238
···
252
252
static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false };
253
253
254
254
static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = {
255
-
{ "reset-gpios", &reset_gpio, 1 },
256
-
{ "shutdown-gpios", &shutdown_gpio, 1 },
257
-
{ }
255
+
{ "reset-gpios", &reset_gpio, 1 },
256
+
{ "shutdown-gpios", &shutdown_gpio, 1 },
257
+
{ }
258
258
};
259
259
260
260
Next, the mapping table needs to be passed as the second argument to
···
270
270
271
271
If a device does not have _DSD or the driver does not create ACPI GPIO
272
272
mapping, the Linux GPIO framework refuses to return any GPIOs. This is
273
-
because the driver does not know what it actually gets. For example if we
273
+
because the driver does not know what it actually gets. For example, if we
274
274
have a device like below::
275
275
276
276
Device (BTH)
···
292
292
...error handling...
293
293
294
294
but since there is no way to know the mapping between "reset" and
295
-
the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT).
295
+
the GpioIo() in _CRS the desc will hold ERR_PTR(-ENOENT).
296
296
297
297
The driver author can solve this by passing the mapping explicitly
298
298
(this is the recommended way and it's documented in the above chapter).
···
318
318
desc = gpiod_get(dev, "non-null-connection-id", flags);
319
319
desc = gpiod_get_index(dev, "non-null-connection-id", index, flags);
320
320
321
+
Case 1 assumes that corresponding ACPI device description must have
322
+
defined device properties and will prevent from getting any GPIO resources
323
+
otherwise.
324
+
321
325
Case 2::
322
326
323
327
desc = gpiod_get(dev, NULL, flags);
324
328
desc = gpiod_get_index(dev, NULL, index, flags);
325
-
326
-
Case 1 assumes that corresponding ACPI device description must have
327
-
defined device properties and will prevent to getting any GPIO resources
328
-
otherwise.
329
329
330
330
Case 2 explicitly tells GPIO core to look for resources in _CRS.
331
331
+4
-4
Documentation/firmware-guide/acpi/i2c-muxes.rst
+4
-4
Documentation/firmware-guide/acpi/i2c-muxes.rst
···
14
14
| | | 0x70 |--CH01--> i2c client B (0x50)
15
15
+------+ +------+
16
16
17
-
which corresponds to the following ASL::
17
+
which corresponds to the following ASL (in the scope of \_SB)::
18
18
19
19
Device (SMB1)
20
20
{
···
24
24
Name (_HID, ...)
25
25
Name (_CRS, ResourceTemplate () {
26
26
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
27
-
AddressingMode7Bit, "^SMB1", 0x00,
27
+
AddressingMode7Bit, "\\_SB.SMB1", 0x00,
28
28
ResourceConsumer,,)
29
29
}
30
30
···
37
37
Name (_HID, ...)
38
38
Name (_CRS, ResourceTemplate () {
39
39
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
40
-
AddressingMode7Bit, "^CH00", 0x00,
40
+
AddressingMode7Bit, "\\_SB.SMB1.CH00", 0x00,
41
41
ResourceConsumer,,)
42
42
}
43
43
}
···
52
52
Name (_HID, ...)
53
53
Name (_CRS, ResourceTemplate () {
54
54
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
55
-
AddressingMode7Bit, "^CH01", 0x00,
55
+
AddressingMode7Bit, "\\_SB.SMB1.CH01", 0x00,
56
56
ResourceConsumer,,)
57
57
}
58
58
}