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
xes 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 Herri
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
> > +++ b/drive
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
> > +++ b/drive
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
> > +++ b/drivers/misc/vpumgr/
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
> > +++ b/drivers
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.
>
> BugLi
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
> > +++ b
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:
"On
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
> > Rev
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, mgr...@linux.i
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
> and
h 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
Underlying 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
> > > + semi-co
>
> 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 devic
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
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 com
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
> ---
>
> arch/x86/kernel/cpu/bug
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'
&g
+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
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 st
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 remot
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 newidle_bal
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 w
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 b/ker
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 se
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 501603057
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 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 yea
> + * PM QoS (qos_type) and the per-dev PM QoS
> + * (enable_dev_pm_qos).
> + *
> + * Note that the array of qos_list should be sorted by freq
> + * in the ascending order.
> */
> struct devfreq_dev_profile {
> unsigned long initial_fre
293,7 +293,7 @@ int dev_pm_qos_update_request(struct dev
> mutex_lock(&dev_pm_qos_mtx);
>
> if (req->dev->power.qos) {
> - if (new_value != req->node.prio)
> + if (new_value != req->data.pnode.prio)
> ret = apply_constra
t; @@ -710,7 +710,9 @@ static void flctl_select_chip(struct mtd
>
> if (!flctl->qos_request) {
> ret = dev_pm_qos_add_request(&flctl->pdev->dev,
> - &flctl->pm_qos, 100);
> +
gt;*/
> - 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_sta
)
> not_suspended++;
> + }
>
> if (not_suspended > genpd->in_progress)
> return -EBUSY;
>
looks ok to me.
Reviewed-by: mark gross
--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/
device *dev)
> +void pm_qos_sysfs_remove_flags(struct device *dev)
> {
> - sysfs_unmerge_group(&dev->kobj, &pm_qos_attr_group);
> + sysfs_unmerge_group(&dev->kobj, &pm_qos_flags_attr_group);
> }
>
> void rpm_sysfs_remove(struct device *dev)
&
;
> + case PM_QOS_UPDATE_REQ:
> + pm_qos_flags_remove_req(pqf, req);
> + case PM_QOS_ADD_REQ:
> + req->flags = val;
> + INIT_LIST_HEAD(&req->node);
> + list_add_tail(&req->node, &pqf->list);
> +
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 new
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, M
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 VT-
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 th
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
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: linux-2.6.24-mm1/drivers/pci
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 debugf
On Wed, Feb 13, 2008 at 10:23:34AM -0800, Randy Dunlap wrote:
>> Index: linux-2.6.24-mm1/Documentation/kernel-parameters.txt
>> ===
>> --- linux-2.6.24-mm1.orig/Documentation/kernel-parameters.txt
>> 2008-02-12
>> 07:12:06.000
On Tue, Feb 12, 2008 at 07:54:48AM -0800, David Miller wrote:
> > Something could be done:
> > we could enable drivers to have DMA-pools they manage that get mapped
> > and are re-used.
> >
> > I would rather the DMA-pools be tied to PID's that way any bad behavior
> > would be limited to the addr
On Tue, Feb 12, 2008 at 12:21:08PM -0800, Randy Dunlap wrote:
>> Index: linux-2.6.24-mm1/Documentation/kernel-parameters.txt
>> ===
>> --- linux-2.6.24-mm1.orig/Documentation/kernel-parameters.txt
>> 2008-02-12
>> 07:12:06.000
On Tue, Feb 12, 2008 at 08:34:39AM -0800, Randy Dunlap wrote:
> mark gross wrote:
>> Index: linux-2.6.24-mm1/drivers/pci/intel-iommu.c
>> ===
>> --- linux-2.6.24-mm1.orig/drivers/pci/intel-iommu.c 2008-02-12
On Mon, Feb 11, 2008 at 03:27:16PM -0800, Randy Dunlap wrote:
> On Mon, 11 Feb 2008 14:41:05 -0800 mark gross wrote:
>
> > The hole is the following scenarios:
> > do many map_signal operations, do some unmap_signals, reuse a recently
> > unmapped page, > memory&g
On Tue, Feb 12, 2008 at 01:00:06AM -0800, David Miller wrote:
> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 10:52:56 +0200
>
> > The streaming DMA-API was designed to conserve IOMMU mappings for
> > machines where IOMMU mappings are a scarce resource, and is a poor
> > fit f
On Tue, Feb 12, 2008 at 10:52:56AM +0200, Muli Ben-Yehuda wrote:
> On Mon, Feb 11, 2008 at 02:41:05PM -0800, mark gross wrote:
>
> > The intel-iommu hardware requires a polling operation to flush IOTLB
> > PTE's after an unmap operation. Through some TSC instrumentati
On Mon, Feb 11, 2008 at 02:29:46PM -0800, Andrew Morton wrote:
> On Mon, 11 Feb 2008 13:56:51 -0800
> mark gross <[EMAIL PROTECTED]> wrote:
>
> > The following patch merges two functions into one allowing for a 3%
> > reduction in overhead in locating, allocating and
The intel-iommu hardware requires a polling operation to flush IOTLB
PTE's after an unmap operation. Through some TSC instrumentation of a
netperf UDP stream with small packets test case it was seen that the
flush operations where sucking up to 16% of the CPU time doing
iommu_flush_iotlb's
The fo
The following patch merges two functions into one allowing for a 3%
reduction in overhead in locating, allocating and inserting pages for
use in IOMMU operations.
Its a bit of a eye-crosser so I welcome any RB-tree / MM experts to take
a look. It works by re-using some of the information gathered
On Mon, Jan 28, 2008 at 05:11:47PM -0700, Matthew Wilcox wrote:
> G'day Linus, mate
>
> Could you pull the dmapool branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/willy/misc.git please?
>
> All the patches have been posted to linux-kernel before, and various
> comments (and acks) have b
On Fri, Jan 25, 2008 at 11:02:55AM +0800, Zhenyu Wang wrote:
>
> Mark, sorry for missing this for long time...
>
> On 2008.01.08 12:44:20 -0800, mark gross wrote:
> > > >
> > > > [agp-mm] [intel_iommu] explicit export current graphics dmar status
> >
Sorry for the late reply.
comments below...
On Fri, Jan 04, 2008 at 09:53:38AM +0800, Zhenyu Wang wrote:
> On 2007.12.19 13:26:08 +, Zhenyu Wang wrote:
> >
> > [agp-mm] [intel_iommu] explicit export current graphics dmar status
> >
> > To make it possbile to tell other modules about curent
I forgot to cc the list.
--mgross
- Forwarded message from mark gross <[EMAIL PROTECTED]> -
Date: Tue, 27 Nov 2007 15:46:09 -0800
From: mark gross <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: intel-iommu-PMEN-think-oh
> +
> + ret = parse_dmar_table();
> + if (ret) {
> + printk(KERN_INFO PREFIX "parse DMAR table failure.\n");
> + return ret;
> + }
> +
> if (list_empty(&dmar_drhd_units)) {
> printk(KERN_INFO PREFIX "No DMAR devices
The following patch fixes an off by one bug in the fault reason string
reporting function, and cleans up some of the code around this buglet.
please apply.
--mgross
Signed-off-by: mark gross <[EMAIL PROTECTED]>
Index: linux-2.6.23-rc2-iommu/drivers/pci/intel-i
On Mon, Nov 19, 2007 at 04:38:02PM -0800, Andrew Morton wrote:
> On Fri, 16 Nov 2007 14:39:57 -0800
> mark gross <[EMAIL PROTECTED]> wrote:
>
> > -#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1
> > +#define MAX_FAULT_REASON_IDX (ARRAY_SIZ
gross
Signed-off-by: mark gross <[EMAIL PROTECTED]>
Index: linux-2.6.23-rc2-iommu/drivers/pci/intel-iommu.c
===
--- linux-2.6.23-rc2-iommu.orig/drivers/pci/intel-iommu.c 2007-11-16
13:25:14.0 -0800
+++ linux-2.6.2
On Thu, Nov 15, 2007 at 11:19:50AM -0800, mark gross wrote:
> On Wed, Nov 14, 2007 at 12:40:08PM -0800, Andrew Morton wrote:
> > On Wed, 14 Nov 2007 12:29:59 -0800 mark gross <[EMAIL PROTECTED]> wrote:
> >
> > > > > [ 102.366932] ===
1 - 100 of 180 matches
Mail list logo
