<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/usb/typec, branch v6.2</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.2</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.2'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2023-02-09T12:23:39Z</updated>
<entry>
<title>usb: typec: altmodes/displayport: Fix probe pin assign check</title>
<updated>2023-02-09T12:23:39Z</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2023-02-08T20:53:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=54e5c00a4eb0a4c663445b245f641bbfab142430'/>
<id>urn:sha1:54e5c00a4eb0a4c663445b245f641bbfab142430</id>
<content type='text'>
While checking Pin Assignments of the port and partner during probe, we
don't take into account whether the peripheral is a plug or receptacle.

This manifests itself in a mode entry failure on certain docks and
dongles with captive cables. For instance, the Startech.com Type-C to DP
dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail
the Pin Assignment compatibility check, despite it supporting
Pin Assignment C as a UFP.

Update the check to use the correct DP Pin Assign macros that
take the peripheral's receptacle bit into account.

Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Reported-by: Diana Zigterman &lt;dzigterman@chromium.org&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: ucsi: Don't attempt to resume the ports before they exist</title>
<updated>2023-02-02T10:27:28Z</updated>
<author>
<name>Heikki Krogerus</name>
<email>heikki.krogerus@linux.intel.com</email>
</author>
<published>2023-01-31T14:15:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f82060da749c611ed427523b6d1605d87338aac1'/>
<id>urn:sha1:f82060da749c611ed427523b6d1605d87338aac1</id>
<content type='text'>
This will fix null pointer dereference that was caused by
the driver attempting to resume ports that were not yet
registered.

Fixes: e0dced9c7d47 ("usb: typec: ucsi: Resume in separate work")
Cc: &lt;stable@vger.kernel.org&gt;
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216697
Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230131141518.78215-1-heikki.krogerus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: tcpm: Fix altmode re-registration causes sysfs create fail</title>
<updated>2023-01-17T16:09:27Z</updated>
<author>
<name>ChiYuan Huang</name>
<email>cy_huang@richtek.com</email>
</author>
<published>2023-01-09T07:19:50Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=36f78477ac2c89e9a2eed4a31404a291a3450b5d'/>
<id>urn:sha1:36f78477ac2c89e9a2eed4a31404a291a3450b5d</id>
<content type='text'>
There's the altmode re-registeration issue after data role
swap (DR_SWAP).

Comparing to USBPD 2.0, in USBPD 3.0, it loose the limit that only DFP
can initiate the VDM command to get partner identity information.

For a USBPD 3.0 UFP device, it may already get the identity information
from its port partner before DR_SWAP. If DR_SWAP send or receive at the
mean time, 'send_discover' flag will be raised again. It causes discover
identify action restart while entering ready state. And after all
discover actions are done, the 'tcpm_register_altmodes' will be called.
If old altmode is not unregistered, this sysfs create fail can be found.

In 'DR_SWAP_CHANGE_DR' state case, only DFP will unregister altmodes.
For UFP, the original altmodes keep registered.

This patch fix the logic that after DR_SWAP, 'tcpm_unregister_altmodes'
must be called whatever the current data role is.

Reviewed-by: Macpaul Lin &lt;macpaul.lin@mediatek.com&gt;
Fixes: ae8a2ca8a221 ("usb: typec: Group all TCPCI/TCPM code together")
Reported-by: TommyYl Chen &lt;tommyyl.chen@mediatek.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Acked-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/1673248790-15794-1-git-send-email-cy_huang@richtek.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: altmodes/displayport: Use proper macro for pin assignment check</title>
<updated>2023-01-17T16:07:25Z</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2023-01-11T02:05:43Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=85af23df903ee14bfcba60c53e4f3b640f2310f8'/>
<id>urn:sha1:85af23df903ee14bfcba60c53e4f3b640f2310f8</id>
<content type='text'>
While looking at the DP configuration VDO to determine the peripheral
configuration, the spec (Table 8-5: DisplayPort Configurations, VESA
DisplayPort Alt Mode Standard v2.0) lists the options as "UFP_U as a DP
Source/Sink Device".

So, use the correct macro while performing this check. Effectively it's
the same as the existing code, but the proposed macro describes the
state a little better.

No functional changes introduced.

Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230111020546.3384569-3-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: altmodes/displayport: Fix pin assignment calculation</title>
<updated>2023-01-17T16:07:25Z</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2023-01-11T02:05:42Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9682b41e52cc9f42f5c33caf410464392adaef04'/>
<id>urn:sha1:9682b41e52cc9f42f5c33caf410464392adaef04</id>
<content type='text'>
Commit c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin
assignment for UFP receptacles") fixed the pin assignment calculation
to take into account whether the peripheral was a plug or a receptacle.

But the "pin_assignments" sysfs logic was not updated. Address this by
using the macros introduced in the aforementioned commit in the sysfs
logic too.

Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230111020546.3384569-2-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: altmodes/displayport: Add pin assignment helper</title>
<updated>2023-01-17T16:07:25Z</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2023-01-11T02:05:41Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=582836e3cfab4faafbdc93bbec96fce036a08ee1'/>
<id>urn:sha1:582836e3cfab4faafbdc93bbec96fce036a08ee1</id>
<content type='text'>
The code to extract a peripheral's currently supported Pin Assignments
is repeated in a couple of locations. Factor it out into a separate
function.

This will also make it easier to add fixes (we only need to update 1
location instead of 2).

Fixes: c1e5c2f0cb8a ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230111020546.3384569-1-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: ucsi: Ensure connector delayed work items are flushed</title>
<updated>2023-01-17T16:06:18Z</updated>
<author>
<name>Jack Pham</name>
<email>quic_jackp@quicinc.com</email>
</author>
<published>2023-01-10T07:12:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=fac4b8633fd682ecc8e9cff61cb3e33374a1c7e5'/>
<id>urn:sha1:fac4b8633fd682ecc8e9cff61cb3e33374a1c7e5</id>
<content type='text'>
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 &lt;heikki.krogerus@linux.intel.com&gt;
Co-developed-by: Linyu Yuan &lt;quic_linyyuan@quicinc.com&gt;
Signed-off-by: Linyu Yuan &lt;quic_linyyuan@quicinc.com&gt;
Signed-off-by: Jack Pham &lt;quic_jackp@quicinc.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Link: https://lore.kernel.org/r/20230110071218.26261-1-quic_jackp@quicinc.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'driver-core-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core</title>
<updated>2022-12-16T11:54:54Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-12-16T11:54:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=71a7507afbc3f27c346898f13ab9bfd918613c34'/>
<id>urn:sha1:71a7507afbc3f27c346898f13ab9bfd918613c34</id>
<content type='text'>
Pull driver core updates from Greg KH:
 "Here is the set of driver core and kernfs changes for 6.2-rc1.

  The "big" change in here is the addition of a new macro,
  container_of_const() that will preserve the "const-ness" of a pointer
  passed into it.

  The "problem" of the current container_of() macro is that if you pass
  in a "const *", out of it can comes a non-const pointer unless you
  specifically ask for it. For many usages, we want to preserve the
  "const" attribute by using the same call. For a specific example, this
  series changes the kobj_to_dev() macro to use it, allowing it to be
  used no matter what the const value is. This prevents every subsystem
  from having to declare 2 different individual macros (i.e.
  kobj_const_to_dev() and kobj_to_dev()) and having the compiler enforce
  the const value at build time, which having 2 macros would not do
  either.

  The driver for all of this have been discussions with the Rust kernel
  developers as to how to properly mark driver core, and kobject,
  objects as being "non-mutable". The changes to the kobject and driver
  core in this pull request are the result of that, as there are lots of
  paths where kobjects and device pointers are not modified at all, so
  marking them as "const" allows the compiler to enforce this.

  So, a nice side affect of the Rust development effort has been already
  to clean up the driver core code to be more obvious about object
  rules.

  All of this has been bike-shedded in quite a lot of detail on lkml
  with different names and implementations resulting in the tiny version
  we have in here, much better than my original proposal. Lots of
  subsystem maintainers have acked the changes as well.

  Other than this change, included in here are smaller stuff like:

   - kernfs fixes and updates to handle lock contention better

   - vmlinux.lds.h fixes and updates

   - sysfs and debugfs documentation updates

   - device property updates

  All of these have been in the linux-next tree for quite a while with
  no problems"

* tag 'driver-core-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (58 commits)
  device property: Fix documentation for fwnode_get_next_parent()
  firmware_loader: fix up to_fw_sysfs() to preserve const
  usb.h: take advantage of container_of_const()
  device.h: move kobj_to_dev() to use container_of_const()
  container_of: add container_of_const() that preserves const-ness of the pointer
  driver core: fix up missed drivers/s390/char/hmcdrv_dev.c class.devnode() conversion.
  driver core: fix up missed scsi/cxlflash class.devnode() conversion.
  driver core: fix up some missing class.devnode() conversions.
  driver core: make struct class.devnode() take a const *
  driver core: make struct class.dev_uevent() take a const *
  cacheinfo: Remove of_node_put() for fw_token
  device property: Add a blank line in Kconfig of tests
  device property: Rename goto label to be more precise
  device property: Move PROPERTY_ENTRY_BOOL() a bit down
  device property: Get rid of __PROPERTY_ENTRY_ARRAY_EL*SIZE*()
  kernfs: fix all kernel-doc warnings and multiple typos
  driver core: pass a const * into of_device_uevent()
  kobject: kset_uevent_ops: make name() callback take a const *
  kobject: kset_uevent_ops: make filter() callback take a const *
  kobject: make kobject_namespace take a const *
  ...
</content>
</entry>
<entry>
<title>usb: typec: tipd: Set mode of operation for USB Type-C connector</title>
<updated>2022-12-08T15:45:10Z</updated>
<author>
<name>Sven Peter</name>
<email>sven@svenpeter.dev</email>
</author>
<published>2022-11-28T16:23:04Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=59d54aa09020fe52061d4cda51d474f5bd5e6be1'/>
<id>urn:sha1:59d54aa09020fe52061d4cda51d474f5bd5e6be1</id>
<content type='text'>
Forward the mode of operation to the typec subsystem such that it can
configure the mux correctly.

Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Sven Peter &lt;sven@svenpeter.dev&gt;
Link: https://lore.kernel.org/r/20221128162304.80125-1-sven@svenpeter.dev
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: typec: wusb3801: fix fwnode refcount leak in wusb3801_probe()</title>
<updated>2022-12-08T15:43:22Z</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2022-12-03T07:10:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=dc18a4c7b3bd447cef2395deeb1f6ac16dfaca0e'/>
<id>urn:sha1:dc18a4c7b3bd447cef2395deeb1f6ac16dfaca0e</id>
<content type='text'>
I got the following report while doing fault injection test:

  OF: ERROR: memory leak, expected refcount 1 instead of 4,
  of_node_get()/of_node_put() unbalanced - destroy cset entry:
  attach overlay node /i2c/tcpc@60/connector

If wusb3801_hw_init() fails, fwnode_handle_put() needs be called to
avoid refcount leak.

Fixes: d016cbe4d7ac ("usb: typec: Support the WUSB3801 port controller")
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Link: https://lore.kernel.org/r/20221203071027.3808308-1-yangyingliang@huawei.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
