Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Intel-SIG] [Meteor Lake] Bluetooth: add support for Intel Misty Peak - 8087:0038 #77

Conversation

pangqiao
Copy link

cd69949403f74 USB: core: Use device_driver directly in struct usb_driver and usb_device_driver
From commit 49a78b0 ("USB: core: Use device_driver directly in struct usb_driver and usb_device_driver")

e67f1218e1b79 Bluetooth: btintel: Print firmware SHA1
From commit a2e7707 ("Bluetooth: btintel: Print firmware SHA1")

01c4f2ba8fdd4 Bluetooth: btusb: Don't suspend when there are connections
From commit 4e0a1d8 ("Bluetooth: btusb: Don't suspend when there are connections")

73dc2a8faff8e Bluetooth: Add support for Intel Misty Peak - 8087:0038
From commit a97258d ("Bluetooth: Add support for Intel Misty Peak - 8087:0038")

satijav and others added 4 commits February 19, 2024 10:47
commit a97258d ("Bluetooth: Add support for Intel Misty Peak - 8087:0038") upstream.

Devices from /sys/kernel/debug/usb/devices:

T:  Bus=01 Lev=01 Prnt=01 Port=13 Cnt=02 Dev#=  3 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0038 Rev= 0.00
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms

deepin-Intel-SIG: commit a97258d ("Bluetooth: Add support for Intel Misty Peak - 8087:0038").

Signed-off-by: Vijay Satija <[email protected]>
Signed-off-by: Kiran K <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
[ Wei Qiao: amend commit log ]
Signed-off-by: Wei Qiao <[email protected]>
commit 4e0a1d8 ("Bluetooth: btusb: Don't suspend when there are connections") upstream.

This checks if there are connections before suspending since that may
disrupt the connections making it stop receiving any data if remote
wakeup is not enabled.

deepin-Intel-SIG: commit 4e0a1d8 ("Bluetooth: btusb: Don't suspend when there are connections").

Signed-off-by: Luiz Augusto von Dentz <[email protected]>
[ Wei Qiao: amend commit log ]
Signed-off-by: Wei Qiao <[email protected]>
commit a2e7707 ("Bluetooth: btintel: Print firmware SHA1") upstream.

Intel Read Version event contains a TLV(0x32) having firmware sha1 in
operational image.

deepin-Intel-SIG: commit a2e7707 ("Bluetooth: btintel: Print firmware SHA1").

Signed-off-by: Kiran K <[email protected]>
Signed-off-by: Luiz Augusto von Dentz <[email protected]>
[ Wei Qiao: amend commit log ]
Signed-off-by: Wei Qiao <[email protected]>
…vice_driver

commit 49a78b0 ("USB: core: Use device_driver directly in struct usb_driver and usb_device_driver") upstream.

There is usbdrv_wrap in struct usb_driver and usb_device_driver, it
contains device_driver and for_devices. for_devices is used to
distinguish between device drivers and interface drivers.

Like the is_usb_device(), it tests the type of the device. We can test
that if the probe of device_driver is equal to usb_probe_device in
is_usb_device_driver(), and then the struct usbdrv_wrap is no longer
needed.

Clean up struct usbdrv_wrap, use device_driver directly in struct
usb_driver and usb_device_driver. This makes the code cleaner.

deepin-Intel-SIG: commit 49a78b0 ("USB: core: Use device_driver directly in struct usb_driver and usb_device_driver").

Signed-off-by: Yajun Deng <[email protected]>
Acked-by: Alan Stern <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
[ Wei Qiao: amend commit log ]
Signed-off-by: Wei Qiao <[email protected]>
@deepin-ci-robot
Copy link

Hi @pangqiao. Thanks for your PR.

I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@deepin-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign hudeng-go for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@pangqiao pangqiao changed the title Bluetooth add support f[Intel-SIG] [Meteor Lake] Bluetooth: add support for Intel Misty Peak - 8087:0038or intel misty peak [Intel-SIG] [Meteor Lake] Bluetooth: add support for Intel Misty Peak - 8087:0038 Feb 19, 2024
@matrix-wsk matrix-wsk merged commit 7d3f571 into deepin-community:linux-6.6.y Feb 19, 2024
1 check was pending
matrix-wsk pushed a commit to matrix-wsk/kernel-6.6 that referenced this pull request Feb 23, 2024
[ Upstream commit b16904f ]

With latest upstream llvm18, the following test cases failed:

  $ ./test_progs -j
  deepin-community#13/2    bpf_cookie/multi_kprobe_link_api:FAIL
  deepin-community#13/3    bpf_cookie/multi_kprobe_attach_api:FAIL
  deepin-community#13      bpf_cookie:FAIL
  deepin-community#77      fentry_fexit:FAIL
  deepin-community#78/1    fentry_test/fentry:FAIL
  deepin-community#78      fentry_test:FAIL
  deepin-community#82/1    fexit_test/fexit:FAIL
  deepin-community#82      fexit_test:FAIL
  deepin-community#112/1   kprobe_multi_test/skel_api:FAIL
  deepin-community#112/2   kprobe_multi_test/link_api_addrs:FAIL
  [...]
  deepin-community#112     kprobe_multi_test:FAIL
  deepin-community#356/17  test_global_funcs/global_func17:FAIL
  deepin-community#356     test_global_funcs:FAIL

Further analysis shows llvm upstream patch [1] is responsible for the above
failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c,
without [1], the asm code is:

  0000000000000400 <bpf_fentry_test7>:
     400: f3 0f 1e fa                   endbr64
     404: e8 00 00 00 00                callq   0x409 <bpf_fentry_test7+0x9>
     409: 48 89 f8                      movq    %rdi, %rax
     40c: c3                            retq
     40d: 0f 1f 00                      nopl    (%rax)

... and with [1], the asm code is:

  0000000000005d20 <bpf_fentry_test7.specialized.1>:
    5d20: e8 00 00 00 00                callq   0x5d25 <bpf_fentry_test7.specialized.1+0x5>
    5d25: c3                            retq

... and <bpf_fentry_test7.specialized.1> is called instead of <bpf_fentry_test7>
and this caused test failures for deepin-community#13/deepin-community#77 etc. except deepin-community#356.

For test case deepin-community#356/17, with [1] (progs/test_global_func17.c)), the main prog
looks like:

  0000000000000000 <global_func17>:
       0:       b4 00 00 00 2a 00 00 00 w0 = 0x2a
       1:       95 00 00 00 00 00 00 00 exit

... which passed verification while the test itself expects a verification
failure.

Let us add 'barrier_var' style asm code in both places to prevent function
specialization which caused selftests failure.

  [1] llvm/llvm-project#72903

Signed-off-by: Yonghong Song <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants