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.

Sign up for GitHub

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

Jump to bottom

Describe upstream regulators for Witherspoon's BMP280 #183

Open
amboar opened this issue Jul 23, 2019 · 6 comments
Open

Describe upstream regulators for Witherspoon's BMP280 #183

amboar opened this issue Jul 23, 2019 · 6 comments

Comments

@amboar
Copy link
Member

amboar commented Jul 23, 2019

Currently the following warnings are issued for Witherspoon's devicetree:

arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dt.yaml: bmp280@77: 'vddd-supply' is a required property
arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dt.yaml: bmp280@77: 'vdda-supply' is a required property
@spinler
Copy link

spinler commented Jul 23, 2019

FYI, that device only existed on some early lab versions of that system, and didn't ship to the field.

@amboar
Copy link
Member Author

amboar commented Jul 24, 2019

Can we drop it from the devicetree then?

@msbarth
Copy link

msbarth commented Jul 24, 2019

@amboar, I'd prefer that it does not get dropped as that would then cause these lab systems still in use to no longer have an available ambient sensor.

@bjwyman
Copy link

bjwyman commented Jul 25, 2019

Not that I am a kernel guru or anything, but BMP280 issue caught my eye.

I was curious what those were, and why they would be required.

Is it just me, or did those start out as optional and move to required?
https://patchwork.ozlabs.org/patch/637124/

@amboar
Copy link
Member Author

amboar commented Jul 30, 2019

@bjwyman hah! Indeed they did, but not in the change you pointed to, but rather this one:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.3-rc2&id=88aa7ae661284accd4c058429d6d0a3b7397e081

This was introduced in v5.2. I'll poke people.

@bjwyman
Copy link

bjwyman commented Jul 30, 2019

Okay, I was just noting that going back to the patch I mentioned, those appeared to be optional, but somehow they later ended up as required. The change you pointed to is obviously where that was introduced.

amboar pushed a commit that referenced this issue Mar 27, 2024
@Vudentz
Bluetooth: af_bluetooth: Fix deadlock
64be3c6 
[ Upstream commit f7b94bd ]

Attemting to do sock_lock on .recvmsg may cause a deadlock as shown
bellow, so instead of using sock_sock this uses sk_receive_queue.lock
on bt_sock_ioctl to avoid the UAF:

INFO: task kworker/u9:1:121 blocked for more than 30 seconds.
      Not tainted 6.7.6-lemon #183
Workqueue: hci0 hci_rx_work
Call Trace:
 <TASK>
 __schedule+0x37d/0xa00
 schedule+0x32/0xe0
 __lock_sock+0x68/0xa0
 ? __pfx_autoremove_wake_function+0x10/0x10
 lock_sock_nested+0x43/0x50
 l2cap_sock_recv_cb+0x21/0xa0
 l2cap_recv_frame+0x55b/0x30a0
 ? psi_task_switch+0xeb/0x270
 ? finish_task_switch.isra.0+0x93/0x2a0
 hci_rx_work+0x33a/0x3f0
 process_one_work+0x13a/0x2f0
 worker_thread+0x2f0/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe0/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 </TASK>

Fixes: 2e07e83 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_sock_recvmsg")
Signed-off-by: Luiz Augusto von Dentz <[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
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@amboar @spinler @bjwyman @msbarth