Add a regulator supply property for vbus. This notifies the regulator
provider to source vbus when Type-C operates in Source power mode,
while turn off sourcing vbus when operating in Sink mode or
disconnected.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260325-max77759-charger-v9-2-4486dd297adc@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Extend the max77759 binding to reference power-supply schema, so that
PMIC node can reference its supplier. Also, add regulator property to
control CHGIN (OTG) voltage.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260325-max77759-charger-v9-1-4486dd297adc@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In case of insufficient bandwidth usb_submit_urb()
returns -ENOSPC. Translating this to -EIO is not
optimal. There are insufficient resources not
an error. EBUSY is a better fit.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260325145537.372993-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The spec for Embedded USB2 Version 2.0 adds a new feature
request. This needs to be added to uapi for monitoring.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260319144715.2957358-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds the USB authentication extensions to the
uapi chapter 9 declarations, so that user space tools
correctly operate on the descriptor and commands.
This is necessary for sniffing and debugging in gadget
mode to correctly work, even though the kernel
does not use these requests in host mode.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260319144715.2957358-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The top-level part defines variable number of clocks and interrupts, and
each "if:then:" block narrows them. It however narrows only the
maxItems leaving minItems undefined, which then takes different values
depending on dtschema being used.
Recommended style is to avoid ambiguity in such case, thus if top-level
part has broad constraints, then each "if:then:" must specify both upper
and lower limits.
Add missing constraints, mostly minItems but also maxItems for one
variant.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260323-dt-bindings-snps-qcom-dwc3-cleanup-v2-2-3bcd37c0a5b5@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
After moving the binding to style with combined wrapper+device (so one
node) there is no child node required. Drop the stale comment about it.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260323-dt-bindings-snps-qcom-dwc3-cleanup-v2-1-3bcd37c0a5b5@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Cadence USBSSP (CDNSP) controller was previously only accessible
through PCI, coupling the gadget driver with the PCI glue layer into a
single monolithic module (cdnsp-udc-pci). This prevented using the
CDNSP IP on SoC/platform designs that expose the controller through
device tree. It restructures the driver to decouple the CDNSP gadget
from PCI.
- Introduce CONFIG_USB_CDNSP as a standalone tristate (analogous to
CONFIG_USB_CDNS3), with USB_CDNSP_GADGET and USB_CDNSP_HOST as
bool sub-options. The gadget code builds as a separate cdnsp.ko
module.
- Regroup USBSSP and CDNS3 Kconfig options under the USB_CDNS_SUPPORT
menu so they appear properly grouped in menuconfig.
- Refactor cdnsp-pci.c into a thin PCI-to-platform wrapper (similar
to cdns3-pci-wrap.c) that registers a platform device and passes
PCI resources and platform data to the common platform driver.
- Auto-detect the controller version (USBSS vs USBSSP) at runtime by
reading the DRD/OTG Device ID register in cdns_drd_init(), and select
the appropriate gadget init function (cdns3_gadget_init or
cdnsp_gadget_init) based on cdns->version. This follows the same
pattern already used for host initialization.
- Fix gadget-export.h to use IS_REACHABLE() keyed on the tristate
module config (CONFIG_USB_CDNS3/CONFIG_USB_CDNSP) instead of
IS_ENABLED() on the bool gadget config. The bool configs are always
'y' when enabled, causing IS_ENABLED/IS_REACHABLE to always return
true and resulting in link errors when cdns-usb-common is built-in
but the gadget module is loadable.
- Add missing MODULE_LICENSE()/MODULE_DESCRIPTION() and
EXPORT_SYMBOL_GPL() to the cdns3 and cdnsp gadget modules, required
by modpost.
- Pass override_apb_timeout through cdns3_platform_data so the PCI
wrapper can communicate PCI-specific APB timeout values to the
common driver.
This patch is Assisted-by: Cursor:claude-4.6-opus
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
Acked-by: Pawel Laszczak <pawell@cadence.com>
Link: https://patch.msgid.link/20260316064831.274865-3-peter.chen@cixtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Update the Cadence USBSS DRD binding to document that it also covers
the USBSSP (SuperSpeed Plus, USB 3.1 gen2x1) controller. Both USBSS
and USBSSP share the same DRD/OTG register interface, so the driver
auto-detects the controller version at runtime — no additional
compatible string is needed.
Changes to the binding:
- Update title and add description
- maximum-speed: add super-speed-plus
This patch is Assisted-by: Cursor:claude-4.6-opus
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260316064831.274865-2-peter.chen@cixtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add names to the memory-region-names for easier identification of memory
regions. As the meaning of the second memory region can be different
also require the use of memory-region-names if memory-region is in use.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Link: https://lore.kernel.org/r/20260318-topic-am62a-ioddr-dt-v6-19-v3-2-c41473cb23c3@baylibre.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Split up the region reserved for the firmware image in more specific
sections to expose the full fixed layout. Especially the LPM metadata
section is important for bootloaders as it contains information about
how to exit IO+DDR. This is read by the bootloader but is written by the
firmware.
Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
Link: https://lore.kernel.org/r/20260318-topic-am62a-ioddr-dt-v6-19-v3-1-c41473cb23c3@baylibre.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
FUSB302 fails to probe with -EINVAL if its interrupt line is connected via
an I2C GPIO expander, such as TI TCA6416.
Switch the interrupt handler to a threaded one, which also works behind
such GPIO expanders.
Cc: stable <stable@kernel.org>
Fixes: 309b6341d5 ("usb: typec: fusb302: Revert incorrect threaded irq fix")
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Reviewed-by: Heikki Krogerus <heikki.krogrerus@linux.intel.com>
Link: https://patch.msgid.link/20260317-fusb302-irq-v2-1-dbabd5c5c961@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Existing checks for VID/PID/DID in the driver are redundant since the
driver is already matched to the device via I2C device ID and OF
compatible strings, and they preclude the use of fallback compatibles.
Remove them to make the driver slimmer and adding new clones easier.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260318-husb311-v4-4-69e029255430@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As stated in [1], ETEK ET7304 is identical to Richtek RT1715, except for
the VID value in its registers, so reflect it in the bindings via a
fallback compatible.
As there are various TCPCI chips by different vendors reimplementing the
registers and behavior of the RT1711H/RT1715, fallback compatibles will
scale better.
Link: https://lore.kernel.org/all/20260220-et7304-v3-2-ede2d9634957@gmail.com/ [1]
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260318-husb311-v4-2-69e029255430@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hynetek Semiconductor Co., Ltd. focuses on intelligent energy control
technology, mainly for the intelligent fast charging and digital energy
fields.
Link: https://en.hynetek.com/
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Link: https://patch.msgid.link/20260318-husb311-v4-1-69e029255430@flipper.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some SpacemiT K1 boards (like OrangePi R2S) provide USB VBUS
through a controllable regulator. Add support for the optional
vbus-supply property so the regulator can be properly managed
in host mode instead of left always-on. Note that this doesn't
apply to USB Hub downstream ports with different VBUS supplies.
The enabled and disabled actions of the regulator are handled
automatically by devm_regulator_get_enable_optional().
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Link: https://patch.msgid.link/20260326100010.3588454-2-amadeus@jmu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add compatible string for DWC3 USB controller found in SpacemiT K3 SoC.
The USB2.0 host controller in K3 SoC actually use DWC3 IP but only support
USB2.0 functionality, thus in the hardware layer, it has only one USB2 PHY.
While in K1 SoC, the USB controller has both USB2 and USB3 Combo PHY
connected, but able to work in a reduced USB2.0 mode which requres only
one USB2 PHY, leaves the USB3 Combo PHY to PCIe controller. So both K1
and K3 SoC are able to work in the USB2.0 mode which requires one PHY.
Explicitly reduce number of phy property to minimal one.
Signed-off-by: Yixun Lan <dlan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260320-02-k3-usb20-support-v2-1-308ea0e44038@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function usb_gadget_udc_start() was renamed to
usb_gadget_udc_start_locked() by commit 286d9975a8 ("usb: gadget:
udc: core: Prevent soft_connect_store() race"). Update the comment
in usb_gadget_udc_set_speed() accordingly.
Assisted-by: unnamed:deepseek-v3.2 coccinelle
Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn>
Link: https://patch.msgid.link/20260321110006.8484-1-kexinsun@smail.nju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the chip indicates its "Connection Orientation" standard output control
in STANDARD_OUTPUT_CAPABILITIES register, it can do the thing by
programming CONFIG_STANDARD_OUTPUT register. Due to the optional feature,
the chip which not present this capability currently doesn't have a way to
correctly set the data path. This add the support to set orientation via
a simple GPIO.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260319-support-setting-orientation-use-gpio-v4-2-ab6dfa8610c2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Type-C chip know the cable orientation and then normally will set the
switch channel to correctly configure the data path. Some chips itself
support to output the control signal by indicating the capability in
bit[0] of STANDARD_OUTPUT_CAPABILITIES register and do it in
CONFIG_STANDARD_OUTPUT register. For PTN5110 which doesn't present this
capability currently there is no way to achieve the orientation setting.
Add an optional "orientation-gpios" property to achieve the same purpose.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Link: https://patch.msgid.link/20260319-support-setting-orientation-use-gpio-v4-1-ab6dfa8610c2@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document the Renesas UPD720201/UPD720202 USB 3.0 xHCI Host Controller,
which connects over PCIe and requires specific power supplies to
start up.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260324-topic-sm8650-ayaneo-pocket-s2-upd-bindings-v2-1-b86a1543b76b@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Onboard USB hubs might be nested. Add the reference for the generic
usb-hub.yaml binding and lift the restriction on peer-hub.
A (downstream) hub might only be connected on USB High-Speed lines.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260313141220.1843488-1-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document the compatible for the Qualcomm Synopsys DWC3 glue controller
found on Eliza SoC.
It follows the same binding requirements as other recent Qualcomm
SoCs, so add it to the existing schema conditionals covering the
required properties.
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260318-eliza-bindings-dwc3-v1-1-92bdf233cb87@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This allows to reduce the size of the initramfs by only selecting
the related firmware when a given SOC is enabled.
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
Link: https://patch.msgid.link/20260323140249.173603-1-kwizart@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
bdc_sr_xsf() decodes a 5-bit endpoint number from the hardware status
report and uses it to index bdc->bdc_ep_array[] directly. The array is
only allocated to bdc->num_eps for the current controller instance, so a
status report can carry an endpoint number that still fits the 5-bit
field but does not fit the runtime-sized endpoint table.
Reject status reports whose endpoint number is outside bdc->num_eps
before indexing the endpoint array.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Justin Chen <justin.chen@broadcom.com>
Link: https://patch.msgid.link/20260323121730.75245-1-pengpeng@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver uses its own definitions for HID requests.
This leads to duplication and obfuscation. Use HID's
definitions.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260325171311.384010-2-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver uses its own definitions for HID requests.
This leads to duplication and obfuscation. Use HID's
definitions.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260325171311.384010-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chen-Yu Tsai <wenst@chromium.org> says:
This series is part of a broader collection of regulator related
cleanups for MediaTek Chromebooks. This one covers the MT6315 PMIC.
Patch 1 adds the names of the power supply inputs to the binding.
Patch 2 adds the supply names from the DT binding change in patch 1
to the regulator descriptions in the driver. This patch has a
checkpatch.pl warnings, but I wonder if it's because the context size
for checking complex macros is not large enough.
Device tree changes will be sent separately. The goal is to get the
regulator tree as complete as possible. This includes adding supply
names to other regulator DT bindings, and adding all the supply links
to the existing DTs.
The MT6315 family of PMICs has 4 buck regulators. Each regulator has a
separate supply.
Add these supplies to the driver.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20260326081050.1115201-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The MT6315 family of PMICs has 4 buck regulators. Each regulator has a
separate supply.
Add these supplies to the device tree binding.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://patch.msgid.link/20260326081050.1115201-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The enum regulator_get_type has been available since 2017, so use that
enum instead of an "untyped" int in the three functions where "get_type"
is used.
No functional change intended.
Suggested-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://patch.msgid.link/20260330-regulator-devres-type-v1-1-d2c244576845@fairphone.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This resolves the following error seen on the ASUS ROG Phone 3:
cpu cpu7: Voltage update failed freq=3091200
cpu cpu7: failed to update OPP for freq=3091200
Fixes: 8e0e8016cb ("arm64: dts: qcom: sm8250: Add CPU opp tables")
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260307-sm8250-cpu7-opp-v1-1-435f5f6628a1@pm.me
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The SM8550-HDK board may be connected to a Display Card external PCB,
which is identical to the already supported SM8650-HDK Display Card,
it provides a VTDR6130 display with Goodix Berlin Touch controller, see
also commit bc90f56a16 ("arm64: dts: sm8650-hdk: add support for the
Display Card overlay") for additional details.
Two overlays are added to support SM8550-HDK plus Display Card and
SM8550-HDK plus Display Card plus Rear Camera Card setups.
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260311001238.4191034-1-vladimir.zapolskiy@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Start gc if the agressiveness of zone garbage collection is changed
by the user (if the file system is not read only).
Without this change, the new setting will not be taken into account
until the gc thread is woken up by e.g. a write.
Cc: stable@vger.kernel.org # v6.15
Fixes: 845abeb1f0 ("xfs: add tunable threshold parameter for triggering zone GC")
Signed-off-by: Hans Holmberg <hans.holmberg@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
XFS buffers are added to the LRU when they are unused, but are only
removed from the LRU lazily when the LRU list scan finds a used buffer.
So far this only happen when the LRU counter hits 0, which is suboptimal
as buffers that were added to the LRU, but are in use again still consume
LRU scanning resources and are aged while actually in use.
Fix this by checking for in-use buffers and removing the from the LRU
before decrementing the LRU counter.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
The per-AG buffer hashes were added when all buffer lookups took a
per-hash look. Since then we've made lookups entirely lockless and
removed the need for a hash-wide lock for inserts and removals as
well. With this there is no need to sharding the hash, so reduce the
used resources by using a per-buftarg hash for all buftargs.
Long after writing this initially, syzbot found a problem in the buffer
cache teardown order, which this happens to fix as well by doing the
entire buffer cache teardown in one places instead of splitting it
between destroying the buftarg and the perag structures.
Link: https://lore.kernel.org/linux-xfs/aLeUdemAZ5wmtZel@dread.disaster.area/
Reported-by: syzbot+0391d34e801643e2809b@syzkaller.appspotmail.com
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Tested-by: syzbot+0391d34e801643e2809b@syzkaller.appspotmail.com
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
The lockref structure allows incrementing/decrementing counters like
an atomic_t for the fast path, while still allowing complex slow path
operations as if the counter was protected by a lock. The only slow
path operations that actually need to take the lock are the final
put, LRU evictions and marking a buffer stale.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
Currently the buffer cache adds a reference to b_hold for buffers that
are on the LRU. This seems to go all the way back and allows releasing
buffers from the LRU using xfs_buf_rele. But it makes xfs_buf_rele
really complicated in differs from how other LRUs are implemented in
Linux.
Switch to not having a reference for buffers in the LRU, and use a
separate negative hold value to mark buffers as dead. This simplifies
xfs_buf_rele, which now just deal with the last "real" reference,
and prepares for using the lockref primitive.
This also removes the b_lock protection for removing buffers from the
buffer hash. This is the desired outcome because the rhashtable is
fully internally synchronized, and previously the lock was mostly
held out of ordering constrains in xfs_buf_rele_cached.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
When writing to SST flash starting at an odd address, a single byte is
first programmed using the byte program (BP) command. After this
operation completes, the flash hardware automatically clears the Write
Enable Latch (WEL) bit.
If an AAI (Auto Address Increment) word program sequence follows, it
requires WEL to be set. Without re-enabling writes, the AAI sequence
fails.
Add spi_nor_write_enable() after the odd-address byte program when more
data needs to be written. Use a local boolean for clarity.
Fixes: b199489d37 ("mtd: spi-nor: add the framework for SPI NOR")
Cc: stable@vger.kernel.org
Signed-off-by: Sanjaikumar V S <sanjaikumar.vs@dicortech.com>
Tested-by: Hendrik Donner <hd@os-cillation.de>
Reviewed-by: Hendrik Donner <hd@os-cillation.de>
Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
The HP Laptop 15-fc0xxx (subsystem ID 0x103c8dc9) has an internal
DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk
entry so the internal microphone is properly detected on this model.
Tested on HP Laptop 15-fc0237ns with Fedora 43 (kernel 6.19.9).
Signed-off-by: Gilson Marquato Júnior <gilsonmandalogo@hotmail.com>
Link: https://patch.msgid.link/20260330-hp-15-fc0xxx-dmic-v2-v1-1-6dd6f53a1917@hotmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To restrict Gunyah watchdog initialization to Qualcomm platforms running
under the Gunyah Hypervisor, register the watchdog device in the QCOM
SCM driver.
When Gunyah is not present or Gunyah emulates MMIO-based watchdog, we
expect Qualcomm watchdog or ARM SBSA watchdog device to be present in
the devicetree. First, we make sure we're running under the Gunyah
Hypervisor. Then we move to check if any of the above mentioned
watchdog device nodes are present, if not then we proceed to register
the SMC-based Gunyah watchdog device.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260311-gunyah_watchdog-v8-1-4c1c0689de22@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Support the graphics clock controller for SM8750 for Graphics SW
driver to use the clocks. GXCLKCTL (Graphics GX Clock Controller) is a
block dedicated to managing clocks for the GPU subsystem on GX power
domain. The GX clock controller driver manages only the GX GDSC and the
rest of the resources of the controller are managed by the firmware.
Update the compatible for Graphics GX Clock Controller for SM8750 as the
GX clock controller is a reuse of the Kaanapali driver.
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Co-developed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260305-gpucc_sm8750_v2-v5-2-78292b40b053@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The SM8750 features a "traditional" GPU_CC block, much of which is
controlled through the GMU microcontroller. GPU_CC block requires the MX
and CX rail control and thus add the corresponding power-domains and
require-opps. Additionally, there's an separate GX_CC block, where
the GX GDSC is moved.
Update the bindings to accommodate for SM8750 SoC.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260305-gpucc_sm8750_v2-v5-1-78292b40b053@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
