* [PATCH] usb: misc: cytherm: replace deprecated simple_strtoul with kstrtoint
From: Jad Keskes @ 2026-06-22 12:31 UTC (permalink / raw)
To: gregkh; +Cc: linux-usb, linux-kernel, Jad Keskes
simple_strtoul() is deprecated in favor of kstrtoint(). The old
function silently accepts garbage input. kstrtoint() returns -EINVAL
so the driver can actually tell the user they typed something stupid
instead of accepting 0 and wondering why the thermometer isn't
responding.
The 0-255 clamping stays the same, just with proper error handling
in front of it now.
Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
drivers/usb/misc/cytherm.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/cytherm.c b/drivers/usb/misc/cytherm.c
index b183df9826bc..81de3fecf3da 100644
--- a/drivers/usb/misc/cytherm.c
+++ b/drivers/usb/misc/cytherm.c
@@ -85,7 +85,9 @@ static ssize_t brightness_store(struct device *dev, struct device_attribute *att
if (!buffer)
return 0;
- cytherm->brightness = simple_strtoul(buf, NULL, 10);
+ retval = kstrtoint(buf, 10, &cytherm->brightness);
+ if (retval < 0)
+ return retval;
if (cytherm->brightness > 0xFF)
cytherm->brightness = 0xFF;
@@ -217,7 +219,9 @@ static ssize_t port0_store(struct device *dev, struct device_attribute *attr, co
if (!buffer)
return 0;
- tmp = simple_strtoul(buf, NULL, 10);
+ retval = kstrtoint(buf, 10, &tmp);
+ if (retval < 0)
+ return retval;
if (tmp > 0xFF)
tmp = 0xFF;
@@ -272,7 +276,9 @@ static ssize_t port1_store(struct device *dev, struct device_attribute *attr, co
if (!buffer)
return 0;
- tmp = simple_strtoul(buf, NULL, 10);
+ retval = kstrtoint(buf, 10, &tmp);
+ if (retval < 0)
+ return retval;
if (tmp > 0xFF)
tmp = 0xFF;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support
From: Andrei Kuchynski @ 2026-06-22 12:03 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Benson Leung, Jameson Thies, Greg Kroah-Hartman, linux-usb,
linux-kernel
In-Reply-To: <ajkMCz52lkq9hz3s@kuha>
Hi Heikki,
On Mon, Jun 22, 2026 at 12:18 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> Hi Andrei,
>
> > +bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> > +{
> > + return unsupported;
>
> So if typec_cable_get() doesn't return a cable, this function will now
> always return false - i.e. the cable is supported? Is that intentional?
>
Yes, this is intentional.
The UCSI GET_CABLE_PROPERTY command is optional. typec_register_cable()
function can also be called without the desc->identity field.
Failing to provide cable information shouldn't be a reason to reject the
alternate mode.
Also, the cable can be registered after the partner's altmodes. We
encounter this scenario with the cros_ec_typec driver. I'm planning to fix
it, but for now, this approach will preserve the previous behavior.
Therefore, the idea is to reject the altmode only if we know the cable
doesn't support it. That's why the function is called "unsupported".
It returns true if a limitation is detected. Otherwise, the function
returns false.
> This would probable be much more clear if you checked the cable only
> ones, right after you take the handle.
>
> cable = typec_cable_get(typec_altmode2port(alt));
> if (!cable)
> return true; /* or false? */
> ...
> /* Now unconditionally */
> typec_cable_put(cable);
>
Ok, I'll redo it. Thanks
> I think this would be even more clear if the function was called
> typec_cable_altmode_supported() and you would then have a wrapper:
>
> static inline bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> {
> return !typec_cable_altmode_supported(alt);
> }
>
I prefer exporting the 'unsupported' helper to altmode drivers. While its
naming is slightly less intuitive, it accurately reflects the logic.
What do you think about it?
Thanks,
Andrei
^ permalink raw reply
* [PATCH] usb: renesas_usbhs: Check pipe allocation in host pipe init
From: Haoxiang Li @ 2026-06-22 11:45 UTC (permalink / raw)
To: gregkh, kees; +Cc: linux-usb, linux-kernel, Haoxiang Li
usbhsh_pipe_init_for_host() allocates pipes with usbhs_dcp_malloc()
or usbhs_pipe_malloc(), both of which may return NULL. The returned
pointer is dereferenced unconditionally when clearing pipe->mod_private.
Check the returned pipe before using it to avoid a NULL pointer
dereference on pipe allocation/setup failure.
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/usb/renesas_usbhs/mod_host.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/renesas_usbhs/mod_host.c b/drivers/usb/renesas_usbhs/mod_host.c
index f7ef3a9f82a4..11244cf3408d 100644
--- a/drivers/usb/renesas_usbhs/mod_host.c
+++ b/drivers/usb/renesas_usbhs/mod_host.c
@@ -1441,6 +1441,9 @@ static void usbhsh_pipe_init_for_host(struct usbhs_priv *priv)
dir_in);
}
+ if (!pipe)
+ return;
+
pipe->mod_private = NULL;
}
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2] xhci: pci: Disable soft retry for Renesas uPD720201
From: Mathias Nyman @ 2026-06-22 11:36 UTC (permalink / raw)
To: Michal Pecio
Cc: raoxu, mathias.nyman, gregkh, linux-usb, linux-kernel, stable
In-Reply-To: <20260619124234.0a9e4670.michal.pecio@gmail.com>
On 6/19/26 13:42, Michal Pecio wrote:
>> On 6/17/26 13:09, raoxu wrote:
>>> From: Xu Rao <raoxu@uniontech.com>
>>>
>>> The Renesas uPD720201 xHCI controller can fail to complete
>>> a Stop Endpoint command after a transaction error on an interrupt
>>> endpoint when soft retry is used.
>>>
>>> This was reproduced with this setup:
>>>
>>> xHCI: Renesas uPD720201, PCI ID 1912:0014 rev 03
>>> dev: USB Ethernet device with an integrated Genesys Logic
>>> USB3.1 hub, USB ID 05e3:0626, and a Realtek RTL8153
>>> Ethernet function, USB ID 0bda:8153
>
> Same thing with uPD720202 (1912:0015) here.
>
> Is the hub even necessary? In my case I have one too, but I cannot
> separate it from the RTL8153 for testing.
>
>>> Reproducer:
>>>
>>> 1. Plug the integrated USB hub and Ethernet device into the
>>> 1912:0014 xHCI controller.
>>> 2. Let r8152 bind to the 0bda:8153 RTL8153 Ethernet function
>>> behind the integrated hub.
>>> 3. Bring the Ethernet device up.
>>> 4. Hot-unplug the device.
>
> In my case, necessary step 3.5: connect a cable and wait for the
> "r8152: carrier on" message. Otherwise it disconnects cleanly.
>
>>> The host reports a transaction error on the RTL8153 interrupt
>>> endpoint, queues a soft reset, and later times out the Stop
>>> Endpoint command while disconnecting the device:
>>>
>>> Transfer error for slot 8 ep 6 on endpoint
>>> Soft-reset ep 6, slot 8
>>> Ignoring reset ep completion code of 1
>>> xHCI host not responding to stop endpoint command
>>> xHCI host controller not responding, assume dead
>>> HC died; cleaning up
>
> There is other stuff too, like concurrent teardown of a separate bulk
> endpoint, not yet sure what exactly breaks these chips.
>
> Would you mind to apply the attached debug patch, reproduce and post
> dmesg from your system for comparison?
>
>>> The Renesas 1912:0014 controller cannot safely use the xHCI soft
>>> retry path. Set XHCI_NO_SOFT_RETRY for this controller so
>>> transaction errors use the pre-soft-retry recovery path. With
>>> this quirk the same hot-unplug test no longer times out the Stop
>>> Endpoint command and the RTL8153 remains usable and stable.
>
> A bit heavy handed, but we might find no better way.
>
> On Thu, 18 Jun 2026 17:03:26 +0300, Mathias Nyman wrote:
>> I'd appreciate your opinion on a related issue.
>> I'm thinking about trying to recover from these stop endpoint command
>> timeouts.
>
> I can share a bit of mine. I tried aborting Stop EP on Etron and found
> the EP in some bogus state afterwards (e.g. Running but Stop EP fails
> with Context State Error, or Stopped but not responing to doorbells,
> something like that, I don't remember).
>
> Per xHCI 4.6.9 there isn't really a case when this command should time
> out, so it's always some internal bug/deadlock in the xHC and IMO good
> chance that abort will leave at least this one EP or slot broken.
>
> Another case is ASMedia, which doesn't seem to implement abort at all -
> at least in my tests with Address Device and a dummy device that always
> NAKs, abort simply waits for the command to finish (these chips have
> internal 3 second timeout on Address Device). I would expect the same
> for Stop EP, except that it likely lacks internal timeout. And the
> driver will busy-wait for several seconds with IRQs disabled.
>
>> While debugging this, did xHC controller otherwise seem somewhat
>> functional? Did you for example see port status change events, or
>> transfer events between queuing the stop endpoint command and the
>> timeout?
>
> Mouse continues to work until we kill the HC. And I can even abort the
> command, but then some URB is never given back, so teardown of the USB
> device gets stuck and IDK what would happen later.
>
> Such recovery would be a bit of work, potential chip specific bugs and
> frankly we can' be sure if the EP won't try to begin executing URBs.
Thanks, sounds like simple recovery by just canceling the command and moving
on might not be the best approach.
If root port is disconnected or link in error state (link:Inactive) then
we could avoid all soft retries and ring restarts for child devices.
This could avoid queuing the problematic stop endpoint command as well.
Thanks
Mathias
^ permalink raw reply
* Re: [PATCH v2] xhci: pci: Disable soft retry for Renesas uPD720201
From: Mathias Nyman @ 2026-06-22 11:31 UTC (permalink / raw)
To: raoxu, michal.pecio
Cc: gregkh, linux-kernel, linux-usb, mathias.nyman, stable
In-Reply-To: <237BFC17C62D63DF+20260622062117.56278-1-raoxu@uniontech.com>
On 6/22/26 09:21, raoxu wrote:
> Hi Michal,
>
>>>> The host reports a transaction error on the RTL8153 interrupt
>>>> endpoint, queues a soft reset, and later times out the Stop
>>>> Endpoint command while disconnecting the device:
>>>>
>>>> Transfer error for slot 8 ep 6 on endpoint
>>>> Soft-reset ep 6, slot 8
>>>> Ignoring reset ep completion code of 1
>>>> xHCI host not responding to stop endpoint command
>>>> xHCI host controller not responding, assume dead
>>>> HC died; cleaning up
>>
>> There is other stuff too, like concurrent teardown of a separate bulk
>> endpoint, not yet sure what exactly breaks these chips.
>>
>> Would you mind to apply the attached debug patch, reproduce and post
>> dmesg from your system for comparison?
>
> I applied the debug patch and reproduced the issue.
> The XHCI_NO_SOFT_RETRY quirk was disabled during the test.
>
> Short timeline from the log:
> 13:23:29 The USB hub with an integrated RTL8153 Ethernet adapter was
> plugged in.
> 13:23:39 The USB hub was unplugged, and the endpoint error occurred.
> 13:23:44 The Stop Endpoint command timed out and the xHCI host was
> declared dead.
>
> The complete dmesg output follows:
Thanks,
I think there are some steps we could do to avoid soft retry, restart, and stopping
an endpoint we know is behind a disconnected parent.
>
> ----- dmesg begin -----
> 2026-06-22T13:23:39.445959+08:00 uos-PC kernel: xhci_hcd:handle_port_status: xhci_hcd 0000:04:00.0: Port change event, 1-3, id 7, portsc: 0x202a0
usb2 part of hub disconnect now known by xhci driver
> 2026-06-22T13:23:39.449096+08:00 uos-PC kernel: xhci_hcd:handle_port_status: xhci_hcd 0000:04:00.0: Port change event, 2-3, id 3, portsc: 0x202c0
usb3 part of hub disconnect now known by xhci driver
> 2026-06-22T13:23:39.449108+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 7/-1 (fff/f) [ffffffff/ffffffff/ffffffff] queue_disable_slot
> 2026-06-22T13:23:39.449111+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 7/-1 (fff/f) [ffffffff/ffffffff/ffffffff] handle_cmd_completion cmd_type 10 comp_code 1
hub slot now disabled
> 2026-06-22T13:23:39.449112+08:00 uos-PC kernel: xhci_hcd:xhci_hub_control: xhci_hcd 0000:04:00.0: Get port status 1-3 read: 0x2a0, return 0x100
> 2026-06-22T13:23:39.457060+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/2) [200cb341b0/200cb341b1/200cb341c0] handle_tx_event comp_code 4 trb_dma 200cb341b0
> 2026-06-22T13:23:39.457070+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/2) [200cb341b0/200cb341b1/200cb341c0] handle_tx_event stream_id 0 trb_len 2 missing 2
> 2026-06-22T13:23:39.457071+08:00 uos-PC kernel: xhci_hcd:handle_tx_event: xhci_hcd 0000:04:00.0: Transfer error for slot 8 ep 6 on endpoint
transfer error on realtek ethernet child device behind the disconnected hub
> 2026-06-22T13:23:39.457072+08:00 uos-PC kernel: xhci_hcd:xhci_reset_halted_ep: xhci_hcd 0000:04:00.0: Soft-reset ep 6, slot 8
Try to soft reset/retry. (xhci driver knows parent is disconnected, need a fix that avoids soft retry here)
> 2026-06-22T13:23:39.457072+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/2) [200cb341b0/200cb341b1/200cb341c0] queue_reset_endpoint tsp 1
> 2026-06-22T13:23:39.457082+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (002/3) [200cb341b0/200cb341b1/200cb341c0] handle_cmd_completion cmd_type 14 comp_code 1
> 2026-06-22T13:23:39.457084+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/3) [200cb341b0/200cb341b1/200cb341c0] ring_ep_doorbell stream 0
Tried to restart ring after soft retry, we know parent is gone, should write a fix that avoids restarting ring.
> 2026-06-22T13:23:39.477064+08:00 uos-PC kernel: xhci_hcd:xhci_hub_control: xhci_hcd 0000:04:00.0: Get port status 2-3 read: 0x2a0, return 0x2a0
> 2026-06-22T13:23:39.477069+08:00 uos-PC kernel: usbcore:port_event: usb usb2-port3: Wait for inactive link disconnect detect
> 2026-06-22T13:23:39.477070+08:00 uos-PC kernel: usbcore:hub_port_connect_change: usb usb2-port3: status 02a0, change 0001, 5.0 Gb/s
> 2026-06-22T13:23:39.477071+08:00 uos-PC kernel: usb 2-3: USB disconnect, device number 3
> 2026-06-22T13:23:39.477071+08:00 uos-PC kernel: r8152-cfgselector 2-3.1: USB disconnect, device number 4
> 2026-06-22T13:23:39.477072+08:00 uos-PC kernel: usbcore:usb_disconnect: r8152-cfgselector 2-3.1: unregistering device
> 2026-06-22T13:23:39.477079+08:00 uos-PC kernel: usbcore:usb_disable_device: r8152-cfgselector 2-3.1: unregistering interface 2-3.1:1.0
> 2026-06-22T13:23:39.477080+08:00 uos-PC kernel: xhci_hcd:xhci_dbg_trace: xhci_hcd 0000:04:00.0: Cancel URB 000000005c134e45, dev 3.1, ep 0x83, starting at offset 0x200cb341b0
Cancel the realtek URB we tried to soft retry earlier.
> 2026-06-22T13:23:39.477082+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (000/3) [200cb341b0/200cb341b1/200cb341c0] xhci_urb_dequeue cancel TD at 200cb341b0 stream 0
> 2026-06-22T13:23:39.477082+08:00 uos-PC kernel: xhci_hcd 0000:04:00.0: 8/6 (004/3) [200cb341b0/200cb341b1/200cb341c0] queue_stop_endpoint suspend 0
queue stop endpoint to cancel URB for realtek device.
Endpoint context still shows endpoint is in "stopped" state.
Note that we restarted the endpoint 20ms earlier, endpoint context might not have updated yet.
> 2026-06-22T13:23:44.565110+08:00 uos-PC kernel: xhci_hcd:xhci_handle_command_timeout: xhci_hcd 0000:04:00.0: Command timeout, USBSTS: 0x00000000
Stop endpoint command times out.
-Mathias
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Niklas Söderlund @ 2026-06-22 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Wesley Cheng, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, linux-samsung-soc, linux-clk, dri-devel,
freedreno, linux-i2c, linux-pm, linux-leds, linux-media,
linux-mmc, linux-phy, linux-gpio, linux-renesas-soc, linux-serial,
linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
Thanks for your work.
On 2026-06-22 12:16:08 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
For the two Renesas bindings,
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
> .../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
> .../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
> 31 files changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> index 27261039d56f..37fdd5a080b7 100644
> --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> qcom,SoC-IP
>
> - For example::
> + For example:
> qcom,sdm845-llcc-bwmon
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..667607ae2c32 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1215,7 +1215,7 @@ properties:
> items:
> items:
> - description: |
> - MSM chipset ID - an exact match value consisting of two bitfields::
> + MSM chipset ID - an exact match value consisting of two bitfields:
> - bits 0-15 - The unique MSM chipset ID
> - bits 16-31 - Reserved; should be 0
> - description: |
> @@ -1241,7 +1241,7 @@ properties:
> - items:
> - items:
> - description: |
> - Board ID consisting of three bitfields::
> + Board ID consisting of three bitfields:
> - bits 31-24 - Unused
> - bits 23-16 - Platform Version Major
> - bits 15-8 - Platform Version Minor
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> index 653f85997643..ab000befe76d 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> samsung,SoC-IP
>
> - For example::
> + For example:
> samsung,exynos5433-cmu-isp
>
> select:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> index dbc0613e427e..395425a70db8 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> @@ -73,16 +73,16 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - bus:: Display AHB clock.
> - - byte:: Display byte clock.
> - - byte_intf:: Display byte interface clock.
> - - core:: Display core clock.
> - - core_mss:: Core MultiMedia SubSystem clock.
> - - iface:: Display AXI clock.
> - - mdp_core:: MDP Core clock.
> - - mnoc:: MNOC clock
> - - pixel:: Display pixel clock.
> + Several clocks are used, depending on the variant. Typical ones are:
> + - bus: Display AHB clock.
> + - byte: Display byte clock.
> + - byte_intf: Display byte interface clock.
> + - core: Display core clock.
> + - core_mss: Core MultiMedia SubSystem clock.
> + - iface: Display AXI clock.
> + - mdp_core: MDP Core clock.
> + - mnoc: MNOC clock
> + - pixel: Display pixel clock.
> minItems: 3
> maxItems: 12
>
> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> index ff685031bb2c..729705f419bb 100644
> --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> @@ -41,7 +41,7 @@ properties:
> additionalProperties: false
> description: |
> Timing configuration for lcd i80 interface support.
> - The parameters are defined as::
> + The parameters are defined as:
> VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
> : : : : :
> Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
> @@ -132,7 +132,7 @@ patternProperties:
> "^port@[0-4]+$":
> $ref: /schemas/graph.yaml#/properties/port
> description: |
> - Contains ports with port with index::
> + Contains ports with port with index:
> 0 - for CAMIF0 input,
> 1 - for CAMIF1 input,
> 2 - for CAMIF2 input,
> diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> index a2ddc6803617..07600b49f2f9 100644
> --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> @@ -35,7 +35,7 @@ properties:
>
> gpios:
> description: |
> - The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
> + The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
> specifier depends on the gpio controller. Required in all cases except
> for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
> permanently wired to the respective client.
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> index ff64225e8281..e002e70580f9 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> @@ -13,7 +13,7 @@ description: |
> Bandwidth Monitor measures current throughput on buses between various NoC
> fabrics and provides information when it crosses configured thresholds.
>
> - Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
> + Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
> - Measuring the bandwidth between CPUs and Last Level Cache Controller -
> called just BWMON,
> - Measuring the bandwidth between Last Level Cache Controller and memory
> diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> index 5e26e48c7217..0203959c8995 100644
> --- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> @@ -23,7 +23,7 @@ description: |
> The each AXI bus has the owned source clock but, has not the only owned power
> line. The power line might be shared among one more sub-blocks. So, we can
> divide into two type of device as the role of each sub-block. There are two
> - type of bus devices as following::
> + type of bus devices as following:
> - parent bus device
> - passive bus device
>
> @@ -44,8 +44,8 @@ description: |
> able to support the bus frequency for all Exynos SoCs.
>
> Detailed correlation between sub-blocks and power line according
> - to Exynos SoC::
> - - In case of Exynos3250, there are two power line as following::
> + to Exynos SoC:
> + - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -89,7 +89,7 @@ description: |
> |L5 |200000 |200000 |400000 |300000 | ||1000000 |
> ----------------------------------------------------------
>
> - - In case of Exynos4210, there is one power line as following::
> + - In case of Exynos4210, there is one power line as following:
> VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
> |--- LEFTBUS
> |--- PERIL
> @@ -106,7 +106,7 @@ description: |
> |--- LCD0
> |--- LCD1
>
> - - In case of Exynos4x12, there are two power line as following::
> + - In case of Exynos4x12, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -124,7 +124,7 @@ description: |
> |--- LCD0
> |--- ISP
>
> - - In case of Exynos5422, there are two power line as following::
> + - In case of Exynos5422, there are two power line as following:
> VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
> |--- DREX 1
>
> @@ -143,7 +143,7 @@ description: |
> |--- FSYS
> |--- FSYS2
>
> - - In case of Exynos5433, there is VDD_INT power line as following::
> + - In case of Exynos5433, there is VDD_INT power line as following:
> VDD_INT |--- G2D (parent device)
> |--- MSCL
> |--- GSCL
> diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> index b409b2a8b5c5..5165bfddcd54 100644
> --- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> +++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> @@ -10,10 +10,10 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
> + The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
> LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
> because sometimes these LED drivers are used for wildly different things than
> - flash or keypad backlight:: their names are more of a suggestion than a
> + flash or keypad backlight: their names are more of a suggestion than a
> hard-wired usecase.
>
> Hardware-wise the different LEDs support slightly different output currents.
> diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> index a6aaa92dbccd..65576dfdca11 100644
> --- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> +++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> @@ -11,7 +11,7 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
> + The device is controlled through two pins: FL_EN and EN_SET. The pins when,
> asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
> respectively. In order to add a capability of selecting the strobe signal
> source (e.g. CPU or camera sensor) there is an additional switch required,
> @@ -39,11 +39,11 @@ properties:
> flash-max-microamp:
> description: |
> Maximum flash LED supply current can be calculated using following
> - formula:: I = 1A * 162 kOhm / Rset.
> + formula: I = 1A * 162 kOhm / Rset.
>
> flash-max-timeout-us:
> description: |
> - Maximum flash timeout can be calculated using following formula::
> + Maximum flash timeout can be calculated using following formula:
> T = 8.82 * 10^9 * Ct.
>
> required:
> diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> index 582c6c9cae48..21118e4bae0f 100644
> --- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> +++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> @@ -14,7 +14,7 @@ description: |
> hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
> to another GPIO line.
>
> - Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
> + Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
> 5V lines it is 5.3V. So you may need some sort of level conversion
> circuitry when connecting them to a GPIO line.
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> index 27c4060f2f91..223fcc9f651f 100644
> --- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> @@ -85,7 +85,7 @@ properties:
> description: |
> The value of CIU TX and RX clock phase shift value for HS400 mode
> operation.
> - Valid values for SDR and DDR CIU clock timing::
> + Valid values for SDR and DDR CIU clock timing:
> - valid value for tx phase shift and rx phase shift is 0 to 7.
> - when CIU clock divider value is set to 3, all possible 8 phase shift
> values can be used.
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 9e2d78a78e40..769243a2bf04 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -13,8 +13,8 @@ description: |
> Mux controller consumers should specify a list of mux controllers that they
> want to use with a property containing a 'mux-ctrl-list':
>
> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
> mux-ctrl-phandle : phandle to mux controller node
> mux-ctrl-specifier : array of #mux-control-cells specifying the
> given mux controller (controller specific)
> diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> index 16967ef8e9ec..87b6a35b2626 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> @@ -13,14 +13,14 @@ maintainers:
>
> description: |
> For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
> - PHY specifier identifies the PHY and its meaning is as follows::
> + PHY specifier identifies the PHY and its meaning is as follows:
> 0 - MIPI CSIS 0,
> 1 - MIPI DSIM 0,
> 2 - MIPI CSIS 1,
> 3 - MIPI DSIM 1.
>
> samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
> - support additional fifth PHY::
> + support additional fifth PHY:
> 4 - MIPI CSIS 2.
>
> properties:
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> index d9f22a801cbf..7db7605a82e2 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> The first phandle argument in the PHY specifier identifies the PHY, its
> meaning is compatible dependent. For the currently supported SoCs (Exynos4210
> - and Exynos4212) it is as follows::
> + and Exynos4212) it is as follows:
> 0 - USB device ("device"),
> 1 - USB host ("host"),
> 2 - HSIC0 ("hsic0"),
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> index 4562e0468f4f..a1b3d9e6a094 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
> compatible PHYs, the second cell in the PHY specifier identifies the
> - PHY id, which is interpreted as follows::
> + PHY id, which is interpreted as follows:
> 0 - UTMI+ type phy,
> 1 - PIPE3 type phy.
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 7b006009ca0e..5e35686eeed3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -18,7 +18,7 @@ description: |
> All the pin controller nodes should be represented in the aliases node using
> the following format 'pinctrl{n}' where n is a unique number for the alias.
>
> - The controller supports three types of interrupts::
> + The controller supports three types of interrupts:
> - External GPIO interrupts (see interrupts property in pin controller node);
>
> - External wake-up interrupts - multiplexed (capable of waking up the system
> diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> index 347571e2545a..b67aa170b2c1 100644
> --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> @@ -13,7 +13,7 @@ maintainers:
> description: |
> The R-Car (RZ/G) System Controller provides power management for the CPU
> cores and various coprocessors.
> - The power domain IDs for consumers are defined in header files::
> + The power domain IDs for consumers are defined in header files:
> include/dt-bindings/power/r8*-sysc.h
>
> properties:
> diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> index 965a834a3dbe..00c00ec5ec81 100644
> --- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> @@ -18,12 +18,12 @@ properties:
> priority:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: |
> - A priority ranging from 0 to 255 according to the following guidelines::
> - 0:: Restart handler of last resort, with limited restart capabilities.
> - 128:: Typical, default restart handler; use if no other restart handler
> + A priority ranging from 0 to 255 according to the following guidelines:
> + 0: Restart handler of last resort, with limited restart capabilities.
> + 128: Typical, default restart handler; use if no other restart handler
> is expected to be available, and/or if restart functionality is
> sufficient to restart the entire system.
> - 255:: Highest priority restart handler, will preempt all other restart handlers.
> + 255: Highest priority restart handler, will preempt all other restart handlers.
> minimum: 0
> maximum: 255
>
> diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> index b704f05ea454..b886495c1396 100644
> --- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> @@ -22,13 +22,13 @@ description: |
>
> Certain regulators support "regulator-initial-mode" and "regulator-mode".
> The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
> - and their meaning is::
> + and their meaning is:
> 1 - Normal regulator voltage output mode.
> 3 - Low Power which reduces the quiescent current down to only 1uA
>
> The standard "regulator-mode" property can only be used for regulators that
> support changing their mode to Low Power Mode during suspend. These
> - regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> + regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> regulator has been enabled for the given suspend state using
> "regulator-on-in-suspend" and has not been disabled for that state using
> "regulator-off-in-suspend".
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> index 022c1f197364..b0aa38edf8c2 100644
> --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> @@ -21,7 +21,7 @@ description: |
> conduction mode (FCCM).
>
> The definition of modes is in the datasheet which is available in below link
> - and their meaning is::
> + and their meaning is:
> 0 - Auto mode for power saving, which reducing the switching frequency at light load condition
> to maintain high frequency.
> 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
> diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> index 788ef5c1c446..bc967ead2350 100644
> --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> @@ -17,7 +17,7 @@ description: |
> software perspective it's mostly compatible with the MSM serial UART except
> that it supports reading and writing multiple characters at a time.
>
> - Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
> + Note: Aliases may be defined to ensure the correct ordering of the UARTs.
> The alias serialN will result in the UART being assigned port N. If any
> serialN alias exists, then an alias must exist for each enabled UART. The
> serialN aliases should be in a .dts file instead of in a .dtsi file.
> diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> index 5a941610ce4e..3910327c8ded 100644
> --- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> +++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> @@ -29,7 +29,7 @@ patternProperties:
> description: |
> Every SLIMbus controller node can contain zero or more child nodes
> representing slave devices on the bus. Every SLIMbus slave device is
> - uniquely determined by the enumeration address containing 4 fields::
> + uniquely determined by the enumeration address containing 4 fields:
> Manufacturer ID, Product code, Device index, and Instance value for the
> device.
>
> @@ -48,7 +48,7 @@ patternProperties:
> reg:
> maxItems: 1
> description: |
> - Pair of (device index, instande ID), where::
> + Pair of (device index, instande ID), where:
> - Device index, which uniquely identifies multiple devices within a
> single component.
> - Instance ID, can be used for the cases where multiple devices of
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> index bdf482db32aa..b663be3ea5a1 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> @@ -40,7 +40,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/string-array
> description: |
> Protection domain service name and path for APR service (if supported).
> - Possible values are::
> + Possible values are:
> "avs/audio", "msm/adsp/audio_pd".
> "kernel/elf_loader", "msm/modem/wlan_pd".
> "tms/servreg", "msm/adsp/audio_pd".
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> index 26d9bc773ec5..1889139a3f7a 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> @@ -23,7 +23,7 @@ description: |
> with a few variations that are captured by the properties here.
>
> A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
> - have powered off to facilitate idle power saving. TCS could be classified as::
> + have powered off to facilitate idle power saving. TCS could be classified as:
> ACTIVE - Triggered by Linux
> SLEEP - Triggered by F/W
> WAKE - Triggered by F/W
> @@ -76,7 +76,7 @@ properties:
> items:
> items:
> - description: |
> - TCS type::
> + TCS type:
> - ACTIVE_TCS
> - SLEEP_TCS
> - WAKE_TCS
> @@ -152,7 +152,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
> // 2, the register offsets for DRV2 start at 0D00, the register
> - // calculations are like this::
> + // calculations are like this:
> // DRV0: 0x179C0000
> // DRV2: 0x179C0000 + 0x10000 = 0x179D0000
> // DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
> @@ -182,7 +182,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
> // register offsets for DRV0 start at 01C00, the register calculations are
> - // like this::
> + // like this:
> // DRV0: 0xAF20000
> // TCS-OFFSET: 0x1C00
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> index 4fcae6bedfff..72a7f8cb09ba 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> @@ -28,7 +28,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description: |
> Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
> - The node must be compatible with one of the following::
> + The node must be compatible with one of the following:
> - qcom,riva"
> - qcom,pronto"
>
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> index 5ddd31f30f26..57c9d3c57021 100644
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> @@ -12,10 +12,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> renesas,SoC-IP
>
> - For example::
> + For example:
> renesas,r8a77965-csi2
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> index 47a105a97ecf..bc8c8ba24f9c 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> @@ -45,7 +45,7 @@ patternProperties:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2]
> description: |
> - The direction of the dai stream::
> + The direction of the dai stream:
> - Q6ASM_DAI_TX_RX (0) for both tx and rx
> - Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
> - Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
> diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> index 29a08b0729ee..3f333db72a71 100644
> --- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> @@ -40,7 +40,7 @@ properties:
> description: |
> The Exynos TMU supports generating interrupts when reaching given
> temperature thresholds. Number of supported thermal trip points depends
> - on the SoC (only first trip points defined in DT will be configured)::
> + on the SoC (only first trip points defined in DT will be configured):
> - most of SoC: 4
> - samsung,exynos5433-tmu: 8
> - samsung,exynos7-tmu: 8
> @@ -52,7 +52,7 @@ properties:
> - description: |
> Shared TMU registers.
>
> - Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
> + Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
> channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
> cases, there is a misplaced register, also provide clock to access
> that base.
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> index a7f58114c02e..90daee616880 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> @@ -92,14 +92,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> index 8201656b41ed..d99af9f413d0 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> @@ -87,14 +87,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> --
> 2.53.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* [PATCH v2] usb: xhci: fix runtime PM usage count leak in xhci_port_bw_show()
From: Wentao Liang @ 2026-06-22 11:01 UTC (permalink / raw)
To: Mathias Nyman, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, Wentao Liang, stable
When xhci_port_bw_show() calls pm_runtime_get_sync() and it fails with
a negative return value, the function returns the error directly without
calling pm_runtime_put_noidle(). This leaks the runtime PM usage count,
preventing the device from ever suspending again.
pm_runtime_get_sync() unconditionally increments dev->power.usage_count
before calling rpm_resume(). If rpm_resume() fails, the usage count is
not decremented — a well-known API pitfall. Add a pm_runtime_put_noidle()
call on the error path to balance the reference.
Cc: stable@vger.kernel.org
Fixes: 59d50e53e070 ("usb: xhci: Add debugfs support for xHCI port bandwidth")
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
---
drivers/usb/host/xhci-debugfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index d07276192256..2974411f775d 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -679,8 +679,10 @@ static int xhci_port_bw_show(struct xhci_hcd *xhci, u8 dev_speed,
struct device *dev = hcd->self.controller;
ret = pm_runtime_get_sync(dev);
- if (ret < 0)
+ if (ret < 0) {
+ pm_runtime_put_noidle(dev);
return ret;
+ }
ctx = xhci_alloc_port_bw_ctx(xhci, 0);
if (!ctx) {
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Mark Brown @ 2026-06-22 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 334 bytes --]
On Mon, Jun 22, 2026 at 12:16:08PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] usb: cdnsp: fix stream context array leak in cdnsp_alloc_stream_info()
From: Peter Chen @ 2026-06-22 10:46 UTC (permalink / raw)
To: Haoxiang Li; +Cc: pawell, gregkh, linux-usb, linux-kernel, stable
In-Reply-To: <20260622052627.696373-1-haoxiang_li2024@163.com>
On 26-06-22 13:26:27, Haoxiang Li wrote:
> cdnsp_alloc_stream_info() allocates stream_info->stream_ctx_array with
> cdnsp_alloc_stream_ctx(). If a later stream ring allocation or stream
> mapping update fails, the error path frees the allocated stream rings
> and stream_rings array, but leaves stream_ctx_array allocated.
>
> Free the stream context array before falling through to the stream_rings
> cleanup path.
>
> Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Peter
> ---
> drivers/usb/cdns3/cdnsp-mem.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/cdns3/cdnsp-mem.c b/drivers/usb/cdns3/cdnsp-mem.c
> index a2a1b21f2ef8..880097f1007d 100644
> --- a/drivers/usb/cdns3/cdnsp-mem.c
> +++ b/drivers/usb/cdns3/cdnsp-mem.c
> @@ -631,6 +631,8 @@ int cdnsp_alloc_stream_info(struct cdnsp_device *pdev,
> }
> }
>
> + cdnsp_free_stream_ctx(pdev, pep);
> +
> cleanup_stream_rings:
> kfree(pep->stream_info.stream_rings);
>
> --
> 2.25.1
>
>
--
Thanks,
Peter Chen
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Geert Uytterhoeven @ 2026-06-22 10:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 22 Jun 2026 at 12:16, Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: AW: AW: AW: AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Nicolai Buchwitz @ 2026-06-22 10:34 UTC (permalink / raw)
To: Sven Schuchmann
Cc: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Woojung.Huh, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-usb, linux-kernel
In-Reply-To: <BEZP281MB22457C80F9D1AC7F788EC008D9EF2@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM>
Hi Sven
On 22.6.2026 12:07, Sven Schuchmann wrote:
> [...]
>> > looks good from my point of view
>> > (Calling the lan78xx_write_vlan_table() from
>> > lan78xx_mac_link_up() and from lan78xx_reset()).
>>
>> Thanks.
>
> Just to be clear I used this patch which is looking good:
> [...]
Thanks for testing! I've sent a v2 of my patch with your t-b:
https://lore.kernel.org/netdev/20260622102911.484045-1-nb@tipi-net.de/
Regards
Nicolai
^ permalink raw reply
* [PATCH net v2] net: usb: lan78xx: restore VLAN and hash filters after link up
From: Nicolai Buchwitz @ 2026-06-22 10:29 UTC (permalink / raw)
To: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Woojung.Huh
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sven Schuchmann, netdev, linux-usb, linux-kernel,
Nicolai Buchwitz
Configured VLANs intermittently stop receiving traffic after a link
down/up cycle, e.g. when the network cable is unplugged and plugged back
in. VLAN filtering stays enabled but all VLAN-tagged frames are dropped
until a VLAN is added or removed again.
The LAN7801 datasheet (DS00002123E) states:
"A portion of the MAC operates on clocks generated by the Ethernet
PHY. During a PHY reset event, this portion of the MAC is designed to
not be taken out of reset until the PHY clocks are operational"
(section 8.10, MAC Reset Watchdog Timer)
"After a reset event, the RFE will automatically initialize the
contents of the VHF to 0h."
(section 7.1.4, VHF Organization)
Thus a link down/up cycle stops and restarts the PHY clock, resets the
PHY-clocked portion of the MAC, and the RFE clears its VLAN/DA hash
filter (VHF) memory. The VHF holds both the VLAN filter table and the
multicast hash table, but the driver never reprograms either from its
shadow copy once the link is back, so both stay empty.
Reprogram the VLAN filter and multicast hash tables on link up.
Reported-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Closes: https://lore.kernel.org/netdev/BEZP281MB224501E38B30BFDC4BD3D364D9E32@BEZP281MB2245.DEUP281.PROD.OUTLOOK.COM/T/#u
Tested-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
v2:
- Reprogram in lan78xx_mac_link_up() instead of lan78xx_reset(); the
table is lost on a plain link down/up cycle, where reset() is not
called. This also avoids the usb_autopm_get_interface() -EACCES path
in reset_resume() that was flagged on v1.
- Also restore the multicast hash table: the RFE clears the whole VHF
(VLAN + hash) memory, per the LAN7801 datasheet.
v1: https://lore.kernel.org/netdev/20260618191109.4086598-1-nb@tipi-net.de/
drivers/net/usb/lan78xx.c | 37 +++++++++++++++++++++++++++++++------
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index bcf293ea1bd3..c4cebacabcb5 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1452,6 +1452,15 @@ static inline u32 lan78xx_hash(char addr[ETH_ALEN])
return (ether_crc(ETH_ALEN, addr) >> 23) & 0x1ff;
}
+static int lan78xx_write_mchash_table(struct lan78xx_net *dev)
+{
+ struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+
+ return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_,
+ DP_SEL_VHF_VLAN_LEN,
+ DP_SEL_VHF_HASH_LEN, pdata->mchash_table);
+}
+
static void lan78xx_deferred_multicast_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
@@ -1462,9 +1471,7 @@ static void lan78xx_deferred_multicast_write(struct work_struct *param)
netif_dbg(dev, drv, dev->net, "deferred multicast write 0x%08x\n",
pdata->rfe_ctl);
- ret = lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_,
- DP_SEL_VHF_VLAN_LEN,
- DP_SEL_VHF_HASH_LEN, pdata->mchash_table);
+ ret = lan78xx_write_mchash_table(dev);
if (ret < 0)
goto multicast_write_done;
@@ -1557,6 +1564,7 @@ static void lan78xx_set_multicast(struct net_device *netdev)
}
static void lan78xx_rx_urb_submit_all(struct lan78xx_net *dev);
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev);
static int lan78xx_mac_reset(struct lan78xx_net *dev)
{
@@ -2514,6 +2522,17 @@ static void lan78xx_mac_link_up(struct phylink_config *config,
if (ret < 0)
goto link_up_fail;
+ /* The RFE clears the VLAN/DA hash filter (VHF) on a link down/up
+ * cycle, so reprogram both tables from their shadow copies.
+ */
+ ret = lan78xx_write_vlan_table(dev);
+ if (ret < 0)
+ goto link_up_fail;
+
+ ret = lan78xx_write_mchash_table(dev);
+ if (ret < 0)
+ goto link_up_fail;
+
netif_start_queue(net);
return;
@@ -3065,14 +3084,20 @@ static int lan78xx_set_features(struct net_device *netdev,
return lan78xx_write_reg(dev, RFE_CTL, pdata->rfe_ctl);
}
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev)
+{
+ struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+
+ return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
+ DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+}
+
static void lan78xx_deferred_vlan_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
container_of(param, struct lan78xx_priv, set_vlan);
- struct lan78xx_net *dev = pdata->dev;
- lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
- DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+ lan78xx_write_vlan_table(pdata->dev);
}
static int lan78xx_vlan_rx_add_vid(struct net_device *netdev,
base-commit: d07d80b6a129a44538cda1549b7acf95154fb197
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] USB: serial: ftdi_sio: make explicit latency_timer sysfs write authoritative
From: Greg Kroah-Hartman @ 2026-06-22 10:19 UTC (permalink / raw)
To: Chinna Mopurigari Naveen Kumar Reddy
Cc: Johan Hovold, linux-usb, linux-kernel, Arun Pappan
In-Reply-To: <180003edbd4fb3f6ef2b87551499698927b1191d.1782121274.git.naveen.reddy@ftdichip.com>
On Mon, Jun 22, 2026 at 05:43:40PM +0800, Chinna Mopurigari Naveen Kumar Reddy wrote:
> write_latency_timer() clamps the value programmed into the FT chip's
> per-channel latency_timer register to 1 whenever ASYNC_LOW_LATENCY is
> set in priv->flags. ASYNC_LOW_LATENCY is set by userspace via
> TIOCSSERIAL, used by setserial(8), libftdi and certain tcsetattr
> paths. The interaction with the existing sysfs latency_timer
> attribute is surprising: once any of those tools has set the flag, a
> later write of "16" (or any other value) to
> /sys/bus/usb-serial/devices/ttyUSBx/latency_timer is silently
> clamped to 1 and never reaches the chip.
>
> The store path is the most explicit way userspace can ask for a
> particular latency_timer value; treat it as authoritative. On an
> explicit sysfs write, clear ASYNC_LOW_LATENCY before calling
> write_latency_timer() so the requested value is what the chip
> register actually receives. Emit a dev_info() so the override is
> visible.
>
> Reads continue to honour ASYNC_LOW_LATENCY (returning "1") so any
> userspace that previously inspected the attribute to confirm
> low-latency mode keeps working until it does its own explicit write.
>
> Signed-off-by: Chinna Mopurigari Naveen Kumar Reddy <naveen.reddy@ftdichip.com>
> ---
> drivers/usb/serial/ftdi_sio.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> index 7aaa7fc1be71..e7f13eca7ae6 100644
> --- a/drivers/usb/serial/ftdi_sio.c
> +++ b/drivers/usb/serial/ftdi_sio.c
> @@ -1683,6 +1683,23 @@ static ssize_t latency_timer_store(struct device *dev,
> if (kstrtou8(valbuf, 10, &v))
> return -EINVAL;
>
> + /*
> + * An explicit sysfs write wins over the legacy ASYNC_LOW_LATENCY
> + * tty-flag override. Without this, if any userspace tool
> + * (setserial(8), libftdi, certain tcsetattr paths) had set
> + * ASYNC_LOW_LATENCY via TIOCSSERIAL, write_latency_timer() would
> + * silently clamp the chip register to 1 regardless of what was
> + * written to sysfs. Clearing the flag here makes sysfs the
> + * authoritative source so the next chip-side write uses exactly
> + * the value the caller asked for.
> + */
> + if (priv->flags & ASYNC_LOW_LATENCY) {
> + dev_info(&port->dev,
> + "explicit latency_timer=%u clears ASYNC_LOW_LATENCY flag\n",
> + v);
When drivers work properly, they are quiet. Make this a debugging
message at the most please.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support
From: Heikki Krogerus @ 2026-06-22 10:18 UTC (permalink / raw)
To: Andrei Kuchynski
Cc: Benson Leung, Jameson Thies, Greg Kroah-Hartman, linux-usb,
linux-kernel
In-Reply-To: <20260622093910.1210089-2-akuchynski@chromium.org>
Hi Andrei,
> +bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> +{
> + struct typec_altmode *plug;
> + struct typec_cable *cable;
> + bool unsupported = false;
> +
> + /*
> + * Check if the cable has an e-marker, supports modal operation, and the
> + * SOP' altmode nodes are created. If yes, then altmode is supported.
> + */
> + plug = typec_altmode_get_plug(alt, TYPEC_PLUG_SOP_P);
> + if (plug) {
> + typec_altmode_put_plug(plug);
> + return false;
> + }
> +
> + /*
> + * Check if the cable is registered and its identity is specified.
> + * If not, the cable altmode restriction cannot be checked.
> + */
> + cable = typec_cable_get(typec_altmode2port(alt));
> + if (cable && cable->identity) {
> + const u32 id_header = cable->identity->id_header;
> + const u32 speed = VDO_TYPEC_CABLE_SPEED(cable->identity->vdo[0]);
> +
> + /*
> + * A cable lacking an ID Header indicates a non-e-marked cable,
> + * can only be guaranteed to have a USB 2.0 data path (D+ and D-).
> + */
> + if (!id_header) {
> + unsupported = true;
> + } else {
> + switch (PD_IDH_PTYPE(id_header)) {
> + /*
> + * If the speed field explicitly declares it is a
> + * USB 2.0-only cable, altmode is unsupported.
> + */
> + case IDH_PTYPE_PCABLE:
> + unsupported = (speed == CABLE_USB2_ONLY);
> + break;
> + /*
> + * Active cables must establish an SOP' communication
> + * node. Since that check failed at the beginning of
> + * this function, this active cable does not support
> + * this specific altmode.
> + */
> + case IDH_PTYPE_ACABLE:
> + unsupported = true;
> + break;
> + }
> + }
> + }
> + if (cable)
> + typec_cable_put(cable);
> +
> + return unsupported;
So if typec_cable_get() doesn't return a cable, this function will now
always return false - i.e. the cable is supported? Is that intentional?
This would probable be much more clear if you checked the cable only
ones, right after you take the handle.
cable = typec_cable_get(typec_altmode2port(alt));
if (!cable)
return true; /* or false? */
...
/* Now unconditionally */
typec_cable_put(cable);
I think this would be even more clear if the function was called
typec_cable_altmode_supported() and you would then have a wrapper:
static inline bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
{
return !typec_cable_altmode_supported(alt);
}
Thanks,
--
heikki
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
In-Reply-To: <20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com>
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Intention for this patch is to go via Rob's tree.
---
.../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
.../devicetree/bindings/arm/qcom.yaml | 4 ++--
.../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
.../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
.../display/samsung/samsung,fimd.yaml | 4 ++--
.../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
.../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
.../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
.../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
.../bindings/leds/skyworks,aat1290.yaml | 6 +++---
.../bindings/media/cec/cec-gpio.yaml | 2 +-
.../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
.../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
.../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
.../bindings/phy/samsung,usb2-phy.yaml | 2 +-
.../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
.../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
.../bindings/power/renesas,rcar-sysc.yaml | 2 +-
.../bindings/power/reset/restart-handler.yaml | 8 ++++----
.../bindings/regulator/maxim,max77802.yaml | 4 ++--
.../bindings/regulator/richtek,rtq2208.yaml | 2 +-
.../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
.../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
.../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
.../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
.../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
.../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
.../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
.../thermal/samsung,exynos-thermal.yaml | 4 ++--
.../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
.../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
31 files changed, 75 insertions(+), 75 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
index 27261039d56f..37fdd5a080b7 100644
--- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
qcom,SoC-IP
- For example::
+ For example:
qcom,sdm845-llcc-bwmon
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..667607ae2c32 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1215,7 +1215,7 @@ properties:
items:
items:
- description: |
- MSM chipset ID - an exact match value consisting of two bitfields::
+ MSM chipset ID - an exact match value consisting of two bitfields:
- bits 0-15 - The unique MSM chipset ID
- bits 16-31 - Reserved; should be 0
- description: |
@@ -1241,7 +1241,7 @@ properties:
- items:
- items:
- description: |
- Board ID consisting of three bitfields::
+ Board ID consisting of three bitfields:
- bits 31-24 - Unused
- bits 23-16 - Platform Version Major
- bits 15-8 - Platform Version Minor
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
index 653f85997643..ab000befe76d 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
samsung,SoC-IP
- For example::
+ For example:
samsung,exynos5433-cmu-isp
select:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index dbc0613e427e..395425a70db8 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -73,16 +73,16 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - bus:: Display AHB clock.
- - byte:: Display byte clock.
- - byte_intf:: Display byte interface clock.
- - core:: Display core clock.
- - core_mss:: Core MultiMedia SubSystem clock.
- - iface:: Display AXI clock.
- - mdp_core:: MDP Core clock.
- - mnoc:: MNOC clock
- - pixel:: Display pixel clock.
+ Several clocks are used, depending on the variant. Typical ones are:
+ - bus: Display AHB clock.
+ - byte: Display byte clock.
+ - byte_intf: Display byte interface clock.
+ - core: Display core clock.
+ - core_mss: Core MultiMedia SubSystem clock.
+ - iface: Display AXI clock.
+ - mdp_core: MDP Core clock.
+ - mnoc: MNOC clock
+ - pixel: Display pixel clock.
minItems: 3
maxItems: 12
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
index ff685031bb2c..729705f419bb 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
@@ -41,7 +41,7 @@ properties:
additionalProperties: false
description: |
Timing configuration for lcd i80 interface support.
- The parameters are defined as::
+ The parameters are defined as:
VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
: : : : :
Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
@@ -132,7 +132,7 @@ patternProperties:
"^port@[0-4]+$":
$ref: /schemas/graph.yaml#/properties/port
description: |
- Contains ports with port with index::
+ Contains ports with port with index:
0 - for CAMIF0 input,
1 - for CAMIF1 input,
2 - for CAMIF2 input,
diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
index a2ddc6803617..07600b49f2f9 100644
--- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
@@ -35,7 +35,7 @@ properties:
gpios:
description: |
- The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
+ The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
specifier depends on the gpio controller. Required in all cases except
for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
permanently wired to the respective client.
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index ff64225e8281..e002e70580f9 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -13,7 +13,7 @@ description: |
Bandwidth Monitor measures current throughput on buses between various NoC
fabrics and provides information when it crosses configured thresholds.
- Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
+ Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
- Measuring the bandwidth between CPUs and Last Level Cache Controller -
called just BWMON,
- Measuring the bandwidth between Last Level Cache Controller and memory
diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
index 5e26e48c7217..0203959c8995 100644
--- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
+++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
@@ -23,7 +23,7 @@ description: |
The each AXI bus has the owned source clock but, has not the only owned power
line. The power line might be shared among one more sub-blocks. So, we can
divide into two type of device as the role of each sub-block. There are two
- type of bus devices as following::
+ type of bus devices as following:
- parent bus device
- passive bus device
@@ -44,8 +44,8 @@ description: |
able to support the bus frequency for all Exynos SoCs.
Detailed correlation between sub-blocks and power line according
- to Exynos SoC::
- - In case of Exynos3250, there are two power line as following::
+ to Exynos SoC:
+ - In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -89,7 +89,7 @@ description: |
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
- - In case of Exynos4210, there is one power line as following::
+ - In case of Exynos4210, there is one power line as following:
VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
|--- LEFTBUS
|--- PERIL
@@ -106,7 +106,7 @@ description: |
|--- LCD0
|--- LCD1
- - In case of Exynos4x12, there are two power line as following::
+ - In case of Exynos4x12, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -124,7 +124,7 @@ description: |
|--- LCD0
|--- ISP
- - In case of Exynos5422, there are two power line as following::
+ - In case of Exynos5422, there are two power line as following:
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|--- DREX 1
@@ -143,7 +143,7 @@ description: |
|--- FSYS
|--- FSYS2
- - In case of Exynos5433, there is VDD_INT power line as following::
+ - In case of Exynos5433, there is VDD_INT power line as following:
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
index b409b2a8b5c5..5165bfddcd54 100644
--- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
+++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
@@ -10,10 +10,10 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
+ The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
because sometimes these LED drivers are used for wildly different things than
- flash or keypad backlight:: their names are more of a suggestion than a
+ flash or keypad backlight: their names are more of a suggestion than a
hard-wired usecase.
Hardware-wise the different LEDs support slightly different output currents.
diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
index a6aaa92dbccd..65576dfdca11 100644
--- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
+++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
@@ -11,7 +11,7 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
+ The device is controlled through two pins: FL_EN and EN_SET. The pins when,
asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
respectively. In order to add a capability of selecting the strobe signal
source (e.g. CPU or camera sensor) there is an additional switch required,
@@ -39,11 +39,11 @@ properties:
flash-max-microamp:
description: |
Maximum flash LED supply current can be calculated using following
- formula:: I = 1A * 162 kOhm / Rset.
+ formula: I = 1A * 162 kOhm / Rset.
flash-max-timeout-us:
description: |
- Maximum flash timeout can be calculated using following formula::
+ Maximum flash timeout can be calculated using following formula:
T = 8.82 * 10^9 * Ct.
required:
diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
index 582c6c9cae48..21118e4bae0f 100644
--- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
+++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
@@ -14,7 +14,7 @@ description: |
hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
to another GPIO line.
- Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
+ Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
5V lines it is 5.3V. So you may need some sort of level conversion
circuitry when connecting them to a GPIO line.
diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index 27c4060f2f91..223fcc9f651f 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -85,7 +85,7 @@ properties:
description: |
The value of CIU TX and RX clock phase shift value for HS400 mode
operation.
- Valid values for SDR and DDR CIU clock timing::
+ Valid values for SDR and DDR CIU clock timing:
- valid value for tx phase shift and rx phase shift is 0 to 7.
- when CIU clock divider value is set to 3, all possible 8 phase shift
values can be used.
diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
index 9e2d78a78e40..769243a2bf04 100644
--- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
@@ -13,8 +13,8 @@ description: |
Mux controller consumers should specify a list of mux controllers that they
want to use with a property containing a 'mux-ctrl-list':
- mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
- single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
+ mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
+ single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
mux-ctrl-phandle : phandle to mux controller node
mux-ctrl-specifier : array of #mux-control-cells specifying the
given mux controller (controller specific)
diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
index 16967ef8e9ec..87b6a35b2626 100644
--- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
@@ -13,14 +13,14 @@ maintainers:
description: |
For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
- PHY specifier identifies the PHY and its meaning is as follows::
+ PHY specifier identifies the PHY and its meaning is as follows:
0 - MIPI CSIS 0,
1 - MIPI DSIM 0,
2 - MIPI CSIS 1,
3 - MIPI DSIM 1.
samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
- support additional fifth PHY::
+ support additional fifth PHY:
4 - MIPI CSIS 2.
properties:
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
index d9f22a801cbf..7db7605a82e2 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
The first phandle argument in the PHY specifier identifies the PHY, its
meaning is compatible dependent. For the currently supported SoCs (Exynos4210
- and Exynos4212) it is as follows::
+ and Exynos4212) it is as follows:
0 - USB device ("device"),
1 - USB host ("host"),
2 - HSIC0 ("hsic0"),
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 4562e0468f4f..a1b3d9e6a094 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
compatible PHYs, the second cell in the PHY specifier identifies the
- PHY id, which is interpreted as follows::
+ PHY id, which is interpreted as follows:
0 - UTMI+ type phy,
1 - PIPE3 type phy.
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 7b006009ca0e..5e35686eeed3 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -18,7 +18,7 @@ description: |
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
- The controller supports three types of interrupts::
+ The controller supports three types of interrupts:
- External GPIO interrupts (see interrupts property in pin controller node);
- External wake-up interrupts - multiplexed (capable of waking up the system
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
index 347571e2545a..b67aa170b2c1 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
@@ -13,7 +13,7 @@ maintainers:
description: |
The R-Car (RZ/G) System Controller provides power management for the CPU
cores and various coprocessors.
- The power domain IDs for consumers are defined in header files::
+ The power domain IDs for consumers are defined in header files:
include/dt-bindings/power/r8*-sysc.h
properties:
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
index 965a834a3dbe..00c00ec5ec81 100644
--- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -18,12 +18,12 @@ properties:
priority:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
- A priority ranging from 0 to 255 according to the following guidelines::
- 0:: Restart handler of last resort, with limited restart capabilities.
- 128:: Typical, default restart handler; use if no other restart handler
+ A priority ranging from 0 to 255 according to the following guidelines:
+ 0: Restart handler of last resort, with limited restart capabilities.
+ 128: Typical, default restart handler; use if no other restart handler
is expected to be available, and/or if restart functionality is
sufficient to restart the entire system.
- 255:: Highest priority restart handler, will preempt all other restart handlers.
+ 255: Highest priority restart handler, will preempt all other restart handlers.
minimum: 0
maximum: 255
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
index b704f05ea454..b886495c1396 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
@@ -22,13 +22,13 @@ description: |
Certain regulators support "regulator-initial-mode" and "regulator-mode".
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
- and their meaning is::
+ and their meaning is:
1 - Normal regulator voltage output mode.
3 - Low Power which reduces the quiescent current down to only 1uA
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These
- regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
+ regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
regulator has been enabled for the given suspend state using
"regulator-on-in-suspend" and has not been disabled for that state using
"regulator-off-in-suspend".
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
index 022c1f197364..b0aa38edf8c2 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -21,7 +21,7 @@ description: |
conduction mode (FCCM).
The definition of modes is in the datasheet which is available in below link
- and their meaning is::
+ and their meaning is:
0 - Auto mode for power saving, which reducing the switching frequency at light load condition
to maintain high frequency.
1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
index 788ef5c1c446..bc967ead2350 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
@@ -17,7 +17,7 @@ description: |
software perspective it's mostly compatible with the MSM serial UART except
that it supports reading and writing multiple characters at a time.
- Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
+ Note: Aliases may be defined to ensure the correct ordering of the UARTs.
The alias serialN will result in the UART being assigned port N. If any
serialN alias exists, then an alias must exist for each enabled UART. The
serialN aliases should be in a .dts file instead of in a .dtsi file.
diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
index 5a941610ce4e..3910327c8ded 100644
--- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
+++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
@@ -29,7 +29,7 @@ patternProperties:
description: |
Every SLIMbus controller node can contain zero or more child nodes
representing slave devices on the bus. Every SLIMbus slave device is
- uniquely determined by the enumeration address containing 4 fields::
+ uniquely determined by the enumeration address containing 4 fields:
Manufacturer ID, Product code, Device index, and Instance value for the
device.
@@ -48,7 +48,7 @@ patternProperties:
reg:
maxItems: 1
description: |
- Pair of (device index, instande ID), where::
+ Pair of (device index, instande ID), where:
- Device index, which uniquely identifies multiple devices within a
single component.
- Instance ID, can be used for the cases where multiple devices of
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
index bdf482db32aa..b663be3ea5a1 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
@@ -40,7 +40,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Protection domain service name and path for APR service (if supported).
- Possible values are::
+ Possible values are:
"avs/audio", "msm/adsp/audio_pd".
"kernel/elf_loader", "msm/modem/wlan_pd".
"tms/servreg", "msm/adsp/audio_pd".
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index 26d9bc773ec5..1889139a3f7a 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -23,7 +23,7 @@ description: |
with a few variations that are captured by the properties here.
A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
- have powered off to facilitate idle power saving. TCS could be classified as::
+ have powered off to facilitate idle power saving. TCS could be classified as:
ACTIVE - Triggered by Linux
SLEEP - Triggered by F/W
WAKE - Triggered by F/W
@@ -76,7 +76,7 @@ properties:
items:
items:
- description: |
- TCS type::
+ TCS type:
- ACTIVE_TCS
- SLEEP_TCS
- WAKE_TCS
@@ -152,7 +152,7 @@ examples:
- |
// For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
// 2, the register offsets for DRV2 start at 0D00, the register
- // calculations are like this::
+ // calculations are like this:
// DRV0: 0x179C0000
// DRV2: 0x179C0000 + 0x10000 = 0x179D0000
// DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
@@ -182,7 +182,7 @@ examples:
- |
// For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
// register offsets for DRV0 start at 01C00, the register calculations are
- // like this::
+ // like this:
// DRV0: 0xAF20000
// TCS-OFFSET: 0x1C00
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
index 4fcae6bedfff..72a7f8cb09ba 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
@@ -28,7 +28,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
- The node must be compatible with one of the following::
+ The node must be compatible with one of the following:
- qcom,riva"
- qcom,pronto"
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
index 5ddd31f30f26..57c9d3c57021 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
@@ -12,10 +12,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
renesas,SoC-IP
- For example::
+ For example:
renesas,r8a77965-csi2
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
index 47a105a97ecf..bc8c8ba24f9c 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
@@ -45,7 +45,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
description: |
- The direction of the dai stream::
+ The direction of the dai stream:
- Q6ASM_DAI_TX_RX (0) for both tx and rx
- Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
- Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
index 29a08b0729ee..3f333db72a71 100644
--- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
@@ -40,7 +40,7 @@ properties:
description: |
The Exynos TMU supports generating interrupts when reaching given
temperature thresholds. Number of supported thermal trip points depends
- on the SoC (only first trip points defined in DT will be configured)::
+ on the SoC (only first trip points defined in DT will be configured):
- most of SoC: 4
- samsung,exynos5433-tmu: 8
- samsung,exynos7-tmu: 8
@@ -52,7 +52,7 @@ properties:
- description: |
Shared TMU registers.
- Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
cases, there is a misplaced register, also provide clock to access
that base.
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a7f58114c02e..90daee616880 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -92,14 +92,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
index 8201656b41ed..d99af9f413d0 100644
--- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
@@ -87,14 +87,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I split the patches to avoid bounces from mailing list due to email size.
This can go via clock tree (no dependencies)... or both could go via
Rob's tree.
---
.../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
.../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
32 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index 53a5ab319159..6863db9bd092 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8150/SM8250/SM8350.
- See also::
+ See also:
include/dt-bindings/clock/qcom,dispcc-sm8150.h
include/dt-bindings/clock/qcom,dispcc-sm8250.h
include/dt-bindings/clock/qcom,dispcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 27df7e3e5bf3..68532244901e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8960.h
include/dt-bindings/reset/qcom,gcc-msm8960.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 0a0a26d9beab..1c022e75fd71 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8084.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-apq8084.h
include/dt-bindings/reset/qcom,gcc-apq8084.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
index 4d2614d4f368..c7fb84438db7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ6018.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq6018.h
include/dt-bindings/reset/qcom,gcc-ipq6018.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
index a71557395c01..b4d3175780bc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
include/dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
index d7da30b0e7ee..0a7be7583bdd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9607.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
index 418dea31eb62..0656d5ee448d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9615.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
index e03b6d0acdb6..70c9da1f35c2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks and resets on
MSM8660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8660.h
include/dt-bindings/reset/qcom,gcc-msm8660.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
index ce1f5a60bd8c..2edb6c251d99 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8909, MSM8917 or QM215.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8909.h
include/dt-bindings/clock/qcom,gcc-msm8917.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
index 258b6b93deca..af4b639ea8c3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8916 or MSM8939.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8916.h
include/dt-bindings/clock/qcom,gcc-msm8939.h
include/dt-bindings/reset/qcom,gcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index ced3118c8580..fc0360554f68 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8937, MSM8940, MSM8953 or SDM439.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8917.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
index 929fafc84c19..378dfe7854ac 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8974 (all variants) and MSM8226.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
include/dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
index 724ce0491118..72aaf699cf70 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on SDM630, SDM636 and SDM660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
$ref: qcom,gcc.yaml#
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 4cdff6161bf0..3ac4419009a9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gpucc-sdm845.h
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
include/dt-bindings/clock/qcom,gpucc-sc7180.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
index 489d0fc5607c..9925b931ecad 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ5018
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq5018-gcc.h
include/dt-bindings/reset/qcom,ipq5018-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 27ae9938febc..5b128fa841aa 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ9574
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq9574-gcc.h
include/dt-bindings/reset/qcom,ipq9574-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
index 61473385da2d..3da10c364a85 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm NSS clock control module provides the clocks and resets
on QCA8386(switch mode)/QCA8084(PHY mode)
- See also::
+ See also:
include/dt-bindings/clock/qcom,qca8k-nsscc.h
include/dt-bindings/reset/qcom,qca8k-nsscc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
index 734880805c1b..bedbdabef672 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,qcm2290-gpucc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8..b6c835bfd0d9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
- come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
+ come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index 99ab9106009f..fd06ac9bceb9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks and
power domains on SC7280.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
index 273d66e245c5..f235b4e24cc7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks,
and reset on SC8280XP.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
index 8cbab3fbb660..d7e1938b5e1b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm LPASS core and audio clock controllers provide audio-related resets
on SM6115 and its derivatives.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6115-lpasscc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
index 5c2ecec0624e..a986ab4ce7c7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,videocc-sm8350.h
include/dt-bindings/reset/qcom,videocc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index f4ff9acef9d5..124d259fc85e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6350-videocc.h
include/dt-bindings/clock/qcom,videocc-sc7180.h
include/dt-bindings/clock/qcom,videocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
index b05f83533e3d..56ab972c3da5 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
@@ -14,17 +14,17 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
- Phy clocks::
+ Phy clocks:
There are several clocks which are generated by specific PHYs. These clocks
are fed into the clock controller and then routed to the hardware blocks.
- These clocks are defined as fixed clocks in the driver with following names::
+ These clocks are defined as fixed clocks in the driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
index b737c9d35a1c..1d907dd8fbf1 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
index 3f9326e09f79..8a289f1e2ace 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "oscclk" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
index c137c6744ef9..a51cd4fafb41 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
index cdc5ded59fe5..68c2fd318765 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos850 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
+ two external clocks: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
clocks must be defined as fixed-rate clocks in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index 32f39e543b36..e9d17d48b4f3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos Auto v9 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
index 6b1fc61a2ff9..475db824d4d3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
@@ -17,7 +17,7 @@ description: |
ExynosAuto v920 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
index 67a33665cf00..b1617d96d3fb 100644
--- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
--
2.53.0
^ permalink raw reply related
* [PATCH] usbip: tools: support SuperSpeed Plus devices
From: raoxu @ 2026-06-22 10:08 UTC (permalink / raw)
To: valentina.manea.m; +Cc: shuah, i, linux-usb, linux-kernel, raoxu
From: Xu Rao <raoxu@uniontech.com>
USB/IP reads a remote device's speed from the server-side sysfs
"speed" attribute. read_attr_speed() converts the string to
enum usb_device_speed before the value is sent to the client.
The conversion table only recognizes 5000 Mbps. Devices reporting
10000 or 20000 Mbps are therefore sent as USB_SPEED_UNKNOWN. The
client then selects a USB 2.0 VHCI port, and the kernel rejects the
attach request because USB_SPEED_UNKNOWN is not a supported speed.
Map both SuperSpeed Plus sysfs values to USB_SPEED_SUPER_PLUS and
select the SuperSpeed VHCI hub for that speed.
The issue was reproduced with the following server hardware:
xHCI controller: Intel 8086:a0ed, revision 20
Subsystem: Lenovo 17aa:382a
USB device: Silicon Motion 090c:2320 mass storage
sysfs speed: 10000 Mbps
Before the change:
$ usbip attach -r 10.20.12.170 -b 2-2
usbip: error: import device
After the change, the device attaches and uses usb-storage:
$ usbip port
Port 08: <Port in Use> at Super Speed(5000Mbps)
8-1 -> usbip://10.20.12.170:3240/2-2
VHCI currently exposes the imported device as SuperSpeed, so the
client reports 5000 Mbps instead of 10000 Mbps. This is a separate
speed-reporting limitation and does not prevent attachment or I/O.
Signed-off-by: Xu Rao <raoxu@uniontech.com>
---
tools/usb/usbip/libsrc/usbip_common.c | 2 ++
tools/usb/usbip/libsrc/vhci_driver.c | 1 +
2 files changed, 3 insertions(+)
diff --git a/tools/usb/usbip/libsrc/usbip_common.c b/tools/usb/usbip/libsrc/usbip_common.c
index b8d7d480595a..d91872a425f5 100644
--- a/tools/usb/usbip/libsrc/usbip_common.c
+++ b/tools/usb/usbip/libsrc/usbip_common.c
@@ -29,6 +29,8 @@ static const struct speed_string speed_strings[] = {
{ USB_SPEED_HIGH, "480", "High Speed(480Mbps)" },
{ USB_SPEED_WIRELESS, "53.3-480", "Wireless"},
{ USB_SPEED_SUPER, "5000", "Super Speed(5000Mbps)" },
+ { USB_SPEED_SUPER_PLUS, "10000", "SuperSpeed Plus" },
+ { USB_SPEED_SUPER_PLUS, "20000", "SuperSpeed Plus" },
{ 0, NULL, NULL }
};
diff --git a/tools/usb/usbip/libsrc/vhci_driver.c b/tools/usb/usbip/libsrc/vhci_driver.c
index 8159fd98680b..4ca3783ee5b7 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -338,6 +338,7 @@ int usbip_vhci_get_free_port(uint32_t speed)
switch (speed) {
case USB_SPEED_SUPER:
+ case USB_SPEED_SUPER_PLUS:
if (vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
continue;
break;
--
2.50.1
^ permalink raw reply related
* AW: AW: AW: AW: [PATCH net] net: usb: lan78xx: restore VLAN filter table after device reset
From: Sven Schuchmann @ 2026-06-22 10:07 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Thangaraj Samynathan, Rengarajan Sundararajan,
UNGLinuxDriver@microchip.com, Woojung.Huh@microchip.com,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <f76711d2f45c527f9ce0f5d288631bc6@tipi-net.de>
Hello Nicolai,
On 19.6.2026 16:01, Nicolai Buchwitz wrote:
> Hi Sven
>
> On 19.6.2026 15:31, Sven Schuchmann wrote:
> > Hello Nicolai,
> >
> > looks good from my point of view
> > (Calling the lan78xx_write_vlan_table() from
> > lan78xx_mac_link_up() and from lan78xx_reset()).
>
> Thanks.
Just to be clear I used this patch which is looking good:
---
drivers/net/usb/lan78xx.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index a5132f2f9..a2db38650 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1571,6 +1571,7 @@ static void lan78xx_set_multicast(struct net_device *netdev)
}
static void lan78xx_rx_urb_submit_all(struct lan78xx_net *dev);
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev);
static int lan78xx_mac_reset(struct lan78xx_net *dev)
{
@@ -2528,6 +2529,10 @@ static void lan78xx_mac_link_up(struct phylink_config *config,
if (ret < 0)
goto link_up_fail;
+ ret = lan78xx_write_vlan_table(dev);
+ if (ret < 0)
+ goto link_up_fail;
+
netif_start_queue(net);
return;
@@ -3081,14 +3086,20 @@ static int lan78xx_set_features(struct net_device *netdev,
return lan78xx_write_reg(dev, RFE_CTL, pdata->rfe_ctl);
}
+static int lan78xx_write_vlan_table(struct lan78xx_net *dev)
+{
+ struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+
+ return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
+ DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+}
+
static void lan78xx_deferred_vlan_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
container_of(param, struct lan78xx_priv, set_vlan);
- struct lan78xx_net *dev = pdata->dev;
- lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_, 0,
- DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
+ lan78xx_write_vlan_table(pdata->dev);
}
static int lan78xx_vlan_rx_add_vid(struct net_device *netdev,
@@ -3378,6 +3389,15 @@ static int lan78xx_reset(struct lan78xx_net *dev)
lan78xx_set_multicast(dev->net);
+ /* The chip reset above also clears the VLAN filter table held in the
+ * shared VLAN/DA hash RAM. The network stack does not re-add VLANs
+ * after a silent device reset (e.g. on reset_resume after USB
+ * autosuspend), so restore the table from our shadow copy here.
+ */
+ ret = lan78xx_write_vlan_table(dev);
+ if (ret < 0)
+ return ret;
+
/* reset PHY */
ret = lan78xx_read_reg(dev, PMT_CTL, &buf);
if (ret < 0)
--
>
> > But I investigated a little more and it seems the hash table
> > (which is right behind the vlan table in the controllers memory)
> > also gets cleared. I wrote some random data into this table and have
> > seen that it gets also cleared. I think this needs to be fixed too.
>
> Something like
>
> static int lan78xx_write_mchash_table(struct lan78xx_net *dev)
> {
> struct lan78xx_priv *pdata = (struct lan78xx_priv
> *)(dev->data[0]);
>
> return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_,
> DP_SEL_VHF_VLAN_LEN,
> DP_SEL_VHF_HASH_LEN,
> pdata->mchash_table); // from lan78xx_deferred_multicast_write)
> }
>
> with callers in lan78xx_deferred_multicast_write() and
> lan78xx_mac_link_up(), should
> do the trick?
I used this one which is also looking good:
---
drivers/net/usb/lan78xx.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index d449c1950fd3..6d7d349816a6 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1466,6 +1466,8 @@ static inline u32 lan78xx_hash(char addr[ETH_ALEN])
return (ether_crc(ETH_ALEN, addr) >> 23) & 0x1ff;
}
+static int lan78xx_write_mchash_table(struct lan78xx_net *dev);
+
static void lan78xx_deferred_multicast_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
@@ -1476,9 +1478,7 @@ static void lan78xx_deferred_multicast_write(struct work_struct *param)
netif_dbg(dev, drv, dev->net, "deferred multicast write 0x%08x\n",
pdata->rfe_ctl);
- ret = lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_,
- DP_SEL_VHF_VLAN_LEN,
- DP_SEL_VHF_HASH_LEN, pdata->mchash_table);
+ ret = lan78xx_write_mchash_table(dev);
if (ret < 0)
goto multicast_write_done;
@@ -2533,6 +2533,10 @@ static void lan78xx_mac_link_up(struct phylink_config *config,
if (ret < 0)
goto link_up_fail;
+ ret = lan78xx_write_mchash_table(dev);
+ if (ret < 0)
+ goto link_up_fail;
+
netif_start_queue(net);
return;
@@ -3094,6 +3098,16 @@ static int lan78xx_write_vlan_table(struct lan78xx_net *dev)
DP_SEL_VHF_VLAN_LEN, pdata->vlan_table);
}
+static int lan78xx_write_mchash_table(struct lan78xx_net *dev)
+{
+ struct lan78xx_priv *pdata = (struct lan78xx_priv *)(dev->data[0]);
+
+ return lan78xx_dataport_write(dev, DP_SEL_RSEL_VLAN_DA_,
+ DP_SEL_VHF_VLAN_LEN,
+ DP_SEL_VHF_HASH_LEN,
+ pdata->mchash_table);
+}
+
static void lan78xx_deferred_vlan_write(struct work_struct *param)
{
struct lan78xx_priv *pdata =
@@ -3398,6 +3412,10 @@ static int lan78xx_reset(struct lan78xx_net *dev)
if (ret < 0)
return ret;
+ ret = lan78xx_write_mchash_table(dev);
+ if (ret < 0)
+ return ret;
+
/* reset PHY */
ret = lan78xx_read_reg(dev, PMT_CTL, &buf);
if (ret < 0)
--
>
> >
> > In the Datasheet from the LAN7801 I can read:
> > "After a reset event, the RFE will automatically initialize the
> > contents of the VHF to 0h."
> > Where VHF also refers to the hash table.
> > But I still do not understand what reset is happening when I just
> > unplug the network cable....
>
> I suspect it is triggered from the PHY:
>
> 8.10 (MAC Reset Watchdog Timer):
> "A portion of the MAC operates on clocks generated by the Ethernet PHY
> [...] PHY Reset
> (PHY_RST) results in resetting the portion of the MAC operating on the
> PHY receive and
> transmit clocks."
>
> So which PHY are you using?
I am using a DP83TC812R from TI. There is currently no driver available
so I ported this one
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/dp83tg720.c
which is working fine (maybe I will also publish a patch for this).
The strange thing is that the MAC Reset Watchdog Timer seems
to occur "silently" so that nor the mac or the phy driver know
about this reset.
But never the less. The two patches fixed my problem and
I think they should be mainline.
Regards,
Sven
^ permalink raw reply related
* Re: [RFC PATCH 2/9] rust: usb: add synchronous control transfer support
From: Oliver Neukum @ 2026-06-22 9:54 UTC (permalink / raw)
To: Mike Lothian, rust-for-linux
Cc: linux-usb, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Daniel Almeida,
Greg Kroah-Hartman, Alexandre Courbot, Shankari Anand,
linux-kernel
In-Reply-To: <20260617145946.1894-3-mike@fireburn.co.uk>
On 17.06.26 16:59, Mike Lothian wrote:
> + to_result(unsafe {
> + bindings::usb_control_msg_send(
> + self.as_raw(),
> + 0,
> + request,
> + request_type,
> + value,
> + index,
> + data.as_ptr().cast::<kernel::ffi::c_void>(),
> + data.len().try_into()?,
> + timeout.as_millis().try_into()?,
> + bindings::GFP_KERNEL,
No, you cannot do this. You cannot just blindly resort to GFP_KERNEL.
These parameters exist for a reason.
Basically USB devices share error handling among the drivers for
all interfaces. That means that all drivers for the purpose of
error handling (and power management) are block drivers.
As such they are restricted in how they can allocate memory. In particular
you cannot do paging. That means that a USB driver must be able
to specify whether GFP_KERNEL, GFP_NOIO or GFP_NOFS are to be passed
to the USB layer.
You must include them in the API exposed to drivers.
Regards
Oliver
^ permalink raw reply
* [PATCH v2 2/2] USB: serial: ftdi_sio: make explicit latency_timer sysfs write authoritative
From: Chinna Mopurigari Naveen Kumar Reddy @ 2026-06-22 9:43 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel, Arun Pappan
In-Reply-To: <cover.1782121274.git.naveen.reddy@ftdichip.com>
write_latency_timer() clamps the value programmed into the FT chip's
per-channel latency_timer register to 1 whenever ASYNC_LOW_LATENCY is
set in priv->flags. ASYNC_LOW_LATENCY is set by userspace via
TIOCSSERIAL, used by setserial(8), libftdi and certain tcsetattr
paths. The interaction with the existing sysfs latency_timer
attribute is surprising: once any of those tools has set the flag, a
later write of "16" (or any other value) to
/sys/bus/usb-serial/devices/ttyUSBx/latency_timer is silently
clamped to 1 and never reaches the chip.
The store path is the most explicit way userspace can ask for a
particular latency_timer value; treat it as authoritative. On an
explicit sysfs write, clear ASYNC_LOW_LATENCY before calling
write_latency_timer() so the requested value is what the chip
register actually receives. Emit a dev_info() so the override is
visible.
Reads continue to honour ASYNC_LOW_LATENCY (returning "1") so any
userspace that previously inspected the attribute to confirm
low-latency mode keeps working until it does its own explicit write.
Signed-off-by: Chinna Mopurigari Naveen Kumar Reddy <naveen.reddy@ftdichip.com>
---
drivers/usb/serial/ftdi_sio.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 7aaa7fc1be71..e7f13eca7ae6 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -1683,6 +1683,23 @@ static ssize_t latency_timer_store(struct device *dev,
if (kstrtou8(valbuf, 10, &v))
return -EINVAL;
+ /*
+ * An explicit sysfs write wins over the legacy ASYNC_LOW_LATENCY
+ * tty-flag override. Without this, if any userspace tool
+ * (setserial(8), libftdi, certain tcsetattr paths) had set
+ * ASYNC_LOW_LATENCY via TIOCSSERIAL, write_latency_timer() would
+ * silently clamp the chip register to 1 regardless of what was
+ * written to sysfs. Clearing the flag here makes sysfs the
+ * authoritative source so the next chip-side write uses exactly
+ * the value the caller asked for.
+ */
+ if (priv->flags & ASYNC_LOW_LATENCY) {
+ dev_info(&port->dev,
+ "explicit latency_timer=%u clears ASYNC_LOW_LATENCY flag\n",
+ v);
+ priv->flags &= ~ASYNC_LOW_LATENCY;
+ }
+
priv->latency = v;
rv = write_latency_timer(port);
if (rv < 0)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/2] USB: serial: ftdi_sio: retry transient errors on chip-side control transfers
From: Chinna Mopurigari Naveen Kumar Reddy @ 2026-06-22 9:43 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel, Arun Pappan
In-Reply-To: <cover.1782121274.git.naveen.reddy@ftdichip.com>
usb_control_msg() can return -ETIMEDOUT, -EPIPE or -EPROTO on a
functioning device when the host controller is momentarily unable to
complete the transfer. These are transient conditions that surface
under heavy USB bus load -- for example when several high-baud FTDI
channels share a busy host controller -- and a short retry generally
succeeds.
When such an error happens during a one-shot userspace operation such
as a sysfs write to /sys/bus/usb-serial/devices/ttyUSBx/latency_timer,
the write fails back to userspace with -EIO and the chip's per-channel
latency timer register is left unchanged, even though the device is
healthy and the next attempt would have worked.
Introduce a small helper, ftdi_send_request(), that wraps
usb_control_msg() with up to FTDI_CONTROL_RETRIES attempts on these
documented transient errno values, separated by
FTDI_CONTROL_RETRY_DELAY_MS. Non-transient errors are returned
immediately, as before. Each retry is logged with dev_warn() so the
underlying bus condition stays visible in dmesg.
Convert write_latency_timer() to use the helper. Only this site is
converted, as it is the one where a transient failure has a directly
userspace-visible effect; other chip-side control transfers are left
unchanged.
Signed-off-by: Chinna Mopurigari Naveen Kumar Reddy <naveen.reddy@ftdichip.com>
---
drivers/usb/serial/ftdi_sio.c | 48 ++++++++++++++++++++++++++++++-----
1 file changed, 41 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index af14548fa03d..7aaa7fc1be71 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -30,6 +30,7 @@
#include <linux/kernel.h>
#include <linux/errno.h>
#include <linux/slab.h>
+#include <linux/delay.h>
#include <linux/tty.h>
#include <linux/tty_driver.h>
#include <linux/tty_flip.h>
@@ -1363,10 +1364,46 @@ static int change_speed(struct tty_struct *tty, struct usb_serial_port *port)
return rv;
}
+/*
+ * Send a chip-side control request, retrying transient bus errors.
+ *
+ * On a healthy device, usb_control_msg() can still return -ETIMEDOUT,
+ * -EPIPE or -EPROTO when the host controller is under heavy load --
+ * for example multiple high-baud FTDI channels sharing a host
+ * controller with limited DMA-channel fairness. Failing a single
+ * one-shot configuration (e.g. a sysfs latency_timer write) to the
+ * caller as -EIO in that situation is unhelpful: the next attempt
+ * usually succeeds. Retry a small number of times before giving up.
+ */
+#define FTDI_CONTROL_RETRIES 3
+#define FTDI_CONTROL_RETRY_DELAY_MS 2
+
+static int ftdi_send_request(struct usb_serial_port *port, u8 request,
+ u8 requesttype, u16 value, u16 index)
+{
+ struct usb_device *udev = port->serial->dev;
+ int attempts;
+ int rv = -EIO;
+
+ for (attempts = 0; attempts < FTDI_CONTROL_RETRIES; ++attempts) {
+ rv = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+ request, requesttype, value, index,
+ NULL, 0, WDR_TIMEOUT);
+ if (rv >= 0)
+ return rv;
+ if (rv != -ETIMEDOUT && rv != -EPIPE && rv != -EPROTO)
+ return rv;
+ dev_warn(&port->dev,
+ "control msg req 0x%02x attempt %d returned %d, retrying\n",
+ request, attempts + 1, rv);
+ msleep(FTDI_CONTROL_RETRY_DELAY_MS);
+ }
+ return rv;
+}
+
static int write_latency_timer(struct usb_serial_port *port)
{
struct ftdi_private *priv = usb_get_serial_port_data(port);
- struct usb_device *udev = port->serial->dev;
int rv;
int l = priv->latency;
@@ -1378,12 +1415,9 @@ static int write_latency_timer(struct usb_serial_port *port)
dev_dbg(&port->dev, "%s: setting latency timer = %i\n", __func__, l);
- rv = usb_control_msg(udev,
- usb_sndctrlpipe(udev, 0),
- FTDI_SIO_SET_LATENCY_TIMER_REQUEST,
- FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE,
- l, priv->channel,
- NULL, 0, WDR_TIMEOUT);
+ rv = ftdi_send_request(port, FTDI_SIO_SET_LATENCY_TIMER_REQUEST,
+ FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE,
+ l, priv->channel);
if (rv < 0)
dev_err(&port->dev, "Unable to write latency timer: %i\n", rv);
return rv;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] USB: serial: ftdi_sio: latency_timer reliability fixes
From: Chinna Mopurigari Naveen Kumar Reddy @ 2026-06-22 9:43 UTC (permalink / raw)
To: Johan Hovold, Greg Kroah-Hartman; +Cc: linux-usb, linux-kernel, Arun Pappan
In-Reply-To: <cover.1781744946.git.naveen.reddy@ftdichip.com>
v2: Drop patches 1, 4, 5, 6 from v1 per Greg Kroah-Hartman's review.
Patches 1 and 6 used module parameters (urb_defer_timer_ns and
low_latency_defer_ns) to address DMA-channel starvation on a host
controller that does not enforce DMA-channel fairness. Greg correctly
pointed out that the host controller driver is the right place to fix
that, and that ftdi_sio should not carry per-driver workarounds for an
out-of-tree host controller deficiency. Those patches are dropped.
Patches 4 and 5 (per-port low_latency sysfs attribute and its
serialisation fix) depended on the hrtimer infrastructure introduced
by the dropped patch 1 and have no standalone purpose without it.
They are dropped too.
This v2 contains only the two patches that are independent correctness
fixes for ftdi_sio itself:
1. Retry transient errors (-ETIMEDOUT / -EPIPE / -EPROTO) on
chip-side control transfers so that a single transient USB hiccup
under bus load does not fail an otherwise-healthy one-shot
configuration (e.g. a latency_timer sysfs write) back to
userspace as -EIO.
2. Make an explicit sysfs write to latency_timer authoritative so
that a userspace write is not silently clamped to 1 by the
ASYNC_LOW_LATENCY tty flag left set by an earlier TIOCSSERIAL
(setserial(8), libftdi, certain tcsetattr paths).
Chinna Mopurigari Naveen Kumar Reddy (2):
USB: serial: ftdi_sio: retry transient errors on chip-side control
transfers
USB: serial: ftdi_sio: make explicit latency_timer sysfs write
authoritative
drivers/usb/serial/ftdi_sio.c | 65 +++++++++++++++++++++++++++++++----
1 file changed, 58 insertions(+), 7 deletions(-)
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
--
2.43.0
^ permalink raw reply
* RE: [PATCH 1/6] USB: serial: ftdi_sio: add configurable inter-batch defer for read URBs
From: Chinna Mopurigari Naveen Kumar Reddy (FTDI-SG) @ 2026-06-22 9:43 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Johan Hovold, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, Arun Pappan (FTDI-SG)
In-Reply-To: <2026062229-pesky-wasabi-ae9b@gregkh>
Hi Greg,
On Mon, Jun 22, 2026 at 05:28:00PM +0000, Greg Kroah-Hartman wrote:
> As this is an out-of-tree issue, there's nothing we can do in our
> in-tree drivers for that.
Understood, thanks Greg. I will drop the urb_defer_timer_ns patch and
the low_latency patches that depended on it, and take the host
controller starvation issue to the Raspberry Pi / BCM2835 USB folks
separately.
I will shortly post a v2 with just the two standalone ftdi_sio fixes
(transient control-transfer retry, and making an explicit latency_timer
sysfs write authoritative), which are independent of the host
controller issue.
Thanks,
Naveen
-----Original Message-----
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sent: Monday, 22 June 2026 5:28 pm
To: Chinna Mopurigari Naveen Kumar Reddy (FTDI-SG) <naveen.reddy@ftdichip.com>
Cc: Johan Hovold <johan@kernel.org>; linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; Arun Pappan (FTDI-SG) <arun.pappan@ftdichip.com>
Subject: Re: [PATCH 1/6] USB: serial: ftdi_sio: add configurable inter-batch defer for read URBs
On Mon, Jun 22, 2026 at 09:05:53AM +0000, Chinna Mopurigari Naveen Kumar Reddy (FTDI-SG) wrote:
> Hi Greg,
>
> On Mon, Jun 22, 2026 at 04:52:00PM +0000, Greg Kroah-Hartman wrote:
> > This is not the 1990's, module parameters should not be used anymore...
> > Why not just fix this at the root of the problem?
>
> Thank you for the review, Greg.
>
> You are right on both points.
>
> On the module parameter: I will switch to sysfs if the per-driver
> approach is accepted, or drop it entirely.
>
> On the location: your core point is well-taken. The DMA channel
> starvation is a BCM2835 DWC_OTG host controller deficiency, and the
> correct fix belongs in the host controller driver, not in each USB device driver.
> I will investigate fixing it there instead. If that is not feasible
> (the
> BCM2835 DWC_OTG is a vendor tree that Broadcom/RPi maintain outside
> mainline), I will report back before proposing any per-driver workaround.
As this is an out-of-tree issue, there's nothing we can do in our in-tree drivers for that. Please work with that team to either get their code merged properly upstream with us, where we can all work on the issue together, or just work with them out-of-tree.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v2 3/3] usb: typec: displayport: Check cable altmode support
From: Andrei Kuchynski @ 2026-06-22 9:39 UTC (permalink / raw)
To: Heikki Krogerus, Benson Leung, Jameson Thies
Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, Andrei Kuchynski
In-Reply-To: <20260622093910.1210089-1-akuchynski@chromium.org>
Update the probe function to utilize the new
typec_cable_altmode_unsupported() helper. If the cable doesn't support
DisplayPort altmode, don't initialize altmode_ops and prevent altmode
from being activated.
A captive cable shouldn't be checked; it may not provide discoverable
capability information, but it is inherently designed to support the
device's requirements.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
drivers/usb/typec/altmodes/displayport.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
index 263a89c5f3243..5ee33a69b9cf7 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -790,7 +790,6 @@ int dp_altmode_probe(struct typec_altmode *alt)
dp->alt = alt;
alt->desc = "DisplayPort";
- typec_altmode_set_ops(alt, &dp_altmode_ops);
if (plug) {
plug->desc = "Displayport";
@@ -811,6 +810,10 @@ int dp_altmode_probe(struct typec_altmode *alt)
if (plug)
typec_altmode_set_drvdata(plug, dp);
+ if ((alt->vdo & DP_CAP_RECEPTACLE) && typec_cable_altmode_unsupported(alt))
+ return 0;
+
+ typec_altmode_set_ops(alt, &dp_altmode_ops);
if (!alt->mode_selection) {
dp->state = plug ? DP_STATE_ENTER_PRIME : DP_STATE_ENTER;
schedule_work(&dp->work);
--
2.55.0.rc0.738.g0c8ab3ebcc-goog
^ permalink raw reply related
* [PATCH v2 2/3] usb: typec: thunderbolt: Check cable altmode support
From: Andrei Kuchynski @ 2026-06-22 9:39 UTC (permalink / raw)
To: Heikki Krogerus, Benson Leung, Jameson Thies
Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, Andrei Kuchynski
In-Reply-To: <20260622093910.1210089-1-akuchynski@chromium.org>
Update the probe function to utilize the new
typec_cable_altmode_unsupported() helper. If the cable doesn't support
Thunderbolt altmode, don't initialize altmode_ops and prevent altmode
from being activated.
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
---
drivers/usb/typec/altmodes/thunderbolt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/typec/altmodes/thunderbolt.c b/drivers/usb/typec/altmodes/thunderbolt.c
index 32250b94262a9..2eccdddf1b1f4 100644
--- a/drivers/usb/typec/altmodes/thunderbolt.c
+++ b/drivers/usb/typec/altmodes/thunderbolt.c
@@ -284,6 +284,10 @@ static int tbt_altmode_probe(struct typec_altmode *alt)
alt->desc = "Thunderbolt3";
typec_altmode_set_drvdata(alt, tbt);
+
+ if (typec_cable_altmode_unsupported(alt))
+ return 0;
+
typec_altmode_set_ops(alt, &tbt_altmode_ops);
if (!alt->mode_selection && tbt_ready(alt)) {
--
2.55.0.rc0.738.g0c8ab3ebcc-goog
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox