Revision tags: v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
266f403e |
| 09-Feb-2024 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
usb: typec: ucsi: Limit read size on v1.2
[ Upstream commit b3db266fb031fba88c423d4bb8983a73a3db6527 ]
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256.
usb: typec: ucsi: Limit read size on v1.2
[ Upstream commit b3db266fb031fba88c423d4bb8983a73a3db6527 ]
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Link: https://lore.kernel.org/r/20240209143723.v5.1.Iacf5570a66b82b73ef03daa6557e2fc0db10266a@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
266f403e |
| 09-Feb-2024 |
Abhishek Pandit-Subedi <abhishekpandit@chromium.org> |
usb: typec: ucsi: Limit read size on v1.2
[ Upstream commit b3db266fb031fba88c423d4bb8983a73a3db6527 ]
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256.
usb: typec: ucsi: Limit read size on v1.2
[ Upstream commit b3db266fb031fba88c423d4bb8983a73a3db6527 ]
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org> Link: https://lore.kernel.org/r/20240209143723.v5.1.Iacf5570a66b82b73ef03daa6557e2fc0db10266a@changeid Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
4a1f0678 |
| 04-Mar-2024 |
Jameson Thies <jthies@google.com> |
usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros
[ Upstream commit 4d0a5a9915793377c0fe1a8d78de6bcd92cea963 ]
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and u
usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros
[ Upstream commit 4d0a5a9915793377c0fe1a8d78de6bcd92cea963 ]
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and updating the modal support macro for consistent naming.
Fixes: 3cf657f07918 ("usb: typec: ucsi: Remove all bit-fields") Cc: stable@vger.kernel.org Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-2-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
4a1f0678 |
| 04-Mar-2024 |
Jameson Thies <jthies@google.com> |
usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros
[ Upstream commit 4d0a5a9915793377c0fe1a8d78de6bcd92cea963 ]
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and u
usb: typec: ucsi: Clean up UCSI_CABLE_PROP macros
[ Upstream commit 4d0a5a9915793377c0fe1a8d78de6bcd92cea963 ]
Clean up UCSI_CABLE_PROP macros by fixing a bitmask shifting error for plug type and updating the modal support macro for consistent naming.
Fixes: 3cf657f07918 ("usb: typec: ucsi: Remove all bit-fields") Cc: stable@vger.kernel.org Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Prashant Malani <pmalani@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jameson Thies <jthies@google.com> Link: https://lore.kernel.org/r/20240305025804.1290919-2-jthies@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44 |
|
#
df0383ff |
| 07-Aug-2023 |
Saranya Gopal <saranya.gopal@intel.com> |
usb: typec: ucsi: Add debugfs for ucsi commands
Add support for UCSI commands through the following debugfs: # /sys/kernel/debug/usb/ucsi/$UCSI_DEVICE/command # /sys/kernel/debug/usb/ucsi/$UCSI_
usb: typec: ucsi: Add debugfs for ucsi commands
Add support for UCSI commands through the following debugfs: # /sys/kernel/debug/usb/ucsi/$UCSI_DEVICE/command # /sys/kernel/debug/usb/ucsi/$UCSI_DEVICE/response
Eg: To execute UCSI GetCapabilities: # echo 0x6 > /sys/kernel/debug/usb/ucsi/<ucsi device>/command Then read the result, # cat /sys/kernel/debug/usb/ucsi/<ucsi device>/response 0x02000320000000020000ff0400000445
UCSI command will be written into the command file and the response for the command can be viewed under the response file.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Saranya Gopal <saranya.gopal@intel.com> Co-developed-by: Rajaram Regupathy <rajaram.regupathy@intel.com> Signed-off-by: Rajaram Regupathy <rajaram.regupathy@intel.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230807105205.742819-1-saranya.gopal@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19 |
|
#
fac4b863 |
| 10-Jan-2023 |
Jack Pham <quic_jackp@quicinc.com> |
usb: ucsi: Ensure connector delayed work items are flushed
During ucsi_unregister() when destroying a connector's workqueue, there may still be pending delayed work items that haven't been scheduled
usb: ucsi: Ensure connector delayed work items are flushed
During ucsi_unregister() when destroying a connector's workqueue, there may still be pending delayed work items that haven't been scheduled yet. Because queue_delayed_work() uses a separate timer to schedule a work item, the destroy_workqueue() call is not aware of any pending items. Hence when a pending item's timer expires it would then try to queue on a dangling workqueue pointer.
Fix this by keeping track of all work items in a list, so that prior to destroying the workqueue any pending items can be flushed. Do this by calling mod_delayed_work() as that will cause pending items to get queued immediately, which then allows the ensuing destroy_workqueue() to implicitly drain all currently queued items to completion and free themselves.
Fixes: b9aa02ca39a4 ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Suggested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Co-developed-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Signed-off-by: Jack Pham <quic_jackp@quicinc.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20230110071218.26261-1-quic_jackp@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.0.18, v6.1.4, v6.1.3, v6.0.17 |
|
#
b04e1747 |
| 02-Jan-2023 |
Saranya Gopal <saranya.gopal@intel.com> |
usb: typec: ucsi: Register USB Power Delivery Capabilities
UCSI allows the USB PD capabilities to be read with the GET_PDO command. This will register those capabilities and make them visible to use
usb: typec: ucsi: Register USB Power Delivery Capabilities
UCSI allows the USB PD capabilities to be read with the GET_PDO command. This will register those capabilities and make them visible to user space.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Co-developed-by: Rajaram Regupathy <rajaram.regupathy@intel.com> Signed-off-by: Rajaram Regupathy <rajaram.regupathy@intel.com> Signed-off-by: Saranya Gopal <saranya.gopal@intel.com> Link: https://lore.kernel.org/r/20230102062108.838423-1-saranya.gopal@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
e0dced9c |
| 23-Nov-2022 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Resume in separate work
It can take more than one second to check each connector when the system is resumed. So if you have, say, eight connectors, it may take eight seconds for uc
usb: typec: ucsi: Resume in separate work
It can take more than one second to check each connector when the system is resumed. So if you have, say, eight connectors, it may take eight seconds for ucsi_resume() to finish. That's a bit too much.
This will modify ucsi_resume() so that it schedules a work where the interface is actually resumed instead of checking the connectors directly. The connections will also be checked in separate tasks which are queued for each connector separately.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216706 Fixes: 99f6d4361113 ("usb: typec: ucsi: Check the connection on resume") Cc: <stable@vger.kernel.org> Reported-by: Todd Brandt <todd.e.brandt@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20221123093021.25981-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
3c162511 |
| 25-Apr-2022 |
Linyu Yuan <quic_linyyuan@quicinc.com> |
usb: typec: ucsi: Wait for the USB role switches
When role switch module probe late than ucsi module, fwnode_usb_role_switch_get() will return -EPROBE_DEFER, it is better to restart ucsi init work t
usb: typec: ucsi: Wait for the USB role switches
When role switch module probe late than ucsi module, fwnode_usb_role_switch_get() will return -EPROBE_DEFER, it is better to restart ucsi init work to find it again every 100ms, total wait time is 10 second.
It also means change ucsi init work to delayed_work.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com> Link: https://lore.kernel.org/r/1650881886-25530-3-git-send-email-quic_linyyuan@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7 |
|
#
512df95b |
| 20-Sep-2021 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Better fix for missing unplug events issue
The commit 217504a05532 ("usb: typec: ucsi: Work around PPM losing change information") had solved this issue previously, but in a really
usb: typec: ucsi: Better fix for missing unplug events issue
The commit 217504a05532 ("usb: typec: ucsi: Work around PPM losing change information") had solved this issue previously, but in a really complex manner. The core issue is that on some platforms the EC firmware does not interrupt the driver on unplug event in some cases, mainly when the cable is unplugged immediately after the plug-in.
From now on handling that problem by simply re-checking new connections.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-8-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
b9aa02ca |
| 20-Sep-2021 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking
The "poll worker" that is introduced here is first used for checking partner alternate modes, but it can later be use
usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking
The "poll worker" that is introduced here is first used for checking partner alternate modes, but it can later be used for any partner task that requires a separate job to be scheduled to the connector specific workqueues.
The mechanism allows the partner device specific tasks to be polling tasks and also delayed tasks if necessary.
By polling the partner alternate modes with this mechanism the long command completion timeout value can be reduced back to normal. The long command completion timeout was only used to work around a problem on some platforms where the EC firmware (PPM) didn't return BUSY even when it should with the alt mode commands.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20210920142419.54493-4-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35 |
|
#
1f4642b7 |
| 03-May-2021 |
Jack Pham <jackp@codeaurora.org> |
usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a
usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs.
If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now().
With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one.
[ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64
We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command.
Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Fixes: 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") Cc: stable@vger.kernel.org Reported-and-tested-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210503074611.30973-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
89795852 |
| 11-Jan-2021 |
Mayank Rana <mrana@codeaurora.org> |
usb: typec: ucsi: Add support for USB role switch
UCSI already conveys the information about a port's connection status, whether it is operating in UFP or DFP mode, and whether the partner supports
usb: typec: ucsi: Add support for USB role switch
UCSI already conveys the information about a port's connection status, whether it is operating in UFP or DFP mode, and whether the partner supports USB data or not. This information can be used to notify a dual-role controller to start up its host or peripheral mode accordingly. Add optional support for this by querying each port's fwnode to look for an associated USB role switch device. If present, call usb_role_switch_set() with the determined data role upon Connect Change or Connector Partner Change updates.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Mayank Rana <mrana@codeaurora.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210111215520.18476-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9 |
|
#
217504a0 |
| 09-Oct-2020 |
Benjamin Berg <bberg@redhat.com> |
usb: typec: ucsi: Work around PPM losing change information
Some/many PPMs are simply clearing the change bitfield when a notification on a port is acknowledge. Unfortunately, doing so means that an
usb: typec: ucsi: Work around PPM losing change information
Some/many PPMs are simply clearing the change bitfield when a notification on a port is acknowledge. Unfortunately, doing so means that any changes between the GET_CONNECTOR_STATUS and ACK_CC_CI commands is simply lost.
Work around this by re-fetching the connector status afterwards. We can then infer any changes that we see have happened but that may not be respresented in the change bitfield.
We end up with the following actions: 1. UCSI_GET_CONNECTOR_STATUS, store result, update unprocessed_changes 2. UCSI_GET_CAM_SUPPORTED, discard result 3. ACK connector change 4. UCSI_GET_CONNECTOR_STATUS, store result 5. Infere lost changes by comparing UCSI_GET_CONNECTOR_STATUS results 6. If PPM reported a new change, then restart in order to ACK 7. Process everything as usual.
The worker is also changed to re-schedule itself if a new change notification happened while it was running.
Doing this fixes quite commonly occurring issues where e.g. the UCSI power supply would remain online even thought the ThunderBolt cable was unplugged.
Cc: Hans de Goede <hdegoede@redhat.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Benjamin Berg <bberg@redhat.com> Link: https://lore.kernel.org/r/20201009144047.505957-3-benjamin@sipsolutions.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e15e32d5 |
| 09-Oct-2020 |
Benjamin Berg <bberg@redhat.com> |
usb: typec: ucsi: Work around PPM losing change information
commit 217504a055325fe76ec1142aa15f14d3db77f94f upstream.
Some/many PPMs are simply clearing the change bitfield when a notification on a
usb: typec: ucsi: Work around PPM losing change information
commit 217504a055325fe76ec1142aa15f14d3db77f94f upstream.
Some/many PPMs are simply clearing the change bitfield when a notification on a port is acknowledge. Unfortunately, doing so means that any changes between the GET_CONNECTOR_STATUS and ACK_CC_CI commands is simply lost.
Work around this by re-fetching the connector status afterwards. We can then infer any changes that we see have happened but that may not be respresented in the change bitfield.
We end up with the following actions: 1. UCSI_GET_CONNECTOR_STATUS, store result, update unprocessed_changes 2. UCSI_GET_CAM_SUPPORTED, discard result 3. ACK connector change 4. UCSI_GET_CONNECTOR_STATUS, store result 5. Infere lost changes by comparing UCSI_GET_CONNECTOR_STATUS results 6. If PPM reported a new change, then restart in order to ACK 7. Process everything as usual.
The worker is also changed to re-schedule itself if a new change notification happened while it was running.
Doing this fixes quite commonly occurring issues where e.g. the UCSI power supply would remain online even thought the ThunderBolt cable was unplugged.
Cc: Hans de Goede <hdegoede@redhat.com> Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Benjamin Berg <bberg@redhat.com> Link: https://lore.kernel.org/r/20201009144047.505957-3-benjamin@sipsolutions.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e5366bea |
| 03-May-2021 |
Jack Pham <jackp@codeaurora.org> |
usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
commit 1f4642b72be79757f050924a9b9673b6a02034bc upstream.
commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD m
usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4
commit 1f4642b72be79757f050924a9b9673b6a02034bc upstream.
commit 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs.
If such a source is connected it's possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object's (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now().
With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one.
[ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP ... [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 ... [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64
We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command.
Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Fixes: 4dbc6a4ef06d ("usb: typec: ucsi: save power data objects in PD mode") Cc: stable@vger.kernel.org Reported-and-tested-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210503074611.30973-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
0e6371fb |
| 10-Nov-2020 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Report power supply changes
When the ucsi power supply goes online/offline, and when the power levels change, the power supply class needs to be notified so it can inform the user
usb: typec: ucsi: Report power supply changes
When the ucsi power supply goes online/offline, and when the power levels change, the power supply class needs to be notified so it can inform the user space.
Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Cc: stable@vger.kernel.org Reported-and-tested-by: Vladimir Yerilov <openmindead@gmail.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20201110120547.67922-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36 |
|
#
1417cff9 |
| 27-Apr-2020 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Fix the stub for ucsi_register_port_psy()
The stub was ucsi_register_port() when it should have been ucsi_register_port_psy().
Cc: Abhilash K V <abhilash.k.v@intel.com> Fixes: 992
usb: typec: ucsi: Fix the stub for ucsi_register_port_psy()
The stub was ucsi_register_port() when it should have been ucsi_register_port_psy().
Cc: Abhilash K V <abhilash.k.v@intel.com> Fixes: 992a60ed0d5e ("usb: typec: ucsi: register with power_supply class") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200427111246.4889-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
992a60ed |
| 23-Apr-2020 |
K V, Abhilash <abhilash.k.v@intel.com> |
usb: typec: ucsi: register with power_supply class
With this change the UCSI device will show up in /sys/class/power_supply/. The following values are exported: - online - usb_type - voltage_min - v
usb: typec: ucsi: register with power_supply class
With this change the UCSI device will show up in /sys/class/power_supply/. The following values are exported: - online - usb_type - voltage_min - voltage_max - voltage_now - current_max - current_now
Once a PD-capable type-C power source is connected to the system, GET_PDOS UCSI command is used to query all source capabilities. Request data object (RDO) is used to get current values.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200423132058.6972-7-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
4dbc6a4e |
| 23-Apr-2020 |
K V, Abhilash <abhilash.k.v@intel.com> |
usb: typec: ucsi: save power data objects in PD mode
When connected to a PD-capable power-source, read & save all partner power data objects (PDOs) by using GET_PDOS UCSI command. Also, save the cur
usb: typec: ucsi: save power data objects in PD mode
When connected to a PD-capable power-source, read & save all partner power data objects (PDOs) by using GET_PDOS UCSI command. Also, save the current power contract in request data object (RDO) for that connector.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200423132058.6972-6-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e2f38ff2 |
| 23-Apr-2020 |
K V, Abhilash <abhilash.k.v@intel.com> |
usb: typec: ucsi: Correct bit-mask for CCI
Bit 0 is reserved in CCI (Command Status & Connector Change Indicator) register. So, change bit-mask for connector number field to 7..1 instead of 7..0. Th
usb: typec: ucsi: Correct bit-mask for CCI
Bit 0 is reserved in CCI (Command Status & Connector Change Indicator) register. So, change bit-mask for connector number field to 7..1 instead of 7..0. There would be no functional change since we were anyways right-shifing by 1 bit.
Signed-off-by: K V, Abhilash <abhilash.k.v@intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200423132058.6972-5-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25 |
|
#
706f4bbf |
| 10-Mar-2020 |
Ajay Gupta <ajayg@nvidia.com> |
usb: typec: ucsi_ccg: workaround for NVIDIA test device
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA test device FTB (Fun
usb: typec: ucsi_ccg: workaround for NVIDIA test device
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. NVIDIA test device FTB (Function Test Board) reports altmode list with vdo=0x3 first and then vdo=0x1. The list is: SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x3 0x955 0x1
Current logic to assign mode value is based on order in altmode list. This causes a mismatch of CON and SOP altmodes since NVIDIA GPU connector has order of vdo=0x1 first and then vdo=0x3. Fixing this by changing the order of vdo values reported by NVIDIA test device. the new list will be:
SVID VDO 0xff01 0xc05 0x28de 0x8085 0x955 0x1085 0x955 0x3
Also NVIDIA VirtualLink (svid 0x955) uses pin E for display mode. NVIDIA test device reports vdo of 0x1 so make sure vdo values always have pin E assignement.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200310121912.57879-1-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.24, v5.4.23, v5.4.22, v5.4.21 |
|
#
c2ae4928 |
| 17-Feb-2020 |
Ajay Gupta <ajayg@nvidia.com> |
usb: typec: ucsi: register DP only for NVIDIA DP VDO
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. Register display altmode drive
usb: typec: ucsi: register DP only for NVIDIA DP VDO
NVIDIA VirtualLink (svid 0x955) has two altmode, vdo=0x1 for VirtualLink DP mode and vdo=0x3 for NVIDIA test mode. Register display altmode driver only for vdo=0x1
Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200217144913.55330-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9 |
|
#
33786a28 |
| 08-Jan-2020 |
Heikki Krogerus <heikki.krogerus@linux.intel.com> |
usb: typec: ucsi: Fix the notification bit offsets
The bit offsets for the Set Notification Enable command were not considering the reserved bits in the middle.
Fixes: 470ce43a1a81 ("usb: typec: uc
usb: typec: ucsi: Fix the notification bit offsets
The bit offsets for the Set Notification Enable command were not considering the reserved bits in the middle.
Fixes: 470ce43a1a81 ("usb: typec: ucsi: Remove struct ucsi_control") Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200108131347.43217-2-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.4.8, v5.4.7 |
|
#
170a6726 |
| 30-Dec-2019 |
Ajay Gupta <ajayg@nvidia.com> |
usb: typec: ucsi: add support for separate DP altmode devices
CCGx controller used on NVIDIA GPU card has two separate display altmode for two DP pin assignments. UCSI specification doesn't prohibit
usb: typec: ucsi: add support for separate DP altmode devices
CCGx controller used on NVIDIA GPU card has two separate display altmode for two DP pin assignments. UCSI specification doesn't prohibits using separate display altmode.
Current UCSI Type-C framework expects only one display altmode for all DP pin assignment. This patch squashes two separate display altmode into single altmode to support controllers with separate display altmode. We first read all the alternate modes of connector and then run through it to know if there are separate display altmodes. If so, it prepares a new port altmode set after squashing two or more separate altmodes into one.
Signed-off-by: Ajay Gupta <ajayg@nvidia.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20191230133431.63445-3-heikki.krogerus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|