When the function _rtl92e_if_silent_reset() is called the variable
priv->rst_progress is set to RESET_TYPE_SILENT.
Since priv->up is always true the function is left at "if (priv->up) {"
without resetting. Now the function _rtl92e_if_silent_reset() is like
deactivated because the equation at the very beginning is false:
"if (priv->rst_progress == RESET_TYPE_NORESET) {"
This leads to a state where the driver hangs in the reset state and
cannot go forward.
In 30% of the cases the wlan is disconnected and cannot reconnect. The
rest of the time it continues working but no reset is done at all.
Further requests for reset are ignored. Remove broken function
_rtl92e_if_silent_reset() and remove return value of
_rtl92e_if_check_reset() to avoid compiler warnings.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/8b1b04b512b5691968a49308fdc052973fbe5032.1696165351.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The return value of _rtl92e_tx_check_stuck() and _rtl92e_rx_check_stuck()
can only be RESET_TYPE_SILENT or RESET_TYPE_NORESET. This functions are
only used in _rtl92e_if_check_reset(). In _rtl92e_if_check_reset() the
return values are checked for RESET_TYPE_NORMAL which cannot occur.
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/5f29332205dd76896e981fa627925d62a6bf7f63.1696165351.git.philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As &priv->tx_dev.tx_dev_lock is also acquired by xmit callback which
could be call from timer under softirq context, use spin_lock_bh()
on it to prevent potential deadlock.
hostif_sme_work()
--> hostif_sme_set_pmksa()
--> hostif_mib_set_request()
--> ks_wlan_hw_tx()
--> spin_lock(&priv->tx_dev.tx_dev_lock)
ks_wlan_start_xmit()
--> hostif_data_request()
--> ks_wlan_hw_tx()
--> spin_lock(&priv->tx_dev.tx_dev_lock)
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Link: https://lore.kernel.org/r/20230926161323.41928-1-dg573847474@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just a style change so that the device release callbacks are defined
in the same way for devices in mcb_bus and mcb_device.
Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
Co-developed-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
Signed-off-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
Link: https://lore.kernel.org/r/20230906114901.63174-3-JoseJavier.Rodriguez@duagon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When calling mcb_bus_add_devices(), both mcb devices and the mcb
bus will attempt to attach a device to a driver because they share
the same bus_type. This causes an issue when trying to cast the
container of the device to mcb_device struct using to_mcb_device(),
leading to a wrong cast when the mcb_bus is added. A crash occurs
when freing the ida resources as the bus numbering of mcb_bus gets
confused with the is_added flag on the mcb_device struct.
The only reason for this cast was to keep an is_added flag on the
mcb_device struct that does not seem necessary. The function
device_attach() handles already bound devices and the mcb subsystem
does nothing special with this is_added flag so remove it completely.
Fixes: 18d2881980 ("mcb: Correctly initialize the bus's device")
Cc: stable <stable@kernel.org>
Signed-off-by: Jorge Sanjuan Garcia <jorge.sanjuangarcia@duagon.com>
Co-developed-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
Signed-off-by: Jose Javier Rodriguez Barbarin <JoseJavier.Rodriguez@duagon.com>
Link: https://lore.kernel.org/r/20230906114901.63174-2-JoseJavier.Rodriguez@duagon.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simplify uart_get_rs485_mode() by using temporary variable for
the GPIO descriptor. With that, use proper type for the flags
of the GPIO descriptor.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231003142346.3072929-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Let's drop the use of pm_runtime_irq_safe() for 8250_omap. The use of
pm_runtime_irq_safe() is not nice as it takes a permanent usage count on
the parent device.
We can finally drop pm_runtime_irq_safe() safely as the kernel now knows
when the uart port tx is active. This changed with commit 84a9582fd2
("serial: core: Start managing serial controllers to enable runtime PM").
For serial port rx, we already use Linux generic wakeirqs for 8250_omap.
To drop pm_runtime_irq_safe(), we need to add handling for shallow idle
state where the port hardware may already be awake and an IO interrupt
happens. We also need to replace the serial8250_rpm sync calls in the
interrupt handlers with async runtime PM calls.
Note that omap8250_irq() calls omap_8250_dma_handle_irq(), so we don't
need separate runtime PM calls in omap_8250_dma_handle_irq().
While at it, let's also add the missing line break to the end of
omap8250_runtime_resume() to group the calls.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20231004062650.64487-1-tony@atomide.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On SM8550, the non-altmode orientation is not given anymore within
altmode events, even with USB SVIDs events.
On the other side, the Type-C connector orientation is correctly
reported by a signal from the PMIC.
Take this gpio signal when we detect some Type-C port activity
to notify any Type-C switches tied to the Type-C port connectors.
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231002-topic-sm8550-upstream-type-c-orientation-v2-2-125410d3ff95@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On SM8450 and SM8550 based platforms, the Type-C plug orientation is given on a
GPIO line for each connector which are set by the PMIC(s).
Document this optional Type-C connector property, and take the
assumption an active level represents an inverted/flipped orientation.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20231002-topic-sm8550-upstream-type-c-orientation-v2-1-125410d3ff95@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add "c_terminal_type" and "p_terminal_type" configfs entries
in order to allow the user to change the capture and playback terminal
type codes.
These fields affect the type of audio device that Windows detects, so
being able to modify this is useful when it would be advantageous for
a gadget to be detected as something other than a generic
speaker/microphone.
The fields default to microphone for the capture type field and speaker
for the playback type field as was the case before.
Signed-off-by: James Gruber <jimmyjgruber@gmail.com>
Link: https://lore.kernel.org/r/20230914222746.155126-1-jimmyjgruber@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a compatible entry for the NXP CBDTU02043 GPIO-based mux hardware
used for connecting, disconnecting and switching orientation of
the SBU lines in USB Type-C applications.
CBTU02043 datasheet: https://www.nxp.com/docs/en/data-sheet/CBTU02043.pdf
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230927123511.45085-1-festevam@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_buffer_map_sg() and usb_buffer_unmap_sg() have no definition
since the beginning of v5.4. The rest are gone from 2.6.12.
Signed-off-by: Randy Li <ayaka@soulik.info>
Link: https://lore.kernel.org/r/20230914172336.18761-2-ayaka@soulik.info
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Current vga arbiter implementation in i915 needs a re-design.
The current approach would cause real problems if anyone actually
needs to talk another GPU using legacy VGA resources.
The main issue is that X becomes a slideshow if it thinks there
are multiple GPUs that have VGA decoding enabled as it insists
on adjusting the VGA routing pretty much for every little operation
involving any of the GPUs.
The cleanup will be planned for i915. Meanwhile to focus on Xe
upstreaming and have a cleaner separation, the said functionality
is being moved to a different file exclusive for i915. Xe driver
will re-use rest of the display code from i915.
v2: Addressed Jani Nikula's review comments.
v3: Dropped a duplicate function (Jani)
v4: Updated commit message with reasoning as sugested by Ville.
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230929074306.1533859-1-uma.shankar@intel.com
