On Tue, Nov 07, 2017 at 11:37:07AM +0100, Roberto Sassu wrote:
> Commit b65a9cfc2c38 ("Untangling ima mess, part 2: deal with counters")
> moved the call of ima_file_check() from may_open() to do_filp_open() at a
> point where the file descriptor is already opened.
>
> This breaks the assumption
Hello,
This series introduces support for the MAX31785 intelligent fan controller, a
PMBus device providing closed-loop fan control among a number of other
features. Along the way the series adds support to control fans and create
virtual pages to the PMBus core, the latter to support some of the
The dual tachometer feature is implemented in hardware with a TACHSEL
input to indicate the rotor under measurement, and exposed on the device
by extending the READ_FAN_SPEED_1 word with two extra bytes*. The need
to read the non-standard four-byte response leads to a cut-down
implementation of
Some circumstances call for virtual pages, to expose multiple values
packed into an extended PMBus register in a manner non-compliant with
the PMBus standard. An example of this is the Maxim MAX31785 controller, which
extends the READ_FAN_SPEED_1 PMBus register from two to four bytes to support
Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
Fans in a PMBus device are driven by the configuration of two registers,
FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
and the tacho operate (if installed), while FAN_COMMAND_x sets the
desired fan rate. The
This patch adds the Documentation/x86/intel_bm.txt file with some
information about Intel Branch monitoring.
Signed-off-by: Megha Dey
---
Documentation/x86/intel_bm.txt | 216 +
1 file changed, 216 insertions(+)
create mode
This patchset adds support for Intel's branch monitoring feature. This
feature uses heuristics to detect the occurrence of an ROP(Return Oriented
Programming) or ROP like(JOP: Jump oriented programming) attack. These
heuristics are based off certain performance monitoring statistics,
measured
Add CPUID of Cannonlake (CNL) processors to Intel family list.
Signed-off-by: Megha Dey
---
arch/x86/include/asm/intel-family.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/include/asm/intel-family.h
b/arch/x86/include/asm/intel-family.h
index
On Sat, Nov 18, 2017 at 12:34:33AM +0100, Thomas Gleixner wrote:
> On Fri, 17 Nov 2017, Darren Hart wrote:
>
> @intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
> do without the silly moderation spam of that list. Please disable that
> nonsense.
>
> > On Mon, Nov 13, 2017
On Fri, 17 Nov 2017, Darren Hart wrote:
@intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can
do without the silly moderation spam of that list. Please disable that
nonsense.
> On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
> Is SGX considered architectural
On Thu, 16 Nov 2017 14:23:09 +0100
Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address
On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:
Please do not submit patches to LKML without a commit message. There is
*always* something you can provide to give the review additional context
to aid in their review of your code.
As Thomas has noted, the various maintainers have
On 11/17/2017 08:53 AM, Stephen Boyd wrote:
> It isn't clear if this function of_node_put()s the 'from'
> argument, or the node it searches. Clearly indicate which
> variable is touched. Fold in some more fixes from Randy too
> because we're in the area.
>
> Cc: Randy Dunlap
It isn't clear if this function of_node_put()s the 'from'
argument, or the node it searches. Clearly indicate which
variable is touched. Fold in some more fixes from Randy too
because we're in the area.
Cc: Randy Dunlap
Signed-off-by: Stephen Boyd
On 17 November 2017 at 15:31, Rafael J. Wysocki wrote:
> On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson wrote:
>> [...]
>>
>> Second, have you considered setting the default value of
>> dev->power.may_skip_resume to true?
>
> Yes.
On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson wrote:
> [...]
>
>>>
> Second, have you considered setting the default value of
> dev->power.may_skip_resume to true?
Yes.
> That would means the subsystem
> instead need to implement an opt-out
On Fri, Nov 17, 2017 at 7:11 AM, Ulf Hansson wrote:
> [...]
>
>>> > +++ linux-pm/include/linux/pm.h
>>> > @@ -559,6 +559,7 @@ struct pm_subsys_data {
>>> > * NEVER_SKIP: Do not skip system suspend/resume callbacks for the
>>> > device.
>>> > * SMART_PREPARE: Check the
On Fri, Nov 17, 2017 at 12:07 AM, Rafael J. Wysocki wrote:
> On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote:
>> On 12 November 2017 at 01:37, Rafael J. Wysocki wrote:
>> > From: Rafael J. Wysocki
>> >
>> >
On 2017-11-17 19:36, Thomas Gleixner wrote:
On Fri, 17 Nov 2017, Quan Xu wrote:
On 2017-11-16 17:53, Thomas Gleixner wrote:
That's just plain wrong. We don't want to see any of this PARAVIRT crap in
anything outside the architecture/hypervisor interfacing code which really
needs it.
The
On Fri, 2017-11-17 at 09:55 +0100, Roberto Sassu wrote:
> On 11/17/2017 2:08 AM, Kees Cook wrote:
> > On Tue, Nov 7, 2017 at 8:45 AM, Roberto Sassu
> > wrote:
> >> On 11/7/2017 2:37 PM, Mimi Zohar wrote:
> >>> Normally, the protection of kernel memory is out of scope
On Fri, 17 Nov 2017, Quan Xu wrote:
> On 2017-11-16 17:53, Thomas Gleixner wrote:
> > That's just plain wrong. We don't want to see any of this PARAVIRT crap in
> > anything outside the architecture/hypervisor interfacing code which really
> > needs it.
> >
> > The problem can and must be solved
On 2017-11-16 17:53, Thomas Gleixner wrote:
On Thu, 16 Nov 2017, Quan Xu wrote:
On 2017-11-16 06:03, Thomas Gleixner wrote:
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
On Thu, Nov 16, 2017 at 02:23:09PM +0100, Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the
On Thu, 16 Nov 2017, Greg Kroah-Hartman wrote:
> Sometimes a single patch is the result of multiple authors. As git only
> can have one "author" of a patch, it is still good to properly give
> credit to the other developers of a commit. To address this, document
> the "Co-Developed-by:" tag
I realize the Cc: list for the cover letter probably should have included all
the relevant maintainers for this set, sorry about that!
For convenience I also put up a more reader friendly copy of the doc after
patch 7 here:
Hi Kees,
Thank you for the proof reading. I will fix the typos/language, but
see the comments on bigger things inside.
> On Tue, Nov 14, 2017 at 11:55 PM, Elena Reshetova
> wrote:
> > Some functions from refcount_t API provide different
> > memory ordering
26 matches
Mail list logo