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

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

Merge tag 'char-misc-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2021-07-05T20:42:16+00:00

Pull char / misc driver updates from Greg KH:
 "Here is the big set of char / misc and other driver subsystem updates
  for 5.14-rc1. Included in here are:

   - habanalabs driver updates

   - fsl-mc driver updates

   - comedi driver updates

   - fpga driver updates

   - extcon driver updates

   - interconnect driver updates

   - mei driver updates

   - nvmem driver updates

   - phy driver updates

   - pnp driver updates

   - soundwire driver updates

   - lots of other tiny driver updates for char and misc drivers

  This is looking more and more like the "various driver subsystems
  mushed together" tree...

  All of these have been in linux-next for a while with no reported
  issues"

* tag 'char-misc-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (292 commits)
  mcb: Use DEFINE_RES_MEM() helper macro and fix the end address
  PNP: moved EXPORT_SYMBOL so that it immediately followed its function/variable
  bus: mhi: pci-generic: Add missing 'pci_disable_pcie_error_reporting()' calls
  bus: mhi: Wait for M2 state during system resume
  bus: mhi: core: Fix power down latency
  intel_th: Wait until port is in reset before programming it
  intel_th: msu: Make contiguous buffers uncached
  intel_th: Remove an unused exit point from intel_th_remove()
  stm class: Spelling fix
  nitro_enclaves: Set Bus Master for the NE PCI device
  misc: ibmasm: Modify matricies to matrices
  misc: vmw_vmci: return the correct errno code
  siox: Simplify error handling via dev_err_probe()
  fpga: machxo2-spi: Address warning about unused variable
  lkdtm/heap: Add init_on_alloc tests
  selftests/lkdtm: Enable various testable CONFIGs
  lkdtm: Add CONFIG hints in errors where possible
  lkdtm: Enable DOUBLE_FAULT on all architectures
  lkdtm/heap: Add vmalloc linear overflow test
  lkdtm/bugs: XFAIL UNALIGNED_LOAD_STORE_WRITE
  ...

extcon: sm5502: Add support for SM5504

2021-06-21T09:28:01+00:00

SM5504 is another MUIC from Silicon Mitus that is fairly similar
to SM5502. They seem to use the same register set, but:

  - SM5504 has some additional bits in SM5502_REG_CONTROL
  - SM5504 has a quite different set of interrupts
  - SM5504 reports USB OTG as dev_type1 = BIT(0) instead of BIT(7)

Overall it's minor and we can support this by defining a separate
struct sm5502_type for SM5504.

Signed-off-by: Stephan Gerhold 
Signed-off-by: Chanwoo Choi

extcon: sm5502: Refactor driver to use chip-specific struct

2021-06-21T09:28:01+00:00

Prepare for supporting SM5504 in the extcon-sm5502 driver by replacing
enum sm5504_types with a struct sm5504_type that stores the chip-specific
definitions. This struct can then be defined separately for SM5504
without having to add if (type == TYPE_SM5504) everywhere in the code.

Signed-off-by: Stephan Gerhold 
Signed-off-by: Chanwoo Choi

extcon: sm5502: Implement i2c_driver->probe_new()

2021-06-21T09:28:01+00:00

sm5022_muic_i2c_probe() does not use the i2c_device_id,
so implement i2c_driver->probe_new() instead of probe().

Signed-off-by: Stephan Gerhold 
Signed-off-by: Chanwoo Choi

extcon: sm5502: Use devm_regmap_add_irq_chip()

2021-06-21T09:28:00+00:00

Use devm_regmap_add_irq_chip() to avoid having to remove the
irqchip explicitly in sm5502_muic_i2c_remove().

Signed-off-by: Stephan Gerhold 
Signed-off-by: Chanwoo Choi

extcon: max8997: Add missing modalias string

2021-06-21T09:28:00+00:00

The platform device driver name is "max8997-muic", so advertise it
properly in the modalias string. This fixes automated module loading when
this driver is compiled as a module.

Fixes: b76668ba8a77 ("Extcon: add MAX8997 extcon driver")
Signed-off-by: Marek Szyprowski 
Signed-off-by: Chanwoo Choi

extcon: sm5502: Drop invalid register write in sm5502_reg_data

2021-06-21T09:28:00+00:00

When sm5502_init_dev_type() iterates over sm5502_reg_data to
initialize the registers it is limited by ARRAY_SIZE(sm5502_reg_data).
There is no need to add another empty element to sm5502_reg_data.

Having the additional empty element in sm5502_reg_data will just
result in writing 0xff to register 0x00, which does not really
make sense.

Fixes: 914b881f9452 ("extcon: sm5502: Add support new SM5502 extcon device driver")
Signed-off-by: Stephan Gerhold 
Signed-off-by: Chanwoo Choi