linux-stable.git/drivers/extcon, branch v5.15.97

extcon: usbc-tusb320: fix kernel-doc warning

2023-02-06T06:59:01+00:00

commit 08099ecd9216219f51cc82637f06797cf81890b6 upstream.

Fix the warning:
drivers/extcon/extcon-usbc-tusb320.c:19: warning: expecting prototype
for drivers/extcon/extcon-tusb320.c(). Prototype was for TUSB320_REG8()
instead

Reported-by: kernel test robot 
Signed-off-by: Rong Chen 
Signed-off-by: Chanwoo Choi 
Cc: Marek Vasut 
Signed-off-by: Greg Kroah-Hartman

extcon: usbc-tusb320: Call the Type-C IRQ handler only if a port is registered

2022-12-31T12:14:48+00:00

commit 341fd15e2e18c24d5c738496cfc3d7a272241201 upstream.

Commit bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support")
added an optional Type-C interface to the driver but missed to check
if it is in use when calling the IRQ handler. This causes an oops on
devices currently using the old extcon interface. Check if a Type-C
port is registered before calling the Type-C IRQ handler.

Fixes: bf7571c00dca ("extcon: usbc-tusb320: Add USB TYPE-C support")
Signed-off-by: Yassine Oudjana 
Reviewed-by: Marek Vasut 
Reviewed-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20221107153317.657803-1-y.oudjana@protonmail.com
Signed-off-by: Greg Kroah-Hartman

extcon: usbc-tusb320: Update state on probe even if no IRQ pending

2022-12-31T12:14:28+00:00

[ Upstream commit 581c848b610dbf3fe1ed4d85fd53d0743c61faba ]

Currently this driver triggers extcon and typec state update in its
probe function, to read out current state reported by the chip and
report the correct state to upper layers. This synchronization is
performed correctly, but only in case the chip indicates a pending
interrupt in reg09 register.

This fails to cover the situation where all interrupts reported by
the chip were already handled by Linux before reboot, then the system
rebooted, and then Linux starts again. In this case, the TUSB320 no
longer reports any interrupts in reg09, and the state update does not
perform any update as it depends on that interrupt indication.

Fix this by turning tusb320_irq_handler() into a thin wrapper around
tusb320_state_update_handler(), where the later now contains the bulk
of the code of tusb320_irq_handler(), but adds new function parameter
"force_update". The "force_update" parameter can be used by the probe
function to assure that the state synchronization is always performed,
independent of the interrupt indicated in reg09. The interrupt handler
tusb320_irq_handler() callback uses force_update=false to avoid state
updates on potential spurious interrupts and retain current behavior.

Fixes: 06bc4ca115cdd ("extcon: Add driver for TI TUSB320")
Signed-off-by: Marek Vasut 
Reviewed-by: Alvin Šipraga 
Acked-by: Heikki Krogerus 
Link: https://lore.kernel.org/r/20221120141509.81012-1-marex@denx.de
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Add USB TYPE-C support

2022-12-31T12:14:28+00:00

[ Upstream commit bf7571c00dca0a9c5af3f5125ef5a89a40b13cd5 ]

The TI TUSB320 seems like a better fit for USB TYPE-C subsystem,
which can expose details collected by the TUSB320 in a far more
precise way than extcon. Since there are existing users in the
kernel and in DT which depend on the extcon interface, keep it
for now.

Add TYPE-C interface and expose the supported supply current,
direction and connector polarity via the TYPE-C interface.

Signed-off-by: Marek Vasut 
Acked-by: Heikki Krogerus 
Reviewed-by: Alvin Šipraga 
Signed-off-by: Chanwoo Choi 
Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending")
Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Factor out extcon into dedicated functions

2022-12-31T12:14:28+00:00

[ Upstream commit 9483811a126a319ecac749f1b767ea5faecc7aed ]

Move extcon code into separate functions in preparation for addition of
USB TYPE-C support. No functional change.

Signed-off-by: Marek Vasut 
Signed-off-by: Chanwoo Choi 
Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending")
Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Add support for TUSB320L

2022-12-31T12:14:28+00:00

[ Upstream commit ce0320bd3872038569be360870e2d5251b975692 ]

TUSB320L is a newer chip with additional features, and it has additional steps
in its mode changing sequence:
 - Disable CC state machine,
 - Write to mode register,
 - Wait for 5 ms,
 - Re-enable CC state machine.
It also has an additional register that a revision number can be read from.

Add support for the mode changing sequence, and read the revision number during
probe and print it as info.

Signed-off-by: Yassine Oudjana 
Signed-off-by: Chanwoo Choi 
Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending")
Signed-off-by: Sasha Levin

extcon: usbc-tusb320: Add support for mode setting and reset

2022-12-31T12:14:28+00:00

[ Upstream commit 70c55d6be634e5f9894169340f3fe5c73f53ac2d ]

Reset the chip and set its mode to default (maintain mode set by PORT pin)
during probe to make sure it comes up in the default state.

Signed-off-by: Yassine Oudjana 
Signed-off-by: Chanwoo Choi 
Stable-dep-of: 581c848b610d ("extcon: usbc-tusb320: Update state on probe even if no IRQ pending")
Signed-off-by: Sasha Levin

extcon: Modify extcon device to be created after driver data is set

2022-06-14T16:36:22+00:00

[ Upstream commit 5dcc2afe716d69f5112ce035cb14f007461ff189 ]

Currently, someone can invoke the sysfs such as state_show()
intermittently before dev_set_drvdata() is done.
And it can be a cause of kernel Oops because of edev is Null at that time.
So modified the driver registration to after setting drviver data.

- Oops's backtrace.

Backtrace:
[] (state_show) from [] (dev_attr_show)
[] (dev_attr_show) from [] (sysfs_kf_seq_show)
[] (sysfs_kf_seq_show) from [] (kernfs_seq_show)
[] (kernfs_seq_show) from [] (seq_read)
[] (seq_read) from [] (kernfs_fop_read)
[] (kernfs_fop_read) from [] (__vfs_read)
[] (__vfs_read) from [] (vfs_read)
[] (vfs_read) from [] (ksys_read)
[] (ksys_read) from [] (sys_read)
[] (sys_read) from [] (__sys_trace_return)

Signed-off-by: bumwoo lee 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

extcon: Fix extcon_get_extcon_dev() error handling

2022-06-14T16:36:21+00:00

[ Upstream commit 58e4a2d27d3255e4e8c507fdc13734dccc9fc4c7 ]

The extcon_get_extcon_dev() function returns error pointers on error,
NULL when it's a -EPROBE_DEFER defer situation, and ERR_PTR(-ENODEV)
when the CONFIG_EXTCON option is disabled.  This is very complicated for
the callers to handle and a number of them had bugs that would lead to
an Oops.

In real life, there are two things which prevented crashes.  First,
error pointers would only be returned if there was bug in the caller
where they passed a NULL "extcon_name" and none of them do that.
Second, only two out of the eight drivers will build when CONFIG_EXTCON
is disabled.

The normal way to write this would be to return -EPROBE_DEFER directly
when appropriate and return NULL when CONFIG_EXTCON is disabled.  Then
the error handling is simple and just looks like:

	dev->edev = extcon_get_extcon_dev(acpi_dev_name(adev));
	if (IS_ERR(dev->edev))
		return PTR_ERR(dev->edev);

For the two drivers which can build with CONFIG_EXTCON disabled, then
extcon_get_extcon_dev() will now return NULL which is not treated as an
error and the probe will continue successfully.  Those two drivers are
"typec_fusb302" and "max8997-battery".  In the original code, the
typec_fusb302 driver had an 800ms hang in tcpm_get_current_limit() but
now that function is a no-op.  For the max8997-battery driver everything
should continue working as is.

Signed-off-by: Dan Carpenter 
Reviewed-by: Hans de Goede 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Acked-by: Sebastian Reichel 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

extcon: ptn5150: Add queue work sync before driver release

2022-06-14T16:36:07+00:00

[ Upstream commit 782cd939cbe0f569197cd1c9b0477ee213167f04 ]

Add device managed action to sync pending queue work, otherwise
the queued work may run after the work is destroyed.

Fixes: 4ed754de2d66 ("extcon: Add support for ptn5150 extcon driver")
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Li Jun 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin