The only driver using this was dell-wmi, and it really was a hack.
The driver was getting a data attribute from another driver and this
type of action should not be encouraged.
Rather drivers that need to interact with one another should pass
data back and forth via exported functions.
Signed-off
For WMI operations that are only Set or Query read or write sysfs
attributes created by WMI vendor drivers make sense.
For other WMI operations that are run on Method, there needs to be a
way to guarantee to userspace that the results from the method call
belong to the data request to the method c
There are some categories of tokens and SMBIOS calls that it makes
sense to protect userspace from accessing. These are calls that
may write to one time use fields or activate hardware debugging
capabilities. They are not intended for general purpose use.
This same functionality may be be later
The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.
This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.
Changing this to
This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm
dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.
Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely. Rather than a sin
All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.
The information found from the WMI descriptor driver is now exported
for use by other drivers.
Sign
The existing way that the dell-smbios helper module and associated
other drivers (dell-laptop, dell-wmi) communicate with the platform
really isn't secure. It requires creating a buffer in physical
DMA32 memory space and passing that to the platform via SMM.
Since the platform got a physical memo
Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.
With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.
This is in
Some platforms this year will be adopting 32k WMI buffer, so don't
complain when encountering those.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/dell-wmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86
Some cases the wrong type was used for errors and checks can be
done more cleanly.
Signed-off-by: Mario Limonciello
Reviewed-by: Edward O'Callaghan
Suggested-by: Andy Shevchenko
---
drivers/platform/x86/dell-wmi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/d
The proper way to indicate that a system is a 'supported' Dell System
is by the presence of this string in OEM strings.
Allowing the driver to load on non-Dell systems will have undefined
results.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/dell-smbios.c | 7 +++
1 file change
Drivers properly using the wmibus can pass their wmi_device
pointer rather than the GUID back to the WMI bus to evaluate
the proper methods.
Any "new" drivers added that use the WMI bus should use this
rather than the old wmi_evaluate_method that would take the
GUID.
Signed-off-by: Mario Limoncie
There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.
If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the
Hi,
On Fri, Oct 06, 2017 at 05:51:35PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> This patch adds support to read/write slimbus value elements.
> Currently it only supports byte read/write. Adding this support in
> regmap would give codec drivers more flexibilit
The current ITS driver works fine as long as normal memory and GICR
regions are located within the lower 48bit (>=0 && <2^48) physical
address space. Some of the registers GICR_PEND/PROP, GICR_VPEND/VPROP
and GITS_CBASER are handled properly but not all when configuring
the hardware with 52bit phys
On Fri, 2017-10-06 at 15:36 -0500, Nathan Zimmer wrote:
> After the buyout/merger our @sgi.com address are slowing being less useful.
> So make sure we are can be contacted properly.
This seems more like a new entry so the commit
message seems wrong.
> Signed-off-by: Nathan Zimmer
> Signed-off-b
Hi Himanshu,
[auto build test ERROR on wireless-drivers-next/master]
[also build test ERROR on v4.14-rc3 next-20170929]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Himanshu-Jha/mwifiex-Use-pu
Hello,
Nice read, see some comments below
On Fri, Oct 06, 2017 at 11:34:30AM -0400, Steven Rostedt wrote:
> On Fri, 6 Oct 2017 13:49:59 +0900
> Masami Hiramatsu wrote:
>
> > Steve, could you write a documentation how to use ftrace callback?
> > I think I should update the Documentation/kprobes.
Hi Steve,
On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> The ftrace_mod_map is a descriptor to save module init function names in
> case they were traced, and the trace output needs to reference the function
> name from the function address. But afte
Hi,
On Fri, Oct 06, 2017 at 05:51:31PM +0200, srinivas.kandaga...@linaro.org wrote:
> From: Sagar Dharia
>
> Slimbus devices use value-element, and information elements to
> control device parameters (e.g. value element is used to represent
> gain for codec, information element is used to repres
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 5f82e71a001d14824a7728ad9e49f6aea420f161
Merge: 6c51e67b64d16 edc2988c548db
Author: Linus Torvalds
AuthorDate: Mon Sep 4 11:5
On Fri, Oct 06, 2017 at 11:59:52PM -0500, Mario Limonciello wrote:
> Currently userspace tools can access system tokens via the dcdbas
> kernel module and a SMI call that will cause the platform to execute
> SMM code.
>
> With a goal in mind of deprecating the dcdbas kernel module a different
> me
901 - 922 of 922 matches
Mail list logo
