-
Notifications
You must be signed in to change notification settings - Fork 144
SOF client support (auxiliary bus) #3007
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
Changes from 1 commit
a87a2b5
4d512ec
44b2a43
9115f5b
476d4c0
7274b1c
6a772ce
a858cfa
49abfdc
11f3b3a
20c9323
9e32894
bcaad35
92a48c2
9e675f2
deb5a0c
cba8df9
64a91b8
5f585a8
d6a888d
6677eec
68d6c63
39459f7
9e6b984
e8bab41
5c75bc5
b3089af
b269552
fd4a66c
5e3f492
f763eea
3bd20bb
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -33,8 +33,12 @@ struct sof_ipc_client_data { | |
|
|
||
| static int sof_ipc_dfsentry_open(struct inode *inode, struct file *file) | ||
| { | ||
| struct sof_client_dev *cdev = inode->i_private; | ||
| int ret; | ||
|
|
||
| if (sof_client_get_fw_state(cdev) == SOF_FW_CRASHED) | ||
| return -ENODEV; | ||
|
|
||
| ret = debugfs_file_get(file->f_path.dentry); | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can the debugfs file be removed while open if we already prevent the core from being removed? Or is debugfs managed by a different module?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. it is owned by this module and we only remove the file when removing the module.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have tried it with the dma-trace and removed the
I need to recompile the firmware with debug enabled to be able to test how the ipc-flood would behave, but I kind of expect similar behavior, likely the tgl rmmod would wait until the test finishes.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. so is this patch needed or not?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is needed, but the |
||
| if (unlikely(ret)) | ||
| return ret; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happened before this test was introduced? Did we get an error or a kernel oops?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first IPC tx would time-out (error prints from the core) and we aborted the test (error print in the flood test).
We could print in dmesg that the test can not be run due to the fact that the firmware is thought to be crashed.
There is definitely no point of trying to execute the test in this case.