summaryrefslogtreecommitdiff
path: root/drivers/acpi/acpi_dbg.c
AgeCommit message (Collapse)AuthorFilesLines
2018-02-12vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds1-2/+2
This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-11-28acpi: annotate ->poll() instancesAl Viro1-2/+2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-06-22ACPI: fix whitespace in pr_fmt() to align log entriesVincent Legoll1-1/+1
See this dmesg extract before the patch: [ 0.679466] ACPI: Dynamic OEM Table Load: [ 0.679470] ACPI: SSDT 0xFFFF910F6B497E00 00018A (v02 PmRef ApCst 00003000 INTL 20160422) [ 0.679579] ACPI: Executed 1 blocks of module-level executable AML code [ 0.681477] ACPI : EC: EC started [ 0.681478] ACPI : EC: interrupt blocked [ 0.684798] ACPI: Interpreter enabled [ 0.684835] ACPI: (supports S0 S3 S4 S5) Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-06ACPI / debugger: Fix regression introduced by IS_ERR_VALUE() removalLv Zheng1-2/+2
The FIFO unlocking mechanism in acpi_dbg has been broken by the following commit: Commit: 287980e49ffc0f6d911601e7e352a812ed27768e Subject: remove lots of IS_ERR_VALUE abuses It converted !IS_ERR_VALUE(ret) into !ret which was not entirely correct. Fix the regression by taking ret > 0 into account too as appropriate. Fixes: 287980e49ffc (remove lots of IS_ERR_VALUE abuses) Signed-off-by: Lv Zheng <lv.zheng@intel.com> [ rjw: Simplifications, changelog & subject massage ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-05-28remove lots of IS_ERR_VALUE abusesArnd Bergmann1-11/+11
Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-12-28ACPI / debugger: Fix a redundant mutex unlock issue in acpi_aml_open()Lv Zheng1-1/+2
Fix a double mutex_unlock() issue where acpi_initialize_debugger() is called with the mutex already unlocked. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-28ACPI / debugger: copy_to_user doesn't return errorsDan Carpenter1-4/+6
The copy_to/from_user() functions don't return error codes, they return the number of bytes remaining. We had intended to return -EFUALT here. We actually have already checked access_ok() in an earlier function so I don't think these functions will fail but let's fix it anyway. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-28ACPI / debugger: remove some unneeded conditionsDan Carpenter1-4/+0
"count" is unsigned so checking for less than zero here causes a static checker warning. And really it's better to let the access_ok() check fail if the user passes in a NULL "buf" pointer because -EFAULT is the correct error code. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-28ACPI / debugger: Fix an issue a flag is modified without lockingLv Zheng1-1/+1
There is one line of code, executed out of locking due to rebase mistakes. This patch fixes this issue. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-15ACPI / debugger: Add module support for ACPI debuggerLv Zheng1-27/+53
This patch converts AML debugger into a loadable module. Note that, it implements driver unloading at the level dependent on the module reference count. Which means if ACPI debugger is being used by a userspace program, "rmmod acpi_dbg" should result in failure. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-15ACPI / debugger: Add IO interface to access debugger functionalitiesLv Zheng1-0/+779
This patch adds /sys/kernel/debug/acpi/acpidbg, which can be used by userspace programs to access ACPICA debugger functionalities. Known issue: 1. IO flush support acpi_os_notify_command_complete() and acpi_os_wait_command_ready() can be used by acpi_dbg module to implement .flush() filesystem operation. While this patch doesn't go that far. It then becomes userspace tool's duty now to flush old commands before executing new batch mode commands. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>