At beginning of probe() function, the driver iterates over OF children
and assigns found device node for later. The code uses
for_each_available_child_of_node() which drops the references on
children on each successful pass, thus the probe function operates later
on the device node without holding the reference.
Fix this by increasing the reference count for found child node and
drop it at the end of the probe, because it is not needed further (the
V4L init code takes its own references).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240816-cleanup-h-of-node-put-var-v1-3-1d0292802470@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Let the kememdup_array() take care about multiplication and possible
overflows.
Signed-off-by: Yu Jiaoliang <yujiaoliang@vivo.com>
Signed-off-by: Louis Peens <louis.peens@corigine.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240821081447.12430-1-yujiaoliang@vivo.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit 6b0e82791b ("powerpc/e500: switch to 64 bits PGD on 85xx
(32 bits)") switched PGD entries to 64 bits, but pgd_val() returns
an unsigned long which is 32 bits on PPC32. This is not a problem
for regular PMD entries because the upper part is always NULL, but
when PMD entries are leaf they contain 64 bits values, so pgd_val()
must return an unsigned long long instead of an unsigned long.
Also change the condition to CONFIG_PPC_85xx instead of CONFIG_PPC_E500
as the change was meant for 32 bits only. Allthough this should be
harmless on PPC64, it generates a warning with pgd_ERROR print.
Fixes: 6b0e82791b ("powerpc/e500: switch to 64 bits PGD on 85xx (32 bits)")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/45f8fdf298ec3df7573b66d21b03a5cda92e2cb1.1724313510.git.christophe.leroy@csgroup.eu
After building the VDSO, there is a verification that it contains
no dynamic relocation, see commit aff69273af ("vdso: Improve
cmd_vdso_check to check all dynamic relocations").
This verification uses readelf -r and doesn't work if rela sections
are discarded.
Fixes: 8ad57add77 ("powerpc/build: vdso linker warning for orphan sections")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/45c3e6fc76cad05ad2cac0f5b5dfb4fae86dc9d6.1724153239.git.christophe.leroy@csgroup.eu
Move the stepping related macros over to display. We can proceed to
remove the compat macros from xe.
Note: Looks like we've failed to actually initialize the display
stepping for GMD ID based platforms in the xe driver. It does get set in
display runtime info, but until now the compat macro used
xe->info.step.display which was not set for GMD ID.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ce8bb94e1a801d3c345f1810837bdd1964c3af75.1724180287.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Both i915 and xe have code to identify display steppings. Start
deduplicating this by, uh, adding a third copy in display code. This is
not yet used for anything other than debug logging. We'll switch over
later.
For platforms before GMD ID, attach the mapping from PCI revision to
stepping in the platform and subplatform descriptors. This is a
considerably cleaner approach than having it completely separate.
Also add a separate field for stepping in display runtime info,
preserving the value from GMD ID.
v2: Handle NULL subdesc (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821095036.2044654-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_display_step_name() is an unnecessary extra
indirection. Simplify by just adding a macro to map intel_step_name() to
xe_step_name().
We'll need to temporarily add a compat INTEL_DISPLAY_STEP() for this.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cbea7def331cc9d2438da49ae344b9987f27cd12.1724180287.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
For a normal calibration blob the calTarget values must be non-zero and
unique, and the calTime values must be non-zero. Don't rely on
get_random_bytes() to be random enough to guarantee this. Force the
calTarget and calTime values to be valid while retaining randomness
in the values.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Fixes: 177862317a ("ASoC: cs-amp-lib: Add KUnit test for calibration helpers")
Link: https://patch.msgid.link/20240822115725.259568-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Prepare for removal of dpcm_playback and dpcm_capture flags in
dailinks.
[Kuninori adjusted Pierre-Louis's patch]
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87o75maah5.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
dpcm_xxx flags are no longer needed.
We need to use xxx_only flags instead if needed, but
snd_soc_dai_link_set_capabilities() user adds dpcm_xxx if playback/capture
were available. Thus converting dpcm_xxx to xxx_only is not needed.
Just remove it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/87r0aiaahh.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
I have been wondering why DPCM needs special flag (= dpcm_playback/capture)
to use it. Below is the history why it was added to ASoC.
(A) In beginning, there was no dpcm_xxx flag on ASoC.
It checks channels_min for DPCM, same as current non-DPCM.
Let's name it as "validation check" here.
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
if (cpu_dai->driver->playback.channels_min)
playback = 1;
if (cpu_dai->driver->capture.channels_min)
capture = 1;
(B) commit 1e9de42f43 ("ASoC: dpcm: Explicitly set BE DAI link supported
stream directions") force to use dpcm_xxx flag on DPCM. According to
this commit log, this is because "Some BE dummy DAI doesn't set
channels_min for playback/capture". But we don't know which DAI is it,
and not know why it can't/don't have channels_min. Let's name it as
"no_chan_DAI" here. According to the code and git-log, it is used as
DCPM-BE and is CPU DAI. I think the correct solution was set
channels_min on "no_chan_DAI" side, not update ASoC framework side. But
everything is under smoke today.
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
playback = rtd->dai_link->dpcm_playback;
capture = rtd->dai_link->dpcm_capture;
(C) commit 9b5db05936 ("ASoC: soc-pcm: dpcm: Only allow playback/capture
if supported") checks channels_min (= validation check) again. Because
DPCM availability was handled by dpcm_xxx flag at that time, but some
Sound Card set it even though it wasn't available. Clearly there's
a contradiction here. I think correct solution was update Sound Card
side instead of ASoC framework. Sound Card side will be updated to
handle this issue later (commit 25612477d2 ("ASoC: soc-dai: set
dai_link dpcm_ flags with a helper"))
if (rtd->dai_link->dynamic || rtd->dai_link->no_pcm) {
...
playback = rtd->dai_link->dpcm_playback &&
snd_soc_dai_stream_valid(cpu_dai, ...);
capture = rtd->dai_link->dpcm_capture &&
snd_soc_dai_stream_valid(cpu_dai, ...);
This (C) patch should have broken "no_chan_DAI" which doesn't have
channels_min, but there was no such report during this 4 years.
Possibilities case are as follows
- No one is using "no_chan_DAI"
- "no_chan_DAI" is no longer exist : was removed ?
- "no_chan_DAI" is no longer exist : has channels_min ?
Because of these history, this dpcm_xxx is unneeded flag today. But because
we have been used it for 10 years since (B), it may have been used
differently. For example some DAI available both playback/capture, but it
set dpcm_playback flag only, in this case dpcm_xxx flag is used as
availability limitation. We can use playback_only flag instead in this
case, but it is very difficult to find such DAI today.
Let's add grace time to remove dpcm_playback/capture flag.
This patch don't use dpcm_xxx flag anymore, and indicates warning to use
xxx_only flag if both playback/capture were available but using only
one of dpcm_xxx flag, and not using xxx_only flag.
Link: https://lore.kernel.org/r/87edaym2cg.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://patch.msgid.link/87seuyaahn.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently in of_regulator_bulk_get_all(), if any regulator request
fails, the error path releases all regulators already requested,
but leaves the |struct regulator_bulk_data| memory to the caller
to free, and also leaves the regulator consumer pointers dangling.
The latter behavior is not documented, and may not be what the
caller is expecting.
Instead, explicitly clean up everything on error, and make it clear
that the result pointer is only update if the whole request succeeds.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
If regulator_get() in of_regulator_bulk_get_all() returns an error, that
error gets overridden and -EINVAL is always passed out. This masks probe
deferral requests and likely won't work properly in all cases.
Fix this by letting of_regulator_bulk_get_all() return the original
error code.
Fixes: 27b9ecc7a9 ("regulator: Add of_regulator_bulk_get_all")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The original error message simply said "get() with no identifier"
without any context as to what was requested or what device the
request was related to. The only thing the user or developer could
do was grep for the message in the full source tree.
Amend the error message to be more specific, and also use dev_*
to associate the error message with a device.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20240822072047.3097740-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
PCI and platform buses have different defaults for runtime PM.
In particular PCI probe is assumed to be called when PM runtime
is enabled by the PCI core. In this case if we try enable it again
the PM runtime complaints with
pxa2xx_spi_pci 0000:00:07.0: Unbalanced pm_runtime_enable!
Fix this by moving PM runtime handling from the SPI PXA2xx core
to the glue drivers.
Fixes: cc160697a5 ("spi: pxa2xx: Convert PCI driver to use spi-pxa2xx code directly")
Fixes: 3d8f037fbc ("spi: pxa2xx: Move platform driver to a separate file")
Fixes: 20ade9b977 ("spi: pxa2xx: Extract pxa2xx_spi_platform_*() callbacks")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240822113408.750831-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The platform_data field may be supplied by legacy board code.
In other cases we override it, and module remove and probe cycle
will crash the kernel since it will carry a stale pointer.
Fix this by supplying a third argument to the pxa2xx_spi_probe()
and avoid overriding dev->platform_data.
Reported-by: Hao Ma <hao.ma@intel.com>
Fixes: cc160697a5 ("spi: pxa2xx: Convert PCI driver to use spi-pxa2xx code directly")
Fixes: 3d8f037fbc ("spi: pxa2xx: Move platform driver to a separate file")
Fixes: 20ade9b977 ("spi: pxa2xx: Extract pxa2xx_spi_platform_*() callbacks")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240822113408.750831-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
GDM1 port on EN7581 SoC is connected to the lan dsa switch.
GDM{2,3,4} can be used as wan port connected to an external
phy module. Configure hw mac address registers according to the port id.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20240821-airoha-eth-wan-mac-addr-v2-1-8706d0cd6cd5@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Commit 39dc8b8ea3 ("wifi: mac80211: pass parsed TPE data to drivers") breaks
ath11k, leading to kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
RIP: 0010:ath11k_mac_get_eirp_power.isra.0+0x5b/0x80 [ath11k]
Call Trace:
<TASK>
ath11k_mac_fill_reg_tpc_info+0x3d6/0x800 [ath11k]
ath11k_mac_vdev_start_restart+0x412/0x4d0 [ath11k]
ath11k_mac_op_sta_state+0x7bc/0xbb0 [ath11k]
drv_sta_state+0xf1/0x5f0 [mac80211]
sta_info_insert_rcu+0x28d/0x530 [mac80211]
sta_info_insert+0xf/0x20 [mac80211]
ieee80211_prep_connection+0x3b4/0x4c0 [mac80211]
ieee80211_mgd_auth+0x363/0x600 [mac80211]
The issue scenario is, AP advertises power spectral density (PSD) values in its
transmit power envelope (TPE) IE and supports 160 MHz bandwidth in 6 GHz. When
connecting to this AP, in ath11k_mac_parse_tx_pwr_env(), the local variable
psd is true and then reg_tpc_info.num_pwr_levels is set to 8 due to 160 MHz
bandwidth. Note here ath11k fails to set reg_tpc_info.is_psd_power as TRUE due
to above commit. Then in ath11k_mac_fill_reg_tpc_info(), for each of the 8
power levels, for a PSD channel, ath11k_mac_get_psd_channel() is expected to
be called to get required information. However due to invalid
reg_tpc_info.is_psd_power, it is ath11k_mac_get_eirp_power() that gets called
and passed with pwr_lvl_idx as one of the arguments. Note this function
implicitly requires pwr_lvl_idx to be no more than 3. So when pwr_lvl_idx is
larger than that ath11k_mac_get_seg_freq() returns invalid center frequency,
with which as the input ieee80211_get_channel() returns NULL, then kernel
crashes due to NULL pointer dereference.
Fix it by setting reg_tpc_info.is_psd_power properly.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
Fixes: 39dc8b8ea3 ("wifi: mac80211: pass parsed TPE data to drivers")
Reported-by: Mikko Tiihonen <mikko.tiihonen@iki.fi>
Tested-by: Mikko Tiihonen <mikko.tiihonen@iki.fi>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219131
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://patch.msgid.link/20240813083808.9224-1-quic_bqiang@quicinc.com
Some CPT AF registers are per LF and others are global. Translation
of PF/VF local LF slot number to actual LF slot number is required
only for accessing perf LF registers. CPT AF global registers access
do not require any LF slot number. Also, there is no reason CPT
PF/VF to know actual lf's register offset.
Without this fix microcode loading will fail, VFs cannot be created
and hardware is not usable.
Fixes: bc35e28af7 ("octeontx2-af: replace cpt slot with lf id on reg write")
Signed-off-by: Bharat Bhushan <bbhushan2@marvell.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20240821070558.1020101-1-bbhushan2@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The current implementation incorrectly sets the mode bit of the PHY chip.
Bit 15 (RTL8211F_LEDCR_MODE) should not be shifted together with the
configuration nibble of a LED- it should be set independently of the
index of the LED being configured.
As a consequence, the RTL8211F LED control is actually operating in Mode A.
Fix the error by or-ing final register value to write with a const-value of
RTL8211F_LEDCR_MODE, thus setting Mode bit explicitly.
Fixes: 17784801d8 ("net: phy: realtek: Add support for PHY LEDs on RTL8211F")
Signed-off-by: Sava Jakovljev <savaj@meyersound.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Link: https://patch.msgid.link/PAWP192MB21287372F30C4E55B6DF6158C38E2@PAWP192MB2128.EURP192.PROD.OUTLOOK.COM
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Common pattern of handling deferred probe can be simplified with
dev_err_probe() and devm_clk_get_optional(). This results in much
less code.
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821214052.6800-6-wahrenst@gmx.net
DRM_ERROR() has been deprecated in favor of pr_err(). However, we
should prefer to use drm_err() whenever possible so we get device-
specific output with the error message. In error case of kcalloc,
we can simply drop DRM_ERROR(), because kcalloc already logs errors.
Suggested-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821214052.6800-4-wahrenst@gmx.net
The commit 0f5251339e ("drm/vc4: hdmi: Make sure the controller is
powered in detect") introduced the necessary power management handling
to avoid register access while controller is powered down.
Unfortunately it just print a warning if pm_runtime_resume_and_get()
fails and proceed anyway.
This could happen during suspend to idle. So we must assume it is unsafe
to access the HDMI register. So bail out properly.
Fixes: 0f5251339e ("drm/vc4: hdmi: Make sure the controller is powered in detect")
Signed-off-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240821214052.6800-3-wahrenst@gmx.net
A few tests check if nettest exists in the $PATH before adding
$PWD to $PATH and re-checking. They don't discard stderr on
the first check (and nettest is built as part of selftests,
so it's pretty normal for it to not be available in system $PATH).
This leads to output noise:
which: no nettest in (/home/virtme/tools/fs/bin:/home/virtme/tools/fs/sbin:/home/virtme/tools/fs/usr/bin:/home/virtme/tools/fs/usr/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin)
Add a common helper for the check which does silence stderr.
There is another small functional change hiding here, because pmtu.sh
and fib_rule_tests.sh used to return from the test case rather than
completely exit. Building nettest is not hard, there should be no need
to maintain the ability to selectively skip cases in its absence.
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Link: https://patch.msgid.link/20240821012227.1398769-1-kuba@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Replace msleep() with usleep_range() in sun50i_a100_ledc_suspend()
to address the checkpatch.pl warning. msleep() for such short delay
can lead to inaccurate sleep times. Switch to usleep_range()
provide more precise delay.
Fix the following warning from checkpatch.pl:
WARNING: msleep < 20ms can sleep for up to 20ms;
see Documentation/timers/timers-howto.rst
+ msleep(1);
Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20240816171129.6411-1-abhishektamboli9@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The MAC only has add the TX delay and it can not be modified.
MAC and PHY are both set the TX delay cause transmission problems.
So just disable TX delay in PHY, when use rgmii to attach to
external phy, set PHY_INTERFACE_MODE_RGMII_RXID to phy drivers.
And it is does not matter to internal phy.
Fixes: bc2426d74a ("net: ngbe: convert phylib to phylink")
Signed-off-by: Mengyuan Lou <mengyuanlou@net-swift.com>
Cc: stable@vger.kernel.org # 6.3+
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Link: https://patch.msgid.link/E6759CF1387CF84C+20240820030425.93003-1-mengyuanlou@net-swift.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Dell platform with ALC215 ALC285 ALC289 ALC225 ALC295 ALC299, plug
headphone or headset.
It had a chance to get no sound from headphone.
Replace depop procedure will solve this issue.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/d0de1b03fd174520945dde216d765223@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Ensure there is sufficient room to access the protocol field of the
VLAN header, validate it once before the flowtable lookup.
=====================================================
BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32
nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626
nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]
nf_ingress net/core/dev.c:5440 [inline]
Fixes: 4cd91f7c29 ("netfilter: flowtable: add vlan support")
Reported-by: syzbot+8407d9bb88cd4c6bf61a@syzkaller.appspotmail.com
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
The probe function never performs any paltform device allocation, thus
error path "undo_platform_dev_alloc" is entirely bogus. It drops the
reference count from the platform device being probed. If error path is
triggered, this will lead to unbalanced device reference counts and
premature release of device resources, thus possible use-after-free when
releasing remaining devm-managed resources.
Fixes: f83fca0707 ("usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC")
Cc: stable@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Link: https://lore.kernel.org/r/20240814093957.37940-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DWC3_EP_RESOURCE_ALLOCATED flag ensures that the resource of an
endpoint is only assigned once. Unless the endpoint is reset, don't
clear this flag. Otherwise we may set endpoint resource again, which
prevents the driver from initiate transfer after handling a STALL or
endpoint halt to the control endpoint.
Commit f2e0eee470 ("usb: dwc3: ep0: Don't reset resource alloc flag")
was fixing the initial issue, but did this only for physical ep1. Since
the function dwc3_ep0_stall_and_restart is resetting the flags for both
physical endpoints, this also has to be done for ep0.
Cc: stable@vger.kernel.org
Fixes: b311048c17 ("usb: dwc3: gadget: Rewrite endpoint allocation flow")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20240814-dwc3hwep0reset-v2-1-29e1d7d923ea@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
