<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/i2c, branch linux-6.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.12.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-13T16:20:43Z</updated>
<entry>
<title>i2c: i801: Revert "i2c: i801: replace acpi_lock with I2C bus lock"</title>
<updated>2026-03-13T16:20:43Z</updated>
<author>
<name>Charles Haithcock</name>
<email>chaithco@redhat.com</email>
</author>
<published>2026-02-28T01:41:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=9507f9953a2a5647eb42668d0c243fdbd7e72954'/>
<id>urn:sha1:9507f9953a2a5647eb42668d0c243fdbd7e72954</id>
<content type='text'>
[ Upstream commit cfc69c2e6c699c96949f7b0455195b0bfb7dc715 ]

This reverts commit f707d6b9e7c18f669adfdb443906d46cfbaaa0c1.

Under rare circumstances, multiple udev threads can collect i801 device
info on boot and walk i801_acpi_io_handler somewhat concurrently. The
first will note the area is reserved by acpi to prevent further touches.
This ultimately causes the area to be deregistered. The second will
enter i801_acpi_io_handler after the area is unregistered but before a
check can be made that the area is unregistered. i2c_lock_bus relies on
the now unregistered area containing lock_ops to lock the bus. The end
result is a kernel panic on boot with the following backtrace;

[   14.971872] ioatdma 0000:09:00.2: enabling device (0100 -&gt; 0102)
[   14.971873] BUG: kernel NULL pointer dereference, address: 0000000000000000
[   14.971880] #PF: supervisor read access in kernel mode
[   14.971884] #PF: error_code(0x0000) - not-present page
[   14.971887] PGD 0 P4D 0
[   14.971894] Oops: 0000 [#1] PREEMPT SMP PTI
[   14.971900] CPU: 5 PID: 956 Comm: systemd-udevd Not tainted 5.14.0-611.5.1.el9_7.x86_64 #1
[   14.971905] Hardware name: XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10.SV91 01/30/2023
[   14.971908] RIP: 0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]
[   14.971929] Code: 00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 54 49 89 f4 be 02 00 00 00 55 4c 89 c5 53 89 fb &lt;48&gt; 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b
[   14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282
[   14.971938] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9685e01ba568
[   14.971941] RDX: 0000000000000008 RSI: 0000000000000002 RDI: 0000000000000000
[   14.971944] RBP: ffff9685ca22f028 R08: ffff9685ca22f028 R09: ffff9685ca22f028
[   14.971948] R10: 000000000000000b R11: 0000000000000580 R12: 0000000000000580
[   14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000
[   14.971954] FS:  00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000
[   14.971959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   14.971963] CR2: 0000000000000000 CR3: 0000000168090001 CR4: 00000000003706f0
[   14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   14.971972] Call Trace:
[   14.971977]  &lt;TASK&gt;
[   14.971981]  ? show_trace_log_lvl+0x1c4/0x2df
[   14.971994]  ? show_trace_log_lvl+0x1c4/0x2df
[   14.972003]  ? acpi_ev_address_space_dispatch+0x16e/0x3c0
[   14.972014]  ? __die_body.cold+0x8/0xd
[   14.972021]  ? page_fault_oops+0x132/0x170
[   14.972028]  ? exc_page_fault+0x61/0x150
[   14.972036]  ? asm_exc_page_fault+0x22/0x30
[   14.972045]  ? i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]
[   14.972061]  acpi_ev_address_space_dispatch+0x16e/0x3c0
[   14.972069]  ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801]
[   14.972085]  acpi_ex_access_region+0x5b/0xd0
[   14.972093]  acpi_ex_field_datum_io+0x73/0x2e0
[   14.972100]  acpi_ex_read_data_from_field+0x8e/0x230
[   14.972106]  acpi_ex_resolve_node_to_value+0x23d/0x310
[   14.972114]  acpi_ds_evaluate_name_path+0xad/0x110
[   14.972121]  acpi_ds_exec_end_op+0x321/0x510
[   14.972127]  acpi_ps_parse_loop+0xf7/0x680
[   14.972136]  acpi_ps_parse_aml+0x17a/0x3d0
[   14.972143]  acpi_ps_execute_method+0x137/0x270
[   14.972150]  acpi_ns_evaluate+0x1f4/0x2e0
[   14.972158]  acpi_evaluate_object+0x134/0x2f0
[   14.972164]  acpi_evaluate_integer+0x50/0xe0
[   14.972173]  ? vsnprintf+0x24b/0x570
[   14.972181]  acpi_ac_get_state.part.0+0x23/0x70
[   14.972189]  get_ac_property+0x4e/0x60
[   14.972195]  power_supply_show_property+0x90/0x1f0
[   14.972205]  add_prop_uevent+0x29/0x90
[   14.972213]  power_supply_uevent+0x109/0x1d0
[   14.972222]  dev_uevent+0x10e/0x2f0
[   14.972228]  uevent_show+0x8e/0x100
[   14.972236]  dev_attr_show+0x19/0x40
[   14.972246]  sysfs_kf_seq_show+0x9b/0x100
[   14.972253]  seq_read_iter+0x120/0x4b0
[   14.972262]  ? selinux_file_permission+0x106/0x150
[   14.972273]  vfs_read+0x24f/0x3a0
[   14.972284]  ksys_read+0x5f/0xe0
[   14.972291]  do_syscall_64+0x5f/0xe0
...

The kernel panic is mitigated by setting limiting the count of udev
children to 1. Revert to using the acpi_lock to continue protecting
marking the area as owned by firmware without relying on a lock in
a potentially unmapped region of memory.

Fixes: f707d6b9e7c1 ("i2c: i801: replace acpi_lock with I2C bus lock")
Signed-off-by: Charles Haithcock &lt;chaithco@redhat.com&gt;
[wsa: added Fixes-tag and updated comment stating the importance of the lock]
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: riic: Move suspend handling to NOIRQ phase</title>
<updated>2026-01-23T10:18:46Z</updated>
<author>
<name>Tommaso Merciai</name>
<email>tommaso.merciai.xr@bp.renesas.com</email>
</author>
<published>2025-12-18T15:10:21Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=469f8fe4c87e43520f279e45b927c35d6fe99194'/>
<id>urn:sha1:469f8fe4c87e43520f279e45b927c35d6fe99194</id>
<content type='text'>
commit e383f0961422f983451ac4dd6aed1a3d3311f2be upstream.

Commit 53326135d0e0 ("i2c: riic: Add suspend/resume support") added
suspend support for the Renesas I2C driver and following this change
on RZ/G3E the following WARNING is seen on entering suspend ...

[  134.275704] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[  134.285536] ------------[ cut here ]------------
[  134.290298] i2c i2c-2: Transfer while suspended
[  134.295174] WARNING: drivers/i2c/i2c-core.h:56 at __i2c_smbus_xfer+0x1e4/0x214, CPU#0: systemd-sleep/388
[  134.365507] Tainted: [W]=WARN
[  134.368485] Hardware name: Renesas SMARC EVK version 2 based on r9a09g047e57 (DT)
[  134.375961] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  134.382935] pc : __i2c_smbus_xfer+0x1e4/0x214
[  134.387329] lr : __i2c_smbus_xfer+0x1e4/0x214
[  134.391717] sp : ffff800083f23860
[  134.395040] x29: ffff800083f23860 x28: 0000000000000000 x27: ffff800082ed5d60
[  134.402226] x26: 0000001f4395fd74 x25: 0000000000000007 x24: 0000000000000001
[  134.409408] x23: 0000000000000000 x22: 000000000000006f x21: ffff800083f23936
[  134.416589] x20: ffff0000c090e140 x19: ffff0000c090e0d0 x18: 0000000000000006
[  134.423771] x17: 6f63657320313030 x16: 2e30206465737061 x15: ffff800083f23280
[  134.430953] x14: 0000000000000000 x13: ffff800082b16ce8 x12: 0000000000000f09
[  134.438134] x11: 0000000000000503 x10: ffff800082b6ece8 x9 : ffff800082b16ce8
[  134.445315] x8 : 00000000ffffefff x7 : ffff800082b6ece8 x6 : 80000000fffff000
[  134.452495] x5 : 0000000000000504 x4 : 0000000000000000 x3 : 0000000000000000
[  134.459672] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c9ee9e80
[  134.466851] Call trace:
[  134.469311]  __i2c_smbus_xfer+0x1e4/0x214 (P)
[  134.473715]  i2c_smbus_xfer+0xbc/0x120
[  134.477507]  i2c_smbus_read_byte_data+0x4c/0x84
[  134.482077]  isl1208_i2c_read_time+0x44/0x178 [rtc_isl1208]
[  134.487703]  isl1208_rtc_read_time+0x14/0x20 [rtc_isl1208]
[  134.493226]  __rtc_read_time+0x44/0x88
[  134.497012]  rtc_read_time+0x3c/0x68
[  134.500622]  rtc_suspend+0x9c/0x170

The warning is triggered because I2C transfers can still be attempted
while the controller is already suspended, due to inappropriate ordering
of the system sleep callbacks.

If the controller is autosuspended, there is no way to wake it up once
runtime PM disabled (in suspend_late()). During system resume, the I2C
controller will be available only after runtime PM is re-enabled
(in resume_early()). However, this may be too late for some devices.

Wake up the controller in the suspend() callback while runtime PM is
still enabled. The I2C controller will remain available until the
suspend_noirq() callback (pm_runtime_force_suspend()) is called. During
resume, the I2C controller can be restored by the resume_noirq() callback
(pm_runtime_force_resume()). Finally, the resume() callback re-enables
autosuspend. As a result, the I2C controller can remain available until
the system enters suspend_noirq() and from resume_noirq().

Cc: stable@vger.kernel.org
Fixes: 53326135d0e0 ("i2c: riic: Add suspend/resume support")
Signed-off-by: Tommaso Merciai &lt;tommaso.merciai.xr@bp.renesas.com&gt;
Reviewed-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Tested-by: Biju Das &lt;biju.das.jz@bp.renesas.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i2c: qcom-geni: make sure I2C hub controllers can't use SE DMA</title>
<updated>2026-01-23T10:18:42Z</updated>
<author>
<name>Neil Armstrong</name>
<email>neil.armstrong@linaro.org</email>
</author>
<published>2025-10-29T18:07:42Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=36c627d3a2ba6333585b9884583ba62434507c26'/>
<id>urn:sha1:36c627d3a2ba6333585b9884583ba62434507c26</id>
<content type='text'>
[ Upstream commit c0c50e3743e467ec4752c638e10e97f89c8644e2 ]

The I2C Hub controller is a simpler GENI I2C variant that doesn't
support DMA at all, add a no_dma flag to make sure it nevers selects
the SE DMA mode with mappable 32bytes long transfers.

Fixes: cacd9643eca7 ("i2c: qcom-geni: add support for I2C Master Hub variant")
Signed-off-by: Neil Armstrong &lt;neil.armstrong@linaro.org&gt;
Reviewed-by: Konrad Dybcio &lt;konrad.dybcio@oss.qualcomm.com&gt;
Reviewed-by: Mukesh Kumar Savaliya &lt;mukesh.savaliya@oss.qualcomm.com&gt;&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: amd-mp2: fix reference leak in MP2 PCI device</title>
<updated>2026-01-08T09:14:30Z</updated>
<author>
<name>Ma Ke</name>
<email>make24@iscas.ac.cn</email>
</author>
<published>2025-10-22T09:54:02Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=36f3cc056dd8596ce2e7c146c78414eda0e468a8'/>
<id>urn:sha1:36f3cc056dd8596ce2e7c146c78414eda0e468a8</id>
<content type='text'>
commit a6ee6aac66fb394b7f6e6187c73bdcd873f2d139 upstream.

In i2c_amd_probe(), amd_mp2_find_device() utilizes
driver_find_next_device() which internally calls driver_find_device()
to locate the matching device. driver_find_device() increments the
reference count of the found device by calling get_device(), but
amd_mp2_find_device() fails to call put_device() to decrement the
reference count before returning. This results in a reference count
leak of the PCI device each time i2c_amd_probe() is executed, which
may prevent the device from being properly released and cause a memory
leak.

Found by code review.

Cc: stable@vger.kernel.org
Fixes: 529766e0a011 ("i2c: Add drivers for the AMD PCIe MP2 I2C controller")
Signed-off-by: Ma Ke &lt;make24@iscas.ac.cn&gt;
Signed-off-by: Andi Shyti &lt;andi.shyti@kernel.org&gt;
Link: https://lore.kernel.org/r/20251022095402.8846-1-make24@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i2c: designware: Disable SMBus interrupts to prevent storms from mis-configured firmware</title>
<updated>2026-01-08T09:14:12Z</updated>
<author>
<name>Jinhui Guo</name>
<email>guojinhui.liam@bytedance.com</email>
</author>
<published>2025-10-21T07:57:14Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3b4c4f26e87c357677854195c6a060998aa5cc48'/>
<id>urn:sha1:3b4c4f26e87c357677854195c6a060998aa5cc48</id>
<content type='text'>
[ Upstream commit d3429178ee51dd7155445d15a5ab87a45fae3c73 ]

When probing the I2C master, disable SMBus interrupts to prevent
storms caused by broken firmware mis-configuring IC_SMBUS=1; the
handler never services them and a mis-configured SMBUS Master
extend-clock timeout or SMBUS Slave extend-clock timeout can
flood the CPU.

Signed-off-by: Jinhui Guo &lt;guojinhui.liam@bytedance.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Acked-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Signed-off-by: Andi Shyti &lt;andi.shyti@kernel.org&gt;
Link: https://lore.kernel.org/r/20251021075714.3712-2-guojinhui.liam@bytedance.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: designware: Add disabling clocks when probe fails</title>
<updated>2025-10-15T10:00:03Z</updated>
<author>
<name>Kunihiko Hayashi</name>
<email>hayashi.kunihiko@socionext.com</email>
</author>
<published>2025-07-24T04:22:11Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=66da22768c803c7f4262b8f7421ed9326a40ad03'/>
<id>urn:sha1:66da22768c803c7f4262b8f7421ed9326a40ad03</id>
<content type='text'>
[ Upstream commit c149841b069ccc6e480b00e11f35a57b5d88c7bb ]

After an error occurs during probing state, dw_i2c_plat_pm_cleanup() is
called. However, this function doesn't disable clocks and the clock-enable
count keeps increasing. Should disable these clocks explicitly.

Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM")
Co-developed-by: Kohei Ito &lt;ito.kohei@socionext.com&gt;
Signed-off-by: Kohei Ito &lt;ito.kohei@socionext.com&gt;
Signed-off-by: Kunihiko Hayashi &lt;hayashi.kunihiko@socionext.com&gt;
Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: designware: Fix clock issue when PM is disabled</title>
<updated>2025-10-15T10:00:03Z</updated>
<author>
<name>Kunihiko Hayashi</name>
<email>hayashi.kunihiko@socionext.com</email>
</author>
<published>2025-07-24T04:22:10Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7493b30cc650fccea5af185fcf9221139aa09a2c'/>
<id>urn:sha1:7493b30cc650fccea5af185fcf9221139aa09a2c</id>
<content type='text'>
[ Upstream commit 70e633bedeeb4a7290d3b1dd9d49cc2bae25a46f ]

When the driver is removed, the clocks are first enabled by
calling pm_runtime_get_sync(), and then disabled with
pm_runtime_put_sync().

If CONFIG_PM=y, clocks for this controller are disabled when it's in
the idle state. So the clocks are properly disabled when the driver
exits.

Othewise, the clocks are always enabled and the PM functions have
no effect. Therefore, the driver exits without disabling the clocks.

    # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
    18
    # echo 1214a000.i2c &gt; /sys/bus/platform/drivers/i2c_designware/bind
    # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
    20
    # echo 1214a000.i2c &gt; /sys/bus/platform/drivers/i2c_designware/unbind
    # cat /sys/kernel/debug/clk/clk-pclk/clk_enable_count
    20

To ensure that the clocks can be disabled correctly even without
CONFIG_PM=y, should add the following fixes:

- Replace with pm_runtime_put_noidle(), which only decrements the runtime
  PM usage count.
- Call i2c_dw_prepare_clk(false) to explicitly disable the clocks.

Fixes: 7272194ed391f ("i2c-designware: add minimal support for runtime PM")
Co-developed-by: Kohei Ito &lt;ito.kohei@socionext.com&gt;
Signed-off-by: Kohei Ito &lt;ito.kohei@socionext.com&gt;
Signed-off-by: Kunihiko Hayashi &lt;hayashi.kunihiko@socionext.com&gt;
Tested-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRD</title>
<updated>2025-10-15T10:00:03Z</updated>
<author>
<name>Leilk.Liu</name>
<email>leilk.liu@mediatek.com</email>
</author>
<published>2025-09-06T08:24:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=be5165760b28d4ce768fe15124ee875bb77f87eb'/>
<id>urn:sha1:be5165760b28d4ce768fe15124ee875bb77f87eb</id>
<content type='text'>
[ Upstream commit b492183652808e0f389272bf63dc836241b287ff ]

The old IC does not support the I2C_MASTER_WRRD (write-then-read)
function, but the current code’s handling of i2c-&gt;auto_restart may
potentially lead to entering the I2C_MASTER_WRRD software flow,
resulting in unexpected bugs.

Instead of repurposing the auto_restart flag, add a separate flag
to signal I2C_MASTER_WRRD operations.

Also fix handling of msgs. If the operation (i2c-&gt;op) is
I2C_MASTER_WRRD, then the msgs pointer is incremented by 2.
For all other operations, msgs is simply incremented by 1.

Fixes: b2ed11e224a2 ("I2C: mediatek: Add driver for MediaTek MT8173 I2C controller")
Signed-off-by: Leilk.Liu &lt;leilk.liu@mediatek.com&gt;
Suggested-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Reviewed-by: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Signed-off-by: Wolfram Sang &lt;wsa+renesas@sang-engineering.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: designware: Add quirk for Intel Xe</title>
<updated>2025-10-02T11:44:07Z</updated>
<author>
<name>Heikki Krogerus</name>
<email>heikki.krogerus@linux.intel.com</email>
</author>
<published>2025-07-01T12:22:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5cae5420519d8fddfeb5d267b743a36f17175757'/>
<id>urn:sha1:5cae5420519d8fddfeb5d267b743a36f17175757</id>
<content type='text'>
[ Upstream commit f6a8e9f3de4567c71ef9f5f13719df69a8b96081 ]

The regmap is coming from the parent also in case of Xe
GPUs. Reusing the Wangxun quirk for that.

Acked-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Co-developed-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Signed-off-by: Michael J. Ruhl &lt;michael.j.ruhl@intel.com&gt;
Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Andi Shyti &lt;andi.shyti@kernel.org&gt;
Link: https://lore.kernel.org/r/20250701122252.2590230-3-heikki.krogerus@linux.intel.com
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
[Rodrigo fixed the co-developed tags while merging]
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: i801: Hide Intel Birch Stream SoC TCO WDT</title>
<updated>2025-09-19T14:35:45Z</updated>
<author>
<name>Chiasheng Lee</name>
<email>chiasheng.lee@linux.intel.com</email>
</author>
<published>2025-09-01T12:59:43Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f98d88bf36b973125e9d98e4a75f16b6af26a1a8'/>
<id>urn:sha1:f98d88bf36b973125e9d98e4a75f16b6af26a1a8</id>
<content type='text'>
commit 664596bd98bb251dd417dfd3f9b615b661e1e44a upstream.

Hide the Intel Birch Stream SoC TCO WDT feature since it was removed.

On platforms with PCH TCO WDT, this redundant device might be rendering
errors like this:

[   28.144542] sysfs: cannot create duplicate filename '/bus/platform/devices/iTCO_wdt'

Fixes: 8c56f9ef25a3 ("i2c: i801: Add support for Intel Birch Stream SoC")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220320
Signed-off-by: Chiasheng Lee &lt;chiasheng.lee@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v6.7+
Reviewed-by: Mika Westerberg &lt;mika.westerberg@linux.intel.com&gt;
Reviewed-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Andi Shyti &lt;andi.shyti@kernel.org&gt;
Link: https://lore.kernel.org/r/20250901125943.916522-1-chiasheng.lee@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
