<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/platform/chrome, branch v6.2</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.2</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.2'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2022-12-16T11:22:53Z</updated>
<entry>
<title>Merge tag 'usb-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb</title>
<updated>2022-12-16T11:22:53Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-12-16T11:22:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=58bcac11fd94f950abc7b8466c5ceac7be07a00e'/>
<id>urn:sha1:58bcac11fd94f950abc7b8466c5ceac7be07a00e</id>
<content type='text'>
Pull USB and Thunderbolt driver updates from Greg KH:
 "Here is the large set of USB and Thunderbolt driver changes for
  6.2-rc1. Overall, thanks to the removal of a driver, more lines were
  removed than added, a nice change. Highlights include:

   - removal of the sisusbvga driver that was not used by anyone anymore

   - minor thunderbolt driver changes and tweaks

   - chipidea driver updates

   - usual set of typec driver features and hardware support added

   - musb minor driver fixes

   - fotg210 driver fixes, bringing that hardware back from the "dead"

   - minor dwc3 driver updates

   - addition, and then removal, of a list.h helper function for many
     USB and other subsystem drivers, that ended up breaking the build.
     That will come back for 6.3-rc1, it missed this merge window.

   - usual xhci updates and enhancements

   - usb-serial driver updates and support for new devices

   - other minor USB driver updates

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

* tag 'usb-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (153 commits)
  usb: gadget: uvc: Rename bmInterfaceFlags -&gt; bmInterlaceFlags
  usb: dwc2: power on/off phy for peripheral mode in dual-role mode
  usb: dwc2: disable lpm feature on Rockchip SoCs
  dt-bindings: usb: mtk-xhci: add support for mt7986
  usb: dwc3: core: defer probe on ulpi_read_id timeout
  usb: ulpi: defer ulpi_register on ulpi_read_id timeout
  usb: misc: onboard_usb_hub: add Genesys Logic GL850G hub support
  dt-bindings: usb: Add binding for Genesys Logic GL850G hub controller
  dt-bindings: vendor-prefixes: add Genesys Logic
  usb: fotg210-udc: fix potential memory leak in fotg210_udc_probe()
  usb: typec: tipd: Set mode of operation for USB Type-C connector
  usb: gadget: udc: drop obsolete dependencies on COMPILE_TEST
  usb: musb: remove extra check in musb_gadget_vbus_draw
  usb: gadget: uvc: Prevent buffer overflow in setup handler
  usb: dwc3: qcom: Fix memory leak in dwc3_qcom_interconnect_init
  usb: typec: wusb3801: fix fwnode refcount leak in wusb3801_probe()
  usb: storage: Add check for kcalloc
  USB: sisusbvga: use module_usb_driver()
  USB: sisusbvga: rename sisusb.c to sisusbvga.c
  USB: sisusbvga: remove console support
  ...
</content>
</entry>
<entry>
<title>Merge tag 'acpi-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm</title>
<updated>2022-12-12T21:38:17Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-12-12T21:38:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=456ed864fd907d5f5484c7c4795da212537842fe'/>
<id>urn:sha1:456ed864fd907d5f5484c7c4795da212537842fe</id>
<content type='text'>
Pull ACPI and PNP updates from Rafael Wysocki:
 "These include new code (for instance, support for the FFH address
  space type and support for new firmware data structures in ACPICA),
  some new quirks (mostly related to backlight handling and I2C
  enumeration), a number of fixes and a fair amount of cleanups all
  over.

  Specifics:

   - Update the ACPICA code in the kernel to the 20221020 upstream
     version and fix a couple of issues in it:
      - Make acpi_ex_load_op() match upstream implementation (Rafael
        Wysocki)
      - Add support for loong_arch-specific APICs in MADT (Huacai Chen)
      - Add support for fixed PCIe wake event (Huacai Chen)
      - Add EBDA pointer sanity checks (Vit Kabele)
      - Avoid accessing VGA memory when EBDA &lt; 1KiB (Vit Kabele)
      - Add CCEL table support to both compiler/disassembler (Kuppuswamy
        Sathyanarayanan)
      - Add a couple of new UUIDs to the known UUID list (Bob Moore)
      - Add support for FFH Opregion special context data (Sudeep
        Holla)
      - Improve warning message for "invalid ACPI name" (Bob Moore)
      - Add support for CXL 3.0 structures (CXIMS &amp; RDPAS) in the CEDT
        table (Alison Schofield)
      - Prepare IORT support for revision E.e (Robin Murphy)
      - Finish support for the CDAT table (Bob Moore)
      - Fix error code path in acpi_ds_call_control_method() (Rafael
        Wysocki)
      - Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage() (Li
        Zetao)
      - Update the version of the ACPICA code in the kernel (Bob Moore)

   - Use ZERO_PAGE(0) instead of empty_zero_page in the ACPI device
     enumeration code (Giulio Benetti)

   - Change the return type of the ACPI driver remove callback to void
     and update its users accordingly (Dawei Li)

   - Add general support for FFH address space type and implement the
     low- level part of it for ARM64 (Sudeep Holla)

   - Fix stale comments in the ACPI tables parsing code and make it
     print more messages related to MADT (Hanjun Guo, Huacai Chen)

   - Replace invocations of generic library functions with more kernel-
     specific counterparts in the ACPI sysfs interface (Christophe
     JAILLET, Xu Panda)

   - Print full name paths of ACPI power resource objects during
     enumeration (Kane Chen)

   - Eliminate a compiler warning regarding a missing function prototype
     in the ACPI power management code (Sudeep Holla)

   - Fix and clean up the ACPI processor driver (Rafael Wysocki, Li
     Zhong, Colin Ian King, Sudeep Holla)

   - Add quirk for the HP Pavilion Gaming 15-cx0041ur to the ACPI EC
     driver (Mia Kanashi)

   - Add some mew ACPI backlight handling quirks and update some
     existing ones (Hans de Goede)

   - Make the ACPI backlight driver prefer the native backlight control
     over vendor backlight control when possible (Hans de Goede)

   - Drop unsetting ACPI APEI driver data on remove (Uwe Kleine-König)

   - Use xchg_release() instead of cmpxchg() for updating new GHES cache
     slots (Ard Biesheuvel)

   - Clean up the ACPI APEI code (Sudeep Holla, Christophe JAILLET, Jay
     Lu)

   - Add new I2C device enumeration quirks for Medion Lifetab S10346 and
     Lenovo Yoga Tab 3 Pro (YT3-X90F) (Hans de Goede)

   - Make the ACPI battery driver notify user space about adding new
     battery hooks and removing the existing ones (Armin Wolf)

   - Modify the pfr_update and pfr_telemetry drivers to use ACPI_FREE()
     for freeing acpi_object structures to help diagnostics (Wang
     ShaoBo)

   - Make the ACPI fan driver use sysfs_emit_at() in its sysfs interface
     code (ye xingchen)

   - Fix the _FIF package extraction failure handling in the ACPI fan
     driver (Hanjun Guo)

   - Fix the PCC mailbox handling error code path (Huisong Li)

   - Avoid using PCC Opregions if there is no platform interrupt
     allocated for this purpose (Huisong Li)

   - Use sysfs_emit() instead of scnprintf() in the ACPI PAD driver and
     CPPC library (ye xingchen)

   - Fix some kernel-doc issues in the ACPI GSI processing code
     (Xiongfeng Wang)

   - Fix name memory leak in pnp_alloc_dev() (Yang Yingliang)

   - Do not disable PNP devices on suspend when they cannot be
     re-enabled on resume (Hans de Goede)

   - Clean up the ACPI thermal driver a bit (Rafael Wysocki)"

* tag 'acpi-6.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (67 commits)
  ACPI: x86: Add skip i2c clients quirk for Medion Lifetab S10346
  ACPI: APEI: EINJ: Refactor available_error_type_show()
  ACPI: APEI: EINJ: Fix formatting errors
  ACPI: processor: perflib: Adjust acpi_processor_notify_smm() return value
  ACPI: processor: perflib: Rearrange acpi_processor_notify_smm()
  ACPI: processor: perflib: Rearrange unregistration routine
  ACPI: processor: perflib: Drop redundant parentheses
  ACPI: processor: perflib: Adjust white space
  ACPI: processor: idle: Drop unnecessary statements and parens
  ACPI: thermal: Adjust critical.flags.valid check
  ACPI: fan: Convert to use sysfs_emit_at() API
  ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()
  ACPI: battery: Call power_supply_changed() when adding hooks
  ACPI: use sysfs_emit() instead of scnprintf()
  ACPI: x86: Add skip i2c clients quirk for Lenovo Yoga Tab 3 Pro (YT3-X90F)
  ACPI: APEI: Remove a useless include
  PNP: Do not disable devices on suspend when they cannot be re-enabled on resume
  ACPI: processor: Silence missing prototype warnings
  ACPI: processor_idle: Silence missing prototype warnings
  ACPI: PM: Silence missing prototype warning
  ...
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_typec: zero out stale pointers</title>
<updated>2022-12-08T01:44:48Z</updated>
<author>
<name>Victor Ding</name>
<email>victording@chromium.org</email>
</author>
<published>2022-12-07T09:39:40Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9a8aadcf0b459c1257b9477fd6402e1d5952ae07'/>
<id>urn:sha1:9a8aadcf0b459c1257b9477fd6402e1d5952ae07</id>
<content type='text'>
`cros_typec_get_switch_handles` allocates four pointers when obtaining
type-c switch handles. These pointers are all freed if failing to obtain
any of them; therefore, pointers in `port` become stale. The stale
pointers eventually cause use-after-free or double free in later code
paths. Zeroing out all pointer fields after freeing to eliminate these
stale pointers.

Fixes: f28adb41dab4 ("platform/chrome: cros_ec_typec: Register Type C switches")
Fixes: 1a8912caba02 ("platform/chrome: cros_ec_typec: Get retimer handle")
Signed-off-by: Victor Ding &lt;victording@chromium.org&gt;
Acked-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221207093924.v2.1.I1864b6a7ee98824118b93677868d22d3750f439b@changeid
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_typec: Set parent of partner PD object</title>
<updated>2022-11-29T07:56:09Z</updated>
<author>
<name>Prashant Malani</name>
<email>pmalani@chromium.org</email>
</author>
<published>2022-11-22T22:05:37Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ab3593eeef606816bcc28b12690c51379c3d12eb'/>
<id>urn:sha1:ab3593eeef606816bcc28b12690c51379c3d12eb</id>
<content type='text'>
In order to tell what Type-C device a PD object belongs to, its parent
needs to be set. Use the Type-C partner USB PD registration wrapper
to set the parent appropriately for PD objects which are created for
connected Type-C partners.

Cc: Benson Leung &lt;bleung@chromium.org&gt;
Cc: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
Link: https://lore.kernel.org/r/20221122220538.2991775-3-pmalani@chromium.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()</title>
<updated>2022-11-25T08:28:28Z</updated>
<author>
<name>Yuan Can</name>
<email>yuancan@huawei.com</email>
</author>
<published>2022-11-17T08:08:23Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5a2d96623670155d94aca72c320c0ac27bdc6bd2'/>
<id>urn:sha1:5a2d96623670155d94aca72c320c0ac27bdc6bd2</id>
<content type='text'>
The following WARNING message was given when rmmod cros_usbpd_notify:

 Unexpected driver unregister!
 WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
 Modules linked in: cros_usbpd_notify(-)
 CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
 ...
 Call Trace:
  &lt;TASK&gt;
  cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
  __x64_sys_delete_module+0x3c7/0x570
  ? __ia32_sys_delete_module+0x570/0x570
  ? lock_is_held_type+0xe3/0x140
  ? syscall_enter_from_user_mode+0x17/0x50
  ? rcu_read_lock_sched_held+0xa0/0xd0
  ? syscall_enter_from_user_mode+0x1c/0x50
  do_syscall_64+0x37/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 RIP: 0033:0x7f333fe9b1b7

The reason is that the cros_usbpd_notify_init() does not check the return
value of platform_driver_register(), and the cros_usbpd_notify can
install successfully even if platform_driver_register() failed.

Fix by checking the return value of platform_driver_register() and
unregister cros_usbpd_notify_plat_driver when it failed.

Fixes: ec2daf6e33f9 ("platform: chrome: Add cros-usbpd-notify driver")
Signed-off-by: Yuan Can &lt;yuancan@huawei.com&gt;
Reviewed-by: Brian Norris &lt;briannorris@chromium.org&gt;
Link: https://lore.kernel.org/r/20221117080823.77549-1-yuancan@huawei.com
Signed-off-by: Prashant Malani &lt;pmalani@chromium.org&gt;
</content>
</entry>
<entry>
<title>ACPI: make remove callback of ACPI driver void</title>
<updated>2022-11-23T18:11:22Z</updated>
<author>
<name>Dawei Li</name>
<email>set_pte_at@outlook.com</email>
</author>
<published>2022-11-13T16:26:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6c0eb5ba3500f6da367351ff3c4452c029cb72fa'/>
<id>urn:sha1:6c0eb5ba3500f6da367351ff3c4452c029cb72fa</id>
<content type='text'>
For bus-based driver, device removal is implemented as:
1 device_remove()-&gt;
2   bus-&gt;remove()-&gt;
3     driver-&gt;remove()

Driver core needs no inform from callee(bus driver) about the
result of remove callback. In that case, commit fc7a6209d571
("bus: Make remove callback return void") forces bus_type::remove
be void-returned.

Now we have the situation that both 1 &amp; 2 of calling chain are
void-returned, so it does not make much sense for 3(driver-&gt;remove)
to return non-void to its caller.

So the basic idea behind this change is making remove() callback of
any bus-based driver to be void-returned.

This change, for itself, is for device drivers based on acpi-bus.

Acked-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Acked-by: Lee Jones &lt;lee@kernel.org&gt;
Acked-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Dawei Li &lt;set_pte_at@outlook.com&gt;
Reviewed-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;  # for drivers/platform/surface/*
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec: Convert to i2c's .probe_new()</title>
<updated>2022-11-19T06:44:46Z</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2022-11-18T22:44:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f9e510dc92df270756b6a42d98c738525d01e8c3'/>
<id>urn:sha1:f9e510dc92df270756b6a42d98c738525d01e8c3</id>
<content type='text'>
The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221118224540.619276-513-uwe@kleine-koenig.org
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_lpc: Force synchronous probe</title>
<updated>2022-11-14T02:26:46Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-11-11T23:13:01Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=ca821c1f4ec11d6181da58118d158a015160106d'/>
<id>urn:sha1:ca821c1f4ec11d6181da58118d158a015160106d</id>
<content type='text'>
This reverts commit bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark
PROBE_PREFER_ASYNCHRONOUS"), and then some.

It has been reported that there are issues with 'cros-ec-keyb' devices
that are children of this. As noted in the initial patch for its ACPI
support (commit ba0f32141bc5 ("Input: cros_ec_keyb - handle x86
detachable/convertible Chromebooks")), it's possible to probe an ACPI
child device before its parent is probed -- hence the need for
EPROBE_DEFER. Unfortunately, poking your parent's dev_get_drvdata()
isn't safe with asynchronous probe, as there's no locking, and the
ordering is all wrong anyway (drvdata is set before the device is
*really* ready).

Because this parent/child relationship has known issues, let's go the
other direction and force synchronous probe, until we resolve the
issues.

Possible solutions involve adding device links, so we ensure the child
doesn't probe before the parent is done; or perhaps some other larger
refactoring (auxiliary bus?). But that might take a little more effort
and review, as there are many other potential sub-devices of
cros_ec_lpc that could need patching.

Note that we don't have the same problem for non-ACPI cros-ec hosts,
like cros-ec-spi (commit 015e4b05c377 ("platform/chrome: cros_ec_spi:
Set PROBE_PREFER_ASYNCHRONOUS")), because its sub-devices aren't created
until cros_ec_register(), or they don't exist at all (e.g., FPMCU uses).

Fixes: bd88b965ae8c ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Reviewed-by: Guenter Roeck &lt;groeck@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221111231302.3458191-1-briannorris@chromium.org
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_spi: Set PROBE_PREFER_ASYNCHRONOUS</title>
<updated>2022-11-02T04:28:47Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-11-01T22:22:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=015e4b05c377dc5e066e88737bff9990d5ac358d'/>
<id>urn:sha1:015e4b05c377dc5e066e88737bff9990d5ac358d</id>
<content type='text'>
This driver often takes on the order of 10ms to start, but in some cases
as much as 600ms [1]. It shouldn't have many cross-device dependencies
to race with, nor racy access to shared state with other drivers, so
this should be a relatively low risk change.

This driver was pinpointed as part of a survey of top slowest initcalls
(i.e., are built in, and probing synchronously) on a lab of ChromeOS
systems.

[1] 600ms was especially surprising to me, so I checked a little deeper.
This driver is used to interface with Embedded Controllers besides just
the traditional laptop power-state controller -- it also interfaces with
some fingerprint readers, which may start up in parallel with the
kernel, or which may not even be present on some SKUs, despite having a
node for it. Thus, our time is wasted just timing out talking to it. At
least we can do that without blocking everyone else.

Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221101152132.v2.5.Ia458a69e1d592bfa4f04cde7018bbc7486f91a23@changeid
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_lightbar: Set PROBE_PREFER_ASYNCHRONOUS</title>
<updated>2022-11-02T04:28:47Z</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2022-11-01T22:22:09Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=873ab3e886b52ba3d6ade3c5f3e6a0cff0c8cb12'/>
<id>urn:sha1:873ab3e886b52ba3d6ade3c5f3e6a0cff0c8cb12</id>
<content type='text'>
This driver takes on the order of 15ms to start on some systems. Even on
systems where there is no lightbar support, it can take a few
milliseconds just to probe the EC for support. It shouldn't have many
cross-device dependencies to race with, nor racy access to shared state
with other drivers, so this should be a relatively low risk change.

This driver was pinpointed as part of a survey of top slowest initcalls
(i.e., are built in, and probing synchronously) on a lab of ChromeOS
systems.

Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Tzung-Bi Shih &lt;tzungbi@kernel.org&gt;
Link: https://lore.kernel.org/r/20221101152132.v2.4.I565598102e0bfb03bdf8c090d3bfdf954d026bc5@changeid
</content>
</entry>
</feed>
