On Mon, Apr 12, 2021 at 04:24:41PM -0500, Jassi Brar wrote:
> On Mon, Mar 8, 2021 at 2:20 PM mark gross wrote:
> >
> > On Fri, Mar 05, 2021 at 03:01:40PM -0600, Rob Herring wrote:
> > > On Fri, Feb 12, 2021 at 02:22:34PM -0800, mgr...@linux.intel.com wrote:
> > &
.@vger.kernel.org
> > Reviewed-by: Mark Gross
> > Signed-off-by: Mark Gross
> > Signed-off-by: Seamus Kelly
> > ---
> > .../bindings/misc/intel,keembay-xlink.yaml| 29 +++
> > 1 file changed, 29 insertions(+)
> > create mode 100644
s and xlink in particular).
I'm working to gather this info.
thanks!
--mark
>
> > enables communication between the Computing Sub-System (CSS) and the
> > Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem
> > Bay.
> >
> > Cc: Rob Herring
> &
On Thu, Feb 18, 2021 at 01:17:23PM -0600, Mario Limonciello wrote:
> On Dell systems that don't support this interface the module is
> mistakingly returning error code "0", when it should be returning
> -ENODEV. Correct a logic error to guarantee the correct return code.
>
> Cc: Divya Bharathi
On Thu, Feb 18, 2021 at 03:09:55PM -0600, Jassi Brar wrote:
> On Thu, Feb 18, 2021 at 6:02 AM Alessandrelli, Daniele
> wrote:
> >
> > Hi Jassi,
> >
> > Thank you very much for your feedback.
> >
> > On Sun, 2021-02-14 at 22:54 -0600, Jassi Brar wrote:
> > > IIUIC, maybe the solution is simpler
On Sat, Feb 13, 2021 at 01:58:17PM +0200, Matti Vaittinen wrote:
> It's not rare that device drivers need delayed work.
> It's not rare that this work needs driver's data.
>
> Often this means that driver must ensure the work is not queued when
> driver exits. Usually this is done by ensuring new
On Tue, Feb 16, 2021 at 10:36:13PM +0100, Petr Vaněk wrote:
> uses by -> used by
>
> Signed-off-by: Petr Vaněk
Reviewed-by: Mark Gross
Thanks for the clean up!
-mark
> ---
> drivers/platform/x86/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Sun, Feb 14, 2021 at 09:48:53AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:23 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/hddl_device/Kconfig
> > b/drivers/misc/hddl_device/Kconfig
> > index e1ae81fdf177..7f9a6a685275 100644
> > --- a/drivers/misc/hddl_device/Kconfig
> > +++
On Sun, Feb 14, 2021 at 09:47:51AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:23 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/hddl_device/Kconfig
> > b/drivers/misc/hddl_device/Kconfig
> > new file mode 100644
> > index ..e1ae81fdf177
> > --- /dev/null
> > +++
On Sun, Feb 14, 2021 at 09:42:22AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:23 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/intel_tsens/Kconfig
> > b/drivers/misc/intel_tsens/Kconfig
> > index be8d27e81864..5cfe6b4004e5 100644
> > --- a/drivers/misc/intel_tsens/Kconfig
> > +++
On Sun, Feb 14, 2021 at 09:41:26AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/intel_tsens/Kconfig
> > b/drivers/misc/intel_tsens/Kconfig
> > index 8b263fdd80c3..be8d27e81864 100644
> > --- a/drivers/misc/intel_tsens/Kconfig
> > +++
On Sun, Feb 14, 2021 at 09:45:56AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/intel_tsens/Kconfig
> > b/drivers/misc/intel_tsens/Kconfig
> > index bfb8fe1997f4..8b263fdd80c3 100644
> > --- a/drivers/misc/intel_tsens/Kconfig
> > +++
On Sun, Feb 14, 2021 at 09:44:53AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/intel_tsens/Kconfig
> > b/drivers/misc/intel_tsens/Kconfig
> > new file mode 100644
> > index ..bfb8fe1997f4
> > --- /dev/null
> > +++
On Sun, Feb 14, 2021 at 09:39:55AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/vpumgr/Kconfig b/drivers/misc/vpumgr/Kconfig
> > new file mode 100644
> > index ..bb82ff83afd3
> > --- /dev/null
> > +++
On Sun, Feb 14, 2021 at 09:52:51AM -0800, Randy Dunlap wrote:
> On 2/12/21 2:22 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/xlink-core/Kconfig
> > b/drivers/misc/xlink-core/Kconfig
> > new file mode 100644
> > index ..a0ceb0b48219
> > --- /dev/null
> > +++
Acked-by: Mark Gross
On Thu, Feb 11, 2021 at 12:04:11AM +0100, Maximilian Luz wrote:
> The raw message frame length is unaligned and explicitly marked as
> little endian. It should not be accessed without the appropriatte
> accessor functions. Fix this.
>
> Reported-by: ke
On Wed, Feb 10, 2021 at 09:39:11PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan
>
> In x86_64, tss.sp1 is reused as cpu_current_top_of_stack. We'd better
> directly use percpu since CR3 and gs_base is correct when it is used.
Be more direct if not using percpu is incorrect in some way.
>
to false.
>
> Note I've made this an int using the standard -1=auto, 0=off, 1=on
> triplett, with the hope that in the future we can come up with a
> better way to detect SW_TABLET_MODE support. ATM the default
> auto option just does the same as off.
>
> BugLink: h
devicet...@vger.kernel.org
> > Reviewed-by: Mark Gross
> > Signed-off-by: Paul Murphy
> > Co-developed-by: Daniele Alessandrelli
> > Signed-off-by: Daniele Alessandrelli
> > ---
> > .../soc/intel/intel,keembay-vpu-ipc.yaml | 153 ++
> &
On Tue, Jan 26, 2021 at 02:47:15PM +, Gross, Mark wrote:
>
>
> > -Original Message-
> > From: Rob Herring
> > Sent: Tuesday, January 26, 2021 5:45 AM
> > To: Mark Gross
> > Cc: markgr...@kernel.org; Arnd Bergmann ; Borislav Petkov
> > ;
On Mon, Jan 11, 2021 at 11:15:06PM -0800, Randy Dunlap wrote:
> On 1/8/21 1:25 PM, mgr...@linux.intel.com wrote:
> > diff --git a/drivers/misc/intel_tsens/Kconfig
> > b/drivers/misc/intel_tsens/Kconfig
> > index 8b263fdd80c3..c2138339bd89 100644
> > --- a/drivers/misc/intel_tsens/Kconfig
> > +++
On Wed, Jan 20, 2021 at 08:50:05PM -0800, Pan Bian wrote:
> Put the PCI device rdev on error paths to fix potential reference count
> leaks.
Can you make a stronger statment than "fix potenital reference count leaks?".
Also, make the commit comment match the code better.
maybe something like:
nd remote host.
> >
> > Cc: Arnd Bergmann
> > Cc: Greg Kroah-Hartman
> > Reviewed-by: Mark Gross
> > Signed-off-by: Srikanth Thokala
> > ---
> > drivers/misc/xlink-pcie/common/interface.c | 109 +++
> > drivers/misc/xlink
On Fri, Dec 18, 2020 at 03:30:18PM -0800, Randy Dunlap wrote:
> Hi--
>
> On 12/1/20 2:34 PM, mgr...@linux.intel.com wrote:
> > From: mark gross
> >
> >
> > Reviewed-by: Mark Gross
> > Signed-off-by: Mark Gross
>
> My reading of submitting-patc
On Fri, Dec 18, 2020 at 02:59:00PM -0800, Randy Dunlap wrote:
> On 12/1/20 2:34 PM, mgr...@linux.intel.com wrote:
> > From: Srikanth Thokala
> >
> > Provide overview of XLink PCIe driver implementation
> >
> > Cc: linux-...@vger.kernel.org
> >
On Tue, Dec 15, 2020 at 10:58:52AM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 14, 2020 at 2:44 PM Stephen Rothwell
> wrote:
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > MAINTAINERS
> >
> > between commit:
> >
> > 885743324513 ("crypto: keembay - Add support for
On Mon, Dec 07, 2020 at 02:31:37PM -0600, Jassi Brar wrote:
> On Mon, Dec 7, 2020 at 12:43 PM Daniele Alessandrelli
> wrote:
> >
> > Hi Rob,
> >
> > Thanks for the feedback.
> >
> > On Mon, 2020-12-07 at 10:01 -0600, Rob Herring wrote:
> > > On Tue, Dec 01, 2020 at 02:34:51PM -0800,
On Sun, Dec 06, 2020 at 07:05:34PM -0800, Joe Perches wrote:
> On Tue, 2020-12-01 at 14:35 -0800, mgr...@linux.intel.com wrote:
> > From: Seamus Kelly
> >
> > Refactor the too large IOCTL function to call helper functions.
>
> This should not be sent as a known poor patch as patch 21 of 22
>
ate with the VPU IP present on the Intel Keem Bay
> > SoC.
> >
> > Cc: devicet...@vger.kernel.org
> > Reviewed-by: Mark Gross
> > Signed-off-by: Seamus Kelly
> > Signed-off-by: Ryan Carnaghi
> > ---
> > .../misc/intel,keembay-xlink-ipc.yaml | 49
On Mon, Dec 07, 2020 at 09:57:26AM -0600, Rob Herring wrote:
> On Tue, 01 Dec 2020 14:34:53 -0800, mgr...@linux.intel.com wrote:
> > From: Paul Murphy
> >
> > Add DT bindings documentation for the Keem Bay VPU IPC driver.
> >
> > Cc: devicet...@vger.kerne
n between the Computing Sub-System (CSS) and the
> > Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem
> > Bay.
> >
> > Cc: devicet...@vger.kernel.org
> > Reviewed-by: Mark Gross
> > Signed-off-by: Daniele Alessandrelli
On Sat, Dec 05, 2020 at 04:37:25PM +, Gross, Mark wrote:
>
>
> > -Original Message-
> > From: Greg KH
> > Sent: Saturday, December 5, 2020 12:40 AM
> > To: mark gross
> > Cc: markgr...@kernel.org; a...@arndb.de; b...@suse.de;
> > damien.lem
On Wed, Dec 02, 2020 at 08:01:18PM +0100, Greg KH wrote:
> On Wed, Dec 02, 2020 at 09:42:00AM -0800, mark gross wrote:
> > On Wed, Dec 02, 2020 at 07:16:20AM +0100, Greg KH wrote:
> > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote:
> > > > -
ivers/char/hw_random/ixp4xx-rng.c
> >
> > +INTEL KEEM BAY IPC DRIVER
> > +M: Daniele Alessandrelli
> > +M: Mark Gross
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/soc/intel/intel,keembay-ipc.yaml
> > +F: drivers/soc/intel/keembay-ipc.c
> > +F: i
On Tue, Dec 01, 2020 at 06:54:28PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 01, 2020 at 09:45:43AM -0800, mark gross wrote:
> > On Tue, Dec 01, 2020 at 11:13:05AM +0100, Greg Kroah-Hartman wrote:
> > > On Mon, Nov 30, 2020 at 03:06:52PM -0800, mgr...@linux.intel.com w
On Tue, Dec 01, 2020 at 11:14:12AM +0100, Greg KH wrote:
> On Mon, Nov 30, 2020 at 03:06:45PM -0800, mgr...@linux.intel.com wrote:
> > From: mark gross
> >
> > The Intel Vision Processing Unit (VPU) is an IP block that is showing up for
> > the first time as part of
derlying PCIe HW controller is a Synopsys DWC PCIe core.
> >
> > Cc: Derek Kiernan
> > Cc: Dragan Cvetic
> > Cc: Arnd Bergmann
> > Cc: Greg Kroah-Hartman
> > Reviewed-by: Mark Gross
> > Signed-off-by: Srikanth Thokala
>
>
>
> Again,
On Thu, Oct 01, 2020 at 11:26:36AM +0200, Hans de Goede wrote:
> Hi,
>
> On 9/30/20 11:02 PM, Limonciello, Mario wrote:
> > > > + possible_values:A file that can be read to
> > > > obtain the possible
> > > > + values of the . Values
>
On Wed, Sep 30, 2020 at 09:02:38PM +, Limonciello, Mario wrote:
> > > + possible_values:A file that can be read to obtain the
> > > possible
> > > + values of the . Values are
> > > separated using
> > > +
l Systems.
>
> This driver allows user to configure Dell systems with a
> uniform common interface. To facilitate this, the patch
> introduces a generic way for driver to be able to create
> configurable BIOS Attributes available in Setup (F2) screen.
>
> Cc: Hans de Goede
> Cc: Andy Shev
Acked-by: Mark Gross
On Wed, Sep 23, 2020 at 04:56:14PM +0800, Voon Weifeng wrote:
> EEE should be only be enabled during stmmac_mac_link_up() when the
> link are up and being set up properly. set_eee should only do settings
> configuration and disabling the eee.
>
> Without th
Acked-by: mark gross
--mark
On Tue, Sep 15, 2020 at 12:09:23PM +0300, Necip Fazil Yildiran wrote:
> When LG_LAPTOP is enabled and NEW_LEDS is disabled, it results in the
> following Kbuild warning:
>
> WARNING: unmet direct dependencies detected for LEDS_CLASS
> Depends on [n
On Wed, Sep 16, 2020 at 09:12:33PM +0200, Samuel Čavoj wrote:
> The UX360CA has a WMI device id 0x00060062, which reports whether the
> lid is flipped in tablet mode (1) or in normal laptop mode (0).
>
> This commit adds a quirk (quirk_asus_use_lid_flip_devid) for devices on
> which this WMI
Acked-by: mark gross
--mark
On Sun, Sep 13, 2020 at 12:02:03PM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> clang static analysis flags this represenative problem
> thinkpad_acpi.c:2523:7: warning: Branch condition evaluates
> to a garbage value
>
On Sat, Sep 12, 2020 at 12:46:30AM +0200, Maximilian Luz wrote:
> On 9/12/20 12:10 AM, mark gross wrote:
> > Surface devices are tablets with detachable keyboards. they don't really
> > have a "lid" as the tablet is the "lid".
>
> The Surface Laptop serie
On Fri, Sep 04, 2020 at 07:58:46PM +0530, Divya Bharathi wrote:
> The Dell WMI Systems Management Driver provides a sysfs
> interface for systems management to enable BIOS configuration
> capability on certain Dell Systems.
>
> This driver allows user to configure Dell systems with a
> uniform
On Thu, Jul 09, 2020 at 12:42:57PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Jul 9, 2020 at 3:51 AM Thomas Gleixner wrote:
> >
> > Abhishek Bhardwaj writes:
> > > This change adds a new kernel configuration that sets the l1d cache
> > > flush setting at compile time rather than at run time.
On Thu, Jul 02, 2020 at 09:19:16AM -0700, Abhishek Bhardwaj wrote:
> This change adds a new kernel configuration that sets the l1d cache
> flush setting at compile time rather than at run time.
Why is this desired?
--mark
>
> Signed-off-by: Abhishek Bhardwaj
> ---
>
>
ack
Reviewed-by: mark gross
--mark
On Wed, Jun 17, 2020 at 07:14:10AM -0700, Guenter Roeck wrote:
> 0-day is not happy that there is no prototype for cpu_show_srbds().
>
> drivers/base/cpu.c:565:16: error:
> no previous prototype for 'cpu_show_srbds'
>
> R
+1
reviewed-by: Mark Gross
Thanks!
--mark
On Mon, Jun 15, 2020 at 10:36:45PM +0200, Heinrich Schuchardt wrote:
> The lengths of underlines must match the titles to avoid build warnings.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> .../hw-vuln/special-register-buffer-da
the text they are under.
>
> Fixes: 7222a1b5b874 ("x86/speculation: Add SRBDS vulnerability and mitigation
> documentation")
> Cc: Mark Gross
> Cc: Josh Poimboeuf
> Cc: Borislav Petkov
> Cc: Tony Luck
> Cc: Thomas Gleixner
> Cc: linux-kernel@vger.kernel.org
>
The following commit has been merged into the x86/cpu branch of tip:
Commit-ID: e9d7144597b10ff13ff2264c059f7d4a7fbc89ac
Gitweb:
https://git.kernel.org/tip/e9d7144597b10ff13ff2264c059f7d4a7fbc89ac
Author:Mark Gross
AuthorDate:Thu, 16 Apr 2020 17:23:10 +02:00
Committer
+1
--mark
On Wed, May 06, 2020 at 09:15:14AM +0200, Borislav Petkov wrote:
> From: Mark Gross
>
> Intel uses the same family/model for several CPUs. Sometimes the
> stepping must be checked to tell them apart.
>
> On x86 there can be at most 16 steppings. Add a
Reviewed-by: Mark Gross
On Wed, May 06, 2020 at 09:15:15AM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... to match Intel family 6 CPUs with steppings.
>
> Signed-off-by: Borislav Petkov
> ---
> arch/x86/include/asm/cpu_device_id.h | 4
> 1 fi
Reviewed-by: Mark Gross
On Wed, May 06, 2020 at 09:15:16AM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> ... and get rid of the function pointers which would spit out the
> microcode revision based on the CPU stepping.
>
> Signed-off-by: Borislav Petkov
&g
On Wed, May 29, 2019 at 08:36:47PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Introduce task_struct::core_cookie as an opaque identifier for core
> scheduling. When enabled; core scheduling will only allow matching
> task to be on the core; where idle matches everything.
>
On Wed, May 29, 2019 at 08:36:45PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Because sched_class::pick_next_task() also implies
> sched_class::set_next_task() (and possibly put_prev_task() and
> newidle_balance) it is not state invariant. This makes it unsuitable
> for
On Wed, May 29, 2019 at 08:36:44PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Avoid the RETRY_TASK case in the pick_next_task() slow path.
>
> By doing the put_prev_task() early, we get the rt/deadline pull done,
> and by testing rq->nr_running we know if we need
On Wed, May 29, 2019 at 08:36:43PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Currently the pick_next_task() loop is convoluted and ugly because of
> how it can drop the rq->lock and needs to restart the picking.
>
> For the RT/Deadline classes, it is put_prev_task() where
On Wed, May 29, 2019 at 08:36:38PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
NULL commit comment.
--mark
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> kernel/sched/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/core.c
On Wed, May 29, 2019 at 08:36:37PM +, Vineeth Remanan Pillai wrote:
> From: Peter Zijlstra
>
> Make sure the entire for loop has stop_cpus_in_progress set.
It is not clear how this commit comment matches the change. Please explain
how adding 2 barrier's makes sure stop_cpus_in_progress is
On Wed, Aug 30, 2017 at 07:30:58PM -0400, Steven Rostedt wrote:
> On Wed, 30 Aug 2017 14:47:19 -0700
> mark gross <mgr...@linux.intel.com> wrote:
>
>
> > > struct dentry *ras_debugfs_dir;
> > >
> > > static atomic_t trace_count = ATOMIC_INIT(
On Wed, Aug 30, 2017 at 07:30:58PM -0400, Steven Rostedt wrote:
> On Wed, 30 Aug 2017 14:47:19 -0700
> mark gross wrote:
>
>
> > > struct dentry *ras_debugfs_dir;
> > >
> > > static atomic_t trace_count = ATOMIC_INIT(0);
> > > @@ -12,7 +1
On Wed, Aug 30, 2017 at 01:48:43PM +0200, Borislav Petkov wrote:
> Btw,
>
> how about communicating stuff to the userspace daemon like this?
>
> This'll simplify a lot of detection in userspace.
>
> Thoughts?
>
> ---
> diff --git a/drivers/ras/debugfs.c b/drivers/ras/debugfs.c
> index
On Wed, Aug 30, 2017 at 01:48:43PM +0200, Borislav Petkov wrote:
> Btw,
>
> how about communicating stuff to the userspace daemon like this?
>
> This'll simplify a lot of detection in userspace.
>
> Thoughts?
>
> ---
> diff --git a/drivers/ras/debugfs.c b/drivers/ras/debugfs.c
> index
On Thu, Feb 27, 2014 at 10:47:58AM -0700, Stephen Warren wrote:
> On 02/27/2014 10:38 AM, Gross, Mark wrote:
> > Please know that no one should not consider me an authority on ACPI at this
> > time. But, I have some comments / context / thoughts below.
> >
> > Also I apologize in advance for any
On Thu, Feb 27, 2014 at 10:47:58AM -0700, Stephen Warren wrote:
On 02/27/2014 10:38 AM, Gross, Mark wrote:
Please know that no one should not consider me an authority on ACPI at this
time. But, I have some comments / context / thoughts below.
Also I apologize in advance for any email
On Sat, Jul 13, 2013 at 11:54:17AM -0700, Greg KH wrote:
> I'm announcing the release of the 3.9.10 kernel.
>
> Note, this might just be the last 3.9-stable kernel release, I'm not
> quite sure I can guarantee another 3.9-stable kernel will be released.
I guess this means 3.9 will NOT be this
On Sat, Jul 13, 2013 at 11:54:17AM -0700, Greg KH wrote:
I'm announcing the release of the 3.9.10 kernel.
Note, this might just be the last 3.9-stable kernel release, I'm not
quite sure I can guarantee another 3.9-stable kernel will be released.
I guess this means 3.9 will NOT be this years
should be sorted by freq
> + * in the ascending order.
> */
> struct devfreq_dev_profile {
> unsigned long initial_freq;
> unsigned int polling_ms;
>
> + /* Optional QoS Handling Specification */
> + int qos_type; /* 0: No global PM-QoS support */
> +
m_qos_update_request(struct dev
> mutex_lock(_pm_qos_mtx);
>
> if (req->dev->power.qos) {
> - if (new_value != req->node.prio)
> + if (new_value != req->data.pnode.prio)
> ret = apply_constraint(req, PM_QOS_UPDATE_REQ,
>
dev->dev,
> - >pm_qos, 100);
> + >pm_qos,
> + DEV_PM_QOS_LATENCY,
> + 100);
> if (ret < 0)
> dev_err(>pdev->dev,
> "PM QoS request failed: %d\n", ret);
> Index: linux/Documentation/power/pm_qos_interface.txt
> ===
> --- linux.orig/Documentation/power/pm_qos_interface.txt
> +++ linux/Documentation/power/pm_qos_interface.txt
> @@ -99,7 +99,7 @@ reading the aggregated value does not re
>
> From kernel mode the use of this interface is the following:
>
> -int dev_pm_qos_add_request(device, handle, value):
> +int dev_pm_qos_add_request(device, handle, type, value):
> Will insert an element into the list for that identified device with the
> target value. Upon change to this list the new target is recomputed and any
> registered notifiers are called only if the target value is now different.
>
Reviewed-by: mark gross
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
if (acpi_target_sleep_state == ACPI_STATE_S0 ||
> - (device_may_wakeup(dev) && adev->wakeup.flags.valid &&
> - adev->wakeup.sleep_state >= acpi_target_sleep_state)) {
> + if (wakeup) {
> acpi_status status;
>
>
QOS_FLAG_REMOTE_WAKEUP);
> + if (stat > PM_QOS_FLAGS_NONE)
> + return -EBUSY;
> +
> if (pdd->dev->driver && (!pm_runtime_suspended(pdd->dev)
> || pdd->dev->power.irq_safe))
>
sysfs_unmerge_group(>kobj, _qos_flags_attr_group);
> }
>
> void rpm_sysfs_remove(struct device *dev)
> Index: linux/Documentation/ABI/testing/sysfs-devices-power
> ===
> --- linux.orig/Documentation/ABI/testing/sysfs-devices-
PM_QOS_UPDATE_REQ:
> + pm_qos_flags_remove_req(pqf, req);
> + case PM_QOS_ADD_REQ:
> + req->flags = val;
> + INIT_LIST_HEAD(>node);
> + list_add_tail(>node, >list);
> + pqf->effective_flags |= val;
> + bre
On Mon, Oct 08, 2012 at 10:04:03AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Currently struct dev_pm_info contains only one PM QoS constraints
> pointer reserved for latency requirements. Since one more device
> constraints type (i.e. flags) will be necessary, introduce a
On Mon, Oct 08, 2012 at 10:04:03AM +0200, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Currently struct dev_pm_info contains only one PM QoS constraints
pointer reserved for latency requirements. Since one more device
constraints type (i.e. flags) will be
!= curr_value;
+}
+
+/**
* pm_qos_request - returns current system wide qos expectation
* @pm_qos_class: identification of which qos value is requested
*
acked-by: mark gross markgr...@thegnar.org
--mark
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
to be signaled from
+ its low-power states.
+
+ Not all drivers support this attribute. If it isn't supported,
+ it is not present.
+
+ This attribute has no effect on system-wide suspend/resume and
+ hibernation.
acked-by: mark gross
.
Reviewed-by: mark gross markgr...@thegnar.org
--mrak
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: mark gross markgr...@thegnar.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
are called only if the target value is now different.
Reviewed-by: mark gross markgr...@thegnar.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
,
new_value);
} else {
Reviewed-by: mark gross markgr...@thegnar.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
;
+ struct notifier_block qos_nb;
+ unsigned long qos_min_freq;
/* information for device freqeuncy transition */
unsigned int total_trans;
--
1.7.4.1
looks ok to me.
Reviewed-by: mark gross markgr...@thegnar.org
--mark
--
To unsubscribe from this list: send the line
On Mon, Sep 17, 2012 at 11:10:09PM +0200, Rafael J. Wysocki wrote:
> On Monday, September 17, 2012, MyungJoo Ham wrote:
> > Sender : Rafael J. Wysocki
> > Date : 2012-09-09 07:20 (GMT+09:00)
> > Title : Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support
> > > On Thursday, August 30, 2012,
On Mon, Sep 17, 2012 at 11:10:09PM +0200, Rafael J. Wysocki wrote:
On Monday, September 17, 2012, MyungJoo Ham wrote:
Sender : Rafael J. Wysockir...@sisk.pl
Date : 2012-09-09 07:20 (GMT+09:00)
Title : Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support
On Thursday, August 30,
On Mon, Feb 25, 2008 at 10:28:50AM -0800, Andrew Morton wrote:
> On Mon, 25 Feb 2008 09:54:02 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Feb 25, 2008 at 07:50:14AM -0800, mark gross wrote:
> > > On Sat, Feb 23, 2008 at 11:20:22AM -0800, Andrew Morton wrote:
On Sat, Feb 23, 2008 at 12:05:17AM -0800, Andrew Morton wrote:
> On Wed, 20 Feb 2008 16:06:23 -0800 mark gross <[EMAIL PROTECTED]> wrote:
>
> > The following patch is for batching up the flushing of the IOTLB for
> > the DMAR implementation found in the Intel
On Sat, Feb 23, 2008 at 12:05:12AM -0800, Andrew Morton wrote:
>
> > Subject: [PATCH]iova-lockdep-false-alarm-fix.
>
> Nice English titles, please...
>
> On Wed, 20 Feb 2008 16:35:28 -0800 mark gross <[EMAIL PROTECTED]> wrote:
>
> > lockdep goes off on
On Sat, Feb 23, 2008 at 11:20:22AM -0800, Andrew Morton wrote:
> On Sat, 23 Feb 2008 11:06:49 -0800 Greg KH <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Feb 23, 2008 at 12:04:43AM -0800, Andrew Morton wrote:
> > > On Thu, 21 Feb 2008 10:15:55 -0800 mark gros
On Sat, Feb 23, 2008 at 11:20:22AM -0800, Andrew Morton wrote:
On Sat, 23 Feb 2008 11:06:49 -0800 Greg KH [EMAIL PROTECTED] wrote:
On Sat, Feb 23, 2008 at 12:04:43AM -0800, Andrew Morton wrote:
On Thu, 21 Feb 2008 10:15:55 -0800 mark gross [EMAIL PROTECTED] wrote:
Index: linux
On Sat, Feb 23, 2008 at 12:05:12AM -0800, Andrew Morton wrote:
Subject: [PATCH]iova-lockdep-false-alarm-fix.
Nice English titles, please...
On Wed, 20 Feb 2008 16:35:28 -0800 mark gross [EMAIL PROTECTED] wrote:
lockdep goes off on the iova copy_reserved_iova because
On Sat, Feb 23, 2008 at 12:05:17AM -0800, Andrew Morton wrote:
On Wed, 20 Feb 2008 16:06:23 -0800 mark gross [EMAIL PROTECTED] wrote:
The following patch is for batching up the flushing of the IOTLB for
the DMAR implementation found in the Intel VT-d hardware. It works by
building a list
On Mon, Feb 25, 2008 at 10:28:50AM -0800, Andrew Morton wrote:
On Mon, 25 Feb 2008 09:54:02 -0800 Greg KH [EMAIL PROTECTED] wrote:
On Mon, Feb 25, 2008 at 07:50:14AM -0800, mark gross wrote:
On Sat, Feb 23, 2008 at 11:20:22AM -0800, Andrew Morton wrote:
On Sat, 23 Feb 2008 11:06:49
The following is a clean up and correction of the copyright holding
entities for the files associated with the intel iommu code.
Its a no brainer.
--mgross
Signed-off-by: <[EMAIL PROTECTED]>
Index: linux-2.6.24-mm1/drivers/pci/dmar.c
The following is a clean up and correction of the copyright holding
entities for the files associated with the intel iommu code.
Its a no brainer.
--mgross
Signed-off-by: [EMAIL PROTECTED]
Index: linux-2.6.24-mm1/drivers/pci/dmar.c
lockdep goes off on the iova copy_reserved_iova because it and a
function it calls grabs locks in the from, and the to of the copy
operation.
This patch gives the reserved_ioval_list locks special lockdep classes.
--mgross
Signed-off-by: <[EMAIL PROTECTED]>
Index:
The following patch is for batching up the flushing of the IOTLB for
the DMAR implementation found in the Intel VT-d hardware. It works by
building a list of to be flushed IOTLB entries and a bitmap list of
which DMAR engine they are from.
After either a high water mark (250 accessible via
The following patch is for batching up the flushing of the IOTLB for
the DMAR implementation found in the Intel VT-d hardware. It works by
building a list of to be flushed IOTLB entries and a bitmap list of
which DMAR engine they are from.
After either a high water mark (250 accessible via
1 - 100 of 298 matches
Mail list logo
