When partner does not support get_status message, tcpm right now
responds with soft reset message. This causes PD renegotiation to
happen and resets PPS link. Avoid soft resetting the link when
partner does not support get_status message to mitigate PPS resets.

[  208.926752] Setting voltage/current limit 9500 mV 2450 mA
[  208.930407] set_auto_vbus_discharge_threshold mode:3 pps_active:y vbus:9500 ret:0
[  208.930418] state change SNK_TRANSITION_SINK -> SNK_READY [rev3 POWER_NEGOTIATION]
[  208.930455] AMS POWER_NEGOTIATION finished

// ALERT message from the Source
[  213.948442] PD RX, header: 0x19a6 [1]
[  213.948451] state change SNK_READY -> GET_STATUS_SEND [rev3 GETTING_SOURCE_SINK_STATUS]
[  213.948457] PD TX, header: 0x492
[  213.950402] PD TX complete, status: 0
[  213.950427] pending state change GET_STATUS_SEND -> GET_STATUS_SEND_TIMEOUT @ 60 ms [rev3 GETTING_SOURCE_SINK_STATUS]

// NOT_SUPPORTED from the Source
[  213.959954] PD RX, header: 0xbb0 [1]

// sink sends SOFT_RESET
[  213.959958] state change GET_STATUS_SEND -> SNK_SOFT_RESET [rev3 GETTING_SOURCE_SINK_STATUS]
[  213.959962] AMS GETTING_SOURCE_SINK_STATUS finished
[  213.959964] AMS SOFT_RESET_AMS start
[  213.959966] state change SNK_SOFT_RESET -> AMS_START [rev3 SOFT_RESET_AMS]
[  213.959969] state change AMS_START -> SOFT_RESET_SEND [rev3 SOFT_RESET_AMS]

Cc: stable@vger.kernel.org
Fixes: 8dea75e1

 ("usb: typec: tcpm: Protocol Error handling")
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230820044449.1005889-1-badhri@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The try_src_count and try_snk_count may still be 1 after enter into
unattached state. This may be caused by below case:
 - SNK_TRY->SNK_TRY_WAIT->SRC_TRYWAIT->SNK_UNATTACHED
 - SRC_TRY->SRC_TRY_WAIT->SNK_TRYWAIT->SNK_UNATTACHED

The port->attached is not true at the end and tcpm_reset_port() will not
be called. This will reset counter into for these cases, otherwise the tcpm
won't try role when new cable attached.

Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230820151518.1403006-1-xu.yang_2@nxp.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When sending Discover Identity messages to a Port Partner that uses Power
Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0,
expecting the port partner to respond with its highest supported SVDM
version as stated in Section 6.4.4.2.3 in the Power Delivery v3
specification. However, sending SVDM v2 to some Power Delivery v2 port
partners results in a NAK whereas sending SVDM v1 does not.

NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1),
and one solution could be to resend Discover Identity on a lower SVDM
version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK
response Should be taken as an indication not to retry that particular
Command."

Instead, we can set the SVDM version to the maximum one supported by the
negotiated PD revision. When operating in PD v2, this obeys Section
6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate
Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate
Version 2.0."

Fixes: c34e85fa

 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230731165926.1815338-1-rdbabiera@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The dwc2 driver has everything we need to run in PCI mode except
for pci_device_id driver_data parse.  With that to set Loongson
dwc2 element and added identified as PCI_VENDOR_ID_LOONGSON
and PCI_DEVICE_ID_LOONGSON_DWC2 in dwc2_pci_ids, the Loongson
dwc2 controller will work.

Signed-off-by: Yinbo Zhu <zhuyinbo@loongson.cn>
Link: https://lore.kernel.org/r/20230815065833.3375-1-zhuyinbo@loongson.cn


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Take ecm_bind() for example, it call gadget_is_{*}speed() API to show
gadget max support speed, it is not much help, remove the API usage here
is safe.

Similar change apply to acm,eem,loopback,ncm,obex,rndis,serial,
sourcesink,subset functions.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-8-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

When call this function, gadget already have working speed, if it is
USB_SPEED_SUPER_PLUS, in theroy gadget_is_superspeed_plus() checking
should be true, so there is no need to call it. it is same for other
working speed.

Remove all gadget_is_{*}speed_plus() API call to clean it up.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-7-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_assign_descriptors() usally called inside function bind operation,
and gadget still have no working connection speed, let's support all
speed at this point, it may possible allocate extra memory to store
descriptors, but it is small and acceptable.

Remove gadget_is_{*}speed() API checking to allow support all speed.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-6-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Take f_midi_bind() for example,  when composite layer call it, it will
allocate hs descriptor by calling gadget_is_dualspeed() API to check
gadget max support speed capability, but most other gadget function didn't
do like this.

To follow other function drivers, it is safe to remove the check which
mean support all possible link speed by default in function driver.

Similar change apply to midi2 and uvc.

Also in midi and midi2, as there is no descriptor difference between
super speed and super speed plus, follow other gadget function drivers,
do not allocate descriptor for super speed plus, composite layer will
handle it properly.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-5-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

when call uvc_function_bind(), gadget still have no connection speed,
just follow other gadget function, use fs endpoint descriptor to allocate
a video endpoint, remove gadget_is_{super|dual}speed() API call.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-4-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In function ecm_bitrate(), it is not support report bit rate for super
speed plus mode, but it can use same bit rate value defined in ncm and
rndis.

Add a common inline function gether_bitrate() which report different for
all possible speeds, it can be used by ecm, ncm and rndis, also remove
old function from them.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-3-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Take ecm_bitrate() as example, it will be called after gadget device
link speed negotiation, consider code
if (gadget_is_superspeed(g) && g->speed == USB_SPEED_SUPER),
if a gadget device link speed is USB_SPEED_SUPER,
gadget_is_superspeed(g) must be true, or not it is a wrong
configuration of gadget max support speed.

Remove gadget_is_superspeed(g) checking should be safe, and remove other
similar operation in ncm, rndis, u_ether.

Signed-off-by: Linyu Yuan <quic_linyyuan@quicinc.com>
Link: https://lore.kernel.org/r/20230803091053.9714-2-quic_linyyuan@quicinc.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Exynos850 has dwc3 compatible USB controller, so it can reuse existing
dwc3 glue layer. Document a new compatible for Exynos850 and its clocks.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20230819031731.22618-2-semen.protsenko@linaro.org


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add Exynos850 compatible string and associated driver data. Only two
clocks are needed for this SoC:
  - bus_early: bus clock needed for registers access
  - ref: USB 2.0 DRD reference clock (50 MHz)

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230819031731.22618-4-semen.protsenko@linaro.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The bitwise attribute is used by the sparse utility to make sure the
variable is converted to the local processor type before other (unsafe)
operations are performed on the variable. Fix the below sparse warnings
type casted with __le16:

warning: incorrect type in assignment (different base types)
   expected unsigned short [usertype]
   got restricted __le16 [usertype]

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/


Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
Link: https://lore.kernel.org/r/20230822063201.16929-4-piyush.mehta@amd.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_ctrlrequest member wValue, wLength and wIndex are of type __le16,
conversion macro cpu_to_le16() input argument is __u16, so properly
typecasted to fix the cast from restricted __le16 warning.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/


Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
Link: https://lore.kernel.org/r/20230822063201.16929-3-piyush.mehta@amd.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_ctrlrequest members wValue and wIndex are of type __le16, so to fix
this warnings we are using le16_to_cpu() macros.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/all/202209020044.CX2PfZzM-lkp@intel.com/


Signed-off-by: Piyush Mehta <piyush.mehta@amd.com>
Link: https://lore.kernel.org/r/20230822063201.16929-2-piyush.mehta@amd.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If the controller is dead, the honest answer to the
question whether it has caused an irq is: unknown
As the purpose of the irq return is to trigger switching
off an IRQ, the correct response if you cannot
determine if your device has caused the interrupt is
IRQ_HANDLED

Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20230822112455.18957-1-oneukum@suse.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

If the serial device never reads data written to it (because it is "output
only") then the write buffers will still be waiting for the URB to complete
on close(), which will hang for 30s until the closing_wait timeout expires.

This can happen with the ESP32-H2/ESP32-C6 USB serial interface. Changing
the port closing_wait timeout is a privileged operation but flushing the
output buffer is not a privileged operation.

Implement the flush_buffer tty operation to cancel in-progress writes so
that tcflush(fd, TCOFLUSH) can be used to unblock the serial port before
close.

Signed-off-by: Simon Arlott <simon@octiron.net>
Link: https://lore.kernel.org/r/555fbc4c-043b-8932-fb9b-a208d61ffbe4@0882a8b5-c6c3-11e9-b005-00805fc181fe.uuid.home.arpa


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The current approach to handling DP on bridge-enabled platforms requires
a chain of DP bridges up to the USB-C connector. Register a last DRM
bridge for such chain.

Acked-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20230817150824.14371-3-dmitry.baryshkov@linaro.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In the embedded cases, the DisplayPort connector is handled by the TCPM
itself. It was proposed to add the "displayport" OF property to the DT
bindings, but it  was rejected in favour of properly describing the
electrical signal path using of_graph.

Fallback to the controller fwnode for HPD notifications to
support such usecases without requiring additional DT properties.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20230817150824.14371-2-dmitry.baryshkov@linaro.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

These declarations are not implemented anymore, remove them.

Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20230818124025.51576-1-yuehaibing@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Remove unnecessary platform_set_drvdata(..., NULL) in ->remove(),
the driver_data will be cleared in device_unbind_cleanup() after
calling ->remove() in driver call code.

Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20230810134710.114356-1-yangyingliang@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dcd_change notification call moved outside of the acm->read_lock
to protect any future tty ldisc that calls wait_serial_change()

Signed-off-by: Dan Drown <dan-netdev@drown.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/ZN1zV/zjPgpGlHXo@vps3.drown.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

According the "USB Type-C Port Controller Interface Specification v2.0"
the TCPC sets the fault status register bit-7
(AllRegistersResetToDefault) once the registers have been reset to
their default values.

This triggers an alert(-irq) on PTN5110 devices albeit we do mask the
fault-irq, which may cause a kernel hang. Fix this generically by writing
a one to the corresponding bit-7.

Cc: stable@vger.kernel.org
Fixes: 74e656d6

 ("staging: typec: Type-C Port Controller Interface driver (tcpci)")
Reported-by: "Angus Ainslie (Purism)" <angus@akkea.ca>
Closes: https://lore.kernel.org/all/20190508002749.14816-2-angus@akkea.ca/


Reported-by: Christian Bach <christian.bach@scs.ch>
Closes: https://lore.kernel.org/regressions/ZR0P278MB07737E5F1D48632897D51AC3EB329@ZR0P278MB0773.CHEP278.PROD.OUTLOOK.COM/t/


Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230816172502.1155079-1-festevam@gmail.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Some usb hubs will negotiate DisplayPort Alt mode with the device
but will then negotiate a data role swap after entering the alt
mode. The data role swap causes the device to unregister all alt
modes, however the usb hub will still send Attention messages
even after failing to reregister the Alt Mode. type_altmode_attention
currently does not verify whether or not a device's altmode partner
exists, which results in a NULL pointer error when dereferencing
the typec_altmode and typec_altmode_ops belonging to the altmode
partner.

Verify the presence of a device's altmode partner before sending
the Attention message to the Alt Mode driver.

Fixes: 8a37d87d

 ("usb: typec: Bus type for alternate modes")
Cc: stable@vger.kernel.org
Signed-off-by: RD Babiera <rdbabiera@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230814180559.923475-1-rdbabiera@google.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the module_led_trigger macro to simplify the code, which is the
same as declaring with module_init() and module_exit().

Signed-off-by: Li Zetao <lizetao1@huawei.com>
Link: https://lore.kernel.org/r/20230815074648.1015175-1-lizetao1@huawei.com


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Device connected to usb otg port of GXL-based boards can not be
recognised after resumption, doesn't recover even if disconnect and
reconnect the device. dmesg shows it disconnects during resumption.

[   41.492911] usb 1-2: USB disconnect, device number 3
[   41.499346] usb 1-2: unregistering device
[   41.511939] usb 1-2: unregistering interface 1-2:1.0

Calling usb_post_init() will fix this issue, and it's tested and
verified on libretech's aml-s905x-cc board.

Cc: stable@vger.kernel.org # v5.8+
Fixes: c9999337

 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
Signed-off-by: Luke Lu <luke.lu@libre.computer>
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20230809212911.18903-1-luke.lu@libre.computer


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The correct compatible for Exynos5433 is "samsung,exynos5433-dwusb3".
Fix the typo in its usage.

Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Fixes: 949ea75b

 ("dt-bindings: usb: samsung,exynos-dwc3: convert to dtschema")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230816201123.3530-1-semen.protsenko@linaro.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The Exynos5433 DTSI had always different order of DWC USB3 controller
clocks than the binding.  The order in the binding was introduced in the
commit 949ea75b ("dt-bindings: usb: samsung,exynos-dwc3: convert to
dtschema") converting to DT schema.  The Linux driver does not care
about order and was always getting clocks by name.  Therefore assume the
DTS is the preferred order and correct the binding.

Fixes: 949ea75b

 ("dt-bindings: usb: samsung,exynos-dwc3: convert to dtschema")
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20230818102911.18388-1-krzysztof.kozlowski@linaro.org


Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'thunderbolt-for-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next

Mika writes:

thunderbolt: Changes for v6.6 merge window

This includes following Thunderbolt/USB4 changes for the v6.6 merge
window:

  - Replace broken mailing list address in the ABI document
  - Small improvements.

All these have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  Documentation/ABI: thunderbolt: Replace 01.org in contact
  thunderbolt: Check Intel vendor ID in tb_switch_get_generation()
  thunderbolt: Log a warning if device links are not found
  thunderbolt: Set variable tmu_params storage class specifier to static

We need the USB and Thunderbolt fixes in here to build on.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'kbuild-fixes-v6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Clear errno before calling getline()

 - Fix a modpost warning for ARCH=alpha

* tag 'kbuild-fixes-v6.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  alpha: remove __init annotation from exported page_is_ram()
  scripts/kallsyms: Fix build failure by setting errno before calling getline()

Merge tag 'platform-drivers-x86-v6.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform drivers fixes from Hans de Goede:

 -  lenovo-ymc driver causes keyboard + touchpad to not work with >= 6.4
    on some Thinkbook models, fix this

 -  A set of small fixes for mlx-platform

 -  Other small fixes and hw-id additions

* tag 'platform-drivers-x86-v6.5-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
  platform/x86: lenovo-ymc: Only bind on machines with a convertible DMI chassis-type
  platform: mellanox: Change register offset addresses
  platform: mellanox: mlx-platform: Modify graceful shutdown callback and power down mask
  platform: mellanox: mlx-platform: Fix signals polarity and latch mask
  platform: mellanox: Fix order in exit flow
  platform/x86: ISST: Reduce noise for missing numa information in logs
  platform/x86: msi-ec: Fix the build
  ACPI: scan: Create platform device for CS35L56
  platform/x86/amd/pmf: Fix unsigned comparison with less than zero

Pull SCSI fixes from James Bottomley:
 "Eleven small fixes, ten in drivers.

  Of the two fixes marked core, one is in the raid helper class (used by
  some raid device drivers) and the other one is the /proc/scsi/scsi
  parsing fix for potential reads beyond the end of the buffer"

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
  scsi: qedf: Fix firmware halt over suspend and resume
  scsi: qedi: Fix firmware halt over suspend and resume
  scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock
  scsi: lpfc: Remove reftag check in DIF paths
  scsi: ufs: renesas: Fix private allocation
  scsi: snic: Fix possible memory leak if device_add() fails
  scsi: core: Fix possible memory leak if device_add() fails
  scsi: core: Fix legacy /proc parsing buffer overflow
  scsi: 53c700: Check that command slot is not NULL
  scsi: fnic: Replace return codes in fnic_clean_pending_aborts()
  scsi: storvsc: Fix handling of virtual Fibre Channel timeouts

The lenovo-ymc driver is causing the keyboard + touchpad to stop working
on some regular laptop models such as the Lenovo ThinkBook 13s G2 ITL 20V9.

The problem is that there are YMC WMI GUID methods in the ACPI tables
of these laptops, despite them not being Yogas and lenovo-ymc loading
causes libinput to see a SW_TABLET_MODE switch with state 1.

This in turn causes libinput to ignore events from the builtin keyboard
and touchpad, since it filters those out for a Yoga in tablet mode.

Similar issues with false-positive SW_TABLET_MODE=1 reporting have
been seen with the intel-hid driver.

Copy the intel-hid driver approach to fix this and only bind to the WMI
device on machines where the DMI chassis-type indicates the machine
is a convertible.

Add a 'force' module parameter to allow overriding the chassis-type check
so that users can easily test if the YMC interface works on models which
report an unexpected chassis-type.

Fixes: e82882cd ("platform/x86: Add driver for Yoga Tablet Mode switch")
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2229373


Cc: André Apitzsch <git@apitzsch.eu>
Cc: stable@vger.kernel.org
Tested-by: Andrew Kallmeyer <kallmeyeras@gmail.com>
Tested-by: Gergő Köteles <soyer@irl.hu>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230812144818.383230-1-hdegoede@redhat.com

Move debug register offsets to different location due to hardware changes.

Fixes: dd635e33

 ("platform: mellanox: Introduce support of new Nvidia L1 switch")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20230813083735.39090-5-vadimp@nvidia.com


Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Use kernel_power_off() instead of kernel_halt() to pass through
machine_power_off() -> pm_power_off(), otherwise axillary power does
not go off.

Change "power down" bitmask.

Fixes: dd635e33

 ("platform: mellanox: Introduce support of new Nvidia L1 switch")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20230813083735.39090-4-vadimp@nvidia.com


Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Change polarity of chassis health and power signals and fix latch reset
mask for L1 switch.

Fixes: dd635e33

 ("platform: mellanox: Introduce support of new Nvidia L1 switch")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20230813083735.39090-3-vadimp@nvidia.com


Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Fix exit flow order: call mlxplat_post_exit() after
mlxplat_i2c_main_exit() in order to unregister main i2c driver before
to "mlxplat" driver.

Fixes: 0170f616

 ("platform: mellanox: Split initialization procedure")
Signed-off-by: Vadim Pasternak <vadimp@nvidia.com>
Reviewed-by: Michael Shych <michaelsh@nvidia.com>
Link: https://lore.kernel.org/r/20230813083735.39090-2-vadimp@nvidia.com


Signed-off-by: Hans de Goede <hdegoede@redhat.com>