- 27 May, 2021 4 commits
-
-
Heikki Krogerus authored
The additional boolean device property "orientation-switch" is not needed when the connection is described with device graph, so removing the check and the requirement for it. Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210526153548.61276-3-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Heikki Krogerus authored
Both the USB Type-C switch and mux have already a device type defined for them. We can use those types instead of the device name to differentiate the two. Reviewed-by:
-
Chunfeng Yun authored
Use usb_role_string() to print role status, make the log readable. Signed-off-by:
Chunfeng Yun <chunfeng.yun@mediatek.com> Link: https://lore.kernel.org/r/1621932786-9335-2-git-send-email-chunfeng.yun@mediatek.comSigned-off-by:
-
Chunfeng Yun authored
Introduces usb_role_string() function, which returns a human-readable name of provided usb role, it's useful to make the log readable. Reviewed-by:
-
- 24 May, 2021 4 commits
-
-
Wei Yongjun authored
The sparse tool complains as follows: drivers/usb/typec/tcpm/tcpci.c:118:5: warning: symbol 'tcpci_apply_rc' was not declared. Should it be static? This symbol is not used outside of tcpci.c, so marks it static. Fixes: 7257fbc7 ("usb: typec: tcpci: Implement callback for apply_rc") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20210524133704.2432555-1-weiyongjun1@huawei.comSigned-off-by:
-
Andy Shevchenko authored
The driver is using open-coded variant of of_find_i2c_device_by_node(). Replace it by the actual call to the above mentioned API. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210521145243.87911-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Geoffrey D. Bennett authored
usb_sndctrlpipe() is evaluated in do_proc_control(), saved in a variable, then evaluated again. Use the saved variable instead, to match the use of usb_rcvctrlpipe(). Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Geoffrey D. Bennett <g@b4.vu> Link: https://lore.kernel.org/r/20210521174027.GA116484@m.b4.vuSigned-off-by:
-
Aditya Srivastava authored
The opening comment mark '/**' is used for highlighting the beginning of kernel-doc comments. The header for drivers/usb/gadget/udc/trace files follows this syntax, but the content inside does not comply with kernel-doc. This line was probably not meant for kernel-doc parsing, but is parsed due to the presence of kernel-doc like comment syntax(i.e, '/**'), which causes unexpected warning from kernel-doc. For e.g., running scripts/kernel-doc -none drivers/usb/gadget/udc/trace.h emits: warning: expecting prototype for udc.c(). Prototype was for TRACE_SYSTEM() instead Provide a simple fix by replacing this occurrence with general comment format, i.e. '/*', to prevent kernel-doc from parsing it. Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Aditya Srivastava <yashsri421@gmail.com> Link: https://lore.kernel.org/r/20210522115227.9977-1-yashsri421@gmail.comSigned-off-by:
-
- 22 May, 2021 1 commit
-
-
Alan Stern authored
When a control URB is submitted, the direction indicated by URB's pipe member is supposed to match the direction indicated by the setup packet's bRequestType member. A mismatch could lead to trouble, depending on which field the host controller drivers use for determining the actual direction. This shouldn't ever happen; it would represent a careless bug in a kernel driver somewhere. This patch adds a dev_WARN_ONCE to let people know about the potential problem. Suggested-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
- 21 May, 2021 31 commits
-
-
Badhri Jagan Sridharan authored
APPLY RC is defined as ROLE_CONTROL.CC1 != ROLE_CONTROL.CC2 and POWER_CONTROL.AutodischargeDisconnect is 0. When ROLE_CONTROL.CC1 == ROLE_CONTROL.CC2, set the other CC to OPEN. Fixes: f321a02c ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support") Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20210517192112.40934-4-badhri@google.comSigned-off-by:
-
Badhri Jagan Sridharan authored
When vbus auto discharge is enabled, TCPCI based TCPC transitions into Attached.SNK/Attached.SRC state. During PR_SWAP, TCPCI based TCPC would disconnect when partner changes power roles. TCPC has to be moved APPLY RC state during PR_SWAP. This is done by ROLE_CONTROL.CC1 != ROLE_CONTROL.CC2 and POWER_CONTROL.AutodischargeDisconnect is 0. Once the swap sequence is done, AutoDischargeDisconnect is re-enabled. Fixes: f321a02c ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support") Reviewed-by:
-
Badhri Jagan Sridharan authored
The logic to enable vbus auto discharge on disconnect is used in more than one place. Since this is repetitive code, moving this into its own method. Fixes: f321a02c ("usb: typec: tcpm: Implement enabling Auto Discharge disconnect support") Reviewed-by:
-
Badhri Jagan Sridharan authored
During PR_SWAP, When TCPM is in PR_SWAP_SNK_SRC_SINK_OFF, vbus is expected to reach VSAFE0V when source turns off vbus. Do not move to SNK_UNATTACHED state when this happens. Fixes: 28b43d3d ("usb: typec: tcpm: Introduce vsafe0v for vbus") Reviewed-by:
-
Tobias Schramm authored
The USB controller in the RK3308 is compatible with the RK3066 USB controller. This patch adds a compatible string for it. Signed-off-by:
Tobias Schramm <t.schramm@manjaro.org> Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210514150044.2099298-4-t.schramm@manjaro.orgSigned-off-by:
-
Johan Hovold authored
There's no need to initialise irq-flags variables before saving the interrupt state. Drop the redundant initialisations from drivers that got this wrong. Cc: Li Yang <leoyang.li@nxp.com> Cc: Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Johan Hovold authored
There's no need to initialise irq-flags variables before saving the interrupt state. While at it drop two redundant return-value initialisations from two of the functions that got it wrong. Cc: Minas Harutyunyan <hminas@synopsys.com> Signed-off-by:
-
Johan Hovold authored
There's no need to initialise irq-flags variables before saving the interrupt state. Cc: Pawel Laszczak <pawell@cadence.com> Signed-off-by:
-
Jon Hunter authored
Rather than testing if the error code is -EPROBE_DEFER before printing an error message, use dev_err_probe() instead to simplify the code. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20210519163553.212682-2-jonathanh@nvidia.comSigned-off-by:
-
Jon Hunter authored
The Tegra XUDC driver prints the following error when deferring probe if the USB PHY is not found ... ERR KERN tegra-xudc 3550000.usb: failed to get usbphy-0: -517 Deferring probe can be normal and so update to driver to avoid printing this error if probe is being deferred. Signed-off-by:
-
zuoqilin authored
Change 'contol' to 'control'. Signed-off-by:
zuoqilin <zuoqilin@yulong.com> Link: https://lore.kernel.org/r/20210521095804.773-1-zuoqilin1@163.comSigned-off-by:
-
Rui Miguel Silva authored
Besides the already host mode support add peripheral mode support for the isp1763 IP from the isp1760 family. Signed-off-by:
Rui Miguel Silva <rui.silva@linaro.org> Link: https://lore.kernel.org/r/20210513084717.2487366-10-rui.silva@linaro.orgSigned-off-by:
-
Rui Miguel Silva authored
The nxp,isp1760 driver is old in the tree, but did not had a bindings entry, since I am extend it to support isp1763 in the same family, use this to add a proper yaml bindings file. Reviewed-by:
-
Rui Miguel Silva authored
isp1763 have some differences from the isp1760, 8 bit address for registers and 16 bit for values, no bulk access to memory addresses, 16 PTD's instead of 32. Following the regmap work done before add the registers, memory access and add the functions to support differences in setup sequences. Signed-off-by:
-
Rui Miguel Silva authored
There is already a binding to describe the dual role mode (dr_mode), use that instead of defining a new one (port1-otg). Update driver code and devicetree files that use that port1-otg binding. Signed-off-by:
-
Rui Miguel Silva authored
In preparation to support other family member IP, which may have different memory layout. Drop macros and setup a configuration struct. Signed-off-by:
-
Rui Miguel Silva authored
Since the removal of the Blackfin port with: commit 4ba66a97 ("arch: remove blackfin port") No one is using or referencing this header and platform data struct. Remove them. Signed-off-by:
-
Rui Miguel Silva authored
Use io relaxed access memory primitives to satisfy strict type checking (__force). This will fix some existing sparse warnings: sparse: warning: cast to restricted __le32 Signed-off-by:
-
Rui Miguel Silva authored
Rework access to registers and memory to use regmap framework. No change in current feature or way of work is intended with this change. This will allow to reuse this driver with other IP of this family, for example isp1763, with little changes and effort. Signed-off-by:
-
Rui Miguel Silva authored
There are a lot of pre-existing typechecking warnings around the access and assign of elements of ptd structure of __dw type. sparse: warning: invalid assignment: |= sparse: left side has type restricted __dw sparse: right side has type unsigned int or warning: restricted __dw degrades to integer or sparse: warning: incorrect type in assignment (different base types) sparse: expected restricted __dw [usertype] dw4 sparse: got unsigned int [assigned] [usertype] usof To handle this, annotate conversions along the {TO,FROM}_DW* macros and some assignments and function arguments. This clean up completely all sparse warnings for this driver. Signed-off-by: -
Zhen Lei authored
Fix some spelling mistakes in comments: trasfer ==> transfer consumtion ==> consumption endoint ==> endpoint sharable ==> shareable contraints ==> constraints Auxilary ==> Auxiliary correspondig ==> corresponding interupt ==> interrupt inifinite ==> infinite assignement ==> assignment Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210517094020.7310-1-thunder.leizhen@huawei.comSigned-off-by:
-
Chunfeng Yun authored
Use dev_err_probe() to print debug or error message depending on whether the error value is -DPROBE_DEFER or not. Signed-off-by:
-
Chunfeng Yun authored
When power on system with OTG cable, IDDIG's interrupt arises before the charger registration, it will cause a NULL pointer dereference, fix the issue by registering the power supply before requesting IDDIG/VBUS irq. Signed-off-by:
-
Andre Przywara authored
The H616 has four PHYs as the H3, along with their respective clock gates and resets, so the property description is identical. However the PHYs itself need some special bits, so we need a new compatible string for it. Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Acked-by:
-
Andre Przywara authored
The H616 MUSB peripheral is compatible to the H3 one (8 endpoints). Signed-off-by:
Maxime Ripard <mripard@kernel.org> Acked-by:
-
Tony Lindgren authored
On start-up, we can get a spurious session request interrupt with nothing connected. After that the devctl session bit will silently clear, but the musb hardware is never idled until a cable is plugged in, or the glue layer module is reloaded. Let's just check the session bit again in 3 seconds in peripheral mode to catch the issue. Signed-off-by:
Tony Lindgren <tony@atomide.com> Link: https://lore.kernel.org/r/20210518150615.53464-1-tony@atomide.comSigned-off-by:
-
Tony Lindgren authored
Looks like we are missing suspend and resume functions for pm_ops that are needed to idle the hardware for system suspend for 2430 glue layer. We can rely on the driver internal PM runtime state, and call driver functions to idle the hardware on suspend if needed. There is no need to add a dependency to PM runtime for system suspend here. Signed-off-by:
-
Chris Chiu authored
This reverts commit ca91fd8c ("USB: Add reset-resume quirk for WD19's Realtek Hub"). The previous patch in the series now handles the problematic hubs by checking the port status and handling it accordingly when PORT_SUSPEND timeout occurs. We don't need to use reset-resume all the time. Acked-by:
Chris Chiu <chris.chiu@canonical.com> Link: https://lore.kernel.org/r/20210514045405.5261-3-chris.chiu@canonical.comSigned-off-by:
-
Chris Chiu authored
On the Realtek high-speed Hub(0bda:5487), the port which has wakeup enabled_descendants will sometimes timeout when setting PORT_SUSPEND feature. After checking the PORT_SUSPEND bit in wPortStatus, it is already set which means the port has been suspended. We should treat it suspended to make sure it will be resumed correctly. Acked-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worse scenario, could lead to heap overflows. This code was detected with the help of Coccinelle and, audited and fixed manually. Acked-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20210513193353.GA196565@embeddedorSigned-off-by:
-
Rikard Falkeborn authored
Constify a couple of ops-structs that are never modified, to let the compiler put them in read-only memory. Acked-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Link: https://lore.kernel.org/r/20210513200908.448351-1-rikard.falkeborn@gmail.comSigned-off-by:
-
