There's no need to set the flag explicitly to false, since that
is the default value from zero initialization.
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
There's no need to set the flag explicitly to false, since that
is the default value from zero initialization.
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
there is an unexpected word "the" in the comments that need to be dropped
file: ./drivers/extcon/extcon.c
line: 250
/* Find the the index of extcon cable in edev->supported_cable */
changed to
/* Find the index of extcon cable in edev->supported_cable */
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
There is an extreneous space before a dev_dbg message, remove it.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
A remove callback that just returns 0 is equivalent to no callback at all
as can be seen in i2c_device_remove(). So simplify accordingly.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
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:
[<c067865c>] (state_show) from [<c05222e8>] (dev_attr_show)
[<c05222c0>] (dev_attr_show) from [<c02c66e0>] (sysfs_kf_seq_show)
[<c02c6648>] (sysfs_kf_seq_show) from [<c02c496c>] (kernfs_seq_show)
[<c02c4938>] (kernfs_seq_show) from [<c025e2a0>] (seq_read)
[<c025e11c>] (seq_read) from [<c02c50a0>] (kernfs_fop_read)
[<c02c5064>] (kernfs_fop_read) from [<c0231cac>] (__vfs_read)
[<c0231c5c>] (__vfs_read) from [<c0231ee0>] (vfs_read)
[<c0231e34>] (vfs_read) from [<c0232464>] (ksys_read)
[<c02323f0>] (ksys_read) from [<c02324fc>] (sys_read)
[<c02324e4>] (sys_read) from [<c00091d0>] (__sys_trace_return)
Signed-off-by: bumwoo lee <bw365.lee@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
While SM5502 and SM5504 are purely micro USB switching
circuits, SM5703 is a multi-function device which has multiple
modules in it. Change the i2c_device_id of it to avoid conflict
with MFD driver.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Some usb controller drivers may not support extcon but use
usb role class as it's the preferred approach, so to support
usb dual role switch with usb role class, add usb role class
consumer support.
Signed-off-by: Li Jun <jun.li@nxp.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Add device managed action to sync pending queue work, otherwise
the queued work may run after the work is destroyed.
Fixes: 4ed754de2d ("extcon: Add support for ptn5150 extcon driver")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
SM5703 is another MFD from Silicon Mitus which has a very similar MUIC
unit to the one in SM5502. The only difference I've noticed is slightly different
configuration only enables the interrupts which are exactly the same as on SM5502.
If we make use of different interrupts in the future, this can be improved by having
a separate struct for SM5703, but the main functionality (detecting cable or OTG adapter)
is working properly.
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
If disable vbus/id irq, it will lead to wakeup system fail
in unisoc platform. In unisoc platform, Irq enable and irq
wakeup are the same interrupt line. So remove disable vbus/id
irq operation is a way to solve the issue.
Signed-off-by: Bruce Chen <bruce.chen@unisoc.com>
Acked-by: Roger Quadros <rogerq@kernel.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Add the description of @id in extcon_sync() kernel-doc comment
and @edev, @id, @prop in extcon_set_property_sync() kernel-doc
comment to remove warnings found by running scripts/kernel-doc,
which is caused by using 'make W=1'.
drivers/extcon/extcon.c:409: warning: Function parameter or
member 'id' not described in 'extcon_sync'
drivers/extcon/extcon.c:750: warning: Function parameter or
member 'edev' not described in 'extcon_set_property_sync'
drivers/extcon/extcon.c:750: warning: Function parameter or
member 'id' not described in 'extcon_set_property_sync'
drivers/extcon/extcon.c:750: warning: Function parameter or
member 'prop' not described in 'extcon_set_property_sync'
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Make use of the struct_size() helper instead of an open-coded version,
in order to avoid any potential type mistakes or integer overflows that,
in the worst scenario, could lead to heap overflows.
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
On some boards the 5V vboost-regulator for powering devices connected to
the micro USB connector is not controlled through a GPIO. This happens
for example when the 5V vboost-regulator is integrated into the charger IC
and controlled over I2C.
Add support for controlling the 5V vboost-regulator through the regulator
framework for such boards.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
On some X86 Android tablets the DSTD lack the INT3496 ACPI device,
while also not handling micro USB port ID pin events inside the DSDT
(instead the forked factory image kernel has things hardcoded).
The new drivers/platform/x86/x86-android-tablets.c module manually
instantiates an intel-int3496 device for these tablets.
Add support to the extcon-intel-int3496 driver to bind to devices
without an ACPI companion and export a normal platform_device
modalias for automatic module loading.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Some DSDTs are buggy and do a read from the ID pin during the ACPI
initialization, causing the pin to be marked as owned by:
"ACPI:OpRegion" and causing gpiod_get() to fail with -EBUSY.
Pass the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag to the gpiod_get() call
to work around this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
On all devices which I have with an INT3496 ACPI device,
there is only an ID pin defined.
Change the log-messages about not being able to get GPIOs for
"VBUS EN" and "USB MUX" to use dev_dbg().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
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 <dan.carpenter@oracle.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
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 <cw00.choi@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <cw00.choi@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <cw00.choi@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <cw00.choi@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <cw00.choi@samsung.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
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 <alexander.stein@ew.tq-group.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
