<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/i2c, branch v5.16-rc4</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>i2c: rk3x: Handle a spurious start completion interrupt flag</title>
<updated>2021-11-30T21:38:15+00:00</updated>
<author>
<name>Ondrej Jirman</name>
<email>megous@megous.com</email>
</author>
<published>2021-09-24T11:15:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=02fe0fbd8a21e183687925c3a266ae27dda9840f'/>
<id>02fe0fbd8a21e183687925c3a266ae27dda9840f</id>
<content type='text'>
In a typical read transfer, start completion flag is being set after
read finishes (notice ipd bit 4 being set):

trasnfer poll=0
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33

This causes I2C transfer being aborted in polled mode from a stop completion
handler:

trasnfer poll=1
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13
i2c stop
rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10

Clearing the START flag after read fixes the issue without any obvious
side effects.

This issue was dicovered on RK3566 when adding support for powering
off the RK817 PMIC.

Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a typical read transfer, start completion flag is being set after
read finishes (notice ipd bit 4 being set):

trasnfer poll=0
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 33

This causes I2C transfer being aborted in polled mode from a stop completion
handler:

trasnfer poll=1
i2c start
rk3x-i2c fdd40000.i2c: IRQ: state 1, ipd: 10
i2c read
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 0
rk3x-i2c fdd40000.i2c: IRQ: state 2, ipd: 1b
i2c stop
rk3x-i2c fdd40000.i2c: IRQ: state 4, ipd: 13
i2c stop
rk3x-i2c fdd40000.i2c: unexpected irq in STOP: 0x10

Clearing the START flag after read fixes the issue without any obvious
side effects.

This issue was dicovered on RK3566 when adding support for powering
off the RK817 PMIC.

Signed-off-by: Ondrej Jirman &lt;megous@megous.com&gt;
Reviewed-by: John Keeping &lt;john@metanate.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: stm32f7: use proper DMAENGINE API for termination</title>
<updated>2021-11-30T09:22:14+00:00</updated>
<author>
<name>Alain Volmat</name>
<email>alain.volmat@foss.st.com</email>
</author>
<published>2021-09-20T15:21:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1229f82deaece681cda664d95c856b68062aa159'/>
<id>1229f82deaece681cda664d95c856b68062aa159</id>
<content type='text'>
dmaengine_terminate_all() is deprecated in favor of explicitly saying if
it should be sync or async.  Here, we use dmaengine_terminate_sync in
i2c_xfer and i2c_smbus_xfer handlers and rely on
dmaengine_terminate_async within interrupt handlers
(transmission error cases).
dmaengine_synchronize is added within i2c_xfer and i2c_smbus_xfer handler
to finalize terminate started in interrupt handlers.

Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
dmaengine_terminate_all() is deprecated in favor of explicitly saying if
it should be sync or async.  Here, we use dmaengine_terminate_sync in
i2c_xfer and i2c_smbus_xfer handlers and rely on
dmaengine_terminate_async within interrupt handlers
(transmission error cases).
dmaengine_synchronize is added within i2c_xfer and i2c_smbus_xfer handler
to finalize terminate started in interrupt handlers.

Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: stm32f7: stop dma transfer in case of NACK</title>
<updated>2021-11-30T09:22:11+00:00</updated>
<author>
<name>Alain Volmat</name>
<email>alain.volmat@foss.st.com</email>
</author>
<published>2021-09-20T15:21:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=31b90a95ccbbb4b628578ac17e3b3cc8eeacfe31'/>
<id>31b90a95ccbbb4b628578ac17e3b3cc8eeacfe31</id>
<content type='text'>
In case of receiving a NACK, the dma transfer should be stopped
to avoid feeding data into the FIFO.
Also ensure to properly return the proper error code and avoid
waiting for the end of the dma completion in case of
error happening during the transmission.

Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In case of receiving a NACK, the dma transfer should be stopped
to avoid feeding data into the FIFO.
Also ensure to properly return the proper error code and avoid
waiting for the end of the dma completion in case of
error happening during the transmission.

Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: stm32f7: recover the bus on access timeout</title>
<updated>2021-11-30T09:22:07+00:00</updated>
<author>
<name>Alain Volmat</name>
<email>alain.volmat@foss.st.com</email>
</author>
<published>2021-09-20T15:21:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b933d1faf8fa30d16171bcff404e39c41b2a7c84'/>
<id>b933d1faf8fa30d16171bcff404e39c41b2a7c84</id>
<content type='text'>
When getting an access timeout, ensure that the bus is in a proper
state prior to returning the error.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When getting an access timeout, ensure that the bus is in a proper
state prior to returning the error.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: stm32f7: flush TX FIFO upon transfer errors</title>
<updated>2021-11-29T12:11:50+00:00</updated>
<author>
<name>Alain Volmat</name>
<email>alain.volmat@foss.st.com</email>
</author>
<published>2021-09-20T15:21:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0c21d02ca469574d2082379db52d1a27b99eed0c'/>
<id>0c21d02ca469574d2082379db52d1a27b99eed0c</id>
<content type='text'>
While handling an error during transfer (ex: NACK), it could
happen that the driver has already written data into TXDR
before the transfer get stopped.
This commit add TXDR Flush after end of transfer in case of error to
avoid sending a wrong data on any other slave upon next transfer.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While handling an error during transfer (ex: NACK), it could
happen that the driver has already written data into TXDR
before the transfer get stopped.
This commit add TXDR Flush after end of transfer in case of error to
avoid sending a wrong data on any other slave upon next transfer.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: Alain Volmat &lt;alain.volmat@foss.st.com&gt;
Reviewed-by: Pierre-Yves MORDRET &lt;pierre-yves.mordret@foss.st.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: cbus-gpio: set atomic transfer callback</title>
<updated>2021-11-29T08:52:10+00:00</updated>
<author>
<name>Aaro Koskinen</name>
<email>aaro.koskinen@iki.fi</email>
</author>
<published>2021-11-27T19:42:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b12764695c3fcade145890b67f82f8b139174cc7'/>
<id>b12764695c3fcade145890b67f82f8b139174cc7</id>
<content type='text'>
CBUS transfers have always been atomic, but after commit 63b96983a5dd
("i2c: core: introduce callbacks for atomic transfers") we started to see
warnings during e.g. poweroff as the atomic callback is not explicitly set.
Fix that.

Fixes the following WARNING seen during Nokia N810 power down:

[  786.570617] reboot: Power down
[  786.573913] ------------[ cut here ]------------
[  786.578826] WARNING: CPU: 0 PID: 672 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x110
[  786.587799] No atomic I2C transfer handler for 'i2c-2'

Fixes: 63b96983a5dd ("i2c: core: introduce callbacks for atomic transfers")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CBUS transfers have always been atomic, but after commit 63b96983a5dd
("i2c: core: introduce callbacks for atomic transfers") we started to see
warnings during e.g. poweroff as the atomic callback is not explicitly set.
Fix that.

Fixes the following WARNING seen during Nokia N810 power down:

[  786.570617] reboot: Power down
[  786.573913] ------------[ cut here ]------------
[  786.578826] WARNING: CPU: 0 PID: 672 at drivers/i2c/i2c-core.h:40 i2c_smbus_xfer+0x100/0x110
[  786.587799] No atomic I2C transfer handler for 'i2c-2'

Fixes: 63b96983a5dd ("i2c: core: introduce callbacks for atomic transfers")
Signed-off-by: Aaro Koskinen &lt;aaro.koskinen@iki.fi&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: virtio: disable timeout handling</title>
<updated>2021-11-23T09:55:48+00:00</updated>
<author>
<name>Vincent Whitchurch</name>
<email>vincent.whitchurch@axis.com</email>
</author>
<published>2021-11-11T16:04:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=84e1d0bf1d7121759622dabf8fbef4c99ad597c5'/>
<id>84e1d0bf1d7121759622dabf8fbef4c99ad597c5</id>
<content type='text'>
If a timeout is hit, it can result is incorrect data on the I2C bus
and/or memory corruptions in the guest since the device can still be
operating on the buffers it was given while the guest has freed them.

Here is, for example, the start of a slub_debug splat which was
triggered on the next transfer after one transfer was forced to timeout
by setting a breakpoint in the backend (rust-vmm/vhost-device):

 BUG kmalloc-1k (Not tainted): Poison overwritten
 First byte 0x1 instead of 0x6b
 Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29
 	__kmalloc+0xc2/0x1c9
 	virtio_i2c_xfer+0x65/0x35c
 	__i2c_transfer+0x429/0x57d
 	i2c_transfer+0x115/0x134
 	i2cdev_ioctl_rdwr+0x16a/0x1de
 	i2cdev_ioctl+0x247/0x2ed
 	vfs_ioctl+0x21/0x30
 	sys_ioctl+0xb18/0xb41
 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29
 	kfree+0x1bd/0x1cc
 	virtio_i2c_xfer+0x32e/0x35c
 	__i2c_transfer+0x429/0x57d
 	i2c_transfer+0x115/0x134
 	i2cdev_ioctl_rdwr+0x16a/0x1de
 	i2cdev_ioctl+0x247/0x2ed
 	vfs_ioctl+0x21/0x30
 	sys_ioctl+0xb18/0xb41

There is no simple fix for this (the driver would have to always create
bounce buffers and hold on to them until the device eventually returns
the buffers), so just disable the timeout support for now.

Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Jie Deng &lt;jie.deng@intel.com&gt;
Signed-off-by: Vincent Whitchurch &lt;vincent.whitchurch@axis.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a timeout is hit, it can result is incorrect data on the I2C bus
and/or memory corruptions in the guest since the device can still be
operating on the buffers it was given while the guest has freed them.

Here is, for example, the start of a slub_debug splat which was
triggered on the next transfer after one transfer was forced to timeout
by setting a breakpoint in the backend (rust-vmm/vhost-device):

 BUG kmalloc-1k (Not tainted): Poison overwritten
 First byte 0x1 instead of 0x6b
 Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29
 	__kmalloc+0xc2/0x1c9
 	virtio_i2c_xfer+0x65/0x35c
 	__i2c_transfer+0x429/0x57d
 	i2c_transfer+0x115/0x134
 	i2cdev_ioctl_rdwr+0x16a/0x1de
 	i2cdev_ioctl+0x247/0x2ed
 	vfs_ioctl+0x21/0x30
 	sys_ioctl+0xb18/0xb41
 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29
 	kfree+0x1bd/0x1cc
 	virtio_i2c_xfer+0x32e/0x35c
 	__i2c_transfer+0x429/0x57d
 	i2c_transfer+0x115/0x134
 	i2cdev_ioctl_rdwr+0x16a/0x1de
 	i2cdev_ioctl+0x247/0x2ed
 	vfs_ioctl+0x21/0x30
 	sys_ioctl+0xb18/0xb41

There is no simple fix for this (the driver would have to always create
bounce buffers and hold on to them until the device eventually returns
the buffers), so just disable the timeout support for now.

Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
Acked-by: Jie Deng &lt;jie.deng@intel.com&gt;
Signed-off-by: Vincent Whitchurch &lt;vincent.whitchurch@axis.com&gt;
Acked-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Reviewed-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: i801: Fix interrupt storm from SMB_ALERT signal</title>
<updated>2021-11-23T09:43:50+00:00</updated>
<author>
<name>Jarkko Nikula</name>
<email>jarkko.nikula@linux.intel.com</email>
</author>
<published>2021-11-17T09:45:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=03a976c9afb5e3c4f8260c6c08a27d723b279c92'/>
<id>03a976c9afb5e3c4f8260c6c08a27d723b279c92</id>
<content type='text'>
Currently interrupt storm will occur from i2c-i801 after first
transaction if SMB_ALERT signal is enabled and ever asserted. It is
enough if the signal is asserted once even before the driver is loaded
and does not recover because that interrupt is not acknowledged.

This fix aims to fix it by two ways:
- Add acknowledging for the SMB_ALERT interrupt status
- Disable the SMB_ALERT interrupt on platforms where possible since the
  driver currently does not make use for it

Acknowledging resets the SMB_ALERT interrupt status on all platforms and
also should help to avoid interrupt storm on older platforms where the
SMB_ALERT interrupt disabling is not available.

For simplicity this fix reuses the host notify feature for disabling and
restoring original register value.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311
Reported-by: ck+kernelbugzilla@bl4ckb0x.de
Reported-by: stephane.poignant@protonmail.com
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Tested-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently interrupt storm will occur from i2c-i801 after first
transaction if SMB_ALERT signal is enabled and ever asserted. It is
enough if the signal is asserted once even before the driver is loaded
and does not recover because that interrupt is not acknowledged.

This fix aims to fix it by two ways:
- Add acknowledging for the SMB_ALERT interrupt status
- Disable the SMB_ALERT interrupt on platforms where possible since the
  driver currently does not make use for it

Acknowledging resets the SMB_ALERT interrupt status on all platforms and
also should help to avoid interrupt storm on older platforms where the
SMB_ALERT interrupt disabling is not available.

For simplicity this fix reuses the host notify feature for disabling and
restoring original register value.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311
Reported-by: ck+kernelbugzilla@bl4ckb0x.de
Reported-by: stephane.poignant@protonmail.com
Signed-off-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Tested-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: i801: Restore INTREN on unload</title>
<updated>2021-11-23T09:43:50+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2021-11-09T15:02:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9b5bf5878138293fb5b14a48a7a17b6ede6bea25'/>
<id>9b5bf5878138293fb5b14a48a7a17b6ede6bea25</id>
<content type='text'>
If driver interrupts are enabled, SMBHSTCNT_INTREN will be 1 after
the first transaction, and will stay to that value forever. This
means that interrupts will be generated for both host-initiated
transactions and also SMBus Alert events even after the driver is
unloaded. To be on the safe side, we should restore the initial state
of this bit at suspend and reboot time, as we do for several other
configuration bits already and for the same reason: the BIOS should
be handed the device in the same configuration state in which we
received it. Otherwise interrupts may be generated which nobody
will process.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Tested-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If driver interrupts are enabled, SMBHSTCNT_INTREN will be 1 after
the first transaction, and will stay to that value forever. This
means that interrupts will be generated for both host-initiated
transactions and also SMBus Alert events even after the driver is
unloaded. To be on the safe side, we should restore the initial state
of this bit at suspend and reboot time, as we do for several other
configuration bits already and for the same reason: the BIOS should
be handed the device in the same configuration state in which we
received it. Otherwise interrupts may be generated which nobody
will process.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Tested-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'acpi-5.16-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm</title>
<updated>2021-11-10T19:52:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2021-11-10T19:52:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=285fc3db0aeb7befdba433e286fa994dc9c9874d'/>
<id>285fc3db0aeb7befdba433e286fa994dc9c9874d</id>
<content type='text'>
Pull more ACPI updates from Rafael Wysocki:
 "These add support for a new ACPI device configuration object called
  _DSC, fix some issues including one recent regression, add two new
  items to quirk lists and clean up assorted pieces of code.

  Specifics:

   - Add support for new ACPI device configuration object called _DSC
     ("Deepest State for Configuration") to allow certain devices to be
     probed without changing their power states, document it and make
     two drivers use it (Sakari Ailus, Rajmohan Mani).

   - Fix device wakeup power reference counting broken recently by
     mistake (Rafael Wysocki).

   - Drop unused symbol and macros depending on it from acgcc.h (Rafael
     Wysocki).

   - Add HP ZHAN 66 Pro to the "no EC wakeup" quirk list (Binbin Zhou).

   - Add Xiaomi Mi Pad 2 to the backlight quirk list and drop an unused
     piece of data from all of the list entries (Hans de Goede).

   - Fix register read accesses handling in the Intel PMIC operation
     region driver (Hans de Goede).

   - Clean up static variables initialization in the EC driver
     (wangzhitong)"

* tag 'acpi-5.16-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Documentation: ACPI: Fix non-D0 probe _DSC object example
  ACPI: Drop ACPI_USE_BUILTIN_STDARG ifdef from acgcc.h
  ACPI: PM: Fix device wakeup power reference counting error
  ACPI: video: use platform backlight driver on Xiaomi Mi Pad 2
  ACPI: video: Drop dmi_system_id.ident settings from video_detect_dmi_table[]
  ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses
  ACPI: EC: Remove initialization of static variables to false
  ACPI: EC: Use ec_no_wakeup on HP ZHAN 66 Pro
  at24: Support probing while in non-zero ACPI D state
  media: i2c: imx319: Support device probe in non-zero ACPI D state
  ACPI: Add a convenience function to tell a device is in D0 state
  Documentation: ACPI: Document _DSC object usage for enum power state
  i2c: Allow an ACPI driver to manage the device's power state during probe
  ACPI: scan: Obtain device's desired enumeration power state
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull more ACPI updates from Rafael Wysocki:
 "These add support for a new ACPI device configuration object called
  _DSC, fix some issues including one recent regression, add two new
  items to quirk lists and clean up assorted pieces of code.

  Specifics:

   - Add support for new ACPI device configuration object called _DSC
     ("Deepest State for Configuration") to allow certain devices to be
     probed without changing their power states, document it and make
     two drivers use it (Sakari Ailus, Rajmohan Mani).

   - Fix device wakeup power reference counting broken recently by
     mistake (Rafael Wysocki).

   - Drop unused symbol and macros depending on it from acgcc.h (Rafael
     Wysocki).

   - Add HP ZHAN 66 Pro to the "no EC wakeup" quirk list (Binbin Zhou).

   - Add Xiaomi Mi Pad 2 to the backlight quirk list and drop an unused
     piece of data from all of the list entries (Hans de Goede).

   - Fix register read accesses handling in the Intel PMIC operation
     region driver (Hans de Goede).

   - Clean up static variables initialization in the EC driver
     (wangzhitong)"

* tag 'acpi-5.16-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Documentation: ACPI: Fix non-D0 probe _DSC object example
  ACPI: Drop ACPI_USE_BUILTIN_STDARG ifdef from acgcc.h
  ACPI: PM: Fix device wakeup power reference counting error
  ACPI: video: use platform backlight driver on Xiaomi Mi Pad 2
  ACPI: video: Drop dmi_system_id.ident settings from video_detect_dmi_table[]
  ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses
  ACPI: EC: Remove initialization of static variables to false
  ACPI: EC: Use ec_no_wakeup on HP ZHAN 66 Pro
  at24: Support probing while in non-zero ACPI D state
  media: i2c: imx319: Support device probe in non-zero ACPI D state
  ACPI: Add a convenience function to tell a device is in D0 state
  Documentation: ACPI: Document _DSC object usage for enum power state
  i2c: Allow an ACPI driver to manage the device's power state during probe
  ACPI: scan: Obtain device's desired enumeration power state
</pre>
</div>
</content>
</entry>
</feed>
