Airoha EN7523 specific bug
--------------------------
We found that some serial console may pull TX line to GROUND during board
boot time. Airoha uses TX line as one of its bootstrap pins. On the EN7523
SoC this may lead to booting in RESERVED boot mode.
It was found that some flashes operates incorrectly in RESERVED mode.
Micron and Skyhigh flashes are definitely affected by the issue,
Winbond flashes are not affected.
Details:
--------
DMA reading of odd pages on affected flashes operates incorrectly. Page
reading offset (start of the page) on hardware level is replaced by 0x10.
Thus results in incorrect data reading. As result OS loading becomes
impossible.
Usage of UBI make things even worse. On attaching, UBI will detects
corruptions (because of wrong reading of odd pages) and will try to
recover. For recovering UBI will erase and write 'damaged' blocks with
a valid information. This will destroy all UBI data.
Non-DMA reading is OK.
This patch detects booting in reserved mode, turn off DMA and print big
fat warning.
It's worth noting that the boot configuration is preserved across reboots.
Therefore, to boot normally, you should do the following:
- disconnect the serial console from the board,
- power cycle the board.
Fixes: a403997c12 ("spi: airoha: add SPI-NAND Flash controller driver")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20251125234047.1101985-2-mikhail.kshevetskiy@iopsys.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Use kvzalloc() instead of kzalloc() to allocate memory to cache the
content of a firmware control.
Most firmware controls are only small, typically a few bytes. But on
some firmware there can be much larger controls for coefficient or
model data.
The overhead of kvzalloc() is negligible because most control allocs
can be satisfied by the normal kmalloc() that kvzalloc() will try first.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251127103947.1094934-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In cs_dsp_debugfs_read_controls_show() take the pwr_lock mutex
around the list walk. This protects against debugfs returning
a partial set of new controls if those controls are being added
to the list while it is being walked.
Controls are never deleted from this list, and are only added to
the end of the list. So there was never a danger of following a
stale pointer to garbage.
The worst case was that the printed list is truncated if it saw an
entry that was the list end just before a new entry was appended to
the list.
With the original code, the truncated list from the debugfs could
show only _some_ of the new entries. This could be confusing because
it appears that some new entries are missing.
Adding the mutex means that the debugfs read provides an atomic view.
Either it shows the old content before any of the new controls were
added; or it shows the new content after all the new controls are
added.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20251127113238.1251352-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Even if something goes wrong when performing suspend on DSP, from the
system perspective the component is not critical enough to block the
suspend operation entirely. Leaving recovery to next resume() suffices.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20251126095523.3925364-7-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
catpt_dai_pcm_new() is called during the bring up sequence of the
machine board device which is a different device to the parent (DSP)
device yet utilizes pm_runtime_xxx() against it in order to send IPCs.
If the parent's pm_runtime is not configured before that happens,
errors will occur.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251126095523.3925364-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Do not leave any resources hanging on the DSP side if
applying user settings fails.
Fixes: 768a3a3b32 ("ASoC: Intel: catpt: Optimize applying user settings")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251126095523.3925364-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is a number of interfaces available for manipulating instances of
struct resource. To improve readability, move away from manual editing
in favor of the common interface.
While at it, adjust spacing so that both code blocks, while found in
separate functions, looks cohesive.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251126095523.3925364-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Verify if the entire block is found within DRAM, not just
the start of it.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251126095523.3925364-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Propagate fwnode of the ACPI device to the SPI controller Linux device.
Currently only OF case propagates fwnode to the controller.
While at it, replace several calls to dev_fwnode() with a single one
cached in a local variable, and unify checks for fwnode type by using
is_*_node() APIs.
Fixes: 55ab8487e0 ("spi: spi-nxp-fspi: Add ACPI support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Haibo Chen <haibo.chen@nxp.com>
Link: https://patch.msgid.link/20251126202501.2319679-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Wei Fang says:
====================
net: fec: fix some PTP related issues
There are some issues which were introduced by the commit 350749b909
("net: fec: Add support for periodic output signal of PPS"). See each
patch for more details.
====================
Link: https://patch.msgid.link/20251125085210.1094306-1-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
There are currently two situations that can trigger the PTP interrupt,
one is the PPS event, the other is the PEROUT event. However, the irq
handler fec_pps_interrupt() does not check the irq event type and
directly registers a PPS event into the system, but the event may be
a PEROUT event. This is incorrect because PEROUT is an output signal,
while PPS is the input of the kernel PPS system. Therefore, add a check
for the event type, if pps_enable is true, it means that the current
event is a PPS event, and then the PPS event is registered.
Fixes: 350749b909 ("net: fec: Add support for periodic output signal of PPS")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20251125085210.1094306-5-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In the current driver, PPS and PEROUT use the same channel to generate
the events, so they cannot be enabled at the same time. Otherwise, the
later configuration will overwrite the earlier configuration. Therefore,
when configuring PPS, the driver will check whether PEROUT is enabled.
Similarly, when configuring PEROUT, the driver will check whether PPS
is enabled.
Fixes: 350749b909 ("net: fec: Add support for periodic output signal of PPS")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20251125085210.1094306-4-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
If the previously set PEROUT is already active, updating it will cause
the new PEROUT to start immediately instead of at the specified time.
This is because fep->reload_period is updated whithout check whether
the PEROUT is enabled, and the old PEROUT is not disabled. Therefore,
the pulse period will be updated immediately in the pulse interrupt
handler fec_pps_interrupt().
Currently, the driver does not support directly updating PEROUT and it
will make the logic be more complicated. To fix the current issue, add
a check before enabling the PEROUT, the driver will return an error if
PEROUT is enabled. If users wants to update a new PEROUT, they should
disable the old PEROUT first.
Fixes: 350749b909 ("net: fec: Add support for periodic output signal of PPS")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20251125085210.1094306-3-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The PEROUT allows the user to set a specified future time to output the
periodic signal. If the future time is far from the current time, the FEC
driver will use hrtimer to configure PEROUT one second before the future
time. However, the hrtimer will not be canceled if the PEROUT is disabled
before the hrtimer expires. So the PEROUT will be configured when the
hrtimer expires, which is not as expected. Therefore, cancel the hrtimer
in fec_ptp_pps_disable() to fix this issue.
Fixes: 350749b909 ("net: fec: Add support for periodic output signal of PPS")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Link: https://patch.msgid.link/20251125085210.1094306-2-wei.fang@nxp.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
On transmit, we are currently relying on skb->dev being set by
mctp_local_output() when we first set up the skb destination fields.
However, forwarded skbs do not use the local_output path, so will retain
their incoming netdev as their ->dev on tx. This does not work when
we're forwarding between interfaces.
Set skb->dev unconditionally in the transmit path, to allow for proper
forwarding.
We keep the skb->dev initialisation in mctp_local_output(), as we use it
for fragmentation.
Fixes: 269936db5e ("net: mctp: separate routing database from routing operations")
Suggested-by: Vince Chang <vince_chang@aspeedtech.com>
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
Link: https://patch.msgid.link/20251125-dev-forward-v1-1-54ecffcd0616@codeconstruct.com.au
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The tas2781-hda supports multi-projects. In some projects, GpioInt() was
dropped due to no IRQ connection. See the example code below:
Device (SPKR)
{
Name (_ADR, One)
Name (_HID, "TXNW2781")
Method (_CRS, 0, NotSerialized)
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x0038, ...)
I2cSerialBusV2 (0x0039, ...)
// GpioInt (Edge, ...) { 0x0000 }
//"GpioInt (...) {}" was commented out due to no IRQ connection.
})
Return (RBUF)
}
}
But in smi_i2c_probe(), smi_spi_probe() (serial-multi-instantiate.c), if
looking for IRQ by smi_get_irq() fails, it will return an error, will not add
new device, and cause smi_probe() to fail:
[ 2.356546] Serial bus multi instantiate pseudo device driver TXNW2781:00:
error -ENXIO: IRQ index 0 not found
[ 2.356561] Serial bus multi instantiate pseudo device driver TXNW2781:00:
error -ENXIO: Error requesting irq at index 0
So, we need to add an exception case for these situations. BTW, this patch
will take effect on both I2C and SPI devices.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20251126141434.11110-1-baojun.xu@ti.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
debugfs access modes were added in Linux 5.10 (Dec 2020) [1], but the
no-mount mode has behaved effectively the same as the off mode since
Linux 5.12 (Apr 2021) [2]. The only difference is the specific error
code returned by the debugfs_create_* functions, which is -ENOENT in
no-mount mode and -EPERM in off mode.
Given that no-mount hasn't worked for several years with no complaints,
just remove it.
[1] a24c6f7bc9 ("debugfs: Add access restriction option")
[2] bc6de804d3 ("debugfs: be more robust at handling improper input in debugfs_lookup()")
56348560d4 ("debugfs: do not attempt to create a new file before the filesystem is initalized")
Signed-off-by: Aaron Thompson <dev@aaront.org>
Link: https://patch.msgid.link/20251120102222.18371-3-dev@null.aaront.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
debugfs_get_tree() can only be called if debugfs itself calls
simple_pin_fs() or register_filesystem(), and those call paths also
check the access mode.
debugfs_start_creating() checks the access mode so the checks in the
debugfs_create_* functions are unnecessary.
An upcoming change will affect debugfs_allow, so doing this cleanup
first will make that change simpler.
Signed-off-by: Aaron Thompson <dev@aaront.org>
Link: https://patch.msgid.link/20251120102222.18371-2-dev@null.aaront.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Duyck says:
====================
net: phy: Add support for fbnic PHY w/ 25G, 50G, and 100G support
To transition the fbnic driver to using the XPCS driver we need to address
the fact that we need a representation for the FW managed PMD that is
actually a SerDes PHY to handle link bouncing during link training.
This patch set introduces the necessary bits to the XPCS driver code to
enable it to read 25G, 50G, and 100G speeds from the PCS ctrl1 register,
and adds support for the approriate interfaces.
The rest of this patch set enables the changes to fbnic to make use of
these interfaces and expose a PMD that can provide a necessary link delay
to avoid link flapping in the event that a cable is disconnected and
reconnected, and to correctly expose the count for the link down events.
With this we have the basic groundwork laid as with this all the bits and
pieces are in place in terms of reading the configuration. The general plan
for follow-on patch sets is to start looking at enabling changing the
configuration in environments where that is supported.
====================
Link: https://patch.msgid.link/176374310349.959489.838154632023183753.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
As we have exposed the PCS registers via the SWMII we can now start looking
at connecting the XPCS driver to those registers and let it mange the PCS
instead of us doing it directly from the fbnic driver.
For now this just gets us the ability to detect link. The hope is in the
future to add some of the vendor specific registers to begin enabling XPCS
configuration of the interface.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374325295.959489.14521115864034905277.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
In order for us to support a PCS device we need to add an MDIO bus to allow
the drivers to have access to the registers for the device. This change
adds such an interface.
The interface will consist of 2 PHY addrs, the first one consisting of a
PMD and PCS, and the second just being a PCS. There is a need for 2 PHYs
addrs due to the fact that in order to support the 50GBase-CR2 mode we will
need to access and configure the PCS vendor registers and RSFEC registers
from the second lane identical to the first.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374324532.959489.15389723111560978054.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
We were previously not displaying the number of link_down_events tracked by
the device. With this change we should now be able to display the value.
The value itself tracks the calls from the phylink interface to the
mac_link_down call.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374323824.959489.6915296616773178954.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
One complication with the design of our part is that the PMD doesn't
provide a direct signal to the host. Instead we have visibility to signals
that the PCS provides to the MAC that allow us to check the link state
through that.
We will need to account for several things in the PMD and firmware when
managing the link. Specifically when the link first starts to come up the
PMD will cause the link to flap. This is due to the firmware starting a
training cycle when the link is first detected. This will cause link
flapping if we were to immediately report link up when the PCS first
detects it.
To address that we are adding a pmd_state variable that is meant to be a
countdown of sorts indicating the state of the PMD. If the link is down or
has been reconfigured the PMD will start out in the initialize state. By
default the link is assumed to be in the SEND_DATA state if it is available
on initial link inspection. If link is detected while in the initialize
state the PMD state will switch to training, and if after 4 seconds the
link is still stable we will transition to link_ready, and finally the
send_data state. With this we can avoid link flapping when a cable is
first connected to the NIC.
One side effect of this is that we need to pull the link state away from
the PCS. For now we use a union of the PCS link state register value and
the pmd_state. The plan is to add a PMD register to report the pmd_state
to the phylink interface. With that we can then look at switching over to
the use of the XPCS driver for fbnic instead of having an internal one.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374323107.959489.14951134213387615059.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Throughout several spots in the code I had called out the IRQ as being
related to the PCS. However the actual IRQ is a part of the MAC and it is
just exposing PCS data. To more accurately reflect the owner of the calls
this change makes it so that we rename the functions and values that are
taking in the interrupt value and processing it to reflect that it is a MAC
call and not a PCS one.
This change is mostly motivated by the fact that we will be moving the
handling of this interrupt from being PCS focused to being more PMA/PMD
focused as this will drive the phydev driver that I am adding instead of
driving the PCS directly.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374322373.959489.12018231545479053860.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The fbnic driver is planning to make use of the XPCS driver to enable
support for PCS and better integration with phylink. To do this though we
will need to enable several workarounds since the PMD interface for fbnic
is likely to be unique since it is a mix of two different vendor products
with a unique wrapper around the IP.
I have generated a PHY identifier based on IEEE 802.3-2022 22.2.4.3.1 using
an OUI belonging to Meta Platforms and used with our NICs. Using this we
will provide it as the PMD ID via the SW based MDIO interface so that
the fbnic device can be identified and necessary workarounds enabled in the
XPCS driver.
As an initial workaround this change adds an exception so that soft_reset
is not set when the driver is initially bound to the PCS.
In addition I have added logic to integrate the PMD Rx signal detect state
into the link state for the PCS. With this we can avoid the link coming up
too soon on the FBNIC PMD and as a result of it being in the training state
so we can avoid link flaps.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374321695.959489.6648161125012056619.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The XPCS driver was mangling the PMA identifier as the original code
appears to have been focused on just capturing the OUI. Rather than store a
mangled ID it is better to work with the actual PMA ID and instead just
mask out the values that don't apply rather than shifting them and
reordering them as you still don't get the original OUI for the NIC without
having to bitswap the values as per the definition of the layout in IEEE
802.3-2022 22.2.4.3.1.
By laying it out as it was in the hardware it is also less likely for us to
have an unintentional collision as the enum values will occupy the revision
number area while the OUI occupies the upper 22 bits.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374320920.959489.17267159479370601070.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
With this change we are adding support for 25G, 50G, and 100G interface
types to the XPCS driver. This had supposedly been enabled with the
addition of XLGMII but I don't see any capability for configuration there
so I suspect it may need to be refactored in the future.
With this change we can enable the XPCS driver with the selected interface
and it should be able to detect link, speed, and report the link status to
the phylink interface.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374320248.959489.11649590675011158859.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The 2.5G and 5G values are not consistent between the PCS CTRL1 and PMA
CTRL1 values. In order to avoid confusion between the two I am updating the
values to include "PMA" in the name similar to values used in similar
places.
To avoid breaking UAPI I have retained the original macros and just defined
them as the new PMA based defines.
Signed-off-by: Alexander Duyck <alexanderduyck@fb.com>
Link: https://patch.msgid.link/176374319569.959489.6610469879021800710.stgit@ahduyck-xeon-server.home.arpa
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace repetitive switch-case statements for PMF_POLICY_BIOS_OUTPUT_*
with a helper function and consolidated case handling. This reduces code
duplication and improves maintainability.
The 10 BIOS output policies (PMF_POLICY_BIOS_OUTPUT_1 through
PMF_POLICY_BIOS_OUTPUT_10) previously each had individual case statements
with identical logic. This patch introduces
amd_pmf_get_bios_output_idx() to map policy values to array indices,
consolidating the handling into a single case block with fallthrough.
Also, add a new function amd_pmf_update_bios_output() to simplify the code
handling.
This approach handles non-sequential policy enum values gracefully and
makes future additions easier to implement.
No functional changes.
Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://patch.msgid.link/20251127091038.2088387-1-Shyam-sundar.S-k@amd.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
The driver previously skipped handling ClearFeature(ENDPOINT_HALT)
when the endpoint was already not halted. This prevented the
controller from resetting the data sequence number and reinitializing
the endpoint state.
According to USB 3.2 specification Rev. 1.1, section 9.4.5,
ClearFeature(ENDPOINT_HALT) must always reset the data sequence and
set the stream state machine to Disabled, regardless of whether the
endpoint was halted.
Remove the early return so that ClearFeature(ENDPOINT_HALT) always
resets the endpoint sequence state as required by the specification.
Fixes: 49db427232 ("usb: gadget: Add UDC driver for tegra XUSB device mode controller")
Cc: stable <stable@kernel.org>
Signed-off-by: Haotien Hsu <haotienh@nvidia.com>
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Link: https://patch.msgid.link/20251127033540.2287517-1-waynec@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are the USB serial updates for 6.19-rc1:
- fix belkin_sa and kobil_sct TIOCMBIS and TIOCMBIC ioctls
- match on interface number for dual-port ftdi devices with reserved
jtag port
- do not log reserved ftdi jtag ports on probe
- apply ftdi_sio NDI quirk remapping 19200 bps consistently
- drop ftdi_sio NDI quirk module parameter
- clean up ftdi_sio quirk implementations
- add more modem device ids
Included are also various clean ups.
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCaSgIYwAKCRALxc3C7H1l
CJNkAP4nUci9snQxOwALfxIb5d4qBgeyHtqA2JO1BNENztExtgEA1vrCIWZJ7uFS
H60jvRQXtNaNJmn5Zgu0gQMbPk1SWwM=
=VLLU
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-6.19-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB serial updates for 6.19-rc1
Here are the USB serial updates for 6.19-rc1:
- fix belkin_sa and kobil_sct TIOCMBIS and TIOCMBIC ioctls
- match on interface number for dual-port ftdi devices with reserved
jtag port
- do not log reserved ftdi jtag ports on probe
- apply ftdi_sio NDI quirk remapping 19200 bps consistently
- drop ftdi_sio NDI quirk module parameter
- clean up ftdi_sio quirk implementations
- add more modem device ids
Included are also various clean ups.
All have been in linux-next with no reported issues.
* tag 'usb-serial-6.19-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: option: move Telit 0x10c7 composition in the right place
USB: serial: option: add Telit Cinterion FE910C04 new compositions
USB: serial: option: add Foxconn T99W760
USB: serial: ftdi_sio: drop NDI quirk module parameter
USB: serial: ftdi_sio: clean up NDI speed hack
USB: serial: ftdi_sio: enable NDI speed hack consistently
USB: serial: ftdi_sio: rename quirk symbols
USB: serial: ftdi_sio: clean up quirk comments
USB: serial: ftdi_sio: rewrite 8u2232c quirk
USB: serial: ftdi_sio: silence jtag probe
USB: serial: ftdi_sio: match on interface number for jtag
USB: serial: kobil_sct: drop unnecessary initialisations
USB: serial: kobil_sct: clean up set_termios()
USB: serial: kobil_sct: add control request helpers
USB: serial: kobil_sct: clean up device type checks
USB: serial: kobil_sct: clean up tiocmset()
USB: serial: belkin_sa: clean up tiocmset()
USB: serial: kobil_sct: fix TIOCMBIS and TIOCMBIC
USB: serial: belkin_sa: fix TIOCMBIS and TIOCMBIC
German Maglione is a co-maintainer of the virtiofsd userspace device
implementation (https://gitlab.com/virtio-fs/virtiofsd) and is currently
one of the most active virtiofs developers outside the kernel.
I have not worked on virtiofs except to review kernel patches for a few
years now and would like German to take over from me gradually. It is
healthier to have a kernel maintainer who is actively involved. I expect
to remove myself in a few months.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Link: https://patch.msgid.link/20251126211548.598469-1-stefanha@redhat.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
The len field originates from untrusted network packets. Boundary
checks have been added to prevent potential out-of-bounds writes when
decrypting the connection secret or processing service tickets.
[ idryomov: changelog ]
Cc: stable@vger.kernel.org
Signed-off-by: ziming zhang <ezrakiez@gmail.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
OSD indexes come from untrusted network packets. Boundary checks are
added to validate these against map->max_osd.
[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic
edits ]
Cc: stable@vger.kernel.org
Signed-off-by: ziming zhang <ezrakiez@gmail.com>
Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The rzg2l_gpt_config() tests the rzg2l_gpt->period_tick variable when
both channels of a hardware channel are in use. This check is not valid
if rzg2l_gpt_config() is called after disabling all the channels, as it
tests against the cached value. Hence, allow checking and setting the
cached value only if the sibling channel is enabled.
While at it, drop else after return statement to fix the check patch
warning.
Cc: stable@kernel.org
Fixes: 061f087f5d ("pwm: Add support for RZ/G2L GPT")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://patch.msgid.link/20251126104308.142302-1-biju.das.jz@bp.renesas.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
The prefetch instruction is meant to speed up access to memory referenced
by its address argument. In the bng_re code path, it has no effect,
because the pointer refers to a function that is executed immediately
afterward.
The issue was identified due to the following kbuild compilation error:
drivers/infiniband/hw/bng_re/bng_fw.c: In function 'bng_re_creq_irq':
drivers/infiniband/hw/bng_re/bng_fw.c:278:9: error: implicit
declaration of function 'prefetch' [-Wimplicit-function-declaration]
278 | prefetch(bng_re_get_qe(hwq, sw_cons, NULL));
| ^~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202511260607.Kuxn4NnN-lkp@intel.com/
Fixes: 4f830cd8d7 ("RDMA/bng_re: Add infrastructure for enabling Firmware channel")
Link: https://patch.msgid.link/20251126-remove-prefetch-v1-1-fcac22007ea7@nvidia.com
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
When building for a platform without CONFIG_PM_SLEEP, such as s390,
there are two unused function warnings:
drivers/video/backlight/aw99706.c:436:12: error: 'aw99706_resume' defined but not used [-Werror=unused-function]
436 | static int aw99706_resume(struct device *dev)
| ^~~~~~~~~~~~~~
drivers/video/backlight/aw99706.c:429:12: error: 'aw99706_suspend' defined but not used [-Werror=unused-function]
429 | static int aw99706_suspend(struct device *dev)
| ^~~~~~~~~~~~~~~
SET_SYSTEM_SLEEP_PM_OPS, used within SIMPLE_DEV_PM_OPS, expands to
nothing when CONFIG_PM_SLEEP is not set, so these functions are
completely unused in this configuration.
SIMPLE_DEV_PM_OPS is deprecated in favor of DEFINE_SIMPLE_DEV_PM_OPS,
which avoids this issue by using pm_sleep_ptr to make these callbacks
NULL when CONFIG_PM_SLEEP is unset while making the callback functions
always appear used to the compiler regardless of configuration. Switch
to DEFINE_SIMPLE_DEV_PM_OPS for aw99706_pm_ops to clear up the warning.
Additionally, wrap the pointer to aw99706_pm_ops in pm_ptr() in
aw99706_i2c_driver to ensure that the structure is completely eliminated
in configurations without CONFIG_PM.
Fixes: 88a8e9b49ee8 ("backlight: aw99706: Add support for Awinic AW99706 backlight")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://patch.msgid.link/20251120-backlight-aw99706-fix-unused-pm-functions-v1-1-8b9c17c4e783@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Linus figured less #ifdef is more better and making x86-32 use
GENERIC_BUG_RELATIVE_POINTERS removes one layer of macro magic from
the bug.h bits.
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Encoding a relative NULL pointer doesn't work for KASLR, when the
whole kernel image gets shifted, the __bug_table and the target string
get shifted by the same amount and the relative offset is preserved.
However when the target is an absolute 0 value and the __bug_table
gets moved about, the end result in a pointer equivalent to
kaslr_offset(), not NULL.
Notably, this will generate SHN_UNDEF relocations, and Ard would
really like to not have those at all.
Use the empty string to denote no-string.
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Building objtool with disassembly support can fail when including
the bdf.h file:
In file included from tools/objtool/include/objtool/arch.h:108,
from check.c:14:
/usr/include/bfd.h:35:2: error: #error config.h must be included before this header
35 | #error config.h must be included before this header
| ^~~~~
This check is present in the bfd.h file generated from the binutils
source code, but it is not necessarily present in the bfd.h file
provided in a binutil package (for example, it is not present in
the binutil RPM).
The solution to this issue is to define the PACKAGE macro before
including bfd.h. This is the solution suggested by the binutil
developer in bug 14243, and it is used by other kernel tools
which also use bfd.h (perf and bpf).
Fixes: 5995330382 ("objtool: Disassemble code with libopcodes instead of running objdump")
Closes: https://lore.kernel.org/all/3fa261fd-3b46-4cbe-b48d-7503aabc96cb@oracle.com/
Reported-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://sourceware.org/bugzilla/show_bug.cgi?id=14243
Link: https://patch.msgid.link/20251126134519.1760889-1-alexandre.chartre@oracle.com
There's an unexpected interaction between the reset-gpio driver and the
shared GPIO support. The reset-gpio device is an auxiliary device that's
created dynamically and fulfills a similar role to the gpio-shared-proxy
driver but is limited in scope to just supporting the "reset-gpios"
property.
The shared GPIO core code does not take into account that the machine
lookup entry we create when scanning the device-tree must connect the
reset-gpio device - that is the actual consumer of the GPIO and not the
consumer defined on the device tree, which in turn consumes the shared
reset control exposed by the reset-gpio device - to the GPIO controller.
We also must not skip the gpio-shared-proxy driver as it's possible that
a shared GPIO may be used by one consumer as a reset-gpios going through
the reset-gpio device and another that uses GPIOLIB.
We need to make it a special case handled in gpiolib-shared.c. Add a new
function - gpio_shared_dev_is_reset_gpio() - whose role it is to verify
if a non-matching consumer of a shared pin is a reset-gpio device and
make sure it's the right one for this pin. To that end make sure that
its parent is the GPIO controller in question and that the fwnode we
identified as sharing the pin references that controller via the
"reset-gpios" property.
Only include that code if the reset-gpio driver is enabled.
Fixes: a060b8c511 ("gpiolib: implement low-level, shared GPIO support")
Reported-by: Val Packett <val@packett.cool>
Closes: https://lore.kernel.org/all/3b5d9df5-934d-4591-8827-6c9573a6f7ba@packett.cool/
Tested-by: Val Packett <val@packett.cool>
Tested-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20251125-gpiolib-shared-reset-gpio-fix-v2-1-4eb6fa41f1dd@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
test just uses vhost features with no change,
but people tend to copy/paste code, so let's
add our own define.
Message-ID: <23ca04512a800ee8b3594482492e536020931340.1764225384.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
virtio pci uses word to mean "16 bits". mmio uses it to mean
"32 bits".
To avoid confusion, let's avoid the term in core virtio
altogether. Just say U64 to mean "64 bit".
Fixes: e7d4c1c5a5 ("virtio: introduce extended features")
Cc: Paolo Abeni <pabeni@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Message-ID: <ad53b7b6be87fc524f45abaeca0bb05fb3633397.1764225384.git.mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
