| Age | Commit message (Collapse) | Author |
|---|
|
tp->rcv_tstamp should be set to tcp_jiffies, not tcp_time_stamp().
Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ayush Sawal <ayush.sawal@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The route lookup can be done now via generic function
udp_tunnel6_dst_lookup() to replace the custom implementation in
vxlan6_get_route().
This is similar to what already done for IPv4 in commit 6f19b2c136d9
("vxlan: use generic function for tunnel IPv4 route lookup").
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The route lookup can be done now via generic function
udp_tunnel6_dst_lookup() to replace the custom implementation in
geneve_get_v6_dst().
This is similar to what already done for IPv4 in commit daa2ba7ed1d1
("geneve: use generic function for tunnel IPv4 route lookup").
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We want to make the function more generic so that it can be used by
other UDP tunnel implementations such as geneve and vxlan. To do that,
add the following arguments:
- source and destination UDP port;
- ifindex of the output interface, needed by vxlan;
- the tos, because in some cases it is not taken from struct
ip_tunnel_info (for example, when it's inherited from the inner
packet);
- the dst cache, because not all tunnel types (e.g. vxlan) want to
use the one from struct ip_tunnel_info.
With these parameters, the function no longer needs the full struct
ip_tunnel_info as argument and we can pass only the relevant part of
it (struct ip_tunnel_key).
This is similar to what already done for IPv4 in commit 72fc68c6356b
("ipv4: add new arguments to udp_tunnel_dst_lookup()").
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The function is now UDP-specific, the protocol is always IPPROTO_UDP.
This is similar to what already done for IPv4 in commit 78f3655adcb5
("ipv4: remove "proto" argument from udp_tunnel_dst_lookup()").
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
At the moment ip6_dst_lookup_tunnel() is used only by bareudp.
Ideally, other UDP tunnel implementations should use it, but to do so
the function needs to accept new parameters that are specific for UDP
tunnels, such as the ports.
Prepare for these changes by renaming the function to
udp_tunnel6_dst_lookup() and move it to file
net/ipv6/ip6_udp_tunnel.c.
This is similar to what already done for IPv4 in commit bf3fcbf7e7a0
("ipv4: rename and move ip_route_output_tunnel()").
Suggested-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Pull phy fixes from Vinod Koul:
- mapphone-mdm6600 runtime pm & pinctrl handling fixes
- Qualcomm qmp usb pcs register fixes, qmp pcie register size warning
fix, m31 fixes for wrong pointer in PTR_ERR and dropping wrong vreg
check, qmp combo fix for 8550 power config register
- realtek usb fix for debugfs_create_dir() and kconfig dependency
* tag 'phy-fixes-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy:
phy: realtek: Realtek PHYs should depend on ARCH_REALTEK
phy: qualcomm: Fix typos in comments
phy: qcom-qmp-combo: initialize PCS_USB registers
phy: qcom-qmp-combo: Square out 8550 POWER_STATE_CONFIG1
phy: qcom: m31: Remove unwanted qphy->vreg is NULL check
phy: realtek: usb: Drop unnecessary error check for debugfs_create_dir()
phy: qcom: phy-qcom-m31: change m31_ipq5332_regs to static
phy: qcom: phy-qcom-m31: fix wrong pointer pass to PTR_ERR()
dt-bindings: phy: qcom,ipq8074-qmp-pcie: fix warning regarding reg size
phy: qcom-qmp-usb: split PCS_USB init table for sc8280xp and sa8775p
phy: qcom-qmp-usb: initialize PCS_USB registers
phy: mapphone-mdm6600: Fix pinctrl_pm handling for sleep pins
phy: mapphone-mdm6600: Fix runtime PM for remove
phy: mapphone-mdm6600: Fix runtime disable on probe
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI fixes from Ard Biesheuvel:
"The boot_params pointer fix uses a somewhat ugly extern struct
declaration but this will be cleaned up the next cycle.
- don't try to print warnings to the console when it is no longer
available
- fix theoretical memory leak in SSDT override handling
- make sure that the boot_params global variable is set before the
KASLR code attempts to hash it for 'randomness'
- avoid soft lockups in the memory acceptance code"
* tag 'efi-fixes-for-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
efi/unaccepted: Fix soft lockups caused by parallel memory acceptance
x86/boot: efistub: Assign global boot_params variable
efi: fix memory leak in krealloc failure handling
x86/efistub: Don't try to print after ExitBootService()
|
|
If there is no NFIT at startup, it will return 0 immediately in function
acpi_nfit_add() and will not install Notify() handler. If hotplugging
a nvdimm device later, it will not be identified as there is no Notify()
handler.
Install the handler before getting NFI table in function acpi_nfit_add()
to avoid above issue.
Fixes: dcca12ab62a2 ("ACPI: NFIT: Install Notify() handler directly")
Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Even though the functions to read/write registers can fail, most of
the places in the r8152 driver that read/write register values don't
check error codes. The lack of error code checking is problematic in
at least two ways.
The first problem is that the r8152 driver often uses code patterns
similar to this:
x = read_register()
x = x | SOME_BIT;
write_register(x);
...with the above pattern, if the read_register() fails and returns
garbage then we'll end up trying to write modified garbage back to the
Realtek adapter. If the write_register() succeeds that's bad. Note
that as of commit f53a7ad18959 ("r8152: Set memory to all 0xFFs on
failed reg reads") the "garbage" returned by read_register() will at
least be consistent garbage, but it is still garbage.
It turns out that this problem is very serious. Writing garbage to
some of the hardware registers on the Ethernet adapter can put the
adapter in such a bad state that it needs to be power cycled (fully
unplugged and plugged in again) before it can enumerate again.
The second problem is that the r8152 driver generally has functions
that are long sequences of register writes. Assuming everything will
be OK if a random register write fails in the middle isn't a great
assumption.
One might wonder if the above two problems are real. You could ask if
we would really have a successful write after a failed read. It turns
out that the answer appears to be "yes, this can happen". In fact,
we've seen at least two distinct failure modes where this happens.
On a sc7180-trogdor Chromebook if you drop into kdb for a while and
then resume, you can see:
1. We get a "Tx timeout"
2. The "Tx timeout" queues up a USB reset.
3. In rtl8152_pre_reset() we try to reinit the hardware.
4. The first several (2-9) register accesses fail with a timeout, then
things recover.
The above test case was actually fixed by the patch ("r8152: Increase
USB control msg timeout to 5000ms as per spec") but at least shows
that we really can see successful calls after failed ones.
On a different (AMD) based Chromebook with a particular adapter, we
found that during reboot tests we'd also sometimes get a transitory
failure. In this case we saw -EPIPE being returned sometimes. Retrying
worked, but retrying is not always safe for all register accesses
since reading/writing some registers might have side effects (like
registers that clear on read).
Let's fully lock out all register access if a register access fails.
When we do this, we'll try to queue up a USB reset and try to unlock
register access after the reset. This is slightly tricker than it
sounds since the r8152 driver has an optimized reset sequence that
only works reliably after probe happens. In order to handle this, we
avoid the optimized reset if probe didn't finish. Instead, we simply
retry the probe routine in this case.
When locking out access, we'll use the existing infrastructure that
the driver was using when it detected we were unplugged. This keeps us
from getting stuck in delay loops in some parts of the driver.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Whenever the RTL8152_UNPLUG is set that just tells the driver that all
accesses will fail and we should just immediately bail. A future patch
will use this same concept at a time when the driver hasn't actually
been unplugged but is about to be reset. Rename the flag in
preparation for the future patch.
This is a no-op change and just a search and replace.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the adapter is unplugged while we're looping in r8153b_ups_en() /
r8153c_ups_en() we could end up looping for 10 seconds (20 ms * 500
loops). Add code similar to what's done in other places in the driver
to check for unplug and bail.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If the adapter is unplugged while we're looping in
rtl_phy_patch_request() we could end up looping for 10 seconds (2 ms *
5000 loops). Add code similar to what's done in other places in the
driver to check for unplug and bail.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The error handling in rtl8152_probe() is missing a call to release
firmware. Add it in to match what's in the cleanup code in
rtl8152_disconnect().
Fixes: 9370f2d05a2a ("r8152: support request_firmware for RTL8153")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The error handling in rtl8152_probe() is missing a call to cancel the
hw_phy_work. Add it in to match what's in the cleanup code in
rtl8152_disconnect().
Fixes: a028a9e003f2 ("r8152: move the settings of PHY to a work queue")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The rtl8152_probe() function lacks a call to the chip-specific
unload() routine when it sees an error in probe. Add it in to match
the cleanup code in rtl8152_disconnect().
Fixes: ac718b69301c ("net/usb: new driver for RTL8152")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
According to the comment next to USB_CTRL_GET_TIMEOUT and
USB_CTRL_SET_TIMEOUT, although sending/receiving control messages is
usually quite fast, the spec allows them to take up to 5 seconds.
Let's increase the timeout in the Realtek driver from 500ms to 5000ms
(using the #defines) to account for this.
This is not just a theoretical change. The need for the longer timeout
was seen in testing. Specifically, if you drop a sc7180-trogdor based
Chromebook into the kdb debugger and then "go" again after sitting in
the debugger for a while, the next USB control message takes a long
time. Out of ~40 tests the slowest USB control message was 4.5
seconds.
While dropping into kdb is not exactly an end-user scenario, the above
is similar to what could happen due to an temporary interrupt storm,
what could happen if there was a host controller (HW or SW) issue, or
what could happen if the Realtek device got into a confused state and
needed time to recover.
This change is fairly critical since the r8152 driver in Linux doesn't
expect register reads/writes (which are backed by USB control
messages) to fail.
Fixes: ac718b69301c ("net/usb: new driver for RTL8152")
Suggested-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The current driver code does not accurately report the supported and
advertised link modes. It basically always assumes the media type
is copper for any particular speed. Utilize the recently added link
mode mappings to accurately report fully qualified ethtool link modes for
advertised and supported speeds.
If the media type is known, we will report the supported link modes for
that media only. If the media is not known, we will report all possible
supported link modes. The user can now specify any supported link modes
(including NRZ and PAM4) to advertise for autoneg. It used to only accept
copper NRZ modes.
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Barring the BNXT_FW_TO_ETHTOOL speed macros, which will be removed
in the next patch, update code to use the newer API.
No functional change.
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Refactor some NRZ/PAM4 link speed related logic into helper functions.
The NRZ and PAM4 link parameters are stored in separate structure fields.
The driver logic has to check whether it is in NRZ or PAM4 mode and
then use the appropriate field.
Refactor this logic into helper functions for better readability.
Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Reviewed-by: Andy Gospodarek <andrew.gospodarek@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A future patch in this series will change the algorithm used to
determine ethtool speed and media modes. Extract the handling of
the unrelated pause, autoneg modes into an independent function.
Also separate FEC handling out of bnxt_fw_to_ethtool_*_spds().
No functional change.
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Recent kernels support changing the number of link lanes via ethtool.
This is useful for determining the appropriate signal mode to use when
a given link speed can be achieved using different lane configurations.
Accept the ethtool lanes parameter when configuring forced speed. If
there is no lanes parameter, select a default.
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add infrastructure to look up the enum ethtool_link_mode_bit_indices
from link information provided by the firmware. The link speed,
signal mode, and media type returned by firmware will be used to
look up the ethtool link mode.
The immediate benefit is that once the link mode is determined, we can
now use ethtool_params_from_link_mode() to fill the basic ethtool
parameters including the number of lanes. Lanes will be fully
supported in the next patch.
Signed-off-by: Edwin Peer <edwin.peer@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
FW sends the async event to the driver when the device temperature goes
above or below the threshold values. Only notify hwmon if the
temperature is increasing to the next alert level, not when it is
decreasing.
Cc: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Kashyap Desai <kashyap.desai@broadcom.com>
Reviewed-by: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Defer hwmon_notify_event() to bnxt_sp_task() workqueue because
hwmon_notify_event() can try to acquire a mutex shown in the stack trace
below. Modify bnxt_event_error_report() to return true if we need to
schedule bnxt_sp_task() to notify hwmon.
__schedule+0x68/0x520
hwmon_notify_event+0xe8/0x114
schedule+0x60/0xe0
schedule_preempt_disabled+0x28/0x40
__mutex_lock.constprop.0+0x534/0x550
__mutex_lock_slowpath+0x18/0x20
mutex_lock+0x5c/0x70
kobject_uevent_env+0x2f4/0x3d0
kobject_uevent+0x10/0x20
hwmon_notify_event+0x94/0x114
bnxt_hwmon_notify_event+0x40/0x70 [bnxt_en]
bnxt_event_error_report+0x260/0x290 [bnxt_en]
bnxt_async_event_process.isra.0+0x250/0x850 [bnxt_en]
bnxt_hwrm_handler.isra.0+0xc8/0x120 [bnxt_en]
bnxt_poll_p5+0x150/0x350 [bnxt_en]
__napi_poll+0x3c/0x210
net_rx_action+0x308/0x3b0
__do_softirq+0x120/0x3e0
Cc: Guenter Roeck <linux@roeck-us.net>
Fixes: a19b4801457b ("bnxt_en: Event handler for Thermal event")
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
syzbot reported the following uninit-value access issue [1]:
smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Failed to read reg index 0x00000030: -32
smsc95xx 1-1:0.0 (unnamed net_device) (uninitialized): Error reading E2P_CMD
=====================================================
BUG: KMSAN: uninit-value in smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896
smsc95xx_reset+0x409/0x25f0 drivers/net/usb/smsc95xx.c:896
smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131
usbnet_probe+0x100b/0x4060 drivers/net/usb/usbnet.c:1750
usb_probe_interface+0xc75/0x1210 drivers/usb/core/driver.c:396
really_probe+0x506/0xf40 drivers/base/dd.c:658
__driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800
driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830
__device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958
bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457
__device_attach+0x3bd/0x640 drivers/base/dd.c:1030
device_initial_probe+0x32/0x40 drivers/base/dd.c:1079
bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532
device_add+0x16ae/0x1f20 drivers/base/core.c:3622
usb_set_configuration+0x31c9/0x38c0 drivers/usb/core/message.c:2207
usb_generic_driver_probe+0x109/0x2a0 drivers/usb/core/generic.c:238
usb_probe_device+0x290/0x4a0 drivers/usb/core/driver.c:293
really_probe+0x506/0xf40 drivers/base/dd.c:658
__driver_probe_device+0x2a7/0x5d0 drivers/base/dd.c:800
driver_probe_device+0x72/0x7b0 drivers/base/dd.c:830
__device_attach_driver+0x55a/0x8f0 drivers/base/dd.c:958
bus_for_each_drv+0x3ff/0x620 drivers/base/bus.c:457
__device_attach+0x3bd/0x640 drivers/base/dd.c:1030
device_initial_probe+0x32/0x40 drivers/base/dd.c:1079
bus_probe_device+0x3d8/0x5a0 drivers/base/bus.c:532
device_add+0x16ae/0x1f20 drivers/base/core.c:3622
usb_new_device+0x15f6/0x22f0 drivers/usb/core/hub.c:2589
hub_port_connect drivers/usb/core/hub.c:5440 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5580 [inline]
port_event drivers/usb/core/hub.c:5740 [inline]
hub_event+0x53bc/0x7290 drivers/usb/core/hub.c:5822
process_one_work kernel/workqueue.c:2630 [inline]
process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2703
worker_thread+0xf45/0x1490 kernel/workqueue.c:2784
kthread+0x3e8/0x540 kernel/kthread.c:388
ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
Local variable buf.i225 created at:
smsc95xx_read_reg drivers/net/usb/smsc95xx.c:90 [inline]
smsc95xx_reset+0x203/0x25f0 drivers/net/usb/smsc95xx.c:892
smsc95xx_bind+0x9bc/0x22e0 drivers/net/usb/smsc95xx.c:1131
CPU: 1 PID: 773 Comm: kworker/1:2 Not tainted 6.6.0-rc1-syzkaller-00125-ge42bebf6db29 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Workqueue: usb_hub_wq hub_event
=====================================================
Similar to e9c65989920f ("net: usb: smsc75xx: Fix uninit-value access in
__smsc75xx_read_reg"), this issue is caused because usbnet_read_cmd() reads
less bytes than requested (zero byte in the reproducer). In this case,
'buf' is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.
sysbot reported similar uninit-value access issue [2]. The root cause is
the same as mentioned above, and this patch addresses it as well.
Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
Reported-and-tested-by: syzbot+c74c24b43c9ae534f0e0@syzkaller.appspotmail.com
Reported-and-tested-by: syzbot+2c97a98a5ba9ea9c23bd@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c74c24b43c9ae534f0e0 [1]
Closes: https://syzkaller.appspot.com/bug?extid=2c97a98a5ba9ea9c23bd [2]
Signed-off-by: Shigeru Yoshida <syoshida@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
t4_set_params_timeout() can return -EINVAL if failed, add check
for this.
Signed-off-by: Su Hui <suhui@nfschina.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
adf7242_stats_show()
strncat() usage in adf7242_debugfs_init() is wrong.
The size given to strncat() is the maximum number of bytes that can be
written, excluding the trailing NULL.
Here, the size that is passed, DNAME_INLINE_LEN, does not take into account
the size of "adf7242-" that is already in the array.
In order to fix it, use snprintf() instead.
Fixes: 7302b9d90117 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- fix interrupt handling in suspend and wakeup in gpio-vf610
- fix a bug on setting direction to output in gpio-vf610
- add a missing memset() in gpio ACPI code
* tag 'gpio-fixes-for-v6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpiolib: acpi: Add missing memset(0) to acpi_get_gpiod_from_data()
gpio: vf610: set value before the direction to avoid a glitch
gpio: vf610: mask the gpio irq in system suspend and support wakeup
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Pull s390 fixes from Vasily Gorbik:
- Fix IOMMU bitmap allocation in s390 PCI to avoid out of bounds access
when IOMMU pages aren't a multiple of 64
- Fix kasan crashes when accessing DCSS mapping in memory holes by
adding corresponding kasan zero shadow mappings
- Fix a memory leak in css_alloc_subchannel in case
dma_set_coherent_mask fails
* tag 's390-6.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/pci: fix iommu bitmap allocation
s390/kasan: handle DCSS mapping in memory holes
s390/cio: fix a memleak in css_alloc_subchannel
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Hans de Goede:
- Fix spurious brightness down presses on newer Asus laptop models
- Fix backlight control not working on T2 Mac Pro all-in-ones
- Add Armin Wolf as new maintainer for the WMI bus driver and change
its status from orphaned to maintained
- A few other small fixes
* tag 'platform-drivers-x86-v6.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/mellanox: mlxbf-tmfifo: Fix a warning message
apple-gmux: Hard Code max brightness for MMIO gmux
platform/surface: platform_profile: Propagate error if profile registration fails
platform/x86: asus-wmi: Map 0x2a code, Ignore 0x2b and 0x2c events
platform/x86: asus-wmi: Only map brightness codes when using asus-wmi backlight control
platform/x86: asus-wmi: Change ASUS_WMI_BRN_DOWN code from 0x20 to 0x2e
platform/x86: wmi: Update MAINTAINERS entry
platform/x86: msi-ec: Fix the 3rd config
platform/x86: intel-uncore-freq: Conditionally create attribute for read frequency
platform: mellanox: Fix a resource leak in an error handling path in probing flow
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB / Thunderbolt fixes and ids from Greg KH:
"Here are four small patches for USB and Thunderbolt for 6.6-rc7 that
do the following:
- new usb-serial device ids
- thunderbolt driver fix for reported issue
All of these have been in linux-next with no reported problems"
* tag 'usb-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: serial: option: add Fibocom to DELL custom modem FM101R-GL
USB: serial: option: add entry for Sierra EM9191 with new firmware
USB: serial: option: add Telit LE910C4-WWX 0x1035 composition
thunderbolt: Call tb_switch_put() once DisplayPort bandwidth request is finished
|
|
Clean up structure defines related to hardware data to be
asserted to fixed sizes, as padding is not allowed
by hardware.
Signed-off-by: Shinas Rasheed <srasheed@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The spi_transfer struct has to have all it's fields initialized to 0 in
this case, since not all of them are set before starting the transfer.
Otherwise, spi_sync_transfer() will sometimes return an error.
Fixes: a526a3cc9c8d ("net: ethernet: adi: adin1110: Fix SPI transfers")
Signed-off-by: Dell Jin <dell.jin.code@outlook.com>
Signed-off-by: Ciprian Regus <ciprian.regus@analog.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Upon boot up, the driver will configure the MAC capabilities based on
the maximum number of tx and rx queues. When the user changes the
tx queues to single queue, the MAC should be capable of supporting Half
Duplex, but the driver does not update the MAC capabilities when it is
configured so.
Using the stmmac_reinit_queues() to check the number of tx queues
and set the MAC capabilities accordingly.
Fixes: 0366f7e06a6b ("net: stmmac: add ethtool support for get/set channels")
Cc: <stable@vger.kernel.org> # 5.17+
Signed-off-by: Michael Sit Wei Hong <michael.wei.hong.sit@intel.com>
Signed-off-by: Gan, Yi Fang <yi.fang.gan@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
mv88e6xxx_tai_write() can return error code (-EOPNOTSUPP ...) if failed.
So check the value of 'ret' after calling mv88e6xxx_tai_write().
Signed-off-by: Su Hui <suhui@nfschina.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit b0377116decd ("net: ethernet: Use device_get_match_data()") dropped
the unconditional use of xgene_enet_of_match resulting in this warning:
drivers/net/ethernet/apm/xgene/xgene_enet_main.c:2004:34: warning: unused variable 'xgene_enet_of_match' [-Wunused-const-variable]
The fix is to drop of_match_ptr() which is not necessary because DT is
always used for this driver (well, it could in theory support ACPI only,
but CONFIG_OF is always enabled for arm64).
Fixes: b0377116decd ("net: ethernet: Use device_get_match_data()")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310170627.2Kvf6ZHY-lkp@intel.com/
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When a programming status desc is encountered on the rx_ring,
next_to_process is bumped along with cleaned_count but next_to_clean is
not. This causes I40E_DESC_UNUSED() macro to misbehave resulting in
overwriting whole ring with new buffers.
Update next_to_clean to point to next_to_process on seeing a programming
status desc if not in the middle of handling a multi-frag packet. Also,
bump cleaned_count only for such case as otherwise next_to_clean buffer
may be returned to hardware on reaching clean_threshold.
Fixes: e9031f2da1ae ("i40e: introduce next_to_process to i40e_ring")
Suggested-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Reported-by: hq.dev+kernel@msdfc.xyz
Reported by: Solomon Peachy <pizza@shaftnet.org>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217678
Tested-by: hq.dev+kernel@msdfc.xyz
Tested by: Indrek Järve <incx@dustbite.net>
Signed-off-by: Tirthendu Sarkar <tirthendu.sarkar@intel.com>
Tested-by: Arpana Arland <arpanax.arland@intel.com> (A Contingent worker at Intel)
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/r/20231019203852.3663665-1-jacob.e.keller@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The 'ethtool_convert_link_mode_to_legacy_u32' method does not allow us to
advertise 2500M speed support and TP (twisted pair) properly. Convert to
'ethtool_link_ksettings_test_link_mode' to advertise supported speed and
eliminate ambiguity.
Fixes: 8c5ad0dae93c ("igc: Add ethtool support")
Suggested-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Suggested-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Tested-by: Naama Meir <naamax.meir@linux.intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://lore.kernel.org/r/20231019203641.3661960-1-jacob.e.keller@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We expect chinfo.name to be NUL-terminated based on its use with format
strings and sprintf:
rpmsg/rpmsg_char.c
165: dev_err(dev, "failed to open %s\n", eptdev->chinfo.name);
368: return sprintf(buf, "%s\n", eptdev->chinfo.name);
... and with strcmp():
| static struct rpmsg_endpoint *qcom_glink_create_ept(struct rpmsg_device *rpdev,
| rpmsg_rx_cb_t cb,
| void *priv,
| struct rpmsg_channel_info
| chinfo)
| ...
| const char *name = chinfo.name;
| ...
| if (!strcmp(channel->name, name))
Since chinfo is initialized as such (just above the strscpy()):
| struct rpmsg_channel_info chinfo = {
| .src = rpwwan->rpdev->src,
| .dst = RPMSG_ADDR_ANY,
| };
... we know other members are zero-initialized. This means no
NUL-padding is required (as any NUL-byte assignments are redundant).
Considering the above, a suitable replacement is `strscpy` due to the
fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://github.com/KSPP/linux/issues/90
Signed-off-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20231019-strncpy-drivers-net-wwan-rpmsg_wwan_ctrl-c-v2-1-ecf9b5a39430@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
check the value of 'ret' after call 'devlink_info_version_stored_put'.
Signed-off-by: Su Hui <suhui@nfschina.com>
Reviewed-by: Shannon Nelson <shannon.nelson@amd.com>
Link: https://lore.kernel.org/r/20231019083351.1526484-1-suhui@nfschina.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix the ACPI initialization ordering on ARM and ACPI IRQ
management in the cases when irq_create_fwspec_mapping() fails.
Specifics:
- Fix ACPI initialization ordering on ARM that was changed
incorrectly during the 6.5 development cycle (Hanjun Guo)
- Make acpi_register_gsi() return an error code as appropriate when
irq_create_fwspec_mapping() returns 0 on failure (Sunil V L)"
* tag 'acpi-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: bus: Move acpi_arm_init() to the place of after acpi_ghes_init()
ACPI: irq: Fix incorrect return value in acpi_register_gsi()
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two small fixes, both in drivers.
The mptsas one is really fixing an error path issue where it can leave
the misc driver loaded even though the sas driver fails to initialize"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: qla2xxx: Fix double free of dsd_list during driver load
scsi: mpt3sas: Fix in error path
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Concurrent register updates in the Qualcomm LPASS pin controller gets
a proper lock.
- revert a mutex fix that was causing problems: contention on the mutex
or something of the sort lead to probe reordering and MMC block
devices start to register in a different order, which unsuspecting
userspace is not ready to handle
* tag 'pinctrl-v6.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
Revert "pinctrl: avoid unsafe code pattern in find_pinctrl()"
pinctrl: qcom: lpass-lpi: fix concurrent register updates
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
Pull MTD fixes from Miquel Raynal:
"In the raw NAND subsystem, the major fix prevents using cached reads
with devices not supporting it. There was two bug reports about this.
Apart from that, three drivers (pl353, arasan and marvell) could
sometimes hide page program failures due to their their own program
page helper not being fully compliant with the specification (many
drivers use the default helpers shared by the core). Adding a missing
check prevents these situation.
Finally, the Qualcomm driver had a broken error path.
In the SPI-NAND subsystem one Micron device used a wrong bitmak
reporting possibly corrupted ECC status.
Finally, the physmap-core got stripped from its map_rom fallback by
mistake, this feature is added back"
* tag 'mtd/fixes-for-6.6-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux:
mtd: rawnand: Ensure the nand chip supports cached reads
mtd: rawnand: qcom: Unmap the right resource upon probe failure
mtd: rawnand: pl353: Ensure program page operations are successful
mtd: rawnand: arasan: Ensure program page operations are successful
mtd: spinand: micron: correct bitmask for ecc status
mtd: physmap-core: Restore map_rom fallback
mtd: rawnand: marvell: Ensure program page operations are successful
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
Pull MMC fixes from Ulf Hansson:
"MMC core:
- Capture correct oemid-bits for eMMC cards
- Fix error propagation for some ioctl commands
- Hold retuning if SDIO is in 1-bit mode
MMC host:
- mtk-sd: Use readl_poll_timeout_atomic to not "schedule while atomic"
- sdhci-msm: Correct minimum number of clocks
- sdhci-pci-gli: Fix LPM negotiation so x86/S0ix SoCs can suspend
- sdhci-sprd: Fix error code in sdhci_sprd_tuning()"
* tag 'mmc-v6.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
mmc: core: Capture correct oemid-bits for eMMC cards
mmc: mtk-sd: Use readl_poll_timeout_atomic in msdc_reset_hw
mmc: core: Fix error propagation for some ioctl commands
mmc: sdhci-sprd: Fix error code in sdhci_sprd_tuning()
mmc: sdhci-pci-gli: fix LPM negotiation so x86/S0ix SoCs can suspend
mmc: core: sdio: hold retuning if sdio in 1-bit mode
dt-bindings: mmc: sdhci-msm: correct minimum number of clocks
|
|
Pull block fixes from Jens Axboe:
"A fix for a regression with sed-opal and saved keys, and outside of
that an NVMe pull request fixing a few minor issues on that front"
* tag 'block-6.6-2023-10-20' of git://git.kernel.dk/linux:
nvme-pci: add BOGUS_NID for Intel 0a54 device
nvmet-auth: complete a request only after freeing the dhchap pointers
nvme: sanitize metadata bounce buffer for reads
block: Fix regression in sed-opal for a saved key.
nvme-auth: use chap->s2 to indicate bidirectional authentication
nvmet-tcp: Fix a possible UAF in queue intialization setup
nvme-rdma: do not try to stop unallocated queues
|
|
Pull drm fixes from Dave Airlie:
"Regular fixes for the week, amdgpu, i915, nouveau, with some other
scattered around, nothing major.
amdgpu:
- Fix possible NULL pointer dereference
- Avoid possible BUG_ON in GPUVM updates
- Disable AMD_CTX_PRIORITY_UNSET
i915:
- Fix display issue that was blocking S0ix
- Retry gtt fault when out of fence registers
bridge:
- ti-sn65dsi86: Fix device lifetime
edid:
- Add quirk for BenQ GW2765
ivpu:
- Extend address range for MMU mmap
nouveau:
- DP-connector fixes
- Documentation fixes
panel:
- Move AUX B116XW03 into panel-simple
scheduler:
- Eliminate DRM_SCHED_PRIORITY_UNSET
ttm:
- Fix possible NULL-ptr deref in cleanup
mediatek:
- Correctly free sg_table in gem prime vmap"
* tag 'drm-fixes-2023-10-20' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu: Reserve fences for VM update
drm/amdgpu: Fix possible null pointer dereference
accel/ivpu: Extend address range for MMU mmap
Revert "accel/ivpu: Use cached buffers for FW loading"
accel/ivpu: Don't enter d0i3 during FLR
drm/i915: Retry gtt fault when out of fence registers
drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes Owned
gpu/drm: Eliminate DRM_SCHED_PRIORITY_UNSET
drm/amdgpu: Unset context priority is now invalid
drm/mediatek: Correctly free sg_table in gem prime vmap
drm/edid: add 8 bpc quirk to the BenQ GW2765
drm/ttm: Reorder sys manager cleanup step
drm/nouveau/disp: fix DP capable DSM connectors
drm/nouveau: exec: fix ioctl kernel-doc warning
drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simple
drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary device
|
|
|
|
Michael reported soft lockups on a system that has unaccepted memory.
This occurs when a user attempts to allocate and accept memory on
multiple CPUs simultaneously.
The root cause of the issue is that memory acceptance is serialized with
a spinlock, allowing only one CPU to accept memory at a time. The other
CPUs spin and wait for their turn, leading to starvation and soft lockup
reports.
To address this, the code has been modified to release the spinlock
while accepting memory. This allows for parallel memory acceptance on
multiple CPUs.
A newly introduced "accepting_list" keeps track of which memory is
currently being accepted. This is necessary to prevent parallel
acceptance of the same memory block. If a collision occurs, the lock is
released and the process is retried.
Such collisions should rarely occur. The main path for memory acceptance
is the page allocator, which accepts memory in MAX_ORDER chunks. As long
as MAX_ORDER is equal to or larger than the unit_size, collisions will
never occur because the caller fully owns the memory block being
accepted.
Aside from the page allocator, only memblock and deferered_free_range()
accept memory, but this only happens during boot.
The code has been tested with unit_size == 128MiB to trigger collisions
and validate the retry codepath.
Fixes: 2053bc57f367 ("efi: Add unaccepted memory support")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Michael Roth <michael.roth@amd.com
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Tested-by: Michael Roth <michael.roth@amd.com>
[ardb: drop unnecessary cpu_relax() call]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
