phy: apple: atc: Fall back to USB2 when pipehandler state is DUMMY#515
Open
p4ulcristian wants to merge 49 commits into
Open
phy: apple: atc: Fall back to USB2 when pipehandler state is DUMMY#515p4ulcristian wants to merge 49 commits into
p4ulcristian wants to merge 49 commits into
Conversation
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL streams carrying audio to be set as "high priority" using a vendor specific command to prevent 10-ish second-long dropouts whenever something does a device scan. This patch sends the command when the socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio. From experimenting with the hardware - this command is not suitable for per-skb priority switching, as prioritization is done on the handle level, with this command reconfiguring certain radio timings, and dropping to low priority in order to send a low packet on the same handle as an audio stream is being played on causes the same kind of dropout it is supposed to avoid. In addition, the hardware is rather picky about when this command can be sent, as sending it during connection open results in a timeout. The vendor stacks solve it by having high-level visibility into what a connection is used for and sending it from userspace when it is known that an audio stream is about to start. As we can't have that visibility without introducing a new ioctl, the socket priority is used as proxy. Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
The current approach of silently disabling all rust drivers if the toolchain is missing results in users that try to compile their own kernels getting a "successful" build and then being confused about where did their drivers go. In comparison, missing openssl results in a build failure, not a disappearance of everything that depends on it. This also means that allyesconfig will depend on rust, but since the rust experiment concluded with "rust is here to stay", i believe that allyesconfig should be building rust drivers too. Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Janne Grunau <j@jannau.net>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition to 'gP00' keys. Add a second compatible to handle this keys with an additional macsmc-gpio instance. Signed-off-by: Janne Grunau <j@jannau.net>
Add support for SMC GPIO keys with a lower letter 'p' via the "apple,smc-low-gpio" compatible. This adds support for a second macsmc-gpio controller using 'gp00' keys. These keys are used on Apple M3 Pro and Max MacBooks in the controller for keyboard and trackpad and for the built-in DisplayPort to HDMI converter. Signed-off-by: Janne Grunau <j@jannau.net>
Apple M3 Pro and Max devices are using 'gp00' keys for GPIO in addition to 'gP00' keys. These keys are handled by an additional macsmc-gpio instance using the "apple,smc-low-gpio" compatible. Signed-off-by: Janne Grunau <j@jannau.net>
- WLAN/BT (SMC PMU GPIO AsahiLinux#13) (all devices) - ASM3142 (SMC PMU GPIO AsahiLinux#14) (j434, iMac with 4 USB-C ports) - SD card reader (SMC PMU GPIO AsahiLinux#23) (j504, 14-inch MacBook Pro) Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Yureka <yuka@yuka.dev>
The internal keyboard and trackpad HID on MacBook variants of the Apple M3 (t8122) SoC are connected through a Apple -developed protocol called DockChannel and mediated by a coprocessor known as the Multi-Touch Processor (MTP). This commit adds the nessecary device tree nodes to the M3's device tree for internal HID to work. It is disabled by default, to be enabled only in MacBook board files where it is tested and confirmed to work. Co-developed-by: Alyssa Milburn <amilburn@zall.org> Signed-off-by: Alyssa Milburn <amilburn@zall.org> Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
Add mtp device nodes for t8122 (M3) based MacBooks. Signed-off-by: Michael Reeves <michael.reeves077@gmail.com>
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
List trackpad firmware files and activate MTP devices nodes on all t6030, t6031 and t6034 based MacBooks. Signed-off-by: Janne Grunau <j@jannau.net>
Add CPU core operating points tables for performance and efficiency cores and cpufreq nodes using "apple,t8112-cluster-cpufreq" as base compatible. Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Yureka <yuka@yuka.dev>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
This reverts commit 30fcc49.
Certain Broadcom bluetooth chips (bcm4377/bcm4378/bcm438) need ACL streams carrying audio to be set as "high priority" using a vendor specific command to prevent 10-ish second-long dropouts whenever something does a device scan. This patch sends the command when the socket priority is set to TC_PRIO_INTERACTIVE, as BlueZ does for audio. Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com>
Add CPU core operating points tables for performance and efficiency cores and cpufreq nodes using "apple,t8112-cluster-cpufreq" as base compatible. Signed-off-by: Janne Grunau <j@jannau.net>
Values determined by running coremark [1] via following script:
```
#!/bin/sh
set -e
CPUS="$@"
for CPU in ${CPUS}; do
echo performance > /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_governor
CUR_FREQ=$(cat /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_cur_freq)
echo -n "coremark on CPU core ${CPU} at ${CUR_FREQ%000} MHz: "
taskset -c ${CPU} make run1.log > /dev/null
grep 'Iterations/Sec' run1.log
echo schedutil > /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_governor
done
```
Link: https://github.com/eembc/coremark [1]
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Values determined by running coremark [1] via following script:
```
#!/bin/sh
set -e
CPUS="$@"
for CPU in ${CPUS}; do
echo performance > /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_governor
CUR_FREQ=$(cat /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_cur_freq)
echo -n "coremark on CPU core ${CPU} at ${CUR_FREQ%000} MHz: "
taskset -c ${CPU} make run1.log > /dev/null
grep 'Iterations/Sec' run1.log
echo schedutil > /sys/devices/system/cpu/cpu${CPU}/cpufreq/scaling_governor
done
```
Link: https://github.com/eembc/coremark [1]
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Values determined using coremark. Signed-off-by: Yureka <yuka@yuka.dev>
Signed-off-by: Janne Grunau <j@jannau.net>
When DP alt mode is active on a TypeC port, atcphy is configured in DP mode and atcphy_modes[mode].pipehandler_state is ATCPHY_PIPEHANDLER_STATE_DUMMY. If DWC3/xHCI then calls phy_set_mode(PHY_MODE_USB_HOST) on the USB3 PHY, atcphy_configure_pipehandler() hits the default branch and returns -EINVAL. This propagates through usb_phy_roothub_set_mode() -> usb_add_hcd() as error -22, failing the entire xhci-hcd probe. USB2 data to the TypeC device is lost, even though D+/D- are unaffected by DP alt mode. Fix this by configuring the dummy pipehandler instead of returning -EINVAL. DUMMY pipehandler state means SS lanes are not available for USB3, so DWC3/xHCI initialises in USB2-only mode and devices enumerate normally. This is consistent with how ATCPHY_PIPEHANDLER_STATE_USB4 is already handled. Tested on apple,j413 (M2 MacBook Air 13") with DP alt mode active: xhci-hcd.3.auto now probes successfully and USB2 HID devices enumerate. Signed-off-by: Paul Cristian <p4ulcristian@gmail.com>
p4ulcristian
force-pushed
the
fix/atcphy-dp-altmode-usb2-fallback
branch
from
ce338e3 to
fdb894d
Compare
|
Independently hit this and root-caused it to the same Reproduced on With the equivalent fix applied (explicit |
jannau
reviewed
Jun 12, 2026
| ret = -EINVAL; | ||
| /* DUMMY pipehandler state (DP-only, USB2-only, OFF): SS lanes are | ||
| * not available for USB3. Configure dummy so DWC3/xHCI falls back | ||
| * to USB2-only operation instead of failing probe. |
Member
There was a problem hiding this comment.
doesn't this just miss a case ATCPHY_PIPEHANDLER_STATE_DUMMY?
I would add
fallthrough;
case ATCPHY_PIPEHANDLER_STATE_DUMMY:
before line 1136 ("ret = atcphy_configure_pipehandler_dummy(atcphy);"). This way the -EINVAL for values not specified in the enum is preserved. I suspect this was the intention. @svenpeter42 ?
Another option would be adding a ATCPHY_PIPEHANDLER_STATE_DP state for APPLE_ATCPHY_MODE_DP. This would enable the dummy pipehandler for USB 2.0 operartion. This change should be added to the fairydust branch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When DP alt mode is active on a TypeC port, atcphy is configured in DP
mode and
atcphy_modes[mode].pipehandler_stateisATCPHY_PIPEHANDLER_STATE_DUMMY. If DWC3/xHCI then callsphy_set_mode(PHY_MODE_USB_HOST)on the USB3 PHY,atcphy_configure_pipehandler()hits thedefault:branch and returns-EINVAL.This propagates through
usb_phy_roothub_set_mode()→usb_add_hcd()as error -22, failing the entire
xhci-hcdprobe. USB2 data to theTypeC device is lost, even though D+/D- are unaffected by DP alt mode.
Fix this by configuring the dummy pipehandler instead of returning
-EINVAL.DUMMYpipehandler state means SS lanes are not availablefor USB3, so DWC3/xHCI initialises in USB2-only mode and devices
enumerate normally. This is consistent with how
ATCPHY_PIPEHANDLER_STATE_USB4is already handled.Tested on
apple,j413(M2 MacBook Air 13") with DP alt mode active:xhci-hcd.3.autonow probes successfully and USB2 HID devices enumerate(USB HID glasses
idVendor=1bbb idProduct=af50on USB bus 1).Signed-off-by: Paul Cristian p4ulcristian@gmail.com