ig4: Add Lunar Lake-M I2C controllers 4 and 5
Commit 851dffef532a added the Lunar Lake-M I2C controllers 0 through 3
(0xa878-0xa87b), which sit on PCI device 0x15. The platform exposes two
further controllers at 0xa850 and 0xa851 on PCI device 0x19, reported by
Intel as I2C #4 and #5. This mirrors the layout already handled for
Arrow Lake-U, where both the 0x777x and 0x775x ranges are listed.
On an HP OmniBook X Flip 16-as0xxx (Core Ultra 9 288V) the firmware
enables only four of the six controllers, and both HID devices sit on
the two that were missing: an ELAN2514 touchscreen on controller 4 and
a SYNA3503 touchpad on controller 5. Neither attaches without this
change, so the machine has no working pointing device.
Like the other four, these use the Tiger Lake revision of the I2C IP;
Linux treats 0xa850/0xa851 identically to 0xa878-0xa87b in
intel-lpss-pci.c.
Tested on: HP OmniBook X Flip 16-as0xxx (Intel Core Ultra 9 288V)
[6 lines not shown]
ig4: Add support for Lunar Lake-M I2C
this patch adds PCI IDs to the ig4(4) driver:
- Lunar Lake-M (0xa878, 0xa879, 0xa87a, 0xa87b)
These controllers use the Tiger Lake hardware revision of the I2C IP.
Adding these IDs enables support for peripherals connected to the I2C Bus.
Tested on: Intel Lunar Lake (LENOVO_MT_21QX_BU_Think_FM_ThinkPad T14s Gen 6)
Signed-off-by: Defenso-EBO <etienne.bonnand at defenso.fr>
MFC after: 2 weeks
Sponsored by: Defenso
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1995
(cherry picked from commit 851dffef532ad9611fcaf02318744c8de9f397b0)
ig4: Add Lunar Lake-M I2C controllers 4 and 5
Commit 851dffef532a added the Lunar Lake-M I2C controllers 0 through 3
(0xa878-0xa87b), which sit on PCI device 0x15. The platform exposes two
further controllers at 0xa850 and 0xa851 on PCI device 0x19, reported by
Intel as I2C #4 and #5. This mirrors the layout already handled for
Arrow Lake-U, where both the 0x777x and 0x775x ranges are listed.
On an HP OmniBook X Flip 16-as0xxx (Core Ultra 9 288V) the firmware
enables only four of the six controllers, and both HID devices sit on
the two that were missing: an ELAN2514 touchscreen on controller 4 and
a SYNA3503 touchpad on controller 5. Neither attaches without this
change, so the machine has no working pointing device.
Like the other four, these use the Tiger Lake revision of the I2C IP;
Linux treats 0xa850/0xa851 identically to 0xa878-0xa87b in
intel-lpss-pci.c.
Tested on: HP OmniBook X Flip 16-as0xxx (Intel Core Ultra 9 288V)
[6 lines not shown]
ig4: Add support for Lunar Lake-M I2C
this patch adds PCI IDs to the ig4(4) driver:
- Lunar Lake-M (0xa878, 0xa879, 0xa87a, 0xa87b)
These controllers use the Tiger Lake hardware revision of the I2C IP.
Adding these IDs enables support for peripherals connected to the I2C Bus.
Tested on: Intel Lunar Lake (LENOVO_MT_21QX_BU_Think_FM_ThinkPad T14s Gen 6)
Signed-off-by: Defenso-EBO <etienne.bonnand at defenso.fr>
MFC after: 2 weeks
Sponsored by: Defenso
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1995
(cherry picked from commit 851dffef532ad9611fcaf02318744c8de9f397b0)
deskutils/taskwarrior: Fix i386 build and WITH_DEBUG builds
- Cast to time_t in Datetime::operator+/- (libshared): time_t is 32-bit
on i386, so the braced return narrowed int64_t and clang rejected it
with -Wc++11-narrowing. Only needed on 32-bit architectures, so apply
the patch through EXTRA_PATCHES when ARCH is i386 instead of always.
- Stop upstream from compiling -DTASK_TEST_RCDIR="${CMAKE_SOURCE_DIR}/doc/rc"
into the binary for Debug builds: WITH_DEBUG made the binary write
"include <WRKSRC>/doc/rc/default.theme" into every generated .taskrc,
breaking it once the work directory is removed. Also drop the
ineffective -DCMAKE_BUILD_TYPE=release (Uses/cmake.mk appends its own
CMAKE_BUILD_TYPE afterwards, which always wins).
jail: set default root directory for a jail to its parent's root.
All default jail parameter values are an empty or otherwise standard
value, or are copied the jail's parent. A notable exception is the
root directory, which is instead copied from the creating process's
jail. Fix that to be in line with everything else.
This change affects only the default when no path is specified; if
a path of "/" is explicitly given, that will still be the creating
process's root directory.
fusefs: fix a deadlock caused by daemons that never initialize
If a daemon never responds to FUSE_INIT, but some process attempts to
access the mountpoint, and a different process (possibly the daemon
itself) attempts to unmount, a deadlock would result.
Fix this bug by blocking any thread that enters fuse_vfsop_root until
the daemon responds to FUSE_INIT or it times out. That will block any
thread attempting to lookup a path in the fuse mountpoint, before it
even gets to fuse VOPs. Remove less thorough initialization checks in
fuse_ticket_fetch and fuse_vnop_access that are no longer necessary.
And add a test case.
PR: 287431
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: js
Differential Revision: https://reviews.freebsd.org/D59737
