Refactor tcpm_fw_get_caps to support the multiple pd capabilities got
from fwnode. For backward compatibility, the original single capability
is still applicable. The fetched data is stored in the newly defined
structure "pd_data" and there is an array "pd_list" to store the
pointers to them. A dedicated array "pds" is used to store the handles
of the registered usb_power_delivery instances.

Also implement the .pd_get and .pd_set ops which are introduced in
commit a7cff92f ("usb: typec: USB Power Delivery helpers for ports
and partners"). Once the .pd_set is called, the current capability will
be updated and state machine will re-negotiate the power contract if
possible.
Signed-off-by: Kyle Tso <kyletso@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231216104630.2720818-3-kyletso@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 662a6010 ("usb: typec: Separate USB Power Delivery from USB
Type-C") allows userspace to configure the PD of a port by selecting
different set of predefined PD capabilities. Define the PD capability
sets in DT for better configurability in device modules.

Define an optional child node "capabilities" to contain multiple USB
Power Delivery capabilities.

Define child nodes with pattern (e.g. caps-0, caps-1) under
"capabilities". Each node contains PDO data of a selectable Power
Delivery capability.

Also define common properties for source-pdos, sink-pdos, and
op-sink-microwatt that can be referenced.
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20231205030114.1349089-2-kyletso@google.comSigned-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231216104630.2720818-2-kyletso@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The xhci retaining bogus hardware states cause usb disconnect devices
connected before hibernation(s4) and refer to the commit 'f3d47885
("usb: ohci-platform: fix usb disconnect issue after s4")' which set
flag "hibernated" as true when resume-from-hibernation and that the
drivers will reset the hardware to get rid of any existing state and
make sure resume from hibernation re-enumerates everything for xhci.
Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
Link: https://lore.kernel.org/r/20231228071113.1719-1-zhuyinbo@loongson.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently for dwc3_usb31 controller, if maximum_speed is limited to
super-speed in DT, then device mode is limited to SS, but host mode
still works in SSP.

The documentation for max-speed property is as follows:

"Tells USB controllers we want to work up to a certain speed.
Incase  this isn't passed via DT, USB controllers should default to
their maximum HW capability."

It doesn't specify that the property is only for device mode.
There are cases where we need to limit the host's maximum speed to
SuperSpeed only. Use this property for host mode to contrain host's
speed to SuperSpeed.
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20231219041559.15789-1-quic_kriskura@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Current implementation blocks the running operations when Plug-out and
Plug-In is performed continuously, process gets stuck in
dwc3_thread_interrupt().

Code Flow:

	CPU1

	->Gadget_start
	->dwc3_interrupt
	->dwc3_thread_interrupt
	->dwc3_process_event_buf
	->dwc3_process_event_entry
	->dwc3_endpoint_interrupt
	->dwc3_ep0_interrupt
	->dwc3_ep0_inspect_setup
	->dwc3_ep0_stall_and_restart

By this time if pending_list is not empty, it will get the next request
on the given list and calls dwc3_gadget_giveback which will unmap request
and call its complete() callback to notify upper layers that it has
completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET,
whereas it should be -ESHUTDOWN based on condition if not dwc->connected
is true.

Cc:  <stable@vger.kernel.org>
Fixes: d742220b ("usb: dwc3: ep0: giveback requests on stall_and_restart")
Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com>
Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A freezable kernel thread can enter frozen state during freezing by
either calling try_to_freeze() or using wait_event_freezable() and its
variants. So for the following snippet of code in a kernel thread loop:
  wait_event_interruptible_timeout();
  try_to_freeze();

We can change it to a simple wait_event_freezable_timeout() and
then eliminate a function call.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20231218074730.1898699-1-haokexin@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Current EP0 dequeue path will share the same as other EPs.  However, there
are some special considerations that need to be made for EP0 transfers:

  - EP0 transfers never transition into the started_list
  - EP0 only has one active request at a time

In case there is a vendor specific control message for a function over USB
FFS, then there is no guarantee on the timeline which the DATA/STATUS stage
is responded to.  While this occurs, any attempt to end transfers on
non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and
defer issuing of the end transfer command.  If the USB FFS application
decides to timeout the control transfer, or if USB FFS AIO path exits, the
USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request.

In case of the AIO exit path, the AIO FS blocks until all pending USB
requests utilizing the AIO path is completed.  However, since the dequeue
of ep0 req does not happen properly, all non-control EPs with the
DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will
be stuck waiting for the USB FFS data endpoints to receive a completion
callback.

Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0
is brought back to the SETUP state, and ensures that any deferred end
transfer commands are handled.  This also will end any active transfers
on EP0, compared to the previous implementation which directly called
giveback only.

Fixes: fcd2def6 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20231206201814.32664-1-quic_wcheng@quicinc.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Unlock before returning on the error path.

Fixes: 86b20af1 ("usb: yurex: Replace snprintf() with the safer scnprintf() variant")
Reported-by: Dan Carpenter <error27@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202312170252.3udgrIcP-lkp@intel.com/Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Link: https://lore.kernel.org/r/20231219063639.450994-1-harshit.m.mogalapalli@oracle.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The TPS6598x PD controller supports firmware updates that can be loaded
either from an external flash memory or a host using the device's I2C
host interface. This patch implements the second approach, which is
especially relevant if no flash memory is available.

In order to make patch bundle updates, a series of tasks (special
commands) must be sent to the device as it is documented in the
TPS65987DDH and TPS65988DH Host Interface Technical Reference Manual[1],
section 4.11 (Patch Bundle Update Tasks).

The update sequence is as follows:
1. PTCs - Start Patch Load Sequence: the proposed approach includes
   device and application configuration data.
2. PTCd - Patch Download: 64-byte data chunks must be sent until the end
   of the firmware file is reached (the last chunk may be shorter).
3. PTCc - Patch Data Transfer Complete: ends the patch loading sequence.

After this sequence and if no errors occurred, the device will change
its mode to 'APP' after SETUP_MS milliseconds, and then it will be ready
for normal operation.

[1] https://www.ti.com/lit/ug/slvubh2b/slvubh2b.pdf?ts=1697623299919&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTPS65987DSigned-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-4-f3cfcde6d890@wolfvision.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The input data passed to execute commands with tps6598x_exec_cmd()
is not supposed to be modified by the function. Moreover, this data is
passed to tps6598x_exec_cmd_tmo() and finally to tps6598x_block_write(),
which expects a const pointer.

The current implementation does not produce any bugs, but it discards
const qualifiers from the pointers passed as arguments. This leads to
compile issues if 'discarded-qualifiers' is active and a const pointer
is passed to the function, which is the case if data from a firmware
structure is passed to execute update commands. Adding the const
modifier to in_data prevents such issues and provides code consistency.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-3-f3cfcde6d890@wolfvision.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The firmware request process is device agnostic and can be used for
other parts.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-2-f3cfcde6d890@wolfvision.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The current implementation includes a number of special cases for the
tps25750. Nevertheless, init and reset functions can be generalized by
adding function pointers to the tipd_data structure in order to offer
that functionality to other parts without additional conditional
clauses.

Some functionality like the cold reset request (GAID) is shared by the
tps25750 and the tps6598x, so they can use the same reset function.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20231207-tps6598x_update-v2-1-f3cfcde6d890@wolfvision.netSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix spelling typo in comments.
Reported-by: k2ci <kernel-bot@kylinos.cn>
Signed-off-by: liyouhong <liyouhong@kylinos.cn>

Link: https://lore.kernel.org/r/20231221023425.1316397-1-liyouhong@kylinos.cnSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit e835c0a4.

Don't omit soft-reset. During initialization, the driver may need to
perform a soft reset to ensure the phy is ready when the controller
updates the GCTL.PRTCAPDIR or other settings by issuing phy soft-reset.
Many platforms often have access to DCTL register for soft-reset despite
being host-only. If there are actual reported issues from the platforms
that don't expose DCTL registers, then we will need to revisit (perhaps
to teach dwc3 to perform xhci's soft-reset USBCMD.HCRST).

Cc:  <stable@vger.kernel.org>
Fixes: e835c0a4 ("usb: dwc3: don't reset device side if dwc3 was configured as host-only")
Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/7668ab11a48f260820825274976eb41fec7f54d1.1703282469.git.Thinh.Nguyen@synopsys.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 8bea147d.

The phy soft reset GUSB2PHYCFG.PHYSOFTRST only applies to UTMI phy, not
ULPI. This fix is incomplete.

Cc:  <stable@vger.kernel.org>
Fixes: 8bea147d ("usb: dwc3: Soft reset phy on probe for host")
Reported-by: Köry Maincent <kory.maincent@bootlin.com>
Closes: https://lore.kernel.org/linux-usb/20231205151959.5236c231@kmaincent-XPS-13-7390Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/29a26593a60eba727de872a3e580a674807b3339.1703282469.git.Thinh.Nguyen@synopsys.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The DWC2 IP on the Rockchip SoCs doesn't support clock gating.
When a clock gating is enabled, system hangs.
Signed-off-by: William Wu <william.wu@rock-chips.com>
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Link: https://lore.kernel.org/r/1703575199-23638-1-git-send-email-william.wu@rock-chips.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit b17b7fe6.

That commit messed up the reference counting, so it needs to
be rethought.

Fixes: b17b7fe6 ("usb: typec: class: fix typec_altmode_put_partner to put plugs")
Cc:  <stable@vger.kernel.org>
Cc: RD Babiera <rdbabiera@google.com>
Reported-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Closes: https://lore.kernel.org/lkml/CAP-bSRb3SXpgo_BEdqZB-p1K5625fMegRZ17ZkPE1J8ZYgEHDg@mail.gmail.com/Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20240102091142.2136472-1-heikki.krogerus@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'thunderbolt-for-v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into char-misc-next

Mika writes:

thunderbolt: Changes for v6.8 merge window

This includes following USB4/Thunderbolt changes for the v6.8 merge
window:

  - Intel Lunar Lake support
  - PCIe tunneling improvements
  - DisplayPort tunneling improvements
  - Asymmetric switching improvements
  - Couple of minor fixes and cleanups.

All these have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Reduce retry timeout to speed up boot for some devices
  thunderbolt: Keep link as asymmetric if preferred by hardware
  thunderbolt: Add support for Intel Lunar Lake
  thunderbolt: Disable PCIe extended encapsulation upon teardown properly
  thunderbolt: Make PCIe tunnel setup and teardown follow CM guide
  thunderbolt: Improve logging when DisplayPort resource is added due to hotplug
  thunderbolt: Use tb_dp_read_cap() to read DP_COMMON_CAP as well
  thunderbolt: Disable CL states only when actually needed
  thunderbolt: Transition link to asymmetric only when both sides support it
  thunderbolt: Log XDomain link speed and width
  thunderbolt: Move width_name() helper to tb.h
  thunderbolt: Handle lane bonding of Gen 4 XDomain links properly
  thunderbolt: Unwind TMU configuration if tb_switch_set_tmu_mode_params() fails
  thunderbolt: Remove duplicated re-assignment of pointer 'out'

Remove the @removable: line to prevent the kernel-doc warning:

include/linux/usb.h:732: warning: Excess struct member 'removable' description in 'usb_device'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Link: https://lore.kernel.org/r/20231223050636.14022-1-rdunlap@infradead.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a followup to "thunderbolt: Workaround an IOMMU fault on certain
systems with Intel Maple Ridge".

It seems like the timeout can be reduced to 250ms. This reduces the overall
delay caused by the retires to ~1s. This is about the time other things
being initialized in parallel need anyway*, so like this the effective boot
time is no longer compromised.

*I only had a single device available for my measurements: A Clevo X170KM-G
desktop replacement notebook.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

In case of the link is brought up as asymmetric (due to hardware preference), we
honor that and don't transition it to symmetric, unless a router with symmetric
link got plugged below, in the topology (and a bandwidth allows transition to
symmetric).
Signed-off-by: Gil Fine <gil.fine@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Now that the driver core can properly handle constant struct bus_type,
move the tb_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.

Cc: Andreas Noever <andreas.noever@gmail.com>
Cc: Michael Jamet <michael.jamet@intel.com>
Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
Cc:  <linux-usb@vger.kernel.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/2023121904-utopia-broadcast-06d1@gregkhSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some of the boards supported by the TCPM drivers can support USB-C
Accessory Modes (Analog Audio, Debug). Parse information about supported
modes from the device tree.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231215173005.313422-3-dmitry.baryshkov@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add description of the USB-C Accessory Modes supported on the particular
USB-C connector. This is required for devices like Qualcomm SM8150-HDK,
which have no other way to express accessory modes supported by the
hardware platform.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20231215173005.313422-2-dmitry.baryshkov@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

During device enumeration usb core resets endpoint 0 if the max packet
size value differs from the one read from the device descriptor.

usb core will additionally reset endpoint 0 during S4 resume, before
re-enumerating the device, if the device has a reset-resume flag set.

In this case the xhci device representation vdev may be lost due to
xHC restore error and re-initialization during S4 resume.

Make sure slot_id and vdev are valid before trying to re-configure max
packet size during endpoint 0 reset.
max packet size will be re-configured later during re-enumeration.

This fixes commit e34900f4 ("xhci: Reconfigure endpoint 0 max packet
size only during endpoint reset") which is currently in usb-next,
on its way to 6.8

Fixes: e34900f4 ("xhci: Reconfigure endpoint 0 max packet size only during endpoint reset")
Tested-by: Wendy Wang <wendy.wang@intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20231215125707.1732989-2-mathias.nyman@linux.intel.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dwc3_imx8mp_pm_resume() warn: 'dwc3_imx->suspend_clk'
from clk_prepare_enable() not released
Signed-off-by: Himanshu Bhavani <himanshu.bhavani@siliconsignals.io>

Link: https://lore.kernel.org/r/20231215143458.158810-1-himanshu.bhavani@siliconsignals.ioSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 588b9e85 ("usb: gadget: uvc: add v4l2 enumeration api calls")
has rendered the precomposed (aka legacy) webcam gadget unloadable.

uvc_alloc() since then has depended on certain config groups being
available in configfs tree related to the UVC function. However, legacy
gadgets do not create anything in configfs, so uvc_alloc() must fail
with -ENOENT no matter what.

This patch mimics the required configfs hierarchy to satisfy the code which
inspects formats and frames found in uvcg_streaming_header.

This has been tested with guvcview on the host side, using vivid as a
source of video stream on the device side and using the userspace program
found at https://gitlab.freedesktop.org/camera/uvc-gadget.git.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
Fixes: 588b9e85 ("usb: gadget: uvc: add v4l2 enumeration api calls")
Link: https://lore.kernel.org/r/20231215131614.29132-1-andrzej.p@collabora.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add X1E80100 to the DT schema.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231214-x1e80100-usb-v1-1-c22be5c0109e@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixed one typo.
Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
Link: https://lore.kernel.org/r/20231215083930.566164-1-ghanshyam1898@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Create an error message or upon deferral add a description for sysfs.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20231214144011.1987586-1-alexander.stein@ew.tq-group.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When compiling with gcc version 14.0.0 20231206 (experimental)
and CONFIG_FORTIFY_SOURCE=y, I've noticed the following warning:

...
In function 'fortify_memcpy_chk',
    inlined from '__ffs_func_bind_do_os_desc' at drivers/usb/gadget/function/f_fs.c:2934:3:
./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field'
declared with attribute warning: detected read beyond size of field (2nd parameter);
maybe use struct_group()? [-Wattribute-warning]
  588 |                         __read_overflow2_field(q_size_field, size);
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This call to 'memcpy()' is interpreted as an attempt to copy both
'CompatibleID' and 'SubCompatibleID' of 'struct usb_ext_compat_desc'
from an address of the first one, which causes an overread warning.
Since we actually want to copy both of them at once, use the
convenient 'struct_group()' and 'sizeof_field()' here.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru>
Link: https://lore.kernel.org/r/20231214090428.27292-1-dmantipov@yandex.ruSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since snprintf() has the documented, but still rather strange trait of
returning the length of the data that *would have been* written to the
array if space were available, rather than the arguably more useful
length of data *actually* written, it is usually considered wise to use
something else instead in order to avoid confusion.

In the case of sysfs call-backs, new wrappers exist that do just that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc:  <usb-storage@lists.one-eyed-alien.net>
Signed-off-by: Lee Jones <lee@kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20231213164246.1021885-13-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Since snprintf() has the documented, but still rather strange trait of
returning the length of the data that *would have been* written to the
array if space were available, rather than the arguably more useful
length of data *actually* written, it is usually considered wise to use
something else instead in order to avoid confusion.

In the case of sysfs call-backs, new wrappers exist that do just that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Hema HK <hemahk@ti.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-12-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-11-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-10-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Whilst we're at it, let's define some magic numbers to increase
readability and ease of maintenance.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc:  <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-8-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Pawel Laszczak <pawell@cadence.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-7-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Cristian Birsan <cristian.birsan@microchip.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Cc:  <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20231213164246.1021885-6-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf()
returns the length of the data *actually* encoded into the destination
array.  However, as per the C99 standard {v}snprintf() really returns
the length of the data that *would have been* written if there were
enough space for it.  This misunderstanding has led to buffer-overruns
in the past.  It's generally considered safer to use the {v}scnprintf()
variants in their place (or even sprintf() in simple cases).  So let's
do that.

Link: https://lwn.net/Articles/69419/
Link: https://github.com/KSPP/linux/issues/105
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Daniel Scally <dan.scally@ideasonboard.com>
Cc: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://lore.kernel.org/r/20231213164246.1021885-5-lee@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>