- 05 Feb, 2021 2 commits
-
-
Heikki Krogerus authored
At the moment the function device_del() is calling device_remove_properties() unconditionally. That will result into the reference count of the software node attached to the device being decremented, and in most cases it will hit 0 at that point. So in practice device_del() will unregister the software node attached to the device, even if that was not the intention of the caller. Right now software nodes can not be reused or shared because of that. So device_del() can not unregister the software nodes unconditionally like that. Unfortunately some of the users of device_add_properties() are now relying on this behaviour. Because of that, and also in general, we do need a function that can offer similar behaviour where the lifetime of the software node is bound to the lifetime of the device. But it just has to be a separate function so the behaviour is optional. We can not remove the device_remove_properties() call from device_del() before we have that new function, and before we have replaced device_add_properties() calls with it in all the places that require that behaviour. This adds function device_create_managed_software_node() that can be used for exactly that purpose. Software nodes created with it are declared "managed", and separate handling for those nodes is added to the software node code. The reference count of the "managed" nodes is decremented when the device they are attached to is removed. This will not affect the other nodes that are not declared "managed". The function device_create_managed_software_node() has also one additional feature that device_add_properties() does not have. It allows the software nodes created with it to be part of a node hierarchy by taking also an optional parent node as parameter. Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210204141711.53775-2-heikki.krogerus@linux.intel.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Greg Kroah-Hartman authored
Merge tag 'tag-ib-usb-typec-chrome-platform-cros-ec-typec-clear-pd-discovery-events-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux into usb-next Benson writes: clear-pd-discovery-events This pair of patches fixes an issue where cros_ec_typec creates stale cable nodes on detach because of uncleared pd discovery status events. * tag 'tag-ib-usb-typec-chrome-platform-cros-ec-typec-clear-pd-discovery-events-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_typec: Clear Type C disc events platform/chrome: cros_ec: Import Type C control command
-
- 04 Feb, 2021 6 commits
-
-
Prashant Malani authored
Clear USB Type C discovery events from the Chrome EC once they've been successfully handled. Signed-off-by:
Prashant Malani <pmalani@chromium.org> Reported-by:
Benson Leung <bleung@chromium.org> Tested-by:
-
Prashant Malani authored
This command is used to communicate with the Chrome Embedded Controller (EC) regarding USB Type C events and state. These header updates are included in the latest Chrome OS EC headers [1] [1] https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/main/include/ec_commands.hSigned-off-by:
-
Heikki Krogerus authored
What platform_device_add_properties() does is it allocates dynamically a software node that will contain the device properties supplied to it, and then couples that node with the device. If the properties are constant, the node can be constant as well. Signed-off-by:
-
Heikki Krogerus authored
What platform_device_add_properties() does is it allocates dynamically a software node that will contain the device properties supplied to it, and then couples that node with the device. Since that node is always created, it might as well be constant. Signed-off-by:
-
Heikki Krogerus authored
The function dwc2_pci_quirks() does nothing. Removing. Signed-off-by:
-
Kyle Tso authored
Reland VDO definitions of PD Revision 2.0 as they are still used in PD2.0 products. Fixes: 0e1d6f55 ("usb: pd: Update VDO definitions") Signed-off-by:
Kyle Tso <kyletso@google.com> Link: https://lore.kernel.org/r/20210204005036.1555294-1-kyletso@google.comSigned-off-by:
-
- 03 Feb, 2021 4 commits
-
-
Bhaskar Chowdhury authored
s/descibe/describe/ Acked-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210203153414.17044-1-unixbhaskar@gmail.comSigned-off-by:
-
Rob Herring authored
The generic OHCI binding needs to document all the specific compatible strings so we can track undocumented compatible strings. Add all the compatible strings from in tree users. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Acked-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20210202175439.3904060-2-robh@kernel.orgSigned-off-by:
-
Rob Herring authored
The generic EHCI binding needs to document all the specific compatible strings so we can track undocumented compatible strings. Add all the compatible strings from in tree users. Turns out we also have the generic 'usb-ehci' compatible which is pretty much the same binding and the correct one for the example, so let's add it. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by:
-
Kyle Tso authored
"PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10" introduces several changes regarding the ID Header VDO and the Product Type VDOs. Signed-off-by:
-
- 02 Feb, 2021 12 commits
-
-
Benson Leung authored
typec_partner_set_pd_revision returns void now. Fixes: cefc011f ("platform/chrome: cros_ec_typec: Set Partner PD revision from status") Signed-off-by:
-
Kyle Tso authored
typec_partner_set_pd_revision doesn't need any return value. Fixes: 29b01295 ("usb: typec: Add typec_partner_set_pd_revision") Reviewed-by:
-
Badhri Jagan Sridharan authored
Configure USB switches when partner is USB Communication capable. The is enabled USB data communication over D+/D- pins. Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Badhri Jagan Sridharan <badhri@google.com> Link: https://lore.kernel.org/r/20210202003101.221145-3-badhri@google.comSigned-off-by:
-
Badhri Jagan Sridharan authored
The USB Communications Capable bit indicates if port partner is capable of communication over the USB data lines (e.g. D+/- or SS Tx/Rx). TCPM passes this information for chip specific operations. Reviewed-by:
-
Badhri Jagan Sridharan authored
The USB Communications Capable bit indicates if port partner is capable of communication over the USB data lines (e.g. D+/- or SS Tx/Rx). Notify the status of the bit to low level drivers to perform chip specific operation. For instance, low level driver enables USB switches on D+/D- lines to set up data path when the bit is set. Refactored from patch initially authored by Kyle Tso <kyletso@google.com> Reviewed-by:
-
Badhri Jagan Sridharan authored
Receiving the first packet in an AMS sequence signals the beginning of AMS. Set in_ams flag to true when SRC_CAPS are received during POWER_NEGOTIATION AMS. This fixes the failure flagged while running TD.PD.SNK.E9 compliance test. >From Deterministic PD compliance MOI spec: TD.PD.SNK.E9. GetSinkCap in Place of Accept Description: As Provider, the Tester intentionally sends a GetSinkCap message in place of Accept message and verifies the UUT will send a SoftReset and recover from the error. Steps: a) Run PROC.PD.E1 Bring-up according to the UUT role. b) The Tester cycles VBus. c) The Tester sends a Source Capabilities message to the UUT. d) Upon receipt of a Request message from the UUT, the Tester replies with a GoodCRC message. e) The Tester sends a GetSinkCap message to the UUT. f) If a SoftReset is not received within 15 ms after the GetSinkCap EOP was sent, the test fails. g) If a SoftReset is received timely, the Tester replies with an Accept message. h) The Tester sends Source Capabilities message to the UUT repeatedly until nCapsCount reached or a GoodCRC is received. If nCapsCount reached, the test fails. i) If a Request is not received timely within 30 ms after the GoodCRC EOP corresponding to Source Capabilities message was received, the test fails. Reviewed-by:
-
Badhri Jagan Sridharan authored
While in source mode, vbus could be shutoff by protections circuits. TCPM does not move back to toggling state to re-initiate connection. Fix this by moving to SRC_UNATTACHED state when vbus shuts off while in source mode. Reviewed-by:
-
Greg Kroah-Hartman authored
Merge tag 'tag-ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux into usb-next Benson writes: cros-ec-typec changes for usb for v5.12 Chrome OS EC Type-C driver features implemented this round: * Registration of cable plug information * Support for SOP' plug registration and altmodes * Support for reporting number of altmodes supported by partners and plugs * Send mux configuration ack to EC via a new host command * Reporting SOP' and Partner PD revisions * tag 'tag-ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux: platform/chrome: cros_ec_typec: Set opmode to PD on SOP connected platform/chrome: cros_ec_typec: Set Partner PD revision from status platform/chrome: cros_ec_typec: Report SOP' PD revision from status platform/chrome: cros_ec_typec: Send mux configuration acknowledgment to EC platform/chrome: cros_ec_typec: Parameterize cros_typec_cmds_supported() platform/chrome: cros_ec_typec: Register plug altmodes platform/chrome: cros_ec_typec: Register SOP' cable plug platform/chrome: cros_ec_typec: Set partner num_altmodes platform/chrome: cros_ec_typec: Store cable plug type platform/chrome: cros_ec_typec: Register cable platform/chrome: cros_ec_typec: Rename discovery struct platform/chrome: cros_ec_typec: Factor out PD identity parsing platform/chrome: cros_ec_typec: Make disc_done flag partner-only
-
Benson Leung authored
When SOP Discovery is done, set the opmode to PD if status indicates SOP is connected. SOP connected indicates a PD contract is in place, and is a solid indication we have transitioned to PD power negotiation, either as source or sink. Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
-
Benson Leung authored
Status provides sop_revision. Process it, and set it using the new setter in the typec class. Signed-off-by:
Prashant Malani <pmalani@chomium.org> Link: https://lore.kernel.org/r/20210129061406.2680146-6-bleung@chromium.orgSigned-off-by:
-
Benson Leung authored
cros_typec_handle_sop_prime_disc now takes the PD revision provided by the EC_CMD_TYPEC_STATUS command response for the SOP'. Attach the properly formatted pd_revision to the cable desc before registering the cable. Signed-off-by:
-
Benson Leung authored
Merge remote-tracking branch 'origin/cros-ec-typec-for-5.12' into ib-usb-typec-chrome-platform-cros-ec-typec-changes-for-5.12
-
- 01 Feb, 2021 3 commits
-
-
Benson Leung authored
The partner's PD revision may be resolved later than the port partner registration since the port partner creation may take place once Type-C detects the port has changed state, but before PD communication is completed. Add a setter so that the partner's PD revision can be attached to it once it becomes available. If the revision is set to a valid version (not 0), the setter will also refresh the partner's usb_pd flag and notify on "supports_usb_power_delivery" sysfs property as well. Reviewed-by:
-
Benson Leung authored
The USB Power Delivery specification Section 6.2.1.1.5 outlines revision backward compatibility requirements starting from Revision 3.0. The Port, the Cable Plug, and the Port Partner may support either revision 2 or revision 3 independently, and communication between ports, partners, and cables of different revisions are allowed under rules that the parties agree to communicate between each other using the lowest common operating revision. This may mean that Port-to-Partner operating revision comms may be different than Port-to-CablePlug operating revision comms. For example, it is possible for a R3.0 port to communicate with a R3.0 partner using R3.0 messages, while the R3.0 port (in the same session) must communicate with the R2.0 cable using R2.0 messages only. Introduce individual revision number properties for cable and port partner so that the port can track them independently. Reviewed-by:
-
Benson Leung authored
The Type-C Revision was in a specific BCD format "0120H" for 1.2. USB PD revision numbers follow a similar pattern with "0300H" for 3.0. Standardizes the sysfs format for usb_power_delivery_revision to align with the BCD format used for usb_typec_revision. Example values: - "2.0": USB Power Delivery Release 2.0 - "3.0": USB Power Delivery Release 3.0 - "3.1": USB Power Delivery Release 3.1 Reviewed-by:
-
- 29 Jan, 2021 13 commits
-
-
Mathias Nyman authored
If we receive a transfer event indicating that an endpoint should be halted, but current endpoint state doesn't match it, then the halt might be just resolved by the stop endpoint completion handler that detects the halted endpoint due to a context state error. In this case the TD we halted on is already moved to the cancelled TD list, and should not be successfully completed and given back anymore. Let the stop endpoint completion handler reset the endpoint, and then let the reset endpoint handler give back the cancelled TD among all other ones on the cancelled TD list Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20210129130044.206855-28-mathias.nyman@linux.intel.comSigned-off-by:
-
Mathias Nyman authored
A halted endpoint can be detected both when transfer events complete, and in stop endpoint command completion. Both these handlers will start clearing up the halted endpoint and queue a reset endpoint command. It's possible to get both events for the same halted endpoint if right after a URB cancel queues a stop endpoint command the endpoint stalls. Use the EP_HALTED flag to prevent resetting the endpoint twice. Signed-off-by:
-
Mathias Nyman authored
xhci_find_new_dequeue_state() and xhci_queue_new_dequeue_state() are no longer used afer introducing the move_dequeue_past_td() function. also remove struct xhci_dequeue_state as its no longer used. Signed-off-by:
-
Mathias Nyman authored
Replace xhci_find_new_dequeue_state() and xhci_queue_new_dequeue_state() functions with one combined function. These function were always called after each other, and had a lot of extra code just to pass the newly found dequeue state from the first function to the other. The new function also returns error in case there is a failure to queue the new dequeue state. This way the caller can decide on recovery measures to handle it. Signed-off-by:
-
Mathias Nyman authored
Handle race where a stop endpoint command fails with "context state error" as hardware hasn't actually started the ring yet after a previous urb cancellation completed and restarted the endpoint. Flushing the doorbell write that restart the endpoint reduced these cases, but didn't completely resolve them. Check if the ring is running in the stop endpoint completion handler, and issue a new stop endpoint command in this case. Signed-off-by:
-
Mathias Nyman authored
xhci 4.6.9: "A busy endpoint may asynchronously transition from the Running to the Halted or Error state due to error conditions detected while processing TRBs. A possible race condition may occur if software, thinking an endpoint is in the running state, issues a Stop Endpoint Command, however at the same time the xHC asynchronously transitions the endpoint to the Halted or Error state. In this case, a Context State Error may be generated for the command completion. Software may verify that this case occurred by inspecting the EP State for Halted or Error when a Stop Endpoint Command results in a Context State Error." Halted endpoints were not detected or handled at all in the stop endpoint completion handler. A set TR Deq ptr command was bluntly queued instead of resetting the endpoint first. The set TR Deq command would fail with a context state error. Fix this case by resetting the halted endpoint first to get it to a stopped state instead of the halted (error) state. Handle cancelled TDs once endpoint reset completes, invalidating cancelled TDs on ring either by turning them to no-op, or in case ring stopped on cancelled TD then move hardware dequeue pointer past it, which will clear the cancelled TD from hw cache, and make sure HW does not process it Signed-off-by:
-
Mathias Nyman authored
Don't queue both a reset endpoint command and a set TR deq command at once when handling a halted endpoint. split this into two steps. Initially only queue a reset endpoint command, and then if needed queue a set TR deq command in the reset endpoint handler. Note: This removes the RESET_EP_QUIRK handling which was added in commit ac9d8fe7 ("USB: xhci: Add quirk for Fresco Logic xHCI hardware.") This quirk was added in 2009 for prototype xHCI hardware meant for evaluation purposes only, and should not reach consumers. This hardware could not handle two commands queued at once, and had bad data in the output context after a reset endpoint command. After this patch two command are no longer queued at once, so that part is solved in this rewrite, but the workaround for bad data in the output context solved by issuing an extra configure endpoint command is bluntly removed. Adding this workaround to the new rewrite just adds complexity, and I think it's time to let this quirk go. Print a debug message instead. Signed-off-by:
-
Mathias Nyman authored
Halted endpoints can be discoverd both when handling transfer events and command completion events. Move code that handles halted endpoints before both of those event handlers. Rename the function to xhci_handle_halted_ep() to better describe what it does. Try to reserve "cleanup" word in function names for last stage cleanup activities. No functional changes Signed-off-by:
-
Mathias Nyman authored
Refactor handler for stop endpoint command completion. Yank out the part that invalidates cancelled TDs and turn it into a separate function. Invalidating cancelled TDs should be done while the ring is stopped, but not exclusively in the stop endpoint command completeion handler. We will need to invalidate TDs after resetting endpoints as well. Signed-off-by:
-
Mathias Nyman authored
In cases where the TD can't be given back in current handler we want to be able to store it until its time to return the TD. Signed-off-by:
-
Mathias Nyman authored
use the existing xhci_td_cleanup() to give back cancelled TDs when a ring is stopped. A minor change to make sure we don't try to remove an already removed td from the list is needed as cancelled TDs are already removed from the td_list immediatelty when it's cancelled. Signed-off-by:
-
Mathias Nyman authored
No funtional changes Signed-off-by:
-
Mathias Nyman authored
Create a separate helper function to issue reset endpont commands to clear halted endpoints. This is useful for cases where a halted endpoint is discovered while completing another command, and the endpoint halt needs to be cleared with a endpoint reset first. No functional changes Signed-off-by:
-
