linux-stable.git/drivers/extcon, branch linux-5.18.y

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

2022-06-14T16:45:11+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:45:11+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:44:50+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

extcon: intel-cht-wc: Report RID_A for ACA adapters

2022-02-01T13:55:12+00:00

Make cht_wc_extcon_get_id() report RID_A for ACA adapters, instead of
reporting ID_FLOAT.

According to the spec. we should read the USB-ID pin ADC value
to determine the resistance of the used pull-down resister and
then return RID_A / RID_B / RID_C based on this. But all "Accessory
Charger Adapter"s (ACAs) which users can actually buy always use
a combination of a charging port with one or more USB-A ports, so
they should always use a resistor indicating RID_A. But the spec
is hard to read / badly-worded so some of them actually indicate
they are a RID_B ACA even though they clearly are a RID_A ACA.

To workaround this simply always return INTEL_USB_RID_A, which
matches all the ACAs which users can actually buy.

Acked-by: Chanwoo Choi 
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Add support for registering a power_supply class-device

2022-02-01T13:55:12+00:00

The bq25890 used on the Yogabook YB1-X90 / -X91 models relies on
the extcon-driver's BC-1.2 charger detection, and the bq25890 driver
expect this info to be  available through a parent power_supply
class-device which models the detected charger (idem to how the Type-C
TCPM code registers a power_supply classdev for the connected charger).

Add support for registering the power_supply class-device expected
by this setup.

Acked-by: Chanwoo Choi 
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Refactor cht_wc_extcon_get_charger()

2022-02-01T13:55:12+00:00

This is a preparation patch for adding support for registering
a power_supply class device.

Setting usbsrc to "CHT_WC_USBSRC_TYPE_SDP << CHT_WC_USBSRC_TYPE_SHIFT"
will make the following switch-case return EXTCON_CHG_USB_SDP
just as before, so there is no functional change.

Acked-by: Chanwoo Choi 
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Support devs with Micro-B / USB-2 only Type-C connectors

2022-02-01T13:55:12+00:00

So far the extcon-intel-cht-wc code has only been tested on devices with
a Type-C connector with USB-PD, USB3 (superspeed) and DP-altmode support
through a FUSB302 Type-C controller.

Some devices with the intel-cht-wc PMIC however come with an USB-micro-B
connector, or an USB-2 only Type-C connector without USB-PD.

Which device-model we are running on can be identified with the new
cht_wc_model intel_soc_pmic field. On models without a Type-C controller
the extcon code must control the Vbus 5V boost converter and the USB role
switch depending on the detected cable-type.

Acked-by: Chanwoo Choi 
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel

extcon: intel-cht-wc: Use new cht_wc_model intel_soc_pmic field

2022-02-01T13:55:12+00:00

The CHT_WC_VBUS_GPIO_CTLO GPIO actually driving an external 5V Vboost
converter for Vbus depends on the board on which the Cherry Trail -
Whiskey Cove PMIC is actually used.

Since the information about the exact PMIC setup is necessary in other
places too, struct intel_soc_pmic now has a new cht_wc_model field
indicating the board model.

Only poke the CHT_WC_VBUS_GPIO_CTLO GPIO if this new field is set to
INTEL_CHT_WC_GPD_WIN_POCKET, which indicates the Type-C (with PD and
DP-altmode) setup used on the GPD pocket and GPD win; and on which
this GPIO actually controls an external 5V Vboost converter.

Acked-by: Chanwoo Choi 
Signed-off-by: Hans de Goede 
Signed-off-by: Sebastian Reichel

extcon: Deduplicate code in extcon_set_state_sync()

2021-12-24T06:27:52+00:00

Finding the cable index and checking for changed status is also done
in extcon_set_state(). So calling extcon_set_state_sync() will do these
checks twice. Remove them and use these checks from extcon_set_state().

Signed-off-by: Alexander Stein 
Signed-off-by: Chanwoo Choi

extcon: usb-gpio: fix a non-kernel-doc comment

2021-12-24T06:27:52+00:00

Do not use "/**" to begin a non-kernel-doc comment.
Fixes this build warning:

drivers/extcon/extcon-usb-gpio.c:23:
	warning: expecting prototype for drivers/extcon/extcon-usb-gpio.c().

Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Signed-off-by: Chanwoo Choi