<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v5.15.89</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.89</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.15.89'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-01-18T10:48:59+00:00</updated>
<entry>
<title>pinctrl: amd: Add dynamic debugging for active GPIOs</title>
<updated>2023-01-18T10:48:59+00:00</updated>
<author>
<name>Mario Limonciello</name>
<email>mario.limonciello@amd.com</email>
</author>
<published>2022-10-13T13:47:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=37c18ef49ec38a3571d9299b51b9760f1c3adb46'/>
<id>urn:sha1:37c18ef49ec38a3571d9299b51b9760f1c3adb46</id>
<content type='text'>
commit 1d66e379731f79ae5039a869c0fde22a4f6a6a91 upstream.

Some laptops have been reported to wake up from s2idle when plugging
in the AC adapter or by closing the lid.  This is a surprising
behavior that is further clarified by commit cb3e7d624c3ff ("PM:
wakeup: Add extra debugging statement for multiple active IRQs").

With that commit in place the following interaction can be seen
when the lid is closed:

[   28.946038] PM: suspend-to-idle
[   28.946083] ACPI: EC: ACPI EC GPE status set
[   28.946101] ACPI: PM: Rearming ACPI SCI for wakeup
[   28.950152] Timekeeping suspended for 3.320 seconds
[   28.950152] PM: Triggering wakeup from IRQ 9
[   28.950152] ACPI: EC: ACPI EC GPE status set
[   28.950152] ACPI: EC: ACPI EC GPE dispatched
[   28.995057] ACPI: EC: ACPI EC work flushed
[   28.995075] ACPI: PM: Rearming ACPI SCI for wakeup
[   28.995131] PM: Triggering wakeup from IRQ 9
[   28.995271] ACPI: EC: ACPI EC GPE status set
[   28.995291] ACPI: EC: ACPI EC GPE dispatched
[   29.098556] ACPI: EC: ACPI EC work flushed
[   29.207020] ACPI: EC: ACPI EC work flushed
[   29.207037] ACPI: PM: Rearming ACPI SCI for wakeup
[   29.211095] Timekeeping suspended for 0.739 seconds
[   29.211095] PM: Triggering wakeup from IRQ 9
[   29.211079] PM: Triggering wakeup from IRQ 7
[   29.211095] ACPI: PM: ACPI non-EC GPE wakeup
[   29.211095] PM: resume from suspend-to-idle

* IRQ9 on this laptop is used for the ACPI SCI.
* IRQ7 on this laptop is used for the GPIO controller.

What has occurred is when the lid was closed the EC woke up the
SoC from it's deepest sleep state and the kernel's s2idle loop
processed all EC events.  When it was finished processing EC events,
it checked for any other reasons to wake (break the s2idle loop).

The IRQ for the GPIO controller was active so the loop broke, and
then this IRQ was processed.  This is not a kernel bug but it is
certainly a surprising behavior, and to better debug it we should
have a dynamic debugging message that we can enact to catch it.

Acked-by: Basavaraj Natikar &lt;Basavaraj.Natikar@amd.com&gt;
Acked-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Acked-by: Mark Pearson &lt;markpearson@lenovo.com&gt;
Signed-off-by: Mario Limonciello &lt;mario.limonciello@amd.com&gt;
Link: https://lore.kernel.org/r/20221013134729.5592-2-mario.limonciello@amd.com
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Revert "usb: ulpi: defer ulpi_register on ulpi_read_id timeout"</title>
<updated>2023-01-18T10:48:58+00:00</updated>
<author>
<name>Ferry Toth</name>
<email>ftoth@exalondelft.nl</email>
</author>
<published>2022-12-22T20:53:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a5841b81adfa5cd29cb1c61a438da5a6ec32a7b3'/>
<id>urn:sha1:a5841b81adfa5cd29cb1c61a438da5a6ec32a7b3</id>
<content type='text'>
commit b659b613cea2ae39746ca8bd2b69d1985dd9d770 upstream.

This reverts commit 8a7b31d545d3a15f0e6f5984ae16f0ca4fd76aac.

This patch results in some qemu test failures, specifically xilinx-zynq-a9
machine and zynq-zc702 as well as zynq-zed devicetree files, when trying
to boot from USB drive.

Link: https://lore.kernel.org/lkml/20221220194334.GA942039@roeck-us.net/
Fixes: 8a7b31d545d3 ("usb: ulpi: defer ulpi_register on ulpi_read_id timeout")
Cc: stable@vger.kernel.org
Reported-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Ferry Toth &lt;ftoth@exalondelft.nl&gt;
Link: https://lore.kernel.org/r/20221222205302.45761-1-ftoth@exalondelft.nl
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>block: handle bio_split_to_limits() NULL return</title>
<updated>2023-01-18T10:48:58+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@kernel.dk</email>
</author>
<published>2023-01-04T15:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ec9a45fc4ee7fc1054c2cabf8b09a6bc708472e'/>
<id>urn:sha1:7ec9a45fc4ee7fc1054c2cabf8b09a6bc708472e</id>
<content type='text'>
commit 613b14884b8595e20b9fac4126bf627313827fbe upstream.

This can't happen right now, but in preparation for allowing
bio_split_to_limits() returning NULL if it ended the bio, check for it
in all the callers.

Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: mpt3sas: Remove scsi_dma_map() error messages</title>
<updated>2023-01-18T10:48:58+00:00</updated>
<author>
<name>Sreekanth Reddy</name>
<email>sreekanth.reddy@broadcom.com</email>
</author>
<published>2022-03-03T14:02:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63c2fa09b85679c17ee5f24de34f412dc76c0764'/>
<id>urn:sha1:63c2fa09b85679c17ee5f24de34f412dc76c0764</id>
<content type='text'>
commit 0c25422d34b4726b2707d5f38560943155a91b80 upstream.

When scsi_dma_map() fails by returning a sges_left value less than zero,
the amount of logging produced can be extremely high.  In a recent end-user
environment, 1200 messages per second were being sent to the log buffer.
This eventually overwhelmed the system and it stalled.

These error messages are not needed. Remove them.

Link: https://lore.kernel.org/r/20220303140203.12642-1-sreekanth.reddy@broadcom.com
Suggested-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Sreekanth Reddy &lt;sreekanth.reddy@broadcom.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Cc: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>efi: fix NULL-deref in init error path</title>
<updated>2023-01-18T10:48:58+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2022-12-19T09:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e2ea55564229e4bea1474af15b111b3a3043b76f'/>
<id>urn:sha1:e2ea55564229e4bea1474af15b111b3a3043b76f</id>
<content type='text'>
[ Upstream commit 703c13fe3c9af557d312f5895ed6a5fda2711104 ]

In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.

Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer.

Fixes: 98086df8b70c ("efi: add missed destroy_workqueue when efisubsys_init fails")
Cc: stable@vger.kernel.org
Cc: Li Heng &lt;liheng40@huawei.com&gt;
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>platform/surface: aggregator: Add missing call to ssam_request_sync_free()</title>
<updated>2023-01-18T10:48:57+00:00</updated>
<author>
<name>Maximilian Luz</name>
<email>luzmaximilian@gmail.com</email>
</author>
<published>2022-12-20T17:56:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d2dc110deabe7142b60ebeed689e67f92795ee24'/>
<id>urn:sha1:d2dc110deabe7142b60ebeed689e67f92795ee24</id>
<content type='text'>
[ Upstream commit c965daac370f08a9b71d573a71d13cda76f2a884 ]

Although rare, ssam_request_sync_init() can fail. In that case, the
request should be freed via ssam_request_sync_free(). Currently it is
leaked instead. Fix this.

Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem")
Signed-off-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Link: https://lore.kernel.org/r/20221220175608.1436273-1-luzmaximilian@gmail.com
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>igc: Fix PPS delta between two synchronized end-points</title>
<updated>2023-01-18T10:48:57+00:00</updated>
<author>
<name>Christopher S Hall</name>
<email>christopher.s.hall@intel.com</email>
</author>
<published>2022-12-14T08:10:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cfd5978411edae852636f8a6cd53ea093f292e79'/>
<id>urn:sha1:cfd5978411edae852636f8a6cd53ea093f292e79</id>
<content type='text'>
[ Upstream commit 5e91c72e560cc85f7163bbe3d14197268de31383 ]

This patch fix the pulse per second output delta between
two synchronized end-points.

Based on Intel Discrete I225 Software User Manual Section
4.2.15 TimeSync Auxiliary Control Register, ST0[Bit 4] and
ST1[Bit 7] must be set to ensure that clock output will be
toggles based on frequency value defined. This is to ensure
that output of the PPS is aligned with the clock.

How to test:

1) Running time synchronization on both end points.
Ex: ptp4l --step_threshold=1 -m -f gPTP.cfg -i &lt;interface name&gt;

2) Configure PPS output using below command for both end-points
Ex: SDP0 on I225 REV4 SKU variant

./testptp -d /dev/ptp0 -L 0,2
./testptp -d /dev/ptp0 -p 1000000000

3) Measure the output using analyzer for both end-points

Fixes: 87938851b6ef ("igc: enable auxiliary PHC functions for the i225")
Signed-off-by: Christopher S Hall &lt;christopher.s.hall@intel.com&gt;
Signed-off-by: Muhammad Husaini Zulkifli &lt;muhammad.husaini.zulkifli@intel.com&gt;
Acked-by: Sasha Neftin &lt;sasha.neftin@intel.com&gt;
Tested-by: Naama Meir &lt;naamax.meir@linux.intel.com&gt;
Signed-off-by: Tony Nguyen &lt;anthony.l.nguyen@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5e: Don't support encap rules with gbp option</title>
<updated>2023-01-18T10:48:56+00:00</updated>
<author>
<name>Gavin Li</name>
<email>gavinl@nvidia.com</email>
</author>
<published>2022-12-27T02:54:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=205f35eee7be8d5b5f994e31200211fc745610f5'/>
<id>urn:sha1:205f35eee7be8d5b5f994e31200211fc745610f5</id>
<content type='text'>
[ Upstream commit d515d63cae2cd186acf40deaa8ef33067bb7f637 ]

Previously, encap rules with gbp option would be offloaded by mistake but
driver does not support gbp option offload.

To fix this issue, check if the encap rule has gbp option and don't
offload the rule

Fixes: d8f9dfae49ce ("net: sched: allow flower to match vxlan options")
Signed-off-by: Gavin Li &lt;gavinl@nvidia.com&gt;
Reviewed-by: Maor Dickman &lt;maord@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Fix ptp max frequency adjustment range</title>
<updated>2023-01-18T10:48:56+00:00</updated>
<author>
<name>Rahul Rameshbabu</name>
<email>rrameshbabu@nvidia.com</email>
</author>
<published>2022-12-05T22:26:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0526fc9330fe7d68b66a79561ebeb0a90f78df75'/>
<id>urn:sha1:0526fc9330fe7d68b66a79561ebeb0a90f78df75</id>
<content type='text'>
[ Upstream commit fe91d57277eef8bb4aca05acfa337b4a51d0bba4 ]

.max_adj of ptp_clock_info acts as an absolute value for the amount in ppb
that can be set for a single call of .adjfine. This means that a single
call to .getfine cannot be greater than .max_adj or less than -(.max_adj).
Provides correct value for max frequency adjustment value supported by
devices.

Fixes: 3d8c38af1493 ("net/mlx5e: Add PTP Hardware Clock (PHC) support")
Signed-off-by: Rahul Rameshbabu &lt;rrameshbabu@nvidia.com&gt;
Reviewed-by: Gal Pressman &lt;gal@nvidia.com&gt;
Reviewed-by: Tariq Toukan &lt;tariqt@nvidia.com&gt;
Signed-off-by: Saeed Mahameed &lt;saeedm@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()</title>
<updated>2023-01-18T10:48:54+00:00</updated>
<author>
<name>Minsuk Kang</name>
<email>linuxlovemin@yonsei.ac.kr</email>
</author>
<published>2023-01-06T08:23:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=39ae73e581112cfe27ba50aecb1c891ce57cecb1'/>
<id>urn:sha1:39ae73e581112cfe27ba50aecb1c891ce57cecb1</id>
<content type='text'>
[ Upstream commit 9dab880d675b9d0dd56c6428e4e8352a3339371d ]

Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.

Found by a modified version of syzkaller.

BUG: KASAN: use-after-free in dummy_timer
Call Trace:
 memcpy (mm/kasan/shadow.c:65)
 dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
 transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
 dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
 arch_static_branch (arch/x86/include/asm/jump_label.h:27)
 static_key_false (include/linux/jump_label.h:207)
 timer_expire_exit (include/trace/events/timer.h:127)
 call_timer_fn (kernel/time/timer.c:1475)
 expire_timers (kernel/time/timer.c:1519)
 __run_timers (kernel/time/timer.c:1790)
 run_timer_softirq (kernel/time/timer.c:1803)

Fixes: c46ee38620a2 ("NFC: pn533: add NXP pn533 nfc device driver")
Signed-off-by: Minsuk Kang &lt;linuxlovemin@yonsei.ac.kr&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
