The PTN5150 dependencies look like they were meant to do the
right thing, but they actually should not allow building without
I2C for compile testing, as that results in a Kconfig warning
and subsequent build failure:
WARNING: unmet direct dependencies detected for REGMAP_I2C
Depends on [m]: I2C [=m]
Selected by [y]:
- EXTCON_PTN5150 [=y] && EXTCON [=y] && (I2C [=m] && GPIOLIB [=y] || COMPILE_TEST [=y])
Selected by [m]:
- EEPROM_AT24 [=m] && I2C [=m] && SYSFS [=y]
- KEYBOARD_CAP11XX [=m] && !UML && INPUT [=y] && INPUT_KEYBOARD [=y] && OF [=y] && I2C [=m]
- INPUT_DRV260X_HAPTICS [=m] && !UML && INPUT_MISC [=y] && INPUT [=y] && I2C [=m] && (GPIOLIB [=y] || COMPILE_TEST [=y])
- ... [many others]
Add parentheses around the expression so we can compile-test
without GPIOLIB but not without I2C.
Fixes: 4ed754de2d ("extcon: Add support for ptn5150 extcon driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
In case of error, the function devm_gpiod_get() returns ERR_PTR() and
never returns NULL. The NULL test in the return value check should be
replaced with IS_ERR().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
PTN5150 is a small thin low power CC (Configurationn Channel)
Logic chip supporting the USB Type-C connector application with
CC control logic detection and indication functions.
Signed-off-by: Vijai Kumar K <vijaikumar.kanagarajan@gmail.com>
[cw00.choi: Fix bulid dependency and clean-up code]
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
MAX8997 driver disables automatic path selection from MicroUSB connector
and manually sets path to either UART or USB lines. However the code for
setting USB path worked only for USB host mode (when ID pin is set
to ground). When standard USB cable (USB device mode) is connected, path
registers are not touched. This means that once the non-USB accessory is
connected to MAX8997-operated micro USB port, the path is no longer set
to USB and USB device mode doesn't work. This patch fixes it by setting
USB path both for USB and USB host modes.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Driver unconditionally forces UART path during probe, probably to ensure
that one can get kernel serial log as soon as possible.
This approach causes some issues, especially when board is booted with
non-UART cable connected to micro-USB port. For example, when USB cable is
connected, UART TX/RX lines are unconditionally short-circuited to USB
D+/D- lines. This is in turn recognized by a series of serial BREAK
signals and some random characters when USB host tries to perform
enumeration procedure.
To solve the above issue and keep UART console operational as early as
possible, set UART path only when USB ID reports UART capable cable.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Driver unconditionally forces UART path during probe, probably to ensure
that one can get kernel serial log as soon as possible.
This approach causes some issues, especially when board is booted with
non-UART cable connected to micro-USB port. For example, when USB cable is
connected, UART TX/RX lines are unconditionally short-circuited to USB
D+/D- lines. This is in turn recognized by a series of serial BREAK
signals and some random characters when USB host tries to perform
enumeration procedure.
To solve the above issue and keep UART console operational as early as
possible, set UART path only when USB ID reports UART capable cable.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Driver unconditionally forces UART path during probe, probably to ensure
that one can get kernel serial log as soon as possible.
This approach causes some issues, especially when board is booted with
non-UART cable connected to micro-USB port. For example, when USB cable is
connected, UART TX/RX lines are unconditionally short-circuited to USB
D+/D- lines. This is in turn recognized by a series of serial BREAK
signals and some random characters when USB host tries to perform
enumeration procedure.
To solve the above issue and keep UART console operational as early as
possible, set UART path only when USB ID reports UART capable cable.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Driver unconditionally forces UART path during probe, probably to ensure
that one can get kernel serial log as soon as possible.
This approach causes some issues, especially when board is booted with
non-UART cable connected to micro-USB port. For example, when USB cable is
connected, UART TX/RX lines are unconditionally short-circuited to USB
D+/D- lines. This is in turn recognized by a series of serial BREAK
signals and some random characters when USB host tries to perform
enumeration procedure.
To solve the above issue and keep UART console operational as early as
possible, set UART path only when USB ID reports UART capable cable.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Convert driver to use SPDX identifier.
While here, fix MODULE_LICENSE() string to be the same as license text states.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
USBID is 2-bit bit field according to specification. Make it clear.
No functional change intended.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
When we have first case to fall through it's not enough to put
single comment there to satisfy compiler. Instead of doing that,
return fall back value directly from default case.
This to avoid following warnings:
drivers/extcon/extcon-intel-cht-wc.c: In function ‘cht_wc_extcon_get_charger’:
include/linux/device.h:1420:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
_dev_warn(dev, dev_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/extcon/extcon-intel-cht-wc.c:148:3: note: in expansion of macro ‘dev_warn’
dev_warn(ext->dev,
^~~~~~~~
drivers/extcon/extcon-intel-cht-wc.c:152:2: note: here
case CHT_WC_USBSRC_TYPE_SDP:
^~~~
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
When assign unions we need to supply non-scalar value, otherwise
static analyzer is not happy:
CHECK drivers/extcon/extcon.c
drivers/extcon/extcon.c:631:22: warning: cast to non-scalar
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Chanwoo writes:
Update extcon for 4.19
Detailed description for this pull request:
1. Release locking when sending the connector state in extcon_sync()
- Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue on extcon
consumer device, release locking when sending the connector state.
2. Fix minor issues of extcon provider driver
- extcon-intel-int3496.c uses 'linux/gpio/consumer.h' instead of 'linux/gpio.h'
- extcon-usbc-cors-ec.c adds SPDX license and fix the wrong license information
Previously, extcon used the spinlock before calling the notifier_call_chain
to prevent the scheduled out of task and to prevent the notification delay.
When spinlock is locked for sending the notification, deadlock issue
occured on the side of extcon consumer device. To fix this issue,
extcon consumer device should always use the work. it is always not
reasonable to use work.
To fix this issue on extcon consumer device, release locking when sending
the notification of connector state.
Fixes: ab11af049f ("extcon: Add the synchronization extcon APIs to support the notification")
Cc: stable@vger.kernel.org
Cc: Roger Quadros <rogerq@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
The license text is specifying "GPLv2" but the MODULE_LICENSE is set to
GPL which means GNU Public License v2 or later. When MODULE_LICENSE and
boiler plate does not match, go for boiler plate license.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Since commit eca0f13c83 ("extcon: int3496: Ignore incorrect
IoRestriction for ID pin"), the driver doesn't use GPIOF_* flags
anymore. We can thus now drop the deprecated include file for GPIO and
use the new one.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Another driver turned up that is missing linux/mod_devicetable.h after
the device IDs are split out from linux/platform_device.h:
drivers/extcon/extcon-max3355.c:127:34: error: array type has incomplete element type 'struct of_device_id'
static const struct of_device_id max3355_match_table[] = {
Fixes: ac3167257b ("headers: separate linux/mod_devicetable.h from linux/platform_device.h")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
At over 4000 #includes, <linux/platform_device.h> is the 9th most
#included header file in the Linux kernel. It does not need
<linux/mod_devicetable.h>, so drop that header and explicitly add
<linux/mod_devicetable.h> to source files that need it.
4146 #include <linux/platform_device.h>
After this patch, there are 225 files that use <linux/mod_devicetable.h>,
for a reduction of around 3900 times that <linux/mod_devicetable.h>
does not have to be read & parsed.
225 #include <linux/mod_devicetable.h>
This patch was build-tested on 20 different arch-es.
It also makes these drivers SubmitChecklist#1 compliant.
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <lkp@intel.com> # drivers/media/platform/vimc/
Reported-by: kbuild test robot <lkp@intel.com> # drivers/pinctrl/pinctrl-u300.c
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull char/misc updates from Greg KH:
"Here is the big set of char/misc driver patches for 4.17-rc1.
There are a lot of little things in here, nothing huge, but all
important to the different hardware types involved:
- thunderbolt driver updates
- parport updates (people still care...)
- nvmem driver updates
- mei updates (as always)
- hwtracing driver updates
- hyperv driver updates
- extcon driver updates
- ... and a handful of even smaller driver subsystem and individual
driver updates
All of these have been in linux-next with no reported issues"
* tag 'char-misc-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (149 commits)
hwtracing: Add HW tracing support menu
intel_th: Add ACPI glue layer
intel_th: Allow forcing host mode through drvdata
intel_th: Pick up irq number from resources
intel_th: Don't touch switch routing in host mode
intel_th: Use correct method of finding hub
intel_th: Add SPDX GPL-2.0 header to replace GPLv2 boilerplate
stm class: Make dummy's master/channel ranges configurable
stm class: Add SPDX GPL-2.0 header to replace GPLv2 boilerplate
MAINTAINERS: Bestow upon myself the care for drivers/hwtracing
hv: add SPDX license id to Kconfig
hv: add SPDX license to trace
Drivers: hv: vmbus: do not mark HV_PCIE as perf_device
Drivers: hv: vmbus: respect what we get from hv_get_synint_state()
/dev/mem: Avoid overwriting "err" in read_mem()
eeprom: at24: use SPDX identifier instead of GPL boiler-plate
eeprom: at24: simplify the i2c functionality checking
eeprom: at24: fix a line break
eeprom: at24: tweak newlines
eeprom: at24: refactor at24_probe()
...
Arnd Bergmann
Wei Yongjun
Vijai Kumar K
Marek Szyprowski
Andy Shevchenko
Krzysztof Kozlowski
Greg Kroah-Hartman
Chanwoo Choi
Enric Balletbo i Serra
Wolfram Sang
Randy Dunlap
Kees Cook
Linus Torvalds