All of lore.kernel.org
 help / color / mirror / Atom feed
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:10 UTC (permalink / raw)
  To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel

The patch

   regmap: sccb: fix typo and sort headers alphabetically

has been applied to the regmap tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically

Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.

Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/base/regmap/regmap-sccb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 // Register map access API - SCCB support
 
-#include <linux/regmap.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/regmap.h>
 
 #include "internal.h"
 
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
 
 /**
  * regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to be read from
  * @val: Pointer to store read value
  *
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
 
 /**
  * regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to write to
  * @val: Value to be written
  *
-- 
2.18.0


^ permalink raw reply related
* [PATCH v2] hvm/altp2m: Clarify the proper way to extend the altp2m interface
From: George Dunlap @ 2018-07-23 17:09 UTC (permalink / raw)
  To: xen-devel
  Cc: Lars Kurth, Stefano Stabellini, Wei Liu, Razvan Cojocaru,
	Andrew Cooper, Adrian Pop, Tim Deegan, George Dunlap,
	Julien Grall, Jan Beulich, Tamas K Lengyel, Ian Jackson

The altp2m functionality was originally envisioned to be used in
several different configurations, one of which was a single in-guest
agent that had full operational control of altp2m.  This required the
single hypercall to be an HVMOP rather than a DOMCTL, since HVM guests
are not allowed to make DOMCTLs.  Access to this HVMOP is controlled
by a per-domain HVM_PARAM, and defaults to 'off'.

Exposing the altp2m functionality to the guest was controversial at
the time, but was ultimately accepted.  The fact that altp2m is an
HVMOP rather than a DOMCTL has caused some problems, however, for
those moving forward trying to extend the interface: Extending the
interface even for the 'external' use case now means extending an
HVMOP, which implicitly extends the surface of attack for the
'internal' use case as well.  The result has been that every addition
to this interface has also been controversial.

Settle the controversy once and for all by documenting 1) the purpose
of the altp2m interface, and 2) how to extend it.  In particular:

* Specify that the fully in-guest agent is a target use case

* Specify that all extensions to altp2m functionality should be subops
  of the HVMOP hypercall

* Specify that new subops should be enabled in ALTP2M_mixed mode by
  default, but that this mode has not been evaluated for safety.

Hopefully this will allow the altp2m interface to be developed further
without unnecessary controversy.

Further discussion:

As far as I can tell there are three possible solutions to this
controversy.

A. Remove the 'internal' functionality as a target by converting the
current HVMOP into a DOMCTL.

B. Have two hypercalls -- an HVMOP which contains functionality
expected to be used by the 'internal' agent, and a DOMCTL for
functionality which is expected to be used only be the 'external'
agent.

C. Agree to add all new subops to the current hypercall (HVMOP), even
if we're not sure if they should be exposed to the guest.

I think A is a terrible idea.  Having a single in-guest agent is a
reasonable design choice, and apparently it was even implemented at
some point; we should make it straightforward for someone in the
future to pick up the work if they want to.

I think B is also a bad idea.  The people extending it at the moment
are primarily concerned with the 'external' use case.  There is nobody
around to represent whether new functionality should end up in the
HVMOP or the DOMCTL, which means that by default it will end up in the
DOMCTL.  If it is discovered, afterwards, that the new operations
*would* be safe and useful for the 'internal' use case, then we will
either have to duplicate them inside the HVMOP (which would be
terrible) or move the operation from the DOMCTL to the HVMOP (which
would make coding an agent against several versions a mess).

It just makes more sense to have all the altp2m operations in a single
place, and a simple way to control whether they're available to the
'internal' use case or not.  As such, I am proposing 'C'.

Even within that, we have several options as far as what to do with
the current interface:

C1: Audit the current subops and make a blacklist of subops not
suitable for exposure to the guest.  Future subops should be on the
blacklist unless they have been evaluated as safe for exposure.

C2: Don't blacklist the current subops, but require that all future
subops be blacklisted unless they have been evaluated as safe for
exposure.

C3: Don't blacklist current or future subops for the present; just
document that they need to be evaluated (and some potentially
blacklisted) before being exposed to a guest in a safety-critical
environment.

C1 would be ideal, but there's nobody at present to do the work.
Given that, C3 has been seen as the best solution in discussion.

Signed-off-by: George Dunlap <george.dunlap@citrix.com>
---
Changes since v1:
- Patch description: clarify that HVM guest can't make domctls
- No blacklist for the 'internal' use case; instead document its risk
- Move more of the discussion into the commit message.

CC: Ian Jackson <ian.jackson@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Jan Beulich <jbeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Konrad Wilk <konrad.wilk@oracle.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
CC: Julien Grall <julien.grall@arm.com>
CC: Tamas K Lengyel <tamas.lengyel@zentific.com>
CC: Razvan Cojocaru <rcojocaru@bitdefender.com>
CC: Adrian Pop <apop@bitdefender.com>
CC: Lars Kurth <lars.kurth@citrix.com>
---
 xen/arch/x86/hvm/hvm.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1816faa9b3..84eed1f4bc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4467,6 +4467,37 @@ static int hvmop_get_param(
     return rc;
 }
 
+/*
+ * altp2m operations are envisioned as being used in several different 
+ * modes:
+ * 
+ * - external: All control and decisions are made by an external agent
+ *   running domain 0.
+ *
+ * - internal: altp2m operations are used exclusively by an in-guest
+ *   agent to protect itself from the guest kernel and in-guest
+ *   attackers.
+ * 
+ * - coordinated: An in-guest agent handles #VE and VMFUNCs locally,
+ *   but makes requests of an agent running outside the domain for
+ *   bigger changes (such as modifying altp2m entires).
+ *
+ * This corresponds to the three values for HVM_PARAM_ALTP2M
+ * (external, mixed, limited). All three models have advantages and
+ * disadvantages.
+ *
+ * Normally hypercalls made by a program in domain 0 in order to
+ * control a guest would be DOMCTLs rather than HVMOPs.  But in order
+ * to properly enable the 'internal' use case, as well as to avoid
+ * fragmentation, all altp2m subops should come under this single
+ * HVMOP.
+ * 
+ * Note that 'internal' mode (HVM_PARAM_ALTP2M == XEN_ALTP2M_mixed)
+ * has not been evaluated for safety from a security perspective.
+ * Before using this mode in a security-critical environment, each
+ * subop should be evaluated for safety, with unsafe subops
+ * blacklisted in xsm_hvm_altp2mhvm_op().
+ */
 static int do_altp2m_op(
     XEN_GUEST_HANDLE_PARAM(void) arg)
 {
-- 
2.18.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply related
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:09 UTC (permalink / raw)
  To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel

The patch

   regmap: sccb: fix typo and sort headers alphabetically

has been applied to the regmap tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically

Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.

Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/base/regmap/regmap-sccb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 // Register map access API - SCCB support
 
-#include <linux/regmap.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/regmap.h>
 
 #include "internal.h"
 
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
 
 /**
  * regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to be read from
  * @val: Pointer to store read value
  *
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
 
 /**
  * regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to write to
  * @val: Value to be written
  *
-- 
2.18.0


^ permalink raw reply related
* Re: [PATCH] firmware: vpd: Fix section enabled flag on vpd_section_destroy
From: Dmitry Torokhov @ 2018-07-23 17:09 UTC (permalink / raw)
  To: Anton Vasilyev
  Cc: Greg Kroah-Hartman, Guenter Roeck, Samuel Holland, Pan Bian,
	linux-kernel, ldv-project
In-Reply-To: <20180723164857.24460-1-vasilyev@ispras.ru>

On Mon, Jul 23, 2018 at 07:48:57PM +0300, Anton Vasilyev wrote:
> static struct ro_vpd and rw_vpd are initialized by vpd_sections_init()
> in vpd_probe() based on header's ro and rw sizes.
> In vpd_remove() vpd_section_destroy() performs deinitialization based
> on enabled flag, which is set to true by vpd_sections_init().
> This leads to call of vpd_section_destroy() on already destroyed section
> for probe-release-probe-release sequence if first probe performs
> ro_vpd initialization and second probe does not initialize it.
> 
> The patch adds changing enabled flag on vpd_section_destroy.
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Anton Vasilyev <vasilyev@ispras.ru>

Good find.

Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

> ---
>  drivers/firmware/google/vpd.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/firmware/google/vpd.c b/drivers/firmware/google/vpd.c
> index e9db895916c3..5347c17c7108 100644
> --- a/drivers/firmware/google/vpd.c
> +++ b/drivers/firmware/google/vpd.c
> @@ -246,6 +246,7 @@ static int vpd_section_destroy(struct vpd_section *sec)
>  		sysfs_remove_bin_file(vpd_kobj, &sec->bin_attr);
>  		kfree(sec->raw_name);
>  		memunmap(sec->baseaddr);
> +		sec->enabled = false;
>  	}
>  
>  	return 0;
> -- 
> 2.18.0
> 

Thanks.

-- 
Dmitry

^ permalink raw reply
* UBIFS: Shrinking in place
From: Martin Vuille @ 2018-07-23 17:08 UTC (permalink / raw)
  To: linux-mtd

I need to shrink an existing UBIFS filesystem "in place" as a
prelude to shrinking the underlying UBI volume.

Back in 2010 (http://lists.infradead.org/pipermail/linux-mtd/2010-January/028667.html)
it was stated on this list that this is not supported.

Wondering whether anything has changed since then?

If still not supported, I would like to consider undertaking
that work, and I'm looking for some guidance how best to
approach it.

MV

^ permalink raw reply
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:08 UTC (permalink / raw)
  To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel

The patch

   regmap: sccb: fix typo and sort headers alphabetically

has been applied to the regmap tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically

Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.

Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/base/regmap/regmap-sccb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 // Register map access API - SCCB support
 
-#include <linux/regmap.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/regmap.h>
 
 #include "internal.h"
 
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
 
 /**
  * regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to be read from
  * @val: Pointer to store read value
  *
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
 
 /**
  * regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to write to
  * @val: Value to be written
  *
-- 
2.18.0


^ permalink raw reply related
* Re: [PATCH] drm/atomic: Check old_plane_state->crtc in drm_atomic_helper_async_check()
From: Eric Anholt @ 2018-07-23 17:07 UTC (permalink / raw)
  To: David Airlie, Daniel Vetter, dri-devel; +Cc: Boris Brezillon
In-Reply-To: <20180723134354.26298-1-boris.brezillon@bootlin.com>


[-- Attachment #1.1: Type: text/plain, Size: 646 bytes --]

Boris Brezillon <boris.brezillon@bootlin.com> writes:

> Async plane update is supposed to work only when updating the FB or FB
> position of an already enabled plane. That does not apply to requests
> where the plane was previously disabled or assigned to a different
> CTRC.
>
> Check old_plane_state->crtc value to make sure async plane update is
> allowed.
>
> Fixes: fef9df8b5945 ("drm/atomic: initial support for asynchronous plane update")
> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>

I don't think any driver I've worked on would want an async flip of a
plane between CRTCs.

Reviewed-by: Eric Anholt <eric@anholt.net>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply
* Applied "regmap: sccb: fix typo and sort headers alphabetically" to the regmap tree
From: Mark Brown @ 2018-07-23 17:06 UTC (permalink / raw)
  To: Akinobu Mita; +Cc: Wolfram Sang, Mark Brown, linux-kernel

The patch

   regmap: sccb: fix typo and sort headers alphabetically

has been applied to the regmap tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 75eb3a67a29e9f87c07c8bd184a7ed4274a58ef0 Mon Sep 17 00:00:00 2001
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Mon, 23 Jul 2018 00:45:46 +0900
Subject: [PATCH] regmap: sccb: fix typo and sort headers alphabetically

Fix typos 's/wit/with/' in the comments and sort headers alphabetically
in order to avoid duplicate includes in future.

Fixes: bcf7eac3d97f ("regmap: add SCCB support")
Reported-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
 drivers/base/regmap/regmap-sccb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/regmap/regmap-sccb.c b/drivers/base/regmap/regmap-sccb.c
index b6eb876ea819..597042e2d009 100644
--- a/drivers/base/regmap/regmap-sccb.c
+++ b/drivers/base/regmap/regmap-sccb.c
@@ -1,9 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 // Register map access API - SCCB support
 
-#include <linux/regmap.h>
 #include <linux/i2c.h>
 #include <linux/module.h>
+#include <linux/regmap.h>
 
 #include "internal.h"
 
@@ -29,7 +29,7 @@ static bool sccb_is_available(struct i2c_adapter *adap)
 
 /**
  * regmap_sccb_read - Read data from SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to be read from
  * @val: Pointer to store read value
  *
@@ -65,7 +65,7 @@ static int regmap_sccb_read(void *context, unsigned int reg, unsigned int *val)
 
 /**
  * regmap_sccb_write - Write data to SCCB slave device
- * @context: Device that will be interacted wit
+ * @context: Device that will be interacted with
  * @reg: Register to write to
  * @val: Value to be written
  *
-- 
2.18.0


^ permalink raw reply related
* [PATCH] scsi: mptfusion: Fix potential Spectre v1
From: Gustavo A. R. Silva @ 2018-07-23 17:06 UTC (permalink / raw)
  To: Sathya Prakash, Chaitra P B, Suganath Prabu Subramani
  Cc: MPT-FusionLinux.pdl, linux-scsi, linux-kernel,
	Gustavo A. R. Silva

port can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/message/fusion/mptctl.c:1360 mptctl_getiocinfo() warn:
potential spectre issue 'ioc->pfacts'

Fix this by sanitizing port before using it to index ioc->pfacts

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
 drivers/message/fusion/mptctl.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/message/fusion/mptctl.c b/drivers/message/fusion/mptctl.c
index 4470630..6751a40 100644
--- a/drivers/message/fusion/mptctl.c
+++ b/drivers/message/fusion/mptctl.c
@@ -66,6 +66,9 @@
 #include <scsi/scsi_host.h>
 #include <scsi/scsi_tcq.h>
 
+/* Hardening for Spectre-v1 */
+#include <linux/nospec.h>
+
 #define COPYRIGHT	"Copyright (c) 1999-2008 LSI Corporation"
 #define MODULEAUTHOR	"LSI Corporation"
 #include "mptbase.h"
@@ -1306,7 +1309,7 @@ mptctl_getiocinfo (unsigned long arg, unsigned int data_size)
 		kfree(karg);
 		return -EINVAL;
 	}
-	port = karg->hdr.port;
+	port = array_index_nospec(karg->hdr.port, 2);
 
 	karg->port = port;
 	pdev = (struct pci_dev *) ioc->pcidev;
-- 
2.7.4

^ permalink raw reply related
* [Amlogic 64-bit DT updates for v4.19, round 2 (redo)
From: Kevin Hilman @ 2018-07-23 17:06 UTC (permalink / raw)
  To: linux-arm-kernel

[ fixes the original round 2 by removing the unnecessary (and wrong)
  merge of v4.18-rc5.]

Olof, Arnd,

A second round of DT updates for Amlogic, directly on top of the redo of
the first one.

This includes a merge of a branch already queued in the clk tree because
of the dependency on clock headers used in the DT changes here..

Kevin

The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:

  ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2-1

for you to fetch changes up to aaa080fa7e0f01f7cd8eb22a7385a4d8106c7478:

  ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini (2018-07-20 09:02:22 -0700)

----------------------------------------------------------------
Amlogic 64-bit DT changes for v4.19, round 2
- new SoC: S905W
- new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
- AXG: add DT for new audio clock controller

----------------------------------------------------------------
Jerome Brunet (3):
      dt-bindings: clock: add meson axg audio clock controller bindings
      clk: meson: expose GEN_CLK clkid
      ARM64: dts: meson-axg: add the audio clock controller

Kevin Hilman (1):
      Merge tag 'meson-clk-dt-for-v4.19' of https://github.com/BayLibre/clk-meson into v4.19/dt64-2

Martin Blumenstingl (5):
      dt-bindings: add vendor prefix for Shenzhen Oranth Technology Co., Ltd.
      dt-bindings: arm: amlogic: Add support for GXL S905W and the P281 board
      dt-bindings: arm: amlogic: Add support for the Oranth Tanix TX3 Mini
      ARM64: dts: meson-gxl: add support for the S905W SoC and the P281 board
      ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini

Yixun Lan (1):
      clk: meson-axg: add pcie and mipi clock bindings

 Documentation/devicetree/bindings/arm/amlogic.txt  |  7 ++
 .../bindings/clock/amlogic,axg-audio-clkc.txt      | 56 +++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 arch/arm64/boot/dts/amlogic/Makefile               |  2 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi         | 36 +++++++++
 .../boot/dts/amlogic/meson-gxl-s905w-p281.dts      | 22 +++++
 .../boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts  | 22 +++++
 include/dt-bindings/clock/axg-audio-clkc.h         | 94 ++++++++++++++++++++++
 include/dt-bindings/clock/axg-clkc.h               |  4 +
 include/dt-bindings/clock/gxbb-clkc.h              |  1 +
 10 files changed, 245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-p281.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
 create mode 100644 include/dt-bindings/clock/axg-audio-clkc.h

^ permalink raw reply
* [Amlogic 64-bit DT updates for v4.19, round 2 (redo)
From: Kevin Hilman @ 2018-07-23 17:06 UTC (permalink / raw)
  To: linus-amlogic

[ fixes the original round 2 by removing the unnecessary (and wrong)
  merge of v4.18-rc5.]

Olof, Arnd,

A second round of DT updates for Amlogic, directly on top of the redo of
the first one.

This includes a merge of a branch already queued in the clk tree because
of the dependency on clock headers used in the DT changes here..

Kevin

The following changes since commit 89803e8b26569bdf5798f8745a4c708bf9360ee6:

  ARM64: dts: meson-axg: add pdm pins (2018-07-20 08:18:37 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64-2-1

for you to fetch changes up to aaa080fa7e0f01f7cd8eb22a7385a4d8106c7478:

  ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini (2018-07-20 09:02:22 -0700)

----------------------------------------------------------------
Amlogic 64-bit DT changes for v4.19, round 2
- new SoC: S905W
- new boards: based on S905W: Amlogic P281, Oranth Tanix TX3 Mini
- AXG: add DT for new audio clock controller

----------------------------------------------------------------
Jerome Brunet (3):
      dt-bindings: clock: add meson axg audio clock controller bindings
      clk: meson: expose GEN_CLK clkid
      ARM64: dts: meson-axg: add the audio clock controller

Kevin Hilman (1):
      Merge tag 'meson-clk-dt-for-v4.19' of https://github.com/BayLibre/clk-meson into v4.19/dt64-2

Martin Blumenstingl (5):
      dt-bindings: add vendor prefix for Shenzhen Oranth Technology Co., Ltd.
      dt-bindings: arm: amlogic: Add support for GXL S905W and the P281 board
      dt-bindings: arm: amlogic: Add support for the Oranth Tanix TX3 Mini
      ARM64: dts: meson-gxl: add support for the S905W SoC and the P281 board
      ARM64: dts: meson-gxl: add support for the Oranth Tanix TX3 Mini

Yixun Lan (1):
      clk: meson-axg: add pcie and mipi clock bindings

 Documentation/devicetree/bindings/arm/amlogic.txt  |  7 ++
 .../bindings/clock/amlogic,axg-audio-clkc.txt      | 56 +++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 arch/arm64/boot/dts/amlogic/Makefile               |  2 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi         | 36 +++++++++
 .../boot/dts/amlogic/meson-gxl-s905w-p281.dts      | 22 +++++
 .../boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts  | 22 +++++
 include/dt-bindings/clock/axg-audio-clkc.h         | 94 ++++++++++++++++++++++
 include/dt-bindings/clock/axg-clkc.h               |  4 +
 include/dt-bindings/clock/gxbb-clkc.h              |  1 +
 10 files changed, 245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/amlogic,axg-audio-clkc.txt
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-p281.dts
 create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-s905w-tx3-mini.dts
 create mode 100644 include/dt-bindings/clock/axg-audio-clkc.h

^ permalink raw reply
* [PATCH] drm/nouveau/drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()
From: Lyude Paul @ 2018-07-23 17:06 UTC (permalink / raw)
  To: gregkh; +Cc: stable, bskeggs, David Airlie, dri-devel, nouveau, linux-kernel
In-Reply-To: <153227750090101@kroah.com>

commit e5d54f1935722f83df7619f3978f774c2b802cd8 upstream

A CRTC being enabled doesn't mean it's on! It doesn't even necessarily
mean it's being used. This fixes runtime PM leaks on the P50 I've got
next to me.

Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
---
 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index 2b3ccd850750..bc5c4f2402b4 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4198,7 +4198,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
 		nv50_disp_atomic_commit_tail(state);
 
 	drm_for_each_crtc(crtc, dev) {
-		if (crtc->state->enable) {
+		if (crtc->state->active) {
 			if (!drm->have_disp_power_ref) {
 				drm->have_disp_power_ref = true;
 				return 0;
-- 
2.17.1

^ permalink raw reply related
* Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
  To: Bhupesh Sharma
  Cc: linux-arm-kernel, Linux Kernel Mailing List, kexec mailing list,
	Bhupesh SHARMA, AKASHI Takahiro, Ard Biesheuvel, Will Deacon,
	Mark Rutland, Catalin Marinas, linux-mips
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>

Hi Bhupesh,

(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )

On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root@frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir

> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
> 
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)

Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.

... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.

But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)


I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.


>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
> 
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:

Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.


> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions

My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.

But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.


> which might not even be present in 'kallsyms').

Eh? How can that happen? I thought even modules had their symbols added to kallsyms.



Thanks,

James

^ permalink raw reply
* [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>

Hi Bhupesh,

(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )

On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root at frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir

> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
> 
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)

Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.

... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.

But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)


I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.


>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
> 
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:

Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.


> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions

My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.

But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.


> which might not even be present in 'kallsyms').

Eh? How can that happen? I thought even modules had their symbols added to kallsyms.



Thanks,

James

^ permalink raw reply
* Re: [PATCH] arm64, kaslr: export offset in VMCOREINFO ELF notes
From: James Morse @ 2018-07-23 17:05 UTC (permalink / raw)
  To: Bhupesh Sharma
  Cc: Mark Rutland, linux-mips, Ard Biesheuvel, Will Deacon,
	kexec mailing list, Linux Kernel Mailing List, AKASHI Takahiro,
	Catalin Marinas, Bhupesh SHARMA, linux-arm-kernel
In-Reply-To: <CACi5LpOa-BMRSTShS019DDv7MoxNfpnnsqjwR3z13GZC49NrSA@mail.gmail.com>

Hi Bhupesh,

(CC: +mips list, looks like mips is missing vmcore's KERNELOFFSET too.
Start of this thread: https://lkml.org/lkml/2018/7/18/951 )

On 19/07/18 15:55, Bhupesh Sharma wrote:
> On Thu, Jul 19, 2018 at 5:01 PM, James Morse <james.morse@arm.com> wrote:
>> On 18/07/18 22:37, Bhupesh Sharma wrote:
>>> Include KASLR offset in VMCOREINFO ELF notes to assist in debugging.
>>>
>>> makedumpfile user-space utility will need fixup to use this KASLR offset
>>> to work with cases where we need to find a way to translate symbol
>>> address from vmlinux to kernel run time address in case of KASLR boot on
>>> arm64.
>>
>> You need the kernel VA for a symbol. Isn't this what kallsyms is for?
>> | root@frikadeller:~# cat /proc/kallsyms | grep swapper_pg_dir
>> | ffff5404610d0000 B swapper_pg_dir

> Its already used by other archs like x86_64.
> Its just that we are enabling this feature for arm64 now that the
> KASLR boot cases are more widely seen on arm64 boards (as newer EFI
> firmware implementations are available which support EFI_RNG_PROTOCOL
> and hence KASLR boot).
> 
> And we want existing user-space application(s) to work similarly on
> arm64 distributions as they work historically on other archs like
> x86_64 (in most cases the user-space user is not even aware, if he is
> developing for or using an underlying hardware which is arm64 or
> x86_64)

Aha, so its ABI. This is the information that should be in the commit message as
it describes why this patch should be merged.

... Ideally core code would do this, that way this information won't be missed
when an architecture adds KASLR support.

But mips has CONFIG_RANDOMIZE_BASE, and doesn't provide kaslr_offset(),
and x86 always provides this value, not just if CONFIG_RANDOMIZE_BASE is
selected. I can't see a way to do this without touching all three architectures.
(we can try and tidy it up once its clear whether mips needs this too)


I think the patch is fine, but could you re-post it with a commit message that
describes that vmcore parsing in user-space already expects this value in the
notes. We're providing it for portability of those existing tools with x86.


>> I picked swapper_pg_dir, but you could use any of the vmcore:SYMBOL() addresses
>> to work out this offset. (you should expect the kernel to rename these symbols
>> at a whim).
>>
> 
> Perhaps you missed what the above makedumpfile command was doing, so
> let me summarize again:

Yes, I glossed over it, all that seemed relevant is you are trying to find the
kernel-va of a symbol from the value in the vmlinux.


> as it breaks the
> existing user-space use-cases and the .conf file can be user-defined
> (and hence he can pick any symbol/functions

My suggestion was you can calculate the offset between the link-time and
run-time address from information you already have. You just need one of each.
This would be better as its independent of how the kernel does the relocation.

But, this is irrelevant as 'KERNELOFFSET=' is already an ABI string.


> which might not even be present in 'kallsyms').

Eh? How can that happen? I thought even modules had their symbols added to kallsyms.



Thanks,

James

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply
* Re: [Qemu-devel] [PATCH v3 40/40] target/mips: Add definition of nanoMIPS I7200 CPU
From: Richard Henderson @ 2018-07-23 17:05 UTC (permalink / raw)
  To: Stefan Markovic, qemu-devel
  Cc: laurent, riku.voipio, philippe.mathieu.daude, aurelien, amarkovic,
	smarkovic, pjovanovic, pburton
In-Reply-To: <1532004912-13899-41-git-send-email-stefan.markovic@rt-rk.com>

On 07/19/2018 05:55 AM, Stefan Markovic wrote:
> +        .insn_flags = CPU_NANOMIPS32 | ASE_MICROMIPS | ASE_DSP | ASE_DSPR2 |
> +                      ASE_MT,

See my comments for 27/40.


r~

^ permalink raw reply
* ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/icp: Add Interrupt Support
From: Patchwork @ 2018-07-23 17:05 UTC (permalink / raw)
  To: Srivatsa, Anusha; +Cc: intel-gfx
In-Reply-To: <1529530565-8985-1-git-send-email-anusha.srivatsa@intel.com>

== Series Details ==

Series: series starting with [1/2] drm/i915/icp: Add Interrupt Support
URL   : https://patchwork.freedesktop.org/series/45124/
State : failure

== Summary ==

Applying: drm/i915/icp: Add Interrupt Support
Using index info to reconstruct a base tree...
M	drivers/gpu/drm/i915/i915_irq.c
M	drivers/gpu/drm/i915/i915_reg.h
Falling back to patching base and 3-way merge...
Auto-merging drivers/gpu/drm/i915/i915_reg.h
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_reg.h
Auto-merging drivers/gpu/drm/i915/i915_irq.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_irq.c
error: Failed to merge in the changes.
Patch failed at 0001 drm/i915/icp: Add Interrupt Support
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9375/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply
* Re: [PATCH] drm/amdgpu: Don't warn on destroying a pinned BO
From: Alex Deucher @ 2018-07-23 17:05 UTC (permalink / raw)
  To: Michel Dänzer; +Cc: amd-gfx list
In-Reply-To: <b39b0ced-3a54-b18c-0e90-e829b21afd17-otUistvHUpPR7s880joybQ@public.gmane.org>

On Mon, Jul 23, 2018 at 12:50 PM, Michel Dänzer <michel@daenzer.net> wrote:
> On 2018-07-19 05:39 PM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daenzer@amd.com>
>>
>> The warning turned out to be not so useful, as BO destruction tends to
>> be deferred to a workqueue.
>>
>> Also, we should be preventing any damage from this now, so not really
>> important anymore to fix code doing this.
>>
>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> index b12526ce1a9d..3010f0136de9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
>> @@ -89,7 +89,7 @@ static void amdgpu_ttm_bo_destroy(struct ttm_buffer_object *tbo)
>>       struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
>>       struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
>>
>> -     if (WARN_ON_ONCE(bo->pin_count > 0))
>> +     if (bo->pin_count > 0)
>>               amdgpu_bo_subtract_pin_size(bo);
>>
>>       if (bo->kfd_bo)
>>
>
> Any feedback?

Acked-by: Alex Deucher <alexander.deucher@amd.com>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

^ permalink raw reply
* [PATCH 6/9] ath9k: report tx status on EOSP
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

Fixes missed indications of end of U-APSD service period to mac80211

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 56a0d1b7527a..d366170f01cf 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -86,7 +86,8 @@ static void ath_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
 	struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
 	struct ieee80211_sta *sta = info->status.status_driver_data[0];
 
-	if (info->flags & IEEE80211_TX_CTL_REQ_TX_STATUS) {
+	if (info->flags & (IEEE80211_TX_CTL_REQ_TX_STATUS |
+			   IEEE80211_TX_STATUS_EOSP)) {
 		ieee80211_tx_status(hw, skb);
 		return;
 	}
-- 
2.17.0

^ permalink raw reply related
* [PATCH 4/9] ath9k: fix moredata bit in PS buffered frame release
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 7fdb152be0bb..cab24b43ac88 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1659,6 +1659,22 @@ void ath_tx_aggr_wakeup(struct ath_softc *sc, struct ath_node *an)
 	}
 }
 
+
+static void
+ath9k_set_moredata(struct ath_softc *sc, struct ath_buf *bf, bool val)
+{
+	struct ieee80211_hdr *hdr;
+	u16 mask = cpu_to_le16(IEEE80211_FCTL_MOREDATA);
+	u16 mask_val = mask * val;
+
+	hdr = (struct ieee80211_hdr *) bf->bf_mpdu->data;
+	if ((hdr->frame_control & mask) != mask_val) {
+		hdr->frame_control = (hdr->frame_control & ~mask) | mask_val;
+		dma_sync_single_for_device(sc->dev, bf->bf_buf_addr,
+			sizeof(*hdr), DMA_TO_DEVICE);
+	}
+}
+
 void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
 				   struct ieee80211_sta *sta,
 				   u16 tids, int nframes,
@@ -1689,6 +1705,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
 			if (!bf)
 				break;
 
+			ath9k_set_moredata(sc, bf, true);
 			list_add_tail(&bf->list, &bf_q);
 			ath_set_rates(tid->an->vif, tid->an->sta, bf);
 			if (bf_isampdu(bf)) {
@@ -1712,6 +1729,9 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
 	if (list_empty(&bf_q))
 		return;
 
+	if (!more_data)
+		ath9k_set_moredata(sc, bf_tail, false);
+
 	info = IEEE80211_SKB_CB(bf_tail->bf_mpdu);
 	info->flags |= IEEE80211_TX_STATUS_EOSP;
 
-- 
2.17.0

^ permalink raw reply related
* [PATCH 1/9] ath9k_hw: set spectral scan enable bit on trigger for AR9003+
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo

AR9002 code and the QCA AR9003+ reference code do the same.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index fe5102ca5010..98c5f524a360 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -1800,6 +1800,8 @@ static void ar9003_hw_spectral_scan_config(struct ath_hw *ah,
 
 static void ar9003_hw_spectral_scan_trigger(struct ath_hw *ah)
 {
+	REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
+		    AR_PHY_SPECTRAL_SCAN_ENABLE);
 	/* Activate spectral scan */
 	REG_SET_BIT(ah, AR_PHY_SPECTRAL_SCAN,
 		    AR_PHY_SPECTRAL_SCAN_ACTIVE);
-- 
2.17.0

^ permalink raw reply related
* [PATCH 3/9] ath9k: force rx_clear when disabling rx
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo, Felix Fietkau
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

From: Felix Fietkau <nbd@openwrt.org>

This makes stopping Rx more reliable and should reduce the frequency of
Rx related DMA stop warnings. Don't use rx_clear in TX99 mode.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
 drivers/net/wireless/ath/ath9k/mac.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 58d02c19b6d0..c9d2bf3fa135 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -678,13 +678,18 @@ void ath9k_hw_startpcureceive(struct ath_hw *ah, bool is_scanning)
 
 	ath9k_ani_reset(ah, is_scanning);
 
-	REG_CLR_BIT(ah, AR_DIAG_SW, (AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT));
+	REG_CLR_BIT(ah, AR_DIAG_SW,
+		    AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT | AR_DIAG_FORCE_RX_CLEAR);
 }
 EXPORT_SYMBOL(ath9k_hw_startpcureceive);
 
 void ath9k_hw_abortpcurecv(struct ath_hw *ah)
 {
-	REG_SET_BIT(ah, AR_DIAG_SW, AR_DIAG_RX_ABORT | AR_DIAG_RX_DIS);
+	u32 reg = AR_DIAG_RX_DIS | AR_DIAG_RX_ABORT;
+
+	if (!IS_ENABLED(CPTCFG_ATH9K_TX99))
+		reg |= AR_DIAG_FORCE_RX_CLEAR;
+	REG_SET_BIT(ah, AR_DIAG_SW, reg);
 
 	ath9k_hw_disable_mib_counters(ah);
 }
-- 
2.17.0

^ permalink raw reply related
* [PATCH 8/9] ath9k_hw: fix channel maximum power level test
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

The tx power applied by set_txpower is limited by the CTL (conformance
test limit) entries in the EEPROM. These can change based on the user
configured regulatory domain.
Depending on the EEPROM data this can cause the tx power to become too
limited, if the original regdomain CTLs impose lower limits than the CTLs
of the user configured regdomain.

To fix this issue, set the initial channel limits without any CTL
restrictions and only apply the CTL at run time when setting the channel
and the real tx power.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/hw.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1665066f4e24..9dc866404eca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2942,16 +2942,19 @@ void ath9k_hw_apply_txpower(struct ath_hw *ah, struct ath9k_channel *chan,
 	struct ath_regulatory *reg = ath9k_hw_regulatory(ah);
 	struct ieee80211_channel *channel;
 	int chan_pwr, new_pwr;
+	u16 ctl = NO_CTL;
 
 	if (!chan)
 		return;
 
+	if (!test)
+		ctl = ath9k_regd_get_ctl(reg, chan);
+
 	channel = chan->chan;
 	chan_pwr = min_t(int, channel->max_power * 2, MAX_RATE_POWER);
 	new_pwr = min_t(int, chan_pwr, reg->power_limit);
 
-	ah->eep_ops->set_txpower(ah, chan,
-				 ath9k_regd_get_ctl(reg, chan),
+	ah->eep_ops->set_txpower(ah, chan, ctl,
 				 get_antenna_gain(ah, chan), new_pwr, test);
 }
 
-- 
2.17.0

^ permalink raw reply related
* [PATCH 5/9] ath9k: clear potentially stale EOSP status bit in intermediate queues
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

Prevents spurious ieee80211_sta_eosp calls.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index cab24b43ac88..56a0d1b7527a 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -969,7 +969,8 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct ath_txq *txq,
 		bf->bf_lastbf = bf;
 
 		tx_info = IEEE80211_SKB_CB(skb);
-		tx_info->flags &= ~IEEE80211_TX_CTL_CLEAR_PS_FILT;
+		tx_info->flags &= ~(IEEE80211_TX_CTL_CLEAR_PS_FILT |
+				    IEEE80211_TX_STATUS_EOSP);
 
 		/*
 		 * No aggregation session is running, but there may be frames
-- 
2.17.0

^ permalink raw reply related
* [PATCH 7/9] ath9k: fix block-ack window tracking issues
From: Felix Fietkau @ 2018-07-23 16:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: kvalo
In-Reply-To: <20180723160300.58024-1-nbd@nbd.name>

Ensure that a buffer gets tracked as part of the block-ack window as
soon as it's dequeued from the tid for the first time. Ensure that
double calls to ath_tx_addto_baw (e.g. on retransmission) don't cause
any issues.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
 drivers/net/wireless/ath/ath9k/xmit.c | 29 +++++++++++++++++----------
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index d366170f01cf..bae0f6c045e1 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -62,7 +62,7 @@ static void ath_tx_rc_status(struct ath_softc *sc, struct ath_buf *bf,
 			     struct ath_tx_status *ts, int nframes, int nbad,
 			     int txok);
 static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
-			      int seqno);
+			      struct ath_buf *bf);
 static struct ath_buf *ath_tx_setup_buffer(struct ath_softc *sc,
 					   struct ath_txq *txq,
 					   struct ath_atx_tid *tid,
@@ -296,7 +296,7 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
 		}
 
 		if (fi->baw_tracked) {
-			ath_tx_update_baw(sc, tid, bf->bf_state.seqno);
+			ath_tx_update_baw(sc, tid, bf);
 			sendbar = true;
 		}
 
@@ -312,10 +312,15 @@ static void ath_tx_flush_tid(struct ath_softc *sc, struct ath_atx_tid *tid)
 }
 
 static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
-			      int seqno)
+			      struct ath_buf *bf)
 {
+	struct ath_frame_info *fi = get_frame_info(bf->bf_mpdu);
+	u16 seqno = bf->bf_state.seqno;
 	int index, cindex;
 
+	if (!fi->baw_tracked)
+		return;
+
 	index  = ATH_BA_INDEX(tid->seq_start, seqno);
 	cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
 
@@ -336,6 +341,9 @@ static void ath_tx_addto_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
 	u16 seqno = bf->bf_state.seqno;
 	int index, cindex;
 
+	if (fi->baw_tracked)
+		return;
+
 	index  = ATH_BA_INDEX(tid->seq_start, seqno);
 	cindex = (tid->baw_head + index) & (ATH_TID_MAX_BUFS - 1);
 	__set_bit(cindex, tid->tx_buf);
@@ -612,7 +620,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
 			 * complete the acked-ones/xretried ones; update
 			 * block-ack window
 			 */
-			ath_tx_update_baw(sc, tid, seqno);
+			ath_tx_update_baw(sc, tid, bf);
 
 			if (rc_update && (acked_cnt == 1 || txfail_cnt == 1)) {
 				memcpy(tx_info->control.rates, rates, sizeof(rates));
@@ -642,7 +650,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
 				 * run out of tx buf.
 				 */
 				if (!tbf) {
-					ath_tx_update_baw(sc, tid, seqno);
+					ath_tx_update_baw(sc, tid, bf);
 
 					ath_tx_complete_buf(sc, bf, txq,
 							    &bf_head, NULL, ts,
@@ -1011,11 +1019,14 @@ ath_tx_get_tid_subframe(struct ath_softc *sc, struct ath_txq *txq,
 
 			INIT_LIST_HEAD(&bf_head);
 			list_add(&bf->list, &bf_head);
-			ath_tx_update_baw(sc, tid, seqno);
+			ath_tx_update_baw(sc, tid, bf);
 			ath_tx_complete_buf(sc, bf, txq, &bf_head, NULL, &ts, 0);
 			continue;
 		}
 
+		if (bf_isampdu(bf))
+			ath_tx_addto_baw(sc, tid, bf);
+
 		return bf;
 	}
 
@@ -1073,8 +1084,6 @@ ath_tx_form_aggr(struct ath_softc *sc, struct ath_txq *txq,
 		bf->bf_next = NULL;
 
 		/* link buffers of this frame to the aggregate */
-		if (!fi->baw_tracked)
-			ath_tx_addto_baw(sc, tid, bf);
 		bf->bf_state.ndelim = ndelim;
 
 		list_add_tail(&bf->list, bf_q);
@@ -1710,10 +1719,8 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
 			ath9k_set_moredata(sc, bf, true);
 			list_add_tail(&bf->list, &bf_q);
 			ath_set_rates(tid->an->vif, tid->an->sta, bf);
-			if (bf_isampdu(bf)) {
-				ath_tx_addto_baw(sc, tid, bf);
+			if (bf_isampdu(bf))
 				bf->bf_state.bf_type &= ~BUF_AGGR;
-			}
 			if (bf_tail)
 				bf_tail->bf_next = bf;
 
-- 
2.17.0

^ permalink raw reply related
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.