Re: update timer frequencies

[Vineet Gupta]

Hi Thomas,

On 03/10/2017 03:58 PM, Thomas Gleixner wrote:

Vlad,

On Fri, 10 Mar 2017, Vlad Zakharov wrote:


I am trying to implement a cpufreq driver for ARC CPUs.  The point is
that ARC timers (including those are used for timekeeping) are driven by
the same clock as ARC CPU core(s).


To be honest: That's broken by design and you really should go and tell
your hardware folks to fix that. Proper timekeeping is essential for any
Operating System (not only Linux).

It's well known for more than TWO decades that changing the frequency of
the timekeeper clocksource is a complete disaster, but obviously every
hardware vendor has to learn that the hard way instead of simply learning
from history.


...


Your hardware design is broken by making the clocksource clock depend on
the CPU frequency. Tell your hardware people to fix that or just use a
seperate independent clocksource.


The hardware is being changed and I had a couple of questions to help do it 
right:

1. The clocksource timers TIMER1, GFRC, RTC etc will now be clocked independent of 
core using a fixed clk. Is there some magic freq value which best works so we can 
recommend that to implementors. AFAIKR ARM has 24 MHz.


2. I'm not sure if the timer generating interrupts (periodic or oneshot) needs to 
be fed invariant fixed clk or dynamic core clk. Naively it should follow the core 
- but what happens to scheduled timers (say TCP timeouts): if this clk changes - 
they need to be canceled/updated. If it doesn't then the notion of timing is 
broken ? I'm likely not thinking this through correctly.


Thx,
-Vineet

[PATCH 1/5] dt-bindings: phy: Add PHY_TYPE_UFS definition

[Vivek Gautam]

Add definition for UFS phy type.

Signed-off-by: Vivek Gautam 
---
 include/dt-bindings/phy/phy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/phy/phy.h b/include/dt-bindings/phy/phy.h
index 6c901930eb3e..d16e8755f6a9 100644
--- a/include/dt-bindings/phy/phy.h
+++ b/include/dt-bindings/phy/phy.h
@@ -15,5 +15,6 @@
 #define PHY_TYPE_PCIE  2
 #define PHY_TYPE_USB2  3
 #define PHY_TYPE_USB3  4
+#define PHY_TYPE_UFS   5
 
 #endif /* _DT_BINDINGS_PHY */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 4/5] scsi/ufs: qcom: Set phy mode based on the controllers HS MODE

[Vivek Gautam]

Set the phy mode based on the UFS HS PA mode. This lets the
controller let phy know the mode in which the PHY Adapter is
running and set the phy rates accordingly.

Signed-off-by: Vivek Gautam 
---
 drivers/scsi/ufs/ufs-qcom.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index c87d770b519a..44c21d5818ee 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -273,6 +273,9 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
bool is_rate_B = (UFS_QCOM_LIMIT_HS_RATE == PA_HS_MODE_B)
? true : false;
 
+   if (is_rate_B)
+   phy_set_mode(phy, PHY_MODE_UFS_HS_B);
+
/* Assert PHY reset and apply PHY calibration values */
ufs_qcom_assert_reset(hba);
/* provide 1ms delay to let the reset pulse propagate */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH] drm/tinydrm: mipi-dbi: Fix unbalanced DMA access

[Noralf Trønnes]

Den 04.08.2017 00.41, skrev David Lechner:

On 08/01/2017 03:14 PM, David Lechner wrote:
If we return here and import_attach is true, then 
dma_buf_end_cpu_access()

will not be called balance dma_buf_begin_cpu_access().

Fix by setting ret instead of returning.

Signed-off-by: David Lechner 
---
  drivers/gpu/drm/tinydrm/mipi-dbi.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c 
b/drivers/gpu/drm/tinydrm/mipi-dbi.c

index c83eeb7..e10fa4b 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -183,7 +183,8 @@ static int mipi_dbi_buf_copy(void *dst, struct 
drm_framebuffer *fb,

  dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
   drm_get_format_name(fb->format->format,
   &format_name));
-return -EINVAL;
+ret = -EINVAL;
+break;
  }
if (import_attach)




I just realized that the next line here can mask ret.


if (import_attach)
ret = dma_buf_end_cpu_access(import_attach->dmabuf,
 DMA_FROM_DEVICE);

So, we should either ignore the return value from 
dma_buf_end_cpu_access() always or add some logic to ignore it if ret 
is already an error.


In some of the other patches I have been sending, we have the same 
situation. I those, I have opted to just ignore the return value from 
dma_buf_end_cpu_access(). e.g...



if (import_attach)
dma_buf_end_cpu_access(import_attach->dmabuf, DMA_FROM_DEVICE);

Is this a reasonable thing to do?


mipi_dbi_buf_copy() can be used by other rgb565 controllers, hence
the format check I think. So when that happens, it can be moved to
tinydrm-helpers.

Currently it's not possible to get an illegal format, since mipi-dbi
only supports those two formats.
Userspace can't set an illegal format, beacuse it's checked:
drm_atomic_commit -> drm_atomic_check_only -> drm_atomic_plane_check ->
drm_plane_check_pixel_format

So I think we can just leave this alone, or put the check before
import_attach if you really want to put this straight.

Noralf.

[PATCH 3/5] phy: qcom-ufs: Add support to set phy mode

[Vivek Gautam]

Adding support to set desired UFS phy mode that can be set
from the host controller.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-ufs-i.h|  2 ++
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c | 14 ++
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c | 14 ++
 3 files changed, 30 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-i.h 
b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
index 13b02b7de30b..94326ed107c3 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-i.h
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
@@ -115,6 +115,8 @@ struct ufs_qcom_phy {
int cached_regs_table_size;
bool is_powered_on;
struct ufs_qcom_phy_specific_ops *phy_spec_ops;
+
+   enum phy_mode mode;
 };
 
 /**
diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c 
b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
index 12a1b498dc4b..af65785230b5 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
@@ -53,6 +53,19 @@ static int ufs_qcom_phy_qmp_14nm_exit(struct phy 
*generic_phy)
 }
 
 static
+int ufs_qcom_phy_qmp_14nm_set_mode(struct phy *generic_phy, enum phy_mode mode)
+{
+   struct ufs_qcom_phy *phy_common = get_ufs_qcom_phy(generic_phy);
+
+   phy_common->mode = PHY_MODE_INVALID;
+
+   if (mode > 0)
+   phy_common->mode = mode;
+
+   return 0;
+}
+
+static
 void ufs_qcom_phy_qmp_14nm_power_control(struct ufs_qcom_phy *phy, bool val)
 {
writel_relaxed(val ? 0x1 : 0x0, phy->mmio + UFS_PHY_POWER_DOWN_CONTROL);
@@ -102,6 +115,7 @@ static int ufs_qcom_phy_qmp_14nm_is_pcs_ready(struct 
ufs_qcom_phy *phy_common)
.exit   = ufs_qcom_phy_qmp_14nm_exit,
.power_on   = ufs_qcom_phy_power_on,
.power_off  = ufs_qcom_phy_power_off,
+   .set_mode   = ufs_qcom_phy_qmp_14nm_set_mode,
.owner  = THIS_MODULE,
 };
 
diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c 
b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
index 4f68acb58b73..5c18c41dbdb4 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
@@ -72,6 +72,19 @@ static int ufs_qcom_phy_qmp_20nm_exit(struct phy 
*generic_phy)
 }
 
 static
+int ufs_qcom_phy_qmp_20nm_set_mode(struct phy *generic_phy, enum phy_mode mode)
+{
+   struct ufs_qcom_phy *phy_common = get_ufs_qcom_phy(generic_phy);
+
+   phy_common->mode = PHY_MODE_INVALID;
+
+   if (mode > 0)
+   phy_common->mode = mode;
+
+   return 0;
+}
+
+static
 void ufs_qcom_phy_qmp_20nm_power_control(struct ufs_qcom_phy *phy, bool val)
 {
bool hibern8_exit_after_pwr_collapse = phy->quirks &
@@ -160,6 +173,7 @@ static int ufs_qcom_phy_qmp_20nm_is_pcs_ready(struct 
ufs_qcom_phy *phy_common)
.exit   = ufs_qcom_phy_qmp_20nm_exit,
.power_on   = ufs_qcom_phy_power_on,
.power_off  = ufs_qcom_phy_power_off,
+   .set_mode   = ufs_qcom_phy_qmp_20nm_set_mode,
.owner  = THIS_MODULE,
 };
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 5/5] ufs/phy: qcom: Refactor to use phy_init call

[Vivek Gautam]

Refactor ufs_qcom_power_up_sequence() to get rid of ugly
exported phy APIs and use the phy_init() and phy_power_on()
to do the phy initialization.

Signed-off-by: Vivek Gautam 
---
 drivers/phy/qualcomm/phy-qcom-ufs-i.h|  2 --
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c |  9 +--
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c |  9 +--
 drivers/phy/qualcomm/phy-qcom-ufs.c  | 38 
 drivers/scsi/ufs/ufs-qcom.c  | 36 ++
 include/linux/phy/phy-qcom-ufs.h |  3 ---
 6 files changed, 38 insertions(+), 59 deletions(-)

diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-i.h 
b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
index 94326ed107c3..495fd5941231 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-i.h
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
@@ -123,7 +123,6 @@ struct ufs_qcom_phy {
  * struct ufs_qcom_phy_specific_ops - set of pointers to functions which have a
  * specific implementation per phy. Each UFS phy, should implement
  * those functions according to its spec and requirements
- * @calibrate_phy: pointer to a function that calibrate the phy
  * @start_serdes: pointer to a function that starts the serdes
  * @is_physical_coding_sublayer_ready: pointer to a function that
  * checks pcs readiness. returns 0 for success and non-zero for error.
@@ -132,7 +131,6 @@ struct ufs_qcom_phy {
  * and writes to QSERDES_RX_SIGDET_CNTRL attribute
  */
 struct ufs_qcom_phy_specific_ops {
-   int (*calibrate_phy)(struct ufs_qcom_phy *phy, bool is_rate_B);
void (*start_serdes)(struct ufs_qcom_phy *phy);
int (*is_physical_coding_sublayer_ready)(struct ufs_qcom_phy *phy);
void (*set_tx_lane_enable)(struct ufs_qcom_phy *phy, u32 val);
diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c 
b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
index af65785230b5..c39440b56b6d 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c
@@ -44,7 +44,13 @@ void ufs_qcom_phy_qmp_14nm_advertise_quirks(struct 
ufs_qcom_phy *phy_common)
 
 static int ufs_qcom_phy_qmp_14nm_init(struct phy *generic_phy)
 {
-   return 0;
+   struct ufs_qcom_phy *phy_common = get_ufs_qcom_phy(generic_phy);
+   bool is_rate_B = false;
+
+   if (phy_common->mode == PHY_MODE_UFS_HS_B)
+   is_rate_B = true;
+
+   return ufs_qcom_phy_qmp_14nm_phy_calibrate(phy_common, is_rate_B);
 }
 
 static int ufs_qcom_phy_qmp_14nm_exit(struct phy *generic_phy)
@@ -120,7 +126,6 @@ static int ufs_qcom_phy_qmp_14nm_is_pcs_ready(struct 
ufs_qcom_phy *phy_common)
 };
 
 static struct ufs_qcom_phy_specific_ops phy_14nm_ops = {
-   .calibrate_phy  = ufs_qcom_phy_qmp_14nm_phy_calibrate,
.start_serdes   = ufs_qcom_phy_qmp_14nm_start_serdes,
.is_physical_coding_sublayer_ready = ufs_qcom_phy_qmp_14nm_is_pcs_ready,
.set_tx_lane_enable = ufs_qcom_phy_qmp_14nm_set_tx_lane_enable,
diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c 
b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
index 5c18c41dbdb4..5705a2d4c6d2 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c
@@ -63,7 +63,13 @@ void ufs_qcom_phy_qmp_20nm_advertise_quirks(struct 
ufs_qcom_phy *phy_common)
 
 static int ufs_qcom_phy_qmp_20nm_init(struct phy *generic_phy)
 {
-   return 0;
+   struct ufs_qcom_phy *phy_common = get_ufs_qcom_phy(generic_phy);
+   bool is_rate_B = false;
+
+   if (phy_common->mode == PHY_MODE_UFS_HS_B)
+   is_rate_B = true;
+
+   return ufs_qcom_phy_qmp_20nm_phy_calibrate(phy_common, is_rate_B);
 }
 
 static int ufs_qcom_phy_qmp_20nm_exit(struct phy *generic_phy)
@@ -178,7 +184,6 @@ static int ufs_qcom_phy_qmp_20nm_is_pcs_ready(struct 
ufs_qcom_phy *phy_common)
 };
 
 static struct ufs_qcom_phy_specific_ops phy_20nm_ops = {
-   .calibrate_phy  = ufs_qcom_phy_qmp_20nm_phy_calibrate,
.start_serdes   = ufs_qcom_phy_qmp_20nm_start_serdes,
.is_physical_coding_sublayer_ready = ufs_qcom_phy_qmp_20nm_is_pcs_ready,
.set_tx_lane_enable = ufs_qcom_phy_qmp_20nm_set_tx_lane_enable,
diff --git a/drivers/phy/qualcomm/phy-qcom-ufs.c 
b/drivers/phy/qualcomm/phy-qcom-ufs.c
index 43865ef340e2..1febe3294fe3 100644
--- a/drivers/phy/qualcomm/phy-qcom-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-ufs.c
@@ -518,9 +518,8 @@ void ufs_qcom_phy_disable_iface_clk(struct ufs_qcom_phy 
*phy)
}
 }
 
-int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
+static int ufs_qcom_phy_start_serdes(struct ufs_qcom_phy *ufs_qcom_phy)
 {
-   struct ufs_qcom_phy *ufs_qcom_phy = get_ufs_qcom_phy(generic_phy);
int ret = 0;
 
if (!ufs_qcom_phy->phy_spec_ops->start_serdes) {
@@ -533,7 +532,6 @@ int ufs_qcom_phy_start_serdes(struct phy *generic_phy)
 
return ret;
 }
-EXPORT_SYMBOL_GPL(ufs_qcom_phy_start_serdes);
 
 int ufs_qcom_phy_set_

[PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Vivek Gautam]

Refactoring the qcom-ufs phy and host controller code to move
further towards the generic phy usage. Right now the qcom-ufs exports
a bunch of APIs that are used by the host controller to initialize
the phy.
With this patch series, we populate the phy_init() which was a no-op
earlier. The host controller then calls the phy_init() at the designated
place rather than doing it invariably in ufs_hcd_init().

As part of this series, we introduce phy modes for ufs phy.
The M-PHY has two data rates defined for each generations (Gears) -
Rate A and Rate B. These can serve as the two modes of ufs HS phy.
Host controller can direct the phy to set the respective configurations
based on the phy modes.

The patch-series has been tested with necessary dt patches on db820c.

Vivek Gautam (5):
  dt-bindings: phy: Add PHY_TYPE_UFS definition
  phy: Add UFS PHY modes
  phy: qcom-ufs: Add support to set phy mode
  scsi/ufs: qcom: Set phy mode based on the controllers HS MODE
  ufs/phy: qcom: Refactor to use phy_init call

 drivers/phy/qualcomm/phy-qcom-ufs-i.h|  4 +--
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-14nm.c | 23 ++--
 drivers/phy/qualcomm/phy-qcom-ufs-qmp-20nm.c | 23 ++--
 drivers/phy/qualcomm/phy-qcom-ufs.c  | 38 +++
 drivers/scsi/ufs/ufs-qcom.c  | 39 
 include/dt-bindings/phy/phy.h|  1 +
 include/linux/phy/phy-qcom-ufs.h |  3 ---
 include/linux/phy/phy.h  |  2 ++
 8 files changed, 74 insertions(+), 59 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 2/5] phy: Add UFS PHY modes

[Vivek Gautam]

UFS phy has two modes for each High speed generation.
These modes are identified by two rates of operations -
Rate A, and Rate B.
Add these UFS phy modes to phy framework.

Signed-off-by: Vivek Gautam 
---
 include/linux/phy/phy.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index 78bb0d7f6b11..27e25bb78bfb 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -27,6 +27,8 @@ enum phy_mode {
PHY_MODE_USB_HOST,
PHY_MODE_USB_DEVICE,
PHY_MODE_USB_OTG,
+   PHY_MODE_UFS_HS_A,
+   PHY_MODE_UFS_HS_B,
 };
 
 /**
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[git pull] drm amd fixes for v4.13-rc4

[Dave Airlie]

Hi Linus,

Either my email ate everything or everyone is on holidays, either way
all I can find is some lonely AMD fixes.

Dave.

The following changes since commit 16f73eb02d7e1765ccab3d2018e0bd98eb93d973:

  Linux 4.13-rc3 (2017-07-30 12:40:36 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc4

for you to fetch changes up to 5669b9989eaa664cacbad6a85631550bccdad963:

  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-08-04
11:43:14 +1000)


just some lonely amd fixes


Alex Deucher (1):
  drm/amdgpu: fix header on gfx9 clear state

Dave Airlie (1):
  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Felix Kuehling (1):
  drm/amdgpu: Use list_del_init in amdgpu_mn_unregister

Jean Delvare (1):
  drm/amdgpu: Fix undue fallthroughs in golden registers initialization

 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/clearstate_gfx9.h | 41 ++--
 drivers/gpu/drm/amd/amdgpu/si.c  |  2 ++
 3 files changed, 24 insertions(+), 21 deletions(-)

[PATCH] bpf: fix selftest/bpf/test_pkt_md_access on s390x

[Thomas Richter]

Commit 18f3d6be6be1 ("selftests/bpf: Add test cases to test narrower ctx field 
loads")
introduced new eBPF test cases. One of them (test_pkt_md_access.c)
fails on s390x. The BPF verifier error message is:

[root@s8360046 bpf]# ./test_progs
test_pkt_access:PASS:ipv4 349 nsec
test_pkt_access:PASS:ipv6 212 nsec
[]
libbpf: load bpf program failed: Permission denied
libbpf: -- BEGIN DUMP LOG ---
libbpf:
0: (71) r2 = *(u8 *)(r1 +0)
invalid bpf_context access off=0 size=1

libbpf: -- END LOG --
libbpf: failed to load program 'test1'
libbpf: failed to load object './test_pkt_md_access.o'
Summary: 29 PASSED, 1 FAILED
[root@s8360046 bpf]#

This is caused by a byte endianess issue. S390x is a big endian
architecture.  Pointer access to the lowest byte or halfword of a
four byte value need to add an offset.
On little endian architectures this offset is not needed.

Fix this and use the same approach as the originator used for other files
(for example test_verifier.c) in his original commit.

With this fix the test program test_progs succeeds on s390x:
[root@s8360046 bpf]# ./test_progs
test_pkt_access:PASS:ipv4 236 nsec
test_pkt_access:PASS:ipv6 217 nsec
test_xdp:PASS:ipv4 3624 nsec
test_xdp:PASS:ipv6 1722 nsec
test_l4lb:PASS:ipv4 926 nsec
test_l4lb:PASS:ipv6 1322 nsec
test_tcp_estats:PASS: 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-prog-id 0 nsec
test_bpf_obj_id:PASS:get-fd-by-notexist-map-id 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-map-info(fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-prog-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-prog-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total prog id found by get_next_id 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:get-map-fd(next_id) 0 nsec
test_bpf_obj_id:PASS:check get-map-info(next_id->fd) 0 nsec
test_bpf_obj_id:PASS:check total map id found by get_next_id 0 nsec
test_pkt_md_access:PASS: 277 nsec
Summary: 30 PASSED, 0 FAILED
[root@s8360046 bpf]#

Signed-off-by: Thomas Richter 
---
 tools/testing/selftests/bpf/test_pkt_md_access.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_pkt_md_access.c 
b/tools/testing/selftests/bpf/test_pkt_md_access.c
index 71729d4..8393ced 100644
--- a/tools/testing/selftests/bpf/test_pkt_md_access.c
+++ b/tools/testing/selftests/bpf/test_pkt_md_access.c
@@ -12,12 +12,23 @@
 
 int _version SEC("version") = 1;
 
+#ifdef __LITTLE_ENDIAN
 #define TEST_FIELD(TYPE, FIELD, MASK)  \
{   \
TYPE tmp = *(volatile TYPE *)&skb->FIELD;   \
if (tmp != ((*(volatile __u32 *)&skb->FIELD) & MASK))   \
return TC_ACT_SHOT; \
}
+#else
+#define TEST_FIELD_OFFSET(a, b)((sizeof(a) - sizeof(b)) / sizeof(b))
+#define TEST_FIELD(TYPE, FIELD, MASK)  \
+   {   \
+   TYPE tmp = *((volatile TYPE *)&skb->FIELD + \
+ TEST_FIELD_OFFSET(skb->FIELD, TYPE)); \
+   if (tmp != ((*(volatile __u32 *)&skb->FIELD) & MASK))   \
+   return TC_ACT_SHOT; \
+   }
+#endif
 
 SEC("test1")
 int process(struct __sk_buff *skb)
-- 
2.9.3

linux-next: Tree for Aug 4

[Stephen Rothwell]

Hi all,

Changes since 20170803:

The wireless-drivers-next gained a conflict against with Linus' tree.

I again reverted a commit from the staging tree that was causing overnight
build failures.

Non-merge commits (relative to Linus' tree): 4300
 4510 files changed, 165118 insertions(+), 106486 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (869c058fbe74 Merge tag 'vfio-v4.13-rc4' of 
git://github.com/awilliam/linux-vfio)
Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig 
entry)
Merging kbuild-current/fixes (ad8181060788 kconfig: fix sparse warnings in 
nconfig)
Merging arc-current/for-curr (37f1db0e85ff ARC: [plat-axs10x]: prepare dts 
files for enabling PAE40 on axs103)
Merging arm-current/fixes (ce184a0dee92 ARM: 8687/1: signal: Fix unparseable 
iwmmxt_sigframe in uc_regspace[])
Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (f283f06014c3 powerpc/64: Fix __check_irq_replay 
missing decrementer interrupt)
Merging sparc/master (8cd3ec51c0c3 sbus: Convert to using %pOF instead of 
full_name)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (b91d532928df ipv6: set rt6i_protocol properly in the route 
when it is installed)
Merging ipsec/master (7bab09631c2a xfrm: policy: check policy direction value)
Merging netfilter/master (9beceb54fa2c netfilter: x_tables: Fix use-after-free 
in ipt_do_table.)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (368bd88ebb64 Merge tag 
'iwlwifi-for-kalle-2017-08-02' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in 
NL80211_ATTR_SCAN_FREQUENCIES)
Merging sound-current/for-linus (5ef26e966d3f Merge tag 'asoc-fix-v4.13-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (8466489ef5ba xhci: Reset Renesas uPD72020x USB 
controller for 32-bit DMA issue)
Merging driver-core.current/driver-core-linus (5771a8c08880 Linux v4.13-rc1)
Merging tty.current/tty-linus (9527b82ae3af Revert "serial: Delete dead code 
for CIR serial ports")
Merging usb.current/usb-linus (8cc34c8d6113 Merge tag 'usb-serial-4.13-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix 
unused-but-set-variable warning)
Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add 
D-Link DWM-222 device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (cef988642cda staging: comedi: 
comedi_fops: do not call blocking ops when !TASK_RUNNING)
Merging char-misc.current/char-misc-linus (52

[PATCH 5/6] misc: lis3lv02d: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/lis3lv02d/lis3lv02d.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c 
b/drivers/misc/lis3lv02d/lis3lv02d.c
index e389b0b..8d53609 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -856,7 +856,7 @@ static DEVICE_ATTR(rate, S_IRUGO | S_IWUSR, 
lis3lv02d_rate_show,
NULL
 };
 
-static struct attribute_group lis3lv02d_attribute_group = {
+static const struct attribute_group lis3lv02d_attribute_group = {
.attrs = lis3lv02d_attributes
 };
 
-- 
1.9.1

[PATCH 1/6] misc: apds9802als: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/apds9802als.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/apds9802als.c b/drivers/misc/apds9802als.c
index c6cc3dc..05ee771 100644
--- a/drivers/misc/apds9802als.c
+++ b/drivers/misc/apds9802als.c
@@ -197,7 +197,7 @@ static DEVICE_ATTR(lux0_sensor_range, S_IRUGO | S_IWUSR,
NULL
 };
 
-static struct attribute_group m_als_gr = {
+static const struct attribute_group m_als_gr = {
.name = "apds9802als",
.attrs = mid_att_als
 };
-- 
1.9.1

[PATCH 4/6] misc: isl29020: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/isl29020.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/isl29020.c b/drivers/misc/isl29020.c
index 4a9c50a..15d1749 100644
--- a/drivers/misc/isl29020.c
+++ b/drivers/misc/isl29020.c
@@ -145,7 +145,7 @@ static DEVICE_ATTR(lux0_sensor_range, S_IRUGO | S_IWUSR,
NULL
 };
 
-static struct attribute_group m_als_gr = {
+static const struct attribute_group m_als_gr = {
.name = "isl29020",
.attrs = mid_att_als
 };
-- 
1.9.1

[PATCH 3/6] misc: bh1770glc: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/bh1770glc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/bh1770glc.c b/drivers/misc/bh1770glc.c
index 38fcfe2..9c62bf0 100644
--- a/drivers/misc/bh1770glc.c
+++ b/drivers/misc/bh1770glc.c
@@ -1175,7 +1175,7 @@ static DEVICE_ATTR(power_state, S_IRUGO | S_IWUSR, 
bh1770_power_state_show,
NULL
 };
 
-static struct attribute_group bh1770_attribute_group = {
+static const struct attribute_group bh1770_attribute_group = {
.attrs = sysfs_attrs
 };
 
-- 
1.9.1

[PATCH 2/6] misc: apds990x: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/apds990x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/apds990x.c b/drivers/misc/apds990x.c
index 84e5b94..c9f0703 100644
--- a/drivers/misc/apds990x.c
+++ b/drivers/misc/apds990x.c
@@ -1051,7 +1051,7 @@ static ssize_t apds990x_chip_id_show(struct device *dev,
NULL
 };
 
-static struct attribute_group apds990x_attribute_group[] = {
+static const struct attribute_group apds990x_attribute_group[] = {
{.attrs = sysfs_attrs_ctrl },
 };
 
-- 
1.9.1

[PATCHv2] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

[Hoeun Ryu]

 Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly
version in panic path) introduced crash_smp_send_stop() which is a weak
function and can be overriden by architecture codes to fix the side effect
caused by commit f06e515 : (kernel/panic.c: add "crash_kexec_post_
notifiers" option).

 ARM architecture uses the weak version function and the problem is that
the weak function simply calls smp_send_stop() which makes other CPUs
offline and takes away the chance to save crash information for nonpanic
CPUs in machine_crash_shutdown() when crash_kexec_post_notifiers kernel
option is enabled.

 Calling smp_call_function(machine_crash_nonpanic_core, NULL, false) in
the function is useless because all nonpanic CPUs are already offline by
smp_send_stop() in this case and smp_call_function() only works against
online CPUs.

 The result is that /proc/vmcore is not available with the error messages;
"Warning: Zero PT_NOTE entries found", "Kdump: vmcore not initialized".

 crash_smp_send_stop() is implemented for ARM architecture to fix this
problem and the function (strong symbol version) saves crash information
for nonpanic CPUs using smp_call_function() and machine_crash_shutdown()
tries to save crash information for nonpanic CPUs only when
crash_kexec_post_notifiers kernel option is disabled.

 We might be able to implement the function like arm64 or x86 using a
dedicated IPI (let's say IPI_CPU_CRASH_STOP), but we cannot implement this
function like that because of the lack of IPI slots. Please see the commit
e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI)

Signed-off-by: Hoeun Ryu 
---
 v2:
  - calling crash_smp_send_stop() in machine_crash_shutdown() for the case
when crash_kexec_post_notifiers kernel option is disabled.
  - fix commit messages for it.

 arch/arm/kernel/machine_kexec.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index fe1419e..b58a49a 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -94,6 +94,31 @@ void machine_crash_nonpanic_core(void *unused)
cpu_relax();
 }
 
+void crash_smp_send_stop(void)
+{
+   static int cpus_stopped;
+   unsigned long msecs;
+
+   /*
+* This function can be called twice in panic path, but obviously
+* we execute this only once.
+*/
+   if (cpus_stopped)
+   return;
+
+   atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+   smp_call_function(machine_crash_nonpanic_core, NULL, false);
+   msecs = 1000; /* Wait at most a second for the other cpus to stop */
+   while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
+   mdelay(1);
+   msecs--;
+   }
+   if (atomic_read(&waiting_for_crash_ipi) > 0)
+   pr_warn("Non-crashing CPUs did not react to IPI\n");
+
+   cpus_stopped = 1;
+}
+
 static void machine_kexec_mask_interrupts(void)
 {
unsigned int i;
@@ -119,19 +144,11 @@ static void machine_kexec_mask_interrupts(void)
 
 void machine_crash_shutdown(struct pt_regs *regs)
 {
-   unsigned long msecs;
+   WARN_ON(num_online_cpus() > 1);
 
local_irq_disable();
 
-   atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
-   smp_call_function(machine_crash_nonpanic_core, NULL, false);
-   msecs = 1000; /* Wait at most a second for the other cpus to stop */
-   while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
-   mdelay(1);
-   msecs--;
-   }
-   if (atomic_read(&waiting_for_crash_ipi) > 0)
-   pr_warn("Non-crashing CPUs did not react to IPI\n");
+   crash_smp_send_stop();
 
crash_save_cpu(regs, smp_processor_id());
machine_kexec_mask_interrupts();
-- 
2.7.4

[PATCH 0/6] constify misc attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (6):
  [PATCH 1/6] misc: apds9802als: constify attribute_group structures.
  [PATCH 2/6] misc: apds990x: constify attribute_group structures.
  [PATCH 3/6] misc: bh1770glc: constify attribute_group structures.
  [PATCH 4/6] misc: isl29020: constify attribute_group structures.
  [PATCH 5/6] misc: lis3lv02d: constify attribute_group structures.
  [PATCH 6/6] misc: ti-st: constify attribute_group structures.

 drivers/misc/apds9802als.c | 2 +-
 drivers/misc/apds990x.c| 2 +-
 drivers/misc/bh1770glc.c   | 2 +-
 drivers/misc/isl29020.c| 2 +-
 drivers/misc/lis3lv02d/lis3lv02d.c | 2 +-
 drivers/misc/ti-st/st_kim.c| 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH 6/6] misc: ti-st: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/misc/ti-st/st_kim.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/ti-st/st_kim.c b/drivers/misc/ti-st/st_kim.c
index e74413f..b77aaca 100644
--- a/drivers/misc/ti-st/st_kim.c
+++ b/drivers/misc/ti-st/st_kim.c
@@ -660,7 +660,7 @@ static ssize_t show_flow_cntrl(struct device *dev,
NULL,
 };
 
-static struct attribute_group uim_attr_grp = {
+static const struct attribute_group uim_attr_grp = {
.attrs = uim_attrs,
 };
 
-- 
1.9.1

Re: linux-next: manual merge of the wireless-drivers-next tree with Linus' tree

[Kalle Valo]

Stephen Rothwell  writes:

> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
>
>   drivers/net/wireless/intel/iwlwifi/mvm/ops.c
>
> between commit:
>
>   bf8b286f86fc ("iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART")
>
> from Linus' tree and commit:
>
>   7174beb60c53 ("iwlwifi: refactor firmware debug code")
>
> from the wireless-drivers-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Thanks, the resolution looks good. I'll notify Dave about this when I
send the wireless-drivers-next pull request to him.

-- 
Kalle Valo

[PATCH] drm/omap: omap_display_timings: constify videomode structures

[Julia Lawall]

The videomode structures are only copied into the vm field of a
panel_drv_data structure, so they can be const.

Done with the help of Coccinelle.

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c |2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c 
b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
index c90474a..74d1396 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-lgphilips-lb035q02.c
@@ -19,7 +19,7 @@
 
 #include "../dss/omapdss.h"
 
-static struct videomode lb035q02_vm = {
+static const struct videomode lb035q02_vm = {
.hactive = 320,
.vactive = 240,
 
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index cbf4c67..0a38a0e 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -40,7 +40,7 @@ struct panel_drv_data {
struct spi_device *spi_dev;
 };
 
-static struct videomode td028ttec1_panel_vm = {
+static const struct videomode td028ttec1_panel_vm = {
.hactive= 480,
.vactive= 640,
.pixelclock = 22153000,

Re: [PATCH 1/2] wireless: move prism54 out to staging

[Kalle Valo]

"Luis R. Rodriguez"  writes:

> prism54 is deprecated in favor of the p54pci device driver. Although
> only *one soul* had reported issues with it long ago Linux most Linux
> distributions these days just disable the device driver given the
> conflicts with the PCI IDs of p54pci and the *very* unlikely situation
> of folks really need this driver anymore.
>
> Before trying to due away with prism54 once more stuff it into staging,
> which is our hospice for dying drivers.
>
> Signed-off-by: Luis R. Rodriguez 

Acked-by: Kalle Valo 

-- 
Kalle Valo

Re: [PATCH 0/2] wireless: move prism54 to staging

[Kalle Valo]

"Luis R. Rodriguez"  writes:

> This moves the prism54 diver to staging. The reason for this are
> stated on the driver's own commit log. Let me know what tree you'd
> prefer this to go through.

Nice. For me it's better if Greg can take this, I suspect less conflicts
that way, but I can take this as well if needed.

-- 
Kalle Valo

Re: [PATCH] pinctrl: intel: Add Intel Denverton pin controller support

[Andy Shevchenko]

On Thu, Aug 3, 2017 at 7:36 PM, Mika Westerberg
 wrote:
> This driver adds pinctrl/GPIO support for Intel Denverton SoC. The GPIO
> controller is based on the same hardware design that is already used in
> Intel Sunrisepoint so we leverage the core driver here.
>

Fine by me!

Reviewed-by: Andy Shevchenko 

> Signed-off-by: Mika Westerberg 
> ---
>  drivers/pinctrl/intel/Kconfig |   8 +
>  drivers/pinctrl/intel/Makefile|   1 +
>  drivers/pinctrl/intel/pinctrl-denverton.c | 302 
> ++
>  3 files changed, 311 insertions(+)
>  create mode 100644 drivers/pinctrl/intel/pinctrl-denverton.c
>
> diff --git a/drivers/pinctrl/intel/Kconfig b/drivers/pinctrl/intel/Kconfig
> index b82d6ff3116f..aba2af032615 100644
> --- a/drivers/pinctrl/intel/Kconfig
> +++ b/drivers/pinctrl/intel/Kconfig
> @@ -64,6 +64,14 @@ config PINCTRL_CANNONLAKE
>   This pinctrl driver provides an interface that allows configuring
>   of Intel Cannon Lake PCH pins and using them as GPIOs.
>
> +config PINCTRL_DENVERTON
> +   tristate "Intel Denverton pinctrl and GPIO driver"
> +   depends on ACPI
> +   select PINCTRL_INTEL
> +   help
> + This pinctrl driver provides an interface that allows configuring
> + of Intel Denverton SoC pins and using them as GPIOs.
> +
>  config PINCTRL_GEMINILAKE
> tristate "Intel Gemini Lake SoC pinctrl and GPIO driver"
> depends on ACPI
> diff --git a/drivers/pinctrl/intel/Makefile b/drivers/pinctrl/intel/Makefile
> index 81df3cf408e3..d9b31f7e2b1b 100644
> --- a/drivers/pinctrl/intel/Makefile
> +++ b/drivers/pinctrl/intel/Makefile
> @@ -6,5 +6,6 @@ obj-$(CONFIG_PINCTRL_MERRIFIELD)+= 
> pinctrl-merrifield.o
>  obj-$(CONFIG_PINCTRL_INTEL)+= pinctrl-intel.o
>  obj-$(CONFIG_PINCTRL_BROXTON)  += pinctrl-broxton.o
>  obj-$(CONFIG_PINCTRL_CANNONLAKE)   += pinctrl-cannonlake.o
> +obj-$(CONFIG_PINCTRL_DENVERTON)+= pinctrl-denverton.o
>  obj-$(CONFIG_PINCTRL_GEMINILAKE)   += pinctrl-geminilake.o
>  obj-$(CONFIG_PINCTRL_SUNRISEPOINT) += pinctrl-sunrisepoint.o
> diff --git a/drivers/pinctrl/intel/pinctrl-denverton.c 
> b/drivers/pinctrl/intel/pinctrl-denverton.c
> new file mode 100644
> index ..4500880240f2
> --- /dev/null
> +++ b/drivers/pinctrl/intel/pinctrl-denverton.c
> @@ -0,0 +1,302 @@
> +/*
> + * Intel Denverton SoC pinctrl/GPIO driver
> + *
> + * Copyright (C) 2017, Intel Corporation
> + * Author: Mika Westerberg 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-intel.h"
> +
> +#define DNV_PAD_OWN0x020
> +#define DNV_HOSTSW_OWN 0x0C0
> +#define DNV_PADCFGLOCK 0x090
> +#define DNV_GPI_IE 0x120
> +
> +#define DNV_GPP(n, s, e)   \
> +   {   \
> +   .reg_num = (n), \
> +   .base = (s),\
> +   .size = ((e) - (s) + 1),\
> +   }
> +
> +#define DNV_COMMUNITY(b, s, e, g)  \
> +   {   \
> +   .barno = (b),   \
> +   .padown_offset = DNV_PAD_OWN,   \
> +   .padcfglock_offset = DNV_PADCFGLOCK,\
> +   .hostown_offset = DNV_HOSTSW_OWN,   \
> +   .ie_offset = DNV_GPI_IE,\
> +   .pin_base = (s),\
> +   .npins = ((e) - (s) + 1),   \
> +   .gpps = (g),\
> +   .ngpps = ARRAY_SIZE(g), \
> +   }
> +
> +static const struct pinctrl_pin_desc dnv_pins[] = {
> +   /* North ALL */
> +   PINCTRL_PIN(0, "GBE0_SDP0"),
> +   PINCTRL_PIN(1, "GBE1_SDP0"),
> +   PINCTRL_PIN(2, "GBE0_SDP1"),
> +   PINCTRL_PIN(3, "GBE1_SDP1"),
> +   PINCTRL_PIN(4, "GBE0_SDP2"),
> +   PINCTRL_PIN(5, "GBE1_SDP2"),
> +   PINCTRL_PIN(6, "GBE0_SDP3"),
> +   PINCTRL_PIN(7, "GBE1_SDP3"),
> +   PINCTRL_PIN(8, "GBE2_LED0"),
> +   PINCTRL_PIN(9, "GBE2_LED1"),
> +   PINCTRL_PIN(10, "GBE0_I2C_CLK"),
> +   PINCTRL_PIN(11, "GBE0_I2C_DATA"),
> +   PINCTRL_PIN(12, "GBE1_I2C_CLK"),
> +   PINCTRL_PIN(13, "GBE1_I2C_DATA"),
> +   PINCTRL_PIN(14, "NCSI_RXD0"),
> +   PINCTRL_PIN(15, "NCSI_CLK_IN"),
> +   PINCTRL_PIN(16, "NCSI_RXD1"),
> +   PINCTRL_PIN(17, "NCSI_CRS_DV"),
> +   PINCTRL_PIN(18, "NCSI_ARB_IN"),
> +   PINCTRL_PIN(19, "NCSI_TX_EN"),
> +   PINCTRL_PIN(20, "NCSI_TXD0"),
> +   PINCTRL_PIN(21, "NCSI_TXD1"),
> +   PINCTRL_PIN(22, "NCSI_ARB_OUT"),
> +   PINCTRL_P

[PATCH] leds: blinkm: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/leds/leds-blinkm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-blinkm.c b/drivers/leds/leds-blinkm.c
index 617fe97..d03ed6b 100644
--- a/drivers/leds/leds-blinkm.c
+++ b/drivers/leds/leds-blinkm.c
@@ -298,7 +298,7 @@ static ssize_t store_test(struct device *dev, struct 
device_attribute *attr,
NULL,
 };
 
-static struct attribute_group blinkm_group = {
+static const struct attribute_group blinkm_group = {
.name = "blinkm",
.attrs = blinkm_attrs,
 };
-- 
1.9.1

Re: Kernel error messages: leds fujitsu::radio_led: Setting an LED's brightness failed

[Michał Kępień]

> Hi Michał,

Hi Harvey,

Thank you for providing us with further information.

> Now I had the time to change the harddisk in my laptop to the Win7 one
> (It's 35 degrees out there - nice excuse to stay inside ;))
> 
> What I found out:
> Neither the E nor the I LED work under Windows in my configuration.
> There is no Bluetooth LED (maybe because there is a combined
> WLAN/Bluetooth adapter used in the laptop?). There is only a Bluetooth
> Icon in the taskbar to indicate Bluetooth status.

Okay, this seems to be consistent with the manual I linked to in my
previous message.

> Pressing the E button brings up some kind of Energy saving applet and
> pressing the I button brings up an applet telling me about the hardware
> in my laptop and its current state.

These hotkeys should already work fine under Linux, i.e. pressing them
should generate input events which you can assign to any action you
please.  If they do not work for you, please let me know so that we can
debug further.

> Please tell me if I can provide more Information.

If I did not miss anything in your reports, there are two issues that
require some work:

  - Fixing radio LED detection.  I have an idea how to do this, but
please mind that I am quite busy lately and cannot guarantee any
specific time frame for submitting a patch.

  - Investigating the E LED.  This requires taking a look at the DSDT
dump from your laptop and searching for clues as to how this LED is
handled.  I will be happy to do that, but again, no promises about
how much time it will take.  (And given the nature of this task, I
cannot promise I will find anything reasonable at all.  I also might
ask you to do some further experiments as I do not have an E751
myself.)

-- 
Best regards,
Michał Kępień

Re: [PATCH] arm:lpae: build TTB control register value from scratch in v7_ttb_setup

[Hoeun Ryu]

Hello, Russell King.

The following patch has not merged yet.
Do you have a plan to accept and merge this patch ?

Thank you.

On Mon, 2017-06-12 at 10:47 +0900, Hoeun Ryu wrote:
>  Reading TTBCR in early boot stage might return the value of the previous
> kernel's configuration, especially in case of kexec. For example, if
> normal kernel (first kernel) had run on a configuration of PHYS_OFFSET <=
> PAGE_OFFSET and crash kernel (second kernel) is running on a configuration
> PHYS_OFFSET > PAGE_OFFSET, which can happen because it depends on the
> reserved area for crash kernel, reading TTBCR and using the value to OR
> other bit fields might be risky because it doesn't have a reset value for
> TTBCR.
> 
> Acked-by: Russell King 
> Suggested-by: Robin Murphy 
> Signed-off-by: Hoeun Ryu 
> 
> ---
> 
>  * add Acked-by: Russell King 
>  * v1: amended based on
>  - "[PATCHv2] arm: LPAE: kexec: clear TTBCR.T1SZ explicitly when
> PHYS_OFFSET > PAGE_OFFSET"
>  - https://lkml.org/lkml/2017/6/5/239
> 
>  arch/arm/mm/proc-v7-3level.S | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/proc-v7-3level.S b/arch/arm/mm/proc-v7-3level.S
> index 5e5720e..7d16bbc 100644
> --- a/arch/arm/mm/proc-v7-3level.S
> +++ b/arch/arm/mm/proc-v7-3level.S
> @@ -129,8 +129,7 @@ ENDPROC(cpu_v7_set_pte_ext)
>   .macro  v7_ttb_setup, zero, ttbr0l, ttbr0h, ttbr1, tmp
>   ldr \tmp, =swapper_pg_dir   @ swapper_pg_dir virtual address
>   cmp \ttbr1, \tmp, lsr #12   @ PHYS_OFFSET > PAGE_OFFSET?
> - mrc p15, 0, \tmp, c2, c0, 2 @ TTB control egister
> - orr \tmp, \tmp, #TTB_EAE
> + mov \tmp, #TTB_EAE  @ for TTB control egister
>   ALT_SMP(orr \tmp, \tmp, #TTB_FLAGS_SMP)
>   ALT_UP(orr  \tmp, \tmp, #TTB_FLAGS_UP)
>   ALT_SMP(orr \tmp, \tmp, #TTB_FLAGS_SMP << 16)

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Oza]

On Fri, Aug 4, 2017 at 11:29 AM, Oza Oza  wrote:
> On Fri, Aug 4, 2017 at 12:27 AM, Bjorn Helgaas  wrote:
>> On Thu, Aug 03, 2017 at 01:50:29PM +0530, Oza Oza wrote:
>>> On Thu, Aug 3, 2017 at 2:34 AM, Bjorn Helgaas  wrote:
>>> > On Thu, Jul 06, 2017 at 08:39:41AM +0530, Oza Pawandeep wrote:
>>> >> For Configuration Requests only, following reset it is possible for a
>>> >> device to terminate the request but indicate that it is temporarily 
>>> >> unable
>>> >> to process the Request, but will be able to process the Request in the
>>> >> future – in this case, the Configuration Request Retry Status 100 (CRS)
>>> >> Completion Status is used.
>>> >
>>> > Please include the spec reference for this.
>>> >
>>> > The "100" looks like it's supposed to be the Completion Status Field
>>> > value for CRS from PCIe r3.1, sec 2.2.9, Table 2-34, but the value in
>>> > the table is actually 0b010, not 0b100.  I don't think this level of
>>> > detail is necessary unless your hardware exposes those values to the
>>> > driver.
>>> >
>>>
>>> I will remove the above description from the comment.
>>>
>>> >> As per PCI spec, CRS Software Visibility only affects config read of the
>>> >> Vendor ID, for config write or any other config read the Root must
>>> >> automatically re-issue configuration request again as a new request.
>>> >> Iproc based PCIe RC (hw) does not retry request on its own.
>>> >
>>> > I think sec 2.3.2 is the relevant part of the spec.  It basically
>>> > says that when an RC receives a CRS completion for a config request:
>>> >
>>> >   - If CRS software visibility is not enabled, the RC must reissue the
>>> > config request as a new request.
>>> >
>>> >   - If CRS software visibility is enabled,
>>> > - for a config read of Vendor ID, the RC must return 0x0001 data
>>> > - for all other config reads/writes, the RC must reissue the
>>> >   request
>>> >
>>>
>>> yes, above is more relevant, and I will include it in the description.
>>>
>>> > Apparently iProc *never* reissues config requests, regardless of
>>> > whether CRS software visibility is enabled?
>>> >
>>>
>>> that is true.
>>>
>>> > But your CFG_RETRY_STATUS definition suggests that iProc always
>>> > fabricates config read data of 0x0001 when it sees CRS status, no
>>> > matter whether software visibility is enabled and no matter what
>>> > config address we read?
>>>
>>> yes, that is precisely the case.
>>
>> Not according to the documentation you quoted below.
>>
>>> > What about CRS status for a config *write*?  There's nothing here to
>>> > reissue those.
>>>
>>> No, we do not need there, because read will always be issued first
>>> before any write.
>>> so we do not need to implement write.
>>
>> How so?  As far as I know, there's nothing in the spec that requires
>> the first config access to a device to be a read, and there are
>> reasons why we might want to do a write first:
>> http://lkml.kernel.org/r/5952d144.8060...@oracle.com
>>
>
> I understand your point here. my thinking was during enumeration
> process first read will always be issued
> such as vendor/device id.
> I will extend this implementation for write.

I am sorry, but I just released that, it is not possible to implement
retry for write.
the reason is:

we have indirect way of accessing configuration space access.
for e.g.
for config write:

A) write to to addr register.
B) write to data register

now above those 2 registers are implemented by host bridge (not in
PCIe core IP).
there is no way of knowing for software, if write has to be retried.

e.g. I can not read data register (step B) to check if write was successful.
I have double checked this with internal ASIC team here.

so in conclusion: I have to do following of things.

1) include Documentation in Changelog.
2) include sec 2.3.2 from PCIe spec in commit description.

please confirm, if you are fine with all the information.
so then I make above 2 changes. and re-post the patch.

Regards,
Oza.

>
>>> > Is there a hardware erratum that describes the actual hardware
>>> > behavior?
>>>
>>> this is documented in our PCIe core hw manual.
>>> >>
>>> 4.7.3.3. Retry Status On Configuration Cycle
>>> Endpoints are allowed to generate retry status on configuration
>>> cycles.  In this case, the RC needs to re-issue the request.  The IP
>>> does not handle this because the number of configuration cycles needed
>>> will probably be less
>>> than the total number of non-posted operations needed.   When a retry status
>>> is received on the User RX interface for a configuration request that
>>> was sent on the User TX interface, it will be indicated with a
>>> completion with the CMPL_STATUS field set to 2=CRS, and the user will
>>> have to find the address and data values and send a new transaction on
>>> the User TX interface.
>>> When the internal configuration space returns a retry status during a
>>> configuration cycle (user_cscfg = 1) on the Command/Status interface,
>>> the pcie_cscrs will assert w

[PATCH] of: platform: Create dummy routines for !CONFIG_OF_ADDRESS

[Viresh Kumar]

Few routines don't have their dummy counterparts which results in build
failures where these routines are used without CONFIG_OF_ADDRESS
enabled.

Fix those by defining the dummy versions.

Signed-off-by: Viresh Kumar 
---
 include/linux/of_platform.h | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index e0d1946270f3..e8d93a5e3ddd 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -52,12 +52,13 @@ struct of_dev_auxdata {
  .platform_data = _pdata }
 
 extern const struct of_device_id of_default_bus_match_table[];
+extern struct platform_device *of_find_device_by_node(struct device_node *np);
 
+#ifdef CONFIG_OF_ADDRESS
 /* Platform drivers register/unregister */
 extern struct platform_device *of_device_alloc(struct device_node *np,
 const char *bus_id,
 struct device *parent);
-extern struct platform_device *of_find_device_by_node(struct device_node *np);
 
 /* Platform devices and busses creation */
 extern struct platform_device *of_platform_device_create(struct device_node 
*np,
@@ -68,7 +69,6 @@ extern int of_platform_device_destroy(struct device *dev, 
void *data);
 extern int of_platform_bus_probe(struct device_node *root,
 const struct of_device_id *matches,
 struct device *parent);
-#ifdef CONFIG_OF_ADDRESS
 extern int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
@@ -82,6 +82,33 @@ extern int devm_of_platform_populate(struct device *dev);
 
 extern void devm_of_platform_depopulate(struct device *dev);
 #else
+static inline struct platform_device *
+of_device_alloc(struct device_node *np, const char *bus_id,
+   struct device *parent)
+{
+   return NULL;
+}
+
+/* Platform devices and busses creation */
+static inline struct platform_device *
+of_platform_device_create(struct device_node *np, const char *bus_id,
+ struct device *parent)
+{
+   return NULL;
+}
+
+static inline int of_platform_device_destroy(struct device *dev, void *data)
+{
+   return -ENODEV;
+}
+
+static inline int of_platform_bus_probe(struct device_node *root,
+   const struct of_device_id *matches,
+   struct device *parent)
+{
+   return -ENODEV;
+}
+
 static inline int of_platform_populate(struct device_node *root,
const struct of_device_id *matches,
const struct of_dev_auxdata *lookup,
-- 
2.13.0.71.gd7076ec9c9cb

[PATCH] arm:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

[Hoeun Ryu]

 Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly
version in panic path) introduced crash_smp_send_stop() which is a weak
function and can be overriden by architecture codes to fix the side effect
caused by commit f06e515 : (kernel/panic.c: add "crash_kexec_post_
notifiers" option).

 ARM architecture uses the weak version function and the problem is that
the weak function simply calls smp_send_stop() which makes other CPUs
offline and takes away the chance to save crash information for nonpanic
CPUs in machine_crash_shutdown() when crash_kexec_post_notifiers kernel
option is enabled.

 Calling smp_call_function(machine_crash_nonpanic_core, NULL, false) in
the function is useless because all nonpanic CPUs are already offline by
smp_send_stop() in this case and smp_call_function() only works against
online CPUs.

 The result is that /proc/vmcore is not available with the error messages;
"Warning: Zero PT_NOTE entries found", "Kdump: vmcore not initialized".

 crash_smp_send_stop() is implemented for ARM architecture to fix this
problem and the function (strong symbol version) saves crash information
for nonpanic CPUs using smp_call_function() and machine_crash_shutdown()
saves crash information only for the panic CPU.

 We might be able to implement the function like arm64 or x86 using a
dedicated IPI (let's say IPI_CPU_CRASH_STOP), but we cannot implement this
function like that because of the lack of IPI slot. Please see the commit
e7273ff4 : (ARM: 8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI)

Signed-off-by: Hoeun Ryu 
---
 arch/arm/kernel/machine_kexec.c | 37 ++---
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index fe1419e..18d084a 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -94,6 +94,31 @@ void machine_crash_nonpanic_core(void *unused)
cpu_relax();
 }
 
+void crash_smp_send_stop(void)
+{
+   static int cpus_stopped;
+   unsigned long msecs;
+
+   /*
+* This function can be called twice in panic path, but obviously
+* we execute this only once.
+*/
+   if (cpus_stopped)
+   return;
+
+   atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+   smp_call_function(machine_crash_nonpanic_core, NULL, false);
+   msecs = 1000; /* Wait at most a second for the other cpus to stop */
+   while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
+   mdelay(1);
+   msecs--;
+   }
+   if (atomic_read(&waiting_for_crash_ipi) > 0)
+   pr_warn("Non-crashing CPUs did not react to IPI\n");
+
+   cpus_stopped = 1;
+}
+
 static void machine_kexec_mask_interrupts(void)
 {
unsigned int i;
@@ -119,20 +144,10 @@ static void machine_kexec_mask_interrupts(void)
 
 void machine_crash_shutdown(struct pt_regs *regs)
 {
-   unsigned long msecs;
+   WARN_ON(num_online_cpus() > 1);
 
local_irq_disable();
 
-   atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
-   smp_call_function(machine_crash_nonpanic_core, NULL, false);
-   msecs = 1000; /* Wait at most a second for the other cpus to stop */
-   while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
-   mdelay(1);
-   msecs--;
-   }
-   if (atomic_read(&waiting_for_crash_ipi) > 0)
-   pr_warn("Non-crashing CPUs did not react to IPI\n");
-
crash_save_cpu(regs, smp_processor_id());
machine_kexec_mask_interrupts();
 
-- 
2.7.4

Re: [PATCH v5 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Oza]

On Fri, Aug 4, 2017 at 12:27 AM, Bjorn Helgaas  wrote:
> On Thu, Aug 03, 2017 at 01:50:29PM +0530, Oza Oza wrote:
>> On Thu, Aug 3, 2017 at 2:34 AM, Bjorn Helgaas  wrote:
>> > On Thu, Jul 06, 2017 at 08:39:41AM +0530, Oza Pawandeep wrote:
>> >> For Configuration Requests only, following reset it is possible for a
>> >> device to terminate the request but indicate that it is temporarily unable
>> >> to process the Request, but will be able to process the Request in the
>> >> future – in this case, the Configuration Request Retry Status 100 (CRS)
>> >> Completion Status is used.
>> >
>> > Please include the spec reference for this.
>> >
>> > The "100" looks like it's supposed to be the Completion Status Field
>> > value for CRS from PCIe r3.1, sec 2.2.9, Table 2-34, but the value in
>> > the table is actually 0b010, not 0b100.  I don't think this level of
>> > detail is necessary unless your hardware exposes those values to the
>> > driver.
>> >
>>
>> I will remove the above description from the comment.
>>
>> >> As per PCI spec, CRS Software Visibility only affects config read of the
>> >> Vendor ID, for config write or any other config read the Root must
>> >> automatically re-issue configuration request again as a new request.
>> >> Iproc based PCIe RC (hw) does not retry request on its own.
>> >
>> > I think sec 2.3.2 is the relevant part of the spec.  It basically
>> > says that when an RC receives a CRS completion for a config request:
>> >
>> >   - If CRS software visibility is not enabled, the RC must reissue the
>> > config request as a new request.
>> >
>> >   - If CRS software visibility is enabled,
>> > - for a config read of Vendor ID, the RC must return 0x0001 data
>> > - for all other config reads/writes, the RC must reissue the
>> >   request
>> >
>>
>> yes, above is more relevant, and I will include it in the description.
>>
>> > Apparently iProc *never* reissues config requests, regardless of
>> > whether CRS software visibility is enabled?
>> >
>>
>> that is true.
>>
>> > But your CFG_RETRY_STATUS definition suggests that iProc always
>> > fabricates config read data of 0x0001 when it sees CRS status, no
>> > matter whether software visibility is enabled and no matter what
>> > config address we read?
>>
>> yes, that is precisely the case.
>
> Not according to the documentation you quoted below.
>
>> > What about CRS status for a config *write*?  There's nothing here to
>> > reissue those.
>>
>> No, we do not need there, because read will always be issued first
>> before any write.
>> so we do not need to implement write.
>
> How so?  As far as I know, there's nothing in the spec that requires
> the first config access to a device to be a read, and there are
> reasons why we might want to do a write first:
> http://lkml.kernel.org/r/5952d144.8060...@oracle.com
>

I understand your point here. my thinking was during enumeration
process first read will always be issued
such as vendor/device id.
I will extend this implementation for write.

>> > Is there a hardware erratum that describes the actual hardware
>> > behavior?
>>
>> this is documented in our PCIe core hw manual.
>> >>
>> 4.7.3.3. Retry Status On Configuration Cycle
>> Endpoints are allowed to generate retry status on configuration
>> cycles.  In this case, the RC needs to re-issue the request.  The IP
>> does not handle this because the number of configuration cycles needed
>> will probably be less
>> than the total number of non-posted operations needed.   When a retry status
>> is received on the User RX interface for a configuration request that
>> was sent on the User TX interface, it will be indicated with a
>> completion with the CMPL_STATUS field set to 2=CRS, and the user will
>> have to find the address and data values and send a new transaction on
>> the User TX interface.
>> When the internal configuration space returns a retry status during a
>> configuration cycle (user_cscfg = 1) on the Command/Status interface,
>> the pcie_cscrs will assert with the pcie_csack signal to indicate the
>> CRS status.
>> When the CRS Software Visibility Enable register in the Root Control
>> register is enabled, the IP will return the data value to 0x0001 for
>> the Vendor ID value and 0x  (all 1’s) for the rest of the data in
>> the request for reads of offset 0 that return with CRS status.  This
>> is true for both the User RX Interface and for the Command/Status
>> interface.  When CRS Software Visibility is enabled, the CMPL_STATUS
>> field of the completion on the User RX Interface will not be 2=CRS and
>> the pcie_cscrs signal will not assert on the Command/Status interface.
>> >>
>> Broadcom does not sell PCIe core IP, so above information is not
>> publicly available in terms of hardware erratum or any similar note.
>>
>>
>> >
>> >> As a result of the fact, PCIe RC driver (sw) should take care of CRS.
>> >> This patch fixes the problem, and attempts to read config space again in
>> >> case of PCIe code fo

Re: [PATCH v3] powerpc/mm: Implemented default_hugepagesz verification for powerpc

[Aneesh Kumar K.V]

Victor Aoqui  writes:

> Implemented default hugepage size verification (default_hugepagesz=)
> in order to allow allocation of defined number of pages (hugepages=)
> only for supported hugepage sizes.
>
> Signed-off-by: Victor Aoqui 

I am still not sure about this. With current upstream we get

 PCI: Probing PCI hardware 
 PCI: Probing PCI hardware done 
  
 HugeTLB: unsupported default_hugepagesz 2097152. Reverting to 16777216 
  
 HugeTLB registered 16.0 MiB page size, pre-allocated 0 pages   
  
 HugeTLB registered 16.0 GiB page size, pre-allocated 0 pages  

That warning is added by

d715cf804a0318e83c75c0a7abd1a4b9ce13e8da

Which should be good enough right ?

-aneesh

Re: [PATCH v2 17/25] mtd: nand: qcom: add BAM DMA descriptor handling

[Archit Taneja]

On 07/19/2017 05:18 PM, Abhishek Sahu wrote:

1. prepare_bam_async_desc is the function which will call
all the DMA API’s. It will fetch the outstanding scatter gather
list for passed channel and will do the DMA descriptor formation.
The DMA flag is dependent upon the type of channel.

2. For ADM DMA, the descriptor is being formed for every DMA
request so its sgl count will be always 1 while in BAM DMA, the
clubbing of descriptor is being done to increase throughput.

3. ADM uses only one channel while in BAM, data descriptors
will be submitted to tx channel (for write) or rx channel
(for read) and all the registers read/write descriptors in
command channel.


Reviewed-by: Archit Taneja 



Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 143 ++
  1 file changed, 130 insertions(+), 13 deletions(-)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index fc29c97..589108b 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -209,14 +209,23 @@ struct bam_transaction {
   * This data type corresponds to the nand dma descriptor
   * @list - list for desc_info
   * @dir - DMA transfer direction
- * @sgl - sgl which will be used for single sgl dma descriptor
+ * @adm_sgl - sgl which will be used for single sgl dma descriptor. Only used 
by
+ *   ADM
+ * @bam_sgl - sgl which will be used for dma descriptor. Only used by BAM
+ * @sgl_cnt - number of SGL in bam_sgl. Only used by BAM
   * @dma_desc - low level dma engine descriptor
   */
  struct desc_info {
struct list_head node;
  
  	enum dma_data_direction dir;

-   struct scatterlist sgl;
+   union {
+   struct scatterlist adm_sgl;
+   struct {
+   struct scatterlist *bam_sgl;
+   int sgl_cnt;
+   };
+   };
struct dma_async_tx_descriptor *dma_desc;
  };
  
@@ -580,9 +589,77 @@ static void update_rw_regs(struct qcom_nand_host *host, int num_cw, bool read)

nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
  }
  
-static int prep_dma_desc(struct qcom_nand_controller *nandc, bool read,

-int reg_off, const void *vaddr, int size,
-bool flow_control)
+/*
+ * Maps the scatter gather list for DMA transfer and forms the DMA descriptor
+ * for BAM. This descriptor will be added in the NAND DMA descriptor queue
+ * which will be submitted to DMA engine.
+ */
+static int prepare_bam_async_desc(struct qcom_nand_controller *nandc,
+ struct dma_chan *chan,
+ unsigned long flags)
+{
+   struct desc_info *desc;
+   struct scatterlist *sgl;
+   unsigned int sgl_cnt;
+   int ret;
+   struct bam_transaction *bam_txn = nandc->bam_txn;
+   enum dma_transfer_direction dir_eng;
+   struct dma_async_tx_descriptor *dma_desc;
+
+   desc = kzalloc(sizeof(*desc), GFP_KERNEL);
+   if (!desc)
+   return -ENOMEM;
+
+   if (chan == nandc->cmd_chan) {
+   sgl = &bam_txn->cmd_sgl[bam_txn->cmd_sgl_start];
+   sgl_cnt = bam_txn->cmd_sgl_pos - bam_txn->cmd_sgl_start;
+   bam_txn->cmd_sgl_start = bam_txn->cmd_sgl_pos;
+   dir_eng = DMA_MEM_TO_DEV;
+   desc->dir = DMA_TO_DEVICE;
+   } else if (chan == nandc->tx_chan) {
+   sgl = &bam_txn->data_sgl[bam_txn->tx_sgl_start];
+   sgl_cnt = bam_txn->tx_sgl_pos - bam_txn->tx_sgl_start;
+   bam_txn->tx_sgl_start = bam_txn->tx_sgl_pos;
+   dir_eng = DMA_MEM_TO_DEV;
+   desc->dir = DMA_TO_DEVICE;
+   } else {
+   sgl = &bam_txn->data_sgl[bam_txn->rx_sgl_start];
+   sgl_cnt = bam_txn->rx_sgl_pos - bam_txn->rx_sgl_start;
+   bam_txn->rx_sgl_start = bam_txn->rx_sgl_pos;
+   desc->dir = DMA_FROM_DEVICE;
+   dir_eng = DMA_DEV_TO_MEM;
+   }
+
+   sg_mark_end(sgl + sgl_cnt - 1);
+   ret = dma_map_sg(nandc->dev, sgl, sgl_cnt, desc->dir);
+   if (ret == 0) {
+   dev_err(nandc->dev, "failure in mapping desc\n");
+   kfree(desc);
+   return -ENOMEM;
+   }
+
+   desc->sgl_cnt = sgl_cnt;
+   desc->bam_sgl = sgl;
+
+   dma_desc = dmaengine_prep_slave_sg(chan, sgl, sgl_cnt, dir_eng,
+  flags);
+
+   if (!dma_desc) {
+   dev_err(nandc->dev, "failure in prep desc\n");
+   kfree(desc);
+   return -EINVAL;
+   }
+
+   desc->dma_desc = dma_desc;
+
+   list_add_tail(&desc->node, &nandc->desc_list);
+
+   return 0;
+}
+
+static int prep_adm_dma_desc(struct qcom_nand_controller *nandc, bool read,
+int reg_off, const void *vaddr, int size,
+bool flow_control)
  {
 

[PATCH v4 1/2] dt-bindings: gpio: davinci: Add keystone-k2g compatible

[Keerthy]

The patch adds keystone-k2g compatible, specific properties and
an example. The patch also adds the details of supported SoCs
for each compatible.

Signed-off-by: Keerthy 
Acked-by: Rob Herring 
---

Changes in v4:

  * Changed documentation links.
  * Added Rob's Ack.
  * Replaced keystone-k2g with 66AK2G
  * Corrected the $Subject
  * Changed compatible to ti,k2g-gpio

Changes in v3:

  * Added details about family of SoCs corresponding to compatibles.

 .../devicetree/bindings/gpio/gpio-davinci.txt  | 91 +-
 1 file changed, 89 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt 
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index 5079ba7..5ad08b2 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,10 @@
 Davinci/Keystone GPIO controller bindings
 
 Required Properties:
-- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
+- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs
+   "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L,
+   66AK2E SoCs
+   "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
 
 - reg: Physical base address of the controller and the size of memory mapped
registers.
@@ -20,7 +23,21 @@ Required Properties:
 - ti,ngpio: The number of GPIO pins supported.
 
 - ti,davinci-gpio-unbanked: The number of GPIOs that have an individual 
interrupt
-line to processor.
+   line to processor.
+
+- clocks: Should contain the device's input clock, and should be defined as per
+  the appropriate clock bindings consumer usage in,
+
+  Documentation/devicetree/bindings/clock/keystone-gate.txt
+for 66AK2HK/66AK2L/66AK2E SoCs or,
+
+  Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+for 66AK2G SoCs
+
+- clock-names: Name should be "gpio";
+
+Currently clock-names and clocks are needed for all keystone 2 platforms
+Davinci platforms do not have DT clocks as of now.
 
 The GPIO controller also acts as an interrupt controller. It uses the default
 two cells specifier as described in Documentation/devicetree/bindings/
@@ -60,3 +77,73 @@ leds {
...
};
 };
+
+Example for 66AK2G:
+
+gpio0: gpio@2603000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x02603000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <144>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001b 0x0>;
+   clock-names = "gpio";
+};
+
+Example for 66AK2HK/66AK2L/66AK2E:
+
+gpio0: gpio@260bf00 {
+   compatible = "ti,keystone-gpio";
+   reg = <0x0260bf00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   /* HW Interrupts mapped to GPIO pins */
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = <&clkgpio>;
+   clock-names = "gpio";
+   ti,ngpio = <32>;
+   ti,davinci-gpio-unbanked = <32>;
+};
-- 
1.9.1

[PATCH v4 2/2] ARM: dts: keystone-k2g: Add gpio nodes

[Keerthy]

66AK2G has 2 instances of gpio. The first one has all the 144 GPIOs
functional. 9 banks with 16 gpios making a total of 144. The second
instance has only the GPIO0:GPIO67 functional and rest are marked
reserved.

Signed-off-by: Keerthy 
Acked-by: Linus Walleij 
---

Changes in v4:

  * Couple of rephrasing in the commit log.
  * Changed compatible to ti,k2g-gpio.

Changes in v2:

  * Split the documentation part into a separate patch.

 arch/arm/boot/dts/keystone-k2g.dtsi | 42 +
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa..4eb1ba8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "ti,k2g","ti,keystone";
@@ -168,5 +169,46 @@
#reset-cells = <2>;
};
};
+
+   gpio0: gpio@2603000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x02603000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <144>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001b 0x0>;
+   clock-names = "gpio";
+   };
+
+   gpio1: gpio@260a000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x0260a000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <68>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001c 0x0>;
+   clock-names = "gpio";
+   };
};
 };
-- 
1.9.1

Re: [v4 2/2] ARM: dts: keystone-k2g: Add gpio nodes

[Keerthy]

On Friday 04 August 2017 11:15 AM, Keerthy wrote:
> 66AK2G has 2 instances of gpio. The first one has all the 144 GPIOs
> functional. 9 banks with 16 gpios making a total of 144. The second
> instance has only the GPIO0:GPIO67 functional and rest are marked
> reserved.

I will send with the $subject fixed please ignore this.


> 
> Signed-off-by: Keerthy 
> Acked-by: Linus Walleij 
> ---
> 
> Changes in v4:
> 
>   * Couple of rephrasing in the commit log.
>   * Changed compatible to ti,k2g-gpio.
> 
> Changes in v2:
> 
>   * Split the documentation part into a separate patch.
> 
>  arch/arm/boot/dts/keystone-k2g.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
> b/arch/arm/boot/dts/keystone-k2g.dtsi
> index bf4d1fa..4eb1ba8 100644
> --- a/arch/arm/boot/dts/keystone-k2g.dtsi
> +++ b/arch/arm/boot/dts/keystone-k2g.dtsi
> @@ -15,6 +15,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  / {
>   compatible = "ti,k2g","ti,keystone";
> @@ -168,5 +169,46 @@
>   #reset-cells = <2>;
>   };
>   };
> +
> + gpio0: gpio@2603000 {
> + compatible = "ti,k2g-gpio", "ti,keystone-gpio";
> + reg = <0x02603000 0x100>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + ti,ngpio = <144>;
> + ti,davinci-gpio-unbanked = <0>;
> + clocks = <&k2g_clks 0x001b 0x0>;
> + clock-names = "gpio";
> + };
> +
> + gpio1: gpio@260a000 {
> + compatible = "ti,k2g-gpio", "ti,keystone-gpio";
> + reg = <0x0260a000 0x100>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + ti,ngpio = <68>;
> + ti,davinci-gpio-unbanked = <0>;
> + clocks = <&k2g_clks 0x001c 0x0>;
> + clock-names = "gpio";
> + };
>   };
>  };
> 

[v4 2/2] ARM: dts: keystone-k2g: Add gpio nodes

[Keerthy]

66AK2G has 2 instances of gpio. The first one has all the 144 GPIOs
functional. 9 banks with 16 gpios making a total of 144. The second
instance has only the GPIO0:GPIO67 functional and rest are marked
reserved.

Signed-off-by: Keerthy 
Acked-by: Linus Walleij 
---

Changes in v4:

  * Couple of rephrasing in the commit log.
  * Changed compatible to ti,k2g-gpio.

Changes in v2:

  * Split the documentation part into a separate patch.

 arch/arm/boot/dts/keystone-k2g.dtsi | 42 +
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa..4eb1ba8 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 
 / {
compatible = "ti,k2g","ti,keystone";
@@ -168,5 +169,46 @@
#reset-cells = <2>;
};
};
+
+   gpio0: gpio@2603000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x02603000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <144>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001b 0x0>;
+   clock-names = "gpio";
+   };
+
+   gpio1: gpio@260a000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x0260a000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <68>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001c 0x0>;
+   clock-names = "gpio";
+   };
};
 };
-- 
1.9.1

[v4 1/2] dt-bindings: gpio: davinci: Add keystone-k2g compatible

[Keerthy]

The patch adds keystone-k2g compatible, specific properties and
an example. The patch also adds the details of supported SoCs
for each compatible.

Signed-off-by: Keerthy 
Acked-by: Rob Herring 
---

Changes in v4:

  * Changed documentation links.
  * Added Rob's Ack.
  * Replaced keystone-k2g with 66AK2G
  * Corrected the $Subject
  * Changed compatible to ti,k2g-gpio

Changes in v3:

  * Added details about family of SoCs corresponding to compatibles.

 .../devicetree/bindings/gpio/gpio-davinci.txt  | 91 +-
 1 file changed, 89 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt 
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index 5079ba7..5ad08b2 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,10 @@
 Davinci/Keystone GPIO controller bindings
 
 Required Properties:
-- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
+- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs
+   "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L,
+   66AK2E SoCs
+   "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G
 
 - reg: Physical base address of the controller and the size of memory mapped
registers.
@@ -20,7 +23,21 @@ Required Properties:
 - ti,ngpio: The number of GPIO pins supported.
 
 - ti,davinci-gpio-unbanked: The number of GPIOs that have an individual 
interrupt
-line to processor.
+   line to processor.
+
+- clocks: Should contain the device's input clock, and should be defined as per
+  the appropriate clock bindings consumer usage in,
+
+  Documentation/devicetree/bindings/clock/keystone-gate.txt
+for 66AK2HK/66AK2L/66AK2E SoCs or,
+
+  Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+for 66AK2G SoCs
+
+- clock-names: Name should be "gpio";
+
+Currently clock-names and clocks are needed for all keystone 2 platforms
+Davinci platforms do not have DT clocks as of now.
 
 The GPIO controller also acts as an interrupt controller. It uses the default
 two cells specifier as described in Documentation/devicetree/bindings/
@@ -60,3 +77,73 @@ leds {
...
};
 };
+
+Example for 66AK2G:
+
+gpio0: gpio@2603000 {
+   compatible = "ti,k2g-gpio", "ti,keystone-gpio";
+   reg = <0x02603000 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   ti,ngpio = <144>;
+   ti,davinci-gpio-unbanked = <0>;
+   clocks = <&k2g_clks 0x001b 0x0>;
+   clock-names = "gpio";
+};
+
+Example for 66AK2HK/66AK2L/66AK2E:
+
+gpio0: gpio@260bf00 {
+   compatible = "ti,keystone-gpio";
+   reg = <0x0260bf00 0x100>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   /* HW Interrupts mapped to GPIO pins */
+   interrupts = ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ,
+   ;
+   clocks = <&clkgpio>;
+   clock-names = "gpio";
+   ti,ngpio = <32>;
+   ti,davinci-gpio-unbanked = <32>;
+};
-- 
1.9.1

Re: [v4 2/2] ARM: dts: keystone-k2g: Add gpio nodes

[Keerthy]

On Friday 04 August 2017 11:15 AM, Keerthy wrote:
> 66AK2G has 2 instances of gpio. The first one has all the 144 GPIOs
> functional. 9 banks with 16 gpios making a total of 144. The second
> instance has only the GPIO0:GPIO67 functional and rest are marked
> reserved.

Oops. I will send with the $subject fixed please ignore this.

> 
> Signed-off-by: Keerthy 
> Acked-by: Linus Walleij 
> ---
> 
> Changes in v4:
> 
>   * Couple of rephrasing in the commit log.
>   * Changed compatible to ti,k2g-gpio.
> 
> Changes in v2:
> 
>   * Split the documentation part into a separate patch.
> 
>  arch/arm/boot/dts/keystone-k2g.dtsi | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
> b/arch/arm/boot/dts/keystone-k2g.dtsi
> index bf4d1fa..4eb1ba8 100644
> --- a/arch/arm/boot/dts/keystone-k2g.dtsi
> +++ b/arch/arm/boot/dts/keystone-k2g.dtsi
> @@ -15,6 +15,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  / {
>   compatible = "ti,k2g","ti,keystone";
> @@ -168,5 +169,46 @@
>   #reset-cells = <2>;
>   };
>   };
> +
> + gpio0: gpio@2603000 {
> + compatible = "ti,k2g-gpio", "ti,keystone-gpio";
> + reg = <0x02603000 0x100>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + ti,ngpio = <144>;
> + ti,davinci-gpio-unbanked = <0>;
> + clocks = <&k2g_clks 0x001b 0x0>;
> + clock-names = "gpio";
> + };
> +
> + gpio1: gpio@260a000 {
> + compatible = "ti,k2g-gpio", "ti,keystone-gpio";
> + reg = <0x0260a000 0x100>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupts = ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + ti,ngpio = <68>;
> + ti,davinci-gpio-unbanked = <0>;
> + clocks = <&k2g_clks 0x001c 0x0>;
> + clock-names = "gpio";
> + };
>   };
>  };
> 

[PATCH] samples/bpf: Fix cross compiler error with bpf sample

[Joel Fernandes]

When cross-compiling the bpf sample map_perf_test for aarch64, I find that
__NR_getpgrp is undefined. This causes build errors. Fix it by allowing the
deprecated syscall in the sample.

Signed-off-by: Joel Fernandes 
---
 samples/bpf/map_perf_test_user.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/samples/bpf/map_perf_test_user.c b/samples/bpf/map_perf_test_user.c
index 1a8894b5ac51..6e6fc7121640 100644
--- a/samples/bpf/map_perf_test_user.c
+++ b/samples/bpf/map_perf_test_user.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 #include 
+#define __ARCH_WANT_SYSCALL_DEPRECATED
 #include 
+#undef __ARCH_WANT_SYSCALL_DEPRECATED
 #include 
 #include 
 #include 
-- 
2.14.0.rc1.383.gd1ce394fe2-goog

Re: Gift-

[Mayrhofer Family]

Good Day,

My wife and I have awarded you with a donation of $ 1,000,000.00 Dollars from 
part of our Jackpot Lottery of 50 Million Dollars, respond with your details 
for claims.

We await your earliest response and God Bless you.

Friedrich And Annand Mayrhofer.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels

[Sam Ravnborg]

Hi Davem.

On Thu, Aug 03, 2017 at 02:57:48PM -0700, David Miller wrote:
> From: Mikael Pettersson 
> Date: Thu, 3 Aug 2017 22:02:57 +0200
> 
> > With that in place the kernel booted fine.
> > When I then ran the `poll' strace test binary, the OOPS was replaced by:
> > 
> > [  140.589913] _copy_from_user(fff000123c8dfa7c,   (null), 240) res 
> > 240
> > [  140.753162] _copy_from_user(fff000123c8dfa7c, f7e4a000, 8) res 8
> > [  140.824155] _copy_from_user(fff000123c8dfa7c, f7e49ff8, 16) res 
> > 18442240552407530112
> > 
> > That last `res' doesn't look good.
> 
> Please test this patch:
> 
> diff --git a/arch/sparc/lib/U3memcpy.S b/arch/sparc/lib/U3memcpy.S
> index 54f9870..5a8cb37 100644
> --- a/arch/sparc/lib/U3memcpy.S
> +++ b/arch/sparc/lib/U3memcpy.S
> @@ -145,13 +145,13 @@ ENDPROC(U3_retl_o2_plus_GS_plus_0x08)
>  ENTRY(U3_retl_o2_and_7_plus_GS)
>   and %o2, 7, %o2
>   retl
> -  add%o2, GLOBAL_SPARE, %o2
> +  add%o2, GLOBAL_SPARE, %o0
>  ENDPROC(U3_retl_o2_and_7_plus_GS)
>  ENTRY(U3_retl_o2_and_7_plus_GS_plus_8)
>   add GLOBAL_SPARE, 8, GLOBAL_SPARE
>   and %o2, 7, %o2
>   retl
> -  add%o2, GLOBAL_SPARE, %o2
> +  add%o2, GLOBAL_SPARE, %o0
>  ENDPROC(U3_retl_o2_and_7_plus_GS_plus_8)
>  #endif
>  
Patch looks obviously correct, and I am a bit irritated that
I did not see this myself.
Reviewed-by: Sam Ravnborg 

I will send another patch that fixes/adds a few comments to the same file.

Sam

[PATCH 4/5] scsi/esp_scsi: Avoid sending ABORT TASK SET messages

[Finn Thain]

If an LLD aborts a task set, it should complete the affected commands
with the appropriate result code. In a couple of cases esp_scsi doesn't
do so.

When the initiator receives an unhandled message, just respond by sending
a MESSAGE REJECT instead of ABORT TASK SET, and thus avoid the issue.

OTOH, a MESSAGE REJECT sent by a target can be taken as an indication
that the initiator messed up somehow. It isn't always possible to abort
correctly, so just fall back on a SCSI bus reset, which will complete the
affected commands with the appropriate result code.

For example, certain Apple (Sony) CD-ROM drives, when the non-existent
LUN 1 is scanned, can't handle the INQUIRY command. The problem is not
detected until the initiator gets a MESSAGE REJECT. Whenever esp_scsi
sees that message, it raises ATN and sends ABORT TASK SET -- but
neglects to complete the failed scmd.

The target then goes into DATA OUT phase (probably bogus), while the ESP
device goes into disconnected mode (surprising, given the bus phase).
The next Transfer Information command from esp_scsi then causes
an Invalid Command interrupt because that command is not valid when in
disconnected mode:

mac_esp: using PDMA for controller 0
mac_esp mac_esp.0: esp0: regs[50f1:(null)] irq[19]
mac_esp mac_esp.0: esp0: is a ESP236, 16 MHz (ccf=4), SCSI ID 7
scsi host0: esp
scsi 0:0:0:0: Direct-Access SEAGATE  ST318416N0010 PQ: 0 ANSI: 3
scsi target0:0:0: Beginning Domain Validation
scsi target0:0:0: asynchronous
scsi target0:0:0: Domain Validation skipping write tests
scsi target0:0:0: Ending Domain Validation
scsi 0:0:3:0: CD-ROMSONY CD-ROM CDU-8003A 1.9a PQ: 0 ANSI: 2 CCS
scsi target0:0:3: Beginning Domain Validation
scsi target0:0:3: FAST-5 SCSI 2.0 MB/s ST (500 ns, offset 15)
scsi target0:0:3: Domain Validation skipping write tests
scsi target0:0:3: Ending Domain Validation
scsi host0: unexpected IREG 40
scsi host0: Dumping command log
scsi host0: ent[2] CMD val[c2] sreg[90] seqreg[cc] sreg2[00] ireg[20] ss[01] 
event[0c]
scsi host0: ent[3] CMD val[00] sreg[91] seqreg[04] sreg2[00] ireg[18] ss[00] 
event[0c]
scsi host0: ent[4] EVENT val[0d] sreg[91] seqreg[04] sreg2[00] ireg[18] ss[00] 
event[0c]
scsi host0: ent[5] EVENT val[03] sreg[91] seqreg[04] sreg2[00] ireg[18] ss[00] 
event[0d]
scsi host0: ent[6] CMD val[90] sreg[91] seqreg[04] sreg2[00] ireg[18] ss[00] 
event[03]
scsi host0: ent[7] EVENT val[05] sreg[91] seqreg[04] sreg2[00] ireg[18] ss[00] 
event[03]
scsi host0: ent[8] EVENT val[0d] sreg[93] seqreg[cc] sreg2[00] ireg[10] ss[00] 
event[05]
scsi host0: ent[9] CMD val[01] sreg[93] seqreg[cc] sreg2[00] ireg[10] ss[00] 
event[0d]
scsi host0: ent[10] CMD val[11] sreg[93] seqreg[cc] sreg2[00] ireg[10] ss[00] 
event[0d]
scsi host0: ent[11] EVENT val[0b] sreg[93] seqreg[cc] sreg2[00] ireg[10] ss[00] 
event[0d]
scsi host0: ent[12] CMD val[12] sreg[97] seqreg[cc] sreg2[00] ireg[08] ss[00] 
event[0b]
scsi host0: ent[13] EVENT val[0c] sreg[97] seqreg[cc] sreg2[00] ireg[08] ss[00] 
event[0b]
scsi host0: ent[14] CMD val[44] sreg[90] seqreg[cc] sreg2[00] ireg[20] ss[00] 
event[0c]
scsi host0: ent[15] CMD val[01] sreg[90] seqreg[cc] sreg2[00] ireg[20] ss[01] 
event[0c]
scsi host0: ent[16] CMD val[c2] sreg[90] seqreg[cc] sreg2[00] ireg[20] ss[01] 
event[0c]
scsi host0: ent[17] CMD val[00] sreg[87] seqreg[02] sreg2[00] ireg[18] ss[00] 
event[0c]
scsi host0: ent[18] EVENT val[0d] sreg[87] seqreg[02] sreg2[00] ireg[18] ss[00] 
event[0c]
scsi host0: ent[19] EVENT val[06] sreg[87] seqreg[02] sreg2[00] ireg[18] ss[00] 
event[0d]
scsi host0: ent[20] CMD val[01] sreg[87] seqreg[02] sreg2[00] ireg[18] ss[00] 
event[06]
scsi host0: ent[21] CMD val[10] sreg[87] seqreg[02] sreg2[00] ireg[18] ss[00] 
event[06]
scsi host0: ent[22] CMD val[1a] sreg[87] seqreg[ca] sreg2[00] ireg[08] ss[00] 
event[06]
scsi host0: ent[23] CMD val[12] sreg[87] seqreg[ca] sreg2[00] ireg[08] ss[00] 
event[06]
scsi host0: ent[24] EVENT val[0d] sreg[87] seqreg[ca] sreg2[00] ireg[08] ss[00] 
event[06]
scsi host0: ent[25] EVENT val[09] sreg[86] seqreg[ca] sreg2[00] ireg[10] ss[00] 
event[0d]
scsi host0: ent[26] CMD val[01] sreg[86] seqreg[ca] sreg2[00] ireg[10] ss[00] 
event[09]
scsi host0: ent[27] CMD val[10] sreg[86] seqreg[ca] sreg2[00] ireg[10] ss[00] 
event[09]
scsi host0: ent[28] EVENT val[0a] sreg[86] seqreg[ca] sreg2[00] ireg[10] ss[00] 
event[09]
scsi host0: ent[29] EVENT val[0d] sreg[80] seqreg[ca] sreg2[00] ireg[20] ss[00] 
event[0a]
scsi host0: ent[30] EVENT val[04] sreg[80] seqreg[ca] sreg2[00] ireg[20] ss[00] 
event[0d]
scsi host0: ent[31] CMD val[01] sreg[80] seqreg[ca] sreg2[00] ireg[20] ss[00] 
event[04]
scsi host0: ent[0] CMD val[90] sreg[80] seqreg[ca] sreg2[00] ireg[20] ss[00] 
event[04]
scsi host0: ent[1] EVENT val[05] sreg[80] seqreg[ca] sreg2[00] ireg[20] ss[00] 
event[04]
scsi target0:0:3: FAST-5 SCSI 2.0 MB/s ST (500 ns, offset 15)
scsi target0:0:0: asynchronous
sr 0:0:3:0: [sr0] scsi-1 drive
cdrom: Uniform CD-ROM driver Revision: 3.20
sd 0:0:0:

[PATCH 3/5] scsi/esp_scsi: Clean up control flow and dead code

[Finn Thain]

This patch improves readability. There are no functional changes.

Since this touches on a questionable ESP_INTR_DC conditional, add some
commentary to help others who may (as I did) find themselves chasing an
"Invalid Command" error after the device flags this condition.

This cleanup also eliminates a warning from "make W=1":
drivers/scsi/esp_scsi.c: In function 'esp_finish_select':
drivers/scsi/esp_scsi.c:1233:5: warning: variable 'orig_select_state' set but 
not used [-Wunused-but-set-variable]
  u8 orig_select_state;

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/scsi/esp_scsi.c | 40 ++--
 drivers/scsi/esp_scsi.h |  1 -
 2 files changed, 14 insertions(+), 27 deletions(-)

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 71cb05b1c3eb..93fef2b3d357 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -597,14 +597,12 @@ static int esp_alloc_lun_tag(struct esp_cmd_entry *ent,
 
lp->non_tagged_cmd = ent;
return 0;
-   } else {
-   /* Tagged command, see if blocked by a
-* non-tagged one.
-*/
-   if (lp->non_tagged_cmd || lp->hold)
-   return -EBUSY;
}
 
+   /* Tagged command. Check that it isn't blocked by a non-tagged one. */
+   if (lp->non_tagged_cmd || lp->hold)
+   return -EBUSY;
+
BUG_ON(lp->tagged_cmds[ent->orig_tag[1]]);
 
lp->tagged_cmds[ent->orig_tag[1]] = ent;
@@ -1210,12 +1208,6 @@ static int esp_reconnect(struct esp *esp)
 
esp->active_cmd = ent;
 
-   if (ent->flags & ESP_CMD_FLAG_ABORT) {
-   esp->msg_out[0] = ABORT_TASK_SET;
-   esp->msg_out_len = 1;
-   scsi_esp_cmd(esp, ESP_CMD_SATN);
-   }
-
esp_event(esp, ESP_EVENT_CHECK_PHASE);
esp_restore_pointers(esp, ent);
esp->flags |= ESP_FLAG_QUICKIRQ_CHECK;
@@ -1230,9 +1222,6 @@ static int esp_finish_select(struct esp *esp)
 {
struct esp_cmd_entry *ent;
struct scsi_cmnd *cmd;
-   u8 orig_select_state;
-
-   orig_select_state = esp->select_state;
 
/* No longer selecting.  */
esp->select_state = ESP_SELECT_NONE;
@@ -1745,7 +1734,6 @@ static int esp_process_event(struct esp *esp)
return 0;
}
goto again;
-   break;
 
case ESP_EVENT_DATA_IN:
write = 1;
@@ -1956,12 +1944,14 @@ static int esp_process_event(struct esp *esp)
} else {
if (esp->msg_out_len > 1)
esp->ops->dma_invalidate(esp);
-   }
 
-   if (!(esp->ireg & ESP_INTR_DC)) {
-   if (esp->rev != FASHME)
+   /* XXX if the chip went into disconnected mode,
+* we can't run the phase state machine anyway.
+*/
+   if (!(esp->ireg & ESP_INTR_DC))
scsi_esp_cmd(esp, ESP_CMD_NULL);
}
+
esp_event(esp, ESP_EVENT_CHECK_PHASE);
goto again;
case ESP_EVENT_MSGIN:
@@ -2022,7 +2012,6 @@ static int esp_process_event(struct esp *esp)
}
esp_schedule_reset(esp);
return 0;
-   break;
 
case ESP_EVENT_RESET:
scsi_esp_cmd(esp, ESP_CMD_RS);
@@ -2033,7 +2022,6 @@ static int esp_process_event(struct esp *esp)
 "Unexpected event %x, resetting\n", esp->event);
esp_schedule_reset(esp);
return 0;
-   break;
}
return 1;
 }
@@ -2170,14 +2158,14 @@ static void __esp_interrupt(struct esp *esp)
 
esp_schedule_reset(esp);
} else {
-   if (!(esp->ireg & ESP_INTR_RSEL)) {
-   /* Some combination of FDONE, BSERV, DC.  */
-   if (esp->select_state != ESP_SELECT_NONE)
-   intr_done = esp_finish_select(esp);
-   } else if (esp->ireg & ESP_INTR_RSEL) {
+   if (esp->ireg & ESP_INTR_RSEL) {
if (esp->active_cmd)
(void) esp_finish_select(esp);
intr_done = esp_reconnect(esp);
+   } else {
+   /* Some combination of FDONE, BSERV, DC. */
+   if (esp->select_state != ESP_SELECT_NONE)
+   intr_done = esp_finish_select(esp);
}
}
while (!intr_done)
diff --git a/drivers/scsi/esp_scsi.h b/drivers/scsi/esp_scsi.h
index 84dcbe4a6268..7e8932ae91f8 100644
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -281,7 +281,6 @@ struct esp_cmd_entry {
 
u8  flags;
 #define ESP_CMD_FLAG_WRITE 0x01 /* DM

[PATCH 5/5] scsi/esp_scsi: Always clear msg_out_len after MESSAGE OUT phase

[Finn Thain]

After sending a message, always clear esp->msg_out_len. Otherwise,
eh_abort_handler may subsequently fail to send an ABORT TASK SET
message.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/scsi/esp_scsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c
index 4d1e08a87274..c3fc34b9964d 100644
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -1951,6 +1951,8 @@ static int esp_process_event(struct esp *esp)
scsi_esp_cmd(esp, ESP_CMD_NULL);
}
 
+   esp->msg_out_len = 0;
+
esp_event(esp, ESP_EVENT_CHECK_PHASE);
goto again;
case ESP_EVENT_MSGIN:
-- 
2.13.0

[PATCH 0/5] esp_scsi, mac_esp: Various fixes and cleanups

[Finn Thain]

This series has been tested on m68k Macs (ESP236 equivalent).

Some more testing with different targets and devices (FAS236 etc)
might be nice. Being that the esp_scsi fixes are on error paths,
more review may actually be more valuable than more testing...


Finn Thain (5):
  scsi/mac_esp: Avoid type warning from sparse
  scsi/mac_esp: Fix PIO transfers for MESSAGE IN phase
  scsi/esp_scsi: Clean up control flow and dead code
  scsi/esp_scsi: Avoid sending ABORT TASK SET messages
  scsi/esp_scsi: Always clear msg_out_len after MESSAGE OUT phase

 drivers/scsi/esp_scsi.c | 53 +
 drivers/scsi/esp_scsi.h |  1 -
 drivers/scsi/mac_esp.c  | 37 +-
 3 files changed, 42 insertions(+), 49 deletions(-)

-- 
2.13.0

[PATCH 1/5] scsi/mac_esp: Avoid type warning from sparse

[Finn Thain]

Avoid the following warning from "make C=1":

  CHECK   drivers/scsi/mac_esp.c
drivers/scsi/mac_esp.c:357:30: warning: incorrect type in initializer 
(different address spaces)
drivers/scsi/mac_esp.c:357:30:expected unsigned char [usertype] *fifo
drivers/scsi/mac_esp.c:357:30:got void [noderef] *

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/scsi/mac_esp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index cdb61eaa2d1f..253142f3cf6f 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -348,7 +348,7 @@ static void mac_esp_send_pio_cmd(struct esp *esp, u32 addr, 
u32 esp_count,
 u32 dma_count, int write, u8 cmd)
 {
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
-   u8 *fifo = esp->regs + ESP_FDATA * 16;
+   u8 __iomem *fifo = esp->regs + ESP_FDATA * 16;
 
cmd &= ~ESP_CMD_DMA;
mep->error = 0;
-- 
2.13.0

[PATCH 2/5] scsi/mac_esp: Fix PIO transfers for MESSAGE IN phase

[Finn Thain]

When in MESSAGE IN phase, the ESP device does not automatically
acknowledge each byte that is transferred by PIO. The mac_esp driver
neglects to explicitly ack them, which causes a timeout during messages
larger than one byte (e.g. tag bytes during reconnect). Fix this with an
ESP_CMD_MOK command after each byte.

The MESSAGE IN phase is also different in that each byte transferred
raises ESP_INTR_FDONE. So don't exit the transfer loop for this interrupt,
for this phase.

That resolves the "Reconnect IRQ2 timeout" error on those Macs which use
PIO transfers instead of PDMA. This patch also improves on the weak tests
for unexpected interrupts and phase changes during PIO transfers.

Tested-by: Stan Johnson 
Fixes: 02507a80b35e ("[PATCH] [SCSI] mac_esp: fix PIO mode, take 2")
Signed-off-by: Finn Thain 
---
 drivers/scsi/mac_esp.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/mac_esp.c b/drivers/scsi/mac_esp.c
index 253142f3cf6f..eb551f3cc471 100644
--- a/drivers/scsi/mac_esp.c
+++ b/drivers/scsi/mac_esp.c
@@ -349,25 +349,23 @@ static void mac_esp_send_pio_cmd(struct esp *esp, u32 
addr, u32 esp_count,
 {
struct mac_esp_priv *mep = MAC_ESP_GET_PRIV(esp);
u8 __iomem *fifo = esp->regs + ESP_FDATA * 16;
+   u8 phase = esp->sreg & ESP_STAT_PMASK;
 
cmd &= ~ESP_CMD_DMA;
mep->error = 0;
 
if (write) {
+   u8 *dst = (u8 *)addr;
+   u8 mask = ~(phase == ESP_MIP ? ESP_INTR_FDONE : ESP_INTR_BSERV);
+
scsi_esp_cmd(esp, cmd);
 
while (1) {
-   unsigned int n;
-
-   n = mac_esp_wait_for_fifo(esp);
-   if (!n)
+   if (!mac_esp_wait_for_fifo(esp))
break;
 
-   if (n > esp_count)
-   n = esp_count;
-   esp_count -= n;
-
-   MAC_ESP_PIO_LOOP("%2@,%0@+", n);
+   *dst++ = esp_read8(ESP_FDATA);
+   --esp_count;
 
if (!esp_count)
break;
@@ -375,14 +373,17 @@ static void mac_esp_send_pio_cmd(struct esp *esp, u32 
addr, u32 esp_count,
if (mac_esp_wait_for_intr(esp))
break;
 
-   if (((esp->sreg & ESP_STAT_PMASK) != ESP_DIP) &&
-   ((esp->sreg & ESP_STAT_PMASK) != ESP_MIP))
+   if ((esp->sreg & ESP_STAT_PMASK) != phase)
break;
 
esp->ireg = esp_read8(ESP_INTRPT);
-   if ((esp->ireg & (ESP_INTR_DC | ESP_INTR_BSERV)) !=
-   ESP_INTR_BSERV)
+   if (esp->ireg & mask) {
+   mep->error = 1;
break;
+   }
+
+   if (phase == ESP_MIP)
+   scsi_esp_cmd(esp, ESP_CMD_MOK);
 
scsi_esp_cmd(esp, ESP_CMD_TI);
}
@@ -402,14 +403,14 @@ static void mac_esp_send_pio_cmd(struct esp *esp, u32 
addr, u32 esp_count,
if (mac_esp_wait_for_intr(esp))
break;
 
-   if (((esp->sreg & ESP_STAT_PMASK) != ESP_DOP) &&
-   ((esp->sreg & ESP_STAT_PMASK) != ESP_MOP))
+   if ((esp->sreg & ESP_STAT_PMASK) != phase)
break;
 
esp->ireg = esp_read8(ESP_INTRPT);
-   if ((esp->ireg & (ESP_INTR_DC | ESP_INTR_BSERV)) !=
-   ESP_INTR_BSERV)
+   if (esp->ireg & ~ESP_INTR_BSERV) {
+   mep->error = 1;
break;
+   }
 
n = MAC_ESP_FIFO_SIZE -
(esp_read8(ESP_FFLAGS) & ESP_FF_FBYTES);
-- 
2.13.0

Re: [PATCH v2 16/25] mtd: nand: qcom: allocate BAM transaction

[Archit Taneja]

On 07/19/2017 05:18 PM, Abhishek Sahu wrote:

The BAM transaction is the core data structure which will be used
for all the data transfers in QPIC NAND. Since the base layer is
serializing all the NAND requests so allocating BAM transaction
before every transfer will be overhead. The memory for it be


What does 'base layer' here mean?


allocated during probe time and before every transfer, it will be
cleared. The BAM transaction contains the array of command
elements, command and data scatter gather list and indexes. For
every transfer, all the resource will be taken from BAM
transaction.


Could you also mention in the commit message that the size of the
buffer used for BAM transactions is calculated based on the NAND device
with the maximum page size, among all the devices connected to the
controller.



Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 114 ++
  1 file changed, 114 insertions(+)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index f49c3da..fc29c97 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /* NANDc reg offsets */

  #define   NAND_FLASH_CMD  0x00
@@ -172,6 +173,45 @@
  #define   ECC_BCH_4BITBIT(2)
  #define   ECC_BCH_8BITBIT(3)
  
+#define QPIC_PER_CW_CMD_ELEMENTS	32

+#define QPIC_PER_CW_CMD_SGL32
+#define QPIC_PER_CW_DATA_SGL   8
+
+/*
+ * This data type corresponds to the BAM transaction which will be used for all
+ * NAND transfers.
+ * @bam_ce - the array of bam command elements
+ * @cmd_sgl - sgl for nand bam command pipe
+ * @data_sgl - sgl for nand bam consumer/producer pipe
+ * @bam_ce_pos - the index in bam_ce which is available for next sgl request
+ * @bam_ce_start - the index in bam_ce which marks the start position ce
+ *for current sgl. It will be used for size calculation
+ *for current sgl
+ * @cmd_sgl_pos - current index in command sgl.
+ * @tx_sgl_pos - current index in data sgl for tx.
+ * @rx_sgl_pos - current index in data sgl for rx.
+ */
+struct bam_transaction {
+   struct bam_cmd_element *bam_ce;
+   struct scatterlist *cmd_sgl;
+   struct scatterlist *data_sgl;
+   u32 bam_ce_pos;
+   u32 bam_ce_start;
+   u32 cmd_sgl_pos;
+   u32 cmd_sgl_start;
+   u32 tx_sgl_pos;
+   u32 tx_sgl_start;
+   u32 rx_sgl_pos;
+   u32 rx_sgl_start;
+};
+
+/*
+ * This data type corresponds to the nand dma descriptor
+ * @list - list for desc_info
+ * @dir - DMA transfer direction
+ * @sgl - sgl which will be used for single sgl dma descriptor
+ * @dma_desc - low level dma engine descriptor
+ */
  struct desc_info {
struct list_head node;
  
@@ -238,6 +278,8 @@ struct nandc_regs {

   * @cmd1/vld: some fixed controller register values
   * @props:properties of current NAND controller IP,
   *initialized via DT match data
+ * @max_cwperpage: maximum qpic codeword required. calcualted


s/calcualted/calculated

Thanks,
Archit


+ * from all nand device pagesize
   */
  struct qcom_nand_controller {
struct nand_hw_control controller;
@@ -265,11 +307,13 @@ struct qcom_nand_controller {
};
  
  	struct list_head desc_list;

+   struct bam_transaction *bam_txn;
  
  	u8		*data_buffer;

int buf_size;
int buf_count;
int buf_start;
+   unsigned intmax_cwperpage;
  
  	__le32 *reg_read_buf;

dma_addr_t reg_read_buf_phys;
@@ -342,6 +386,50 @@ struct qcom_props {
bool is_bam;
  };
  
+/* Frees the BAM transaction memory */

+static void free_bam_transaction(struct qcom_nand_controller *nandc)
+{
+   struct bam_transaction *bam_txn = nandc->bam_txn;
+
+   devm_kfree(nandc->dev, bam_txn);
+}
+
+/* Allocates and Initializes the BAM transaction */
+static struct bam_transaction *
+alloc_bam_transaction(struct qcom_nand_controller *nandc)
+{
+   struct bam_transaction *bam_txn;
+   size_t bam_txn_size;
+   unsigned int num_cw = nandc->max_cwperpage;
+   void *bam_txn_buf;
+
+   bam_txn_size =
+   sizeof(*bam_txn) + num_cw *
+   ((sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS) +
+   (sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL) +
+   (sizeof(*bam_txn->data_sgl) * QPIC_PER_CW_DATA_SGL));
+
+   bam_txn_buf = devm_kzalloc(nandc->dev, bam_txn_size, GFP_KERNEL);
+   if (!bam_txn_buf)
+   return NULL;
+
+   bam_txn = bam_txn_buf;
+   bam_txn_buf += sizeof(*bam_txn);
+
+   bam_txn->bam_ce = bam_txn_buf;
+   bam_txn_buf +=
+   sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS * num_cw;
+
+   bam_txn->cmd_sgl = bam_txn_buf;
+   bam_t

Re: [v5 09/15] sparc64: optimized struct page zeroing

[Sam Ravnborg]

Hi Pavel.

On Thu, Aug 03, 2017 at 05:23:47PM -0400, Pavel Tatashin wrote:
> Add an optimized mm_zero_struct_page(), so struct page's are zeroed without
> calling memset(). We do eight regular stores, thus avoid cost of membar.

The commit message does no longer reflect the implementation,
and should be updated.

> 
> Signed-off-by: Pavel Tatashin 
> Reviewed-by: Steven Sistare 
> Reviewed-by: Daniel Jordan 
> Reviewed-by: Bob Picco 
> ---
>  arch/sparc/include/asm/pgtable_64.h | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/arch/sparc/include/asm/pgtable_64.h 
> b/arch/sparc/include/asm/pgtable_64.h
> index 6fbd931f0570..be47537e84c5 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -230,6 +230,38 @@ extern unsigned long _PAGE_ALL_SZ_BITS;
>  extern struct page *mem_map_zero;
>  #define ZERO_PAGE(vaddr) (mem_map_zero)
>  
> +/* This macro must be updated when the size of struct page grows above 80
> + * or reduces below 64.
> + * The idea that compiler optimizes out switch() statement, and only
> + * leaves clrx instructions or memset() call.
> + */
> +#define  mm_zero_struct_page(pp) do {
> \
> + unsigned long *_pp = (void *)(pp);  \
> + \
> + /* Check that struct page is 8-byte aligned */  \
> + BUILD_BUG_ON(sizeof(struct page) & 7);  \
Would also be good to catch if sizeof > 80 so we do not silently
migrate to the suboptimal version (silent at build time).
Can you at build time catch if size is no any of: 64, 72, 80
and simplify the below a little?

Sam

Re: [PATCH net-next] net: dsa: User per-cpu 64-bit statistics

[Eric Dumazet]

On Thu, 2017-08-03 at 21:33 -0700, Florian Fainelli wrote:
> During testing with a background iperf pushing 1Gbit/sec worth of
> traffic and having both ifconfig and ethtool collect statistics, we
> could see quite frequent deadlocks. Convert the often accessed DSA slave
> network devices statistics to per-cpu 64-bit statistics to remove these
> deadlocks and provide fast efficient statistics updates.
> 

This seems to be a bug fix, it would be nice to get a proper tag like :

Fixes: f613ed665bb3 ("net: dsa: Add support for 64-bit statistics")

Problem here is that if multiple cpus can call dsa_switch_rcv() at the
same time, then u64_stats_update_begin() contract is not respected.

include/linux/u64_stats_sync.h states :

 * Usage :
 *
 * Stats producer (writer) should use following template granted it already got
 * an exclusive access to counters (a lock is already taken, or per cpu
 * data is used [in a non preemptable context])
 *
 *   spin_lock_bh(...) or other synchronization to get exclusive access
 *   ...
 *   u64_stats_update_begin(&stats->syncp);

[PATCH BUGFIX/IMPROVEMENT V2 1/2] block,bfq: refactor device-idling logic

[Paolo Valente]

The logic that decides whether to idle the device is scattered across
three functions. Almost all of the logic is in the function
bfq_bfqq_may_idle, but (1) part of the decision is made in
bfq_update_idle_window, and (2) the function bfq_bfqq_must_idle may
switch off idling regardless of the output of bfq_bfqq_may_idle. In
addition, both bfq_update_idle_window and bfq_bfqq_must_idle make
their decisions as a function of parameters that are used, for similar
purposes, also in bfq_bfqq_may_idle. This commit addresses these
issues by moving all the logic into bfq_bfqq_may_idle.

Signed-off-by: Paolo Valente 
---
 block/bfq-iosched.c | 117 +++-
 block/bfq-iosched.h |  12 +++---
 2 files changed, 67 insertions(+), 62 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 436b6ca..ccdc9e6 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -128,7 +128,7 @@ BFQ_BFQQ_FNS(busy);
 BFQ_BFQQ_FNS(wait_request);
 BFQ_BFQQ_FNS(non_blocking_wait_rq);
 BFQ_BFQQ_FNS(fifo_expire);
-BFQ_BFQQ_FNS(idle_window);
+BFQ_BFQQ_FNS(has_short_ttime);
 BFQ_BFQQ_FNS(sync);
 BFQ_BFQQ_FNS(IO_bound);
 BFQ_BFQQ_FNS(in_large_burst);
@@ -731,10 +731,10 @@ bfq_bfqq_resume_state(struct bfq_queue *bfqq, struct 
bfq_data *bfqd,
unsigned int old_wr_coeff = bfqq->wr_coeff;
bool busy = bfq_already_existing && bfq_bfqq_busy(bfqq);
 
-   if (bic->saved_idle_window)
-   bfq_mark_bfqq_idle_window(bfqq);
+   if (bic->saved_has_short_ttime)
+   bfq_mark_bfqq_has_short_ttime(bfqq);
else
-   bfq_clear_bfqq_idle_window(bfqq);
+   bfq_clear_bfqq_has_short_ttime(bfqq);
 
if (bic->saved_IO_bound)
bfq_mark_bfqq_IO_bound(bfqq);
@@ -2012,7 +2012,7 @@ static void bfq_bfqq_save_state(struct bfq_queue *bfqq)
return;
 
bic->saved_ttime = bfqq->ttime;
-   bic->saved_idle_window = bfq_bfqq_idle_window(bfqq);
+   bic->saved_has_short_ttime = bfq_bfqq_has_short_ttime(bfqq);
bic->saved_IO_bound = bfq_bfqq_IO_bound(bfqq);
bic->saved_in_large_burst = bfq_bfqq_in_large_burst(bfqq);
bic->was_in_burst_list = !hlist_unhashed(&bfqq->burst_list_node);
@@ -3038,8 +3038,8 @@ void bfq_bfqq_expire(struct bfq_data *bfqd,
}
 
bfq_log_bfqq(bfqd, bfqq,
-   "expire (%d, slow %d, num_disp %d, idle_win %d)", reason,
-   slow, bfqq->dispatched, bfq_bfqq_idle_window(bfqq));
+   "expire (%d, slow %d, num_disp %d, short_ttime %d)", reason,
+   slow, bfqq->dispatched, bfq_bfqq_has_short_ttime(bfqq));
 
/*
 * Increase, decrease or leave budget unchanged according to
@@ -3122,6 +3122,18 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
return true;
 
/*
+* Idling is performed only if slice_idle > 0. In addition, we
+* do not idle if
+* (a) bfqq is async
+* (b) bfqq is in the idle io prio class: in this case we do
+* not idle because we want to minimize the bandwidth that
+* queues in this class can steal to higher-priority queues
+*/
+   if (bfqd->bfq_slice_idle == 0 || !bfq_bfqq_sync(bfqq) ||
+   bfq_class_idle(bfqq))
+   return false;
+
+   /*
 * The next variable takes into account the cases where idling
 * boosts the throughput.
 *
@@ -3142,7 +3154,7 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
 */
idling_boosts_thr = !bfqd->hw_tag ||
(!blk_queue_nonrot(bfqd->queue) && bfq_bfqq_IO_bound(bfqq) &&
-bfq_bfqq_idle_window(bfqq));
+bfq_bfqq_has_short_ttime(bfqq));
 
/*
 * The value of the next variable,
@@ -3313,16 +3325,13 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
asymmetric_scenario && !bfq_bfqq_in_large_burst(bfqq);
 
/*
-* We have now all the components we need to compute the return
-* value of the function, which is true only if both the following
-* conditions hold:
-* 1) bfqq is sync, because idling make sense only for sync queues;
-* 2) idling either boosts the throughput (without issues), or
-*is necessary to preserve service guarantees.
+* We have now all the components we need to compute the
+* return value of the function, which is true only if idling
+* either boosts the throughput (without issues), or is
+* necessary to preserve service guarantees.
 */
-   return bfq_bfqq_sync(bfqq) &&
-   (idling_boosts_thr_without_issues ||
-idling_needed_for_service_guarantees);
+   return idling_boosts_thr_without_issues ||
+   idling_needed_for_service_guarantees;
 }
 
 /*
@@ -3338,10 +3347,7 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
  */
 static bool bfq_bfqq_must_idle(

[PATCH BUGFIX/IMPROVEMENT V2 0/2] block, bfq: improve and refactor throughput-boosting logic

[Paolo Valente]

Hi,
these two patches improve throughput-boosting logic in two
aspects. The first patch refactors the parts of the device-idling
logic, related to throughput boosting, that are still scattered across
the source file bfq-iosched.c. The patch concetrates all the logic in
one function. The second patch fixes/improves device idling for
flash-based devices that have no internal queueing of I/O requests.

The contribution in the first patch has been triggered by that in the
second patch: finding the change made by the second patch has been
more difficult than it had to be, because the logic that decides
whether to idle the device is scattered across three functions.

The second patch provides a significant throghput boost, for random
I/O with flash-based non-queueing devices. For example, on a HiKey
board, throughput increases by up to 125%, growing, e.g., from 6.9MB/s
to 15.6MB/s with two or three random readers in parallel.

Thanks,
Paolo

Paolo Valente (2):
  block,bfq: refactor device-idling logic
  block, bfq: boost throughput with flash-based non-queueing devices

 block/bfq-iosched.c | 144 
 block/bfq-iosched.h |  12 ++---
 2 files changed, 85 insertions(+), 71 deletions(-)

--
2.10.0

[PATCH BUGFIX/IMPROVEMENT V2 2/2] block, bfq: boost throughput with flash-based non-queueing devices

[Paolo Valente]

When a queue associated with a process remains empty, there are cases
where throughput gets boosted if the device is idled to await the
arrival of a new I/O request for that queue. Currently, BFQ assumes
that one of these cases is when the device has no internal queueing
(regardless of the properties of the I/O being served). Unfortunately,
this condition has proved to be too general. So, this commit refines it
as "the device has no internal queueing and is rotational".

This refinement provides a significant throughput boost with random
I/O, on flash-based storage without internal queueing. For example, on
a HiKey board, throughput increases by up to 125%, growing, e.g., from
6.9MB/s to 15.6MB/s with two or three random readers in parallel.

Signed-off-by: Paolo Valente 
Signed-off-by: Luca Miccio 
---
 block/bfq-iosched.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index ccdc9e6..509f399 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -3114,7 +3114,10 @@ static bool bfq_may_expire_for_budg_timeout(struct 
bfq_queue *bfqq)
 static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
 {
struct bfq_data *bfqd = bfqq->bfqd;
-   bool idling_boosts_thr, idling_boosts_thr_without_issues,
+   bool rot_without_queueing =
+   !blk_queue_nonrot(bfqd->queue) && !bfqd->hw_tag,
+   bfqq_sequential_and_IO_bound,
+   idling_boosts_thr, idling_boosts_thr_without_issues,
idling_needed_for_service_guarantees,
asymmetric_scenario;
 
@@ -3133,28 +3136,34 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq)
bfq_class_idle(bfqq))
return false;
 
+   bfqq_sequential_and_IO_bound = !BFQQ_SEEKY(bfqq) &&
+   bfq_bfqq_IO_bound(bfqq) && bfq_bfqq_has_short_ttime(bfqq);
+
/*
 * The next variable takes into account the cases where idling
 * boosts the throughput.
 *
 * The value of the variable is computed considering, first, that
 * idling is virtually always beneficial for the throughput if:
-* (a) the device is not NCQ-capable, or
-* (b) regardless of the presence of NCQ, the device is rotational
-* and the request pattern for bfqq is I/O-bound and sequential.
+* (a) the device is not NCQ-capable and rotational, or
+* (b) regardless of the presence of NCQ, the device is rotational and
+* the request pattern for bfqq is I/O-bound and sequential, or
+* (c) regardless of whether it is rotational, the device is
+* not NCQ-capable and the request pattern for bfqq is
+* I/O-bound and sequential.
 *
 * Secondly, and in contrast to the above item (b), idling an
 * NCQ-capable flash-based device would not boost the
 * throughput even with sequential I/O; rather it would lower
 * the throughput in proportion to how fast the device
 * is. Accordingly, the next variable is true if any of the
-* above conditions (a) and (b) is true, and, in particular,
-* happens to be false if bfqd is an NCQ-capable flash-based
-* device.
+* above conditions (a), (b) or (c) is true, and, in
+* particular, happens to be false if bfqd is an NCQ-capable
+* flash-based device.
 */
-   idling_boosts_thr = !bfqd->hw_tag ||
-   (!blk_queue_nonrot(bfqd->queue) && bfq_bfqq_IO_bound(bfqq) &&
-bfq_bfqq_has_short_ttime(bfqq));
+   idling_boosts_thr = rot_without_queueing ||
+   ((!blk_queue_nonrot(bfqd->queue) || !bfqd->hw_tag) &&
+bfqq_sequential_and_IO_bound);
 
/*
 * The value of the next variable,
-- 
2.10.0

Re: [V3 1/2] phy: ralink-usb: add driver for Mediatek/Ralink

[Kishon Vijay Abraham I]

On Thursday 03 August 2017 04:02 PM, Harvey Hunt wrote:
> From: John Crispin 
> 
> Add a driver to setup the USB phy on Mediatek/Ralink SoCs.
> The driver is trivial and only sets up power and host mode.
> 
> Signed-off-by: John Crispin 
> Signed-off-by: Harvey Hunt 
> Cc: linux-kernel@vger.kernel.org 
> Cc: linux-media...@lists.infradead.org 
> ---
> Changes in V3
> * Separate DT bindings
> * Update Kconfig text
> * Modify John's email address
> * Rebase onto v4.13-rc3
> 
> Changes in V2
> * remove refcounting
> * drop empty functions
> * dont use static globals
> * use explicit compatible strings
> 
>  drivers/phy/Kconfig  |   8 ++
>  drivers/phy/Makefile |   1 +
>  drivers/phy/phy-ralink-usb.c | 175 
> +++
>  3 files changed, 184 insertions(+)
>  create mode 100644 drivers/phy/phy-ralink-usb.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index c1807d4..79f966a 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -41,6 +41,14 @@ config PHY_PISTACHIO_USB
>   help
> Enable this to support the USB2.0 PHY on the IMG Pistachio SoC.
>  
> +config PHY_RALINK_USB
> + tristate "Ralink USB PHY driver"
> + select GENERIC_PHY
> + depends on RALINK

depends on RALINK || COMPILE_TEST?

Thanks
Kishon

Re: [PATCH v2 2/4] phy: add inno-usb2-phy driver for hi3798cv200 SoC

[Kishon Vijay Abraham I]

Hi,

On Wednesday 26 July 2017 11:36 AM, Jiancheng Xue wrote:
> From: Pengcheng Li 
> 
> Add inno-usb2-phy driver for hi3798cv200 SoC.
> 
> Signed-off-by: Pengcheng Li 
> Signed-off-by: Jiancheng Xue 
> ---
>  drivers/phy/hisilicon/Kconfig  |  11 +-
>  drivers/phy/hisilicon/Makefile |   1 +
>  drivers/phy/hisilicon/phy-hisi-inno-usb2.c | 236 
> +
>  3 files changed, 247 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> 
> diff --git a/drivers/phy/hisilicon/Kconfig b/drivers/phy/hisilicon/Kconfig
> index 6164c4c..6a675c5 100644
> --- a/drivers/phy/hisilicon/Kconfig
> +++ b/drivers/phy/hisilicon/Kconfig
> @@ -8,9 +8,18 @@ config PHY_HI6220_USB
>   select MFD_SYSCON
>   help
> Enable this to support the HISILICON HI6220 USB PHY.
> -
  ^^
not related to $patch.
> To compile this driver as a module, choose M here.
>  
> +config PHY_HISI_INNO_USB2
> +   tristate "HiSilicon INNO USB2 PHY support"
> +   depends on (ARCH_HISI) || COMPILE_TEST
> +   select GENERIC_PHY
> +   select MFD_SYSCON
> +   help
> + Support for INNO USB2 PHY on HiSilicon SoCs. This Phy supports
> + USB 1.5Mb/s, USB 12Mb/s, USB 480Mb/s speeds. It supports one
> + USB host port to accept one USB device.
> +
>  config PHY_HIX5HD2_SATA
>   tristate "HIX5HD2 SATA PHY Driver"
>   depends on ARCH_HIX5HD2 && OF && HAS_IOMEM
> diff --git a/drivers/phy/hisilicon/Makefile b/drivers/phy/hisilicon/Makefile
> index 541b348..e6c9794 100644
> --- a/drivers/phy/hisilicon/Makefile
> +++ b/drivers/phy/hisilicon/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_PHY_HI6220_USB) += phy-hi6220-usb.o
> +obj-$(CONFIG_PHY_HISI_INNO_USB2) += phy-hisi-inno-usb2.o
>  obj-$(CONFIG_PHY_HIX5HD2_SATA)   += phy-hix5hd2-sata.o
> diff --git a/drivers/phy/hisilicon/phy-hisi-inno-usb2.c 
> b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> new file mode 100644
> index 000..7edf4a3
> --- /dev/null
> +++ b/drivers/phy/hisilicon/phy-hisi-inno-usb2.c
> @@ -0,0 +1,236 @@
> +/*
> + * HiSilicon INNO USB2 PHY Driver.
> + *
> + * Copyright (c) 2016-2017 HiSilicon Technologies Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define INNO_PHY_PORT_NUM2
> +#define REF_CLK_STABLE_TIME  100 /* unit:us */
> +#define UTMI_CLK_STABLE_TIME 200 /* unit:us */
> +#define TEST_CLK_STABLE_TIME 2   /* unit:ms */
> +#define PHY_CLK_STABLE_TIME  2   /* unit:ms */
> +#define UTMI_RST_COMPLETE_TIME   2   /* unit:ms */
> +#define TEST_RST_COMPLETE_TIME   100 /* unit:us */
> +#define POR_RST_COMPLETE_TIME300 /* unit:us */
> +#define PHY_TEST_DATAGENMASK(7, 0)
> +#define PHY_TEST_ADDRGENMASK(15, 8)
> +#define PHY_TEST_PORTGENMASK(18, 16)
> +#define PHY_TEST_WRENBIT(21)
> +#define PHY_TEST_CLK BIT(22) /* rising edge active */
> +#define PHY_TEST_RST BIT(23) /* low active */
> +#define PHY_CLK_ENABLE   BIT(2)
> +
> +struct hisi_inno_phy_priv {
> + struct regmap *syscon;
> + u32 reg;
> + struct clk *ref_clk;
> + struct reset_control *por_rst;
> + struct reset_control *test_rst;
> + struct reset_control *utmi_rst[INNO_PHY_PORT_NUM];
> + u32 port_num;
> +};
> +
> +static void hisi_inno_phy_write_reg(struct regmap *syscon,
> + u32 reg, u8 port, u32 addr, u32 data)
> +{
> + u32 value;
> +
> + value = (data & PHY_TEST_DATA)
> + | ((addr << 8) & PHY_TEST_ADDR)
> + | ((port << 16) & PHY_TEST_PORT)
> + | PHY_TEST_WREN | PHY_TEST_RST;
> + regmap_write(syscon, reg, value);
> + value |= PHY_TEST_CLK;
> + regmap_write(syscon, reg, value);
> + value &= ~PHY_TEST_CLK;
> + regmap_write(syscon, reg, value);
> +}
> +
> +static void hisi_inno_phy_setup(struct hisi_inno_phy_priv *priv)
> +{
> + /* The phy clk is controlled by the port0 register 0x06. */
> + hisi_inno_phy_write_reg(priv->syscon,
> + priv->reg, 0, 0x06, PHY_CLK_ENABLE);
> + msleep(PHY_CLK_STABLE_TIME);
> +}
> +
> +static int hisi_inno_phy_init(struct phy *phy)
> +{
> + struct hisi_inno_phy_priv *p

Re: [PATCH v2 15/25] mtd: nand: qcom: DMA mapping support for register read buffer

[Archit Taneja]

Hi,

On 07/19/2017 05:18 PM, Abhishek Sahu wrote:

The EBI2 NAND directly remaps register read buffer with
dma_map_sg. The QPIC NAND will give register read buffer in its
command descriptor and the command descriptor will be mapped with
dma_map_sg instead of register read buffer. This command
descriptor will contain the dma address of the register read
buffer.


It isn't entirely clear from the commit message why we can't use
the existing code with QPIC NAND. A bit of background would help.
Can you consider adding something like this:

"On QPIC NAND, which uses BAM DMA, we read the controller registers
by preparing a BAM command descriptor. This descriptor requires the
the a) controller register address and b) the DMA address in which we
want to store the value read back from the controller register. Therefore,
it's required that we also map our register read buffer for DMA (using
dma_map_single). We use the returned DMA address for preparing
entries in our command descriptor."



This patch adds the DMA mapping support for register read buffer.
This buffer will be DMA mapped during allocation time. Before
starting of any operation, this buffer will be synced for device
operation and after operation completion, it will be synced for
CPU.

Signed-off-by: Abhishek Sahu 
---
  drivers/mtd/nand/qcom_nandc.c | 40 
  1 file changed, 40 insertions(+)

diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
index cb2b245..f49c3da 100644
--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -229,6 +229,7 @@ struct nandc_regs {
   *by upper layers directly
   * @buf_size/count/start: markers for chip->read_buf/write_buf functions
   * @reg_read_buf: local buffer for reading back registers via DMA
+ * @reg_read_buf_phys: contains dma address for register read buffer


Maybe we should rename this as reg_read_dma since it is dma_addr_t ?

Looks good otherwise.

Thanks,
Archit


   * @reg_read_pos: marker for data read in reg_read_buf
   *
   * @regs: a contiguous chunk of memory for DMA register
@@ -271,6 +272,7 @@ struct qcom_nand_controller {
int buf_start;
  
  	__le32 *reg_read_buf;

+   dma_addr_t reg_read_buf_phys;
int reg_read_pos;
  
  	struct nandc_regs *regs;

@@ -363,6 +365,24 @@ static inline void nandc_write(struct qcom_nand_controller 
*nandc, int offset,
iowrite32(val, nandc->base + offset);
  }
  
+static inline void nandc_read_buffer_sync(struct qcom_nand_controller *nandc,

+ bool is_cpu)
+{
+   if (!nandc->props->is_bam)
+   return;
+
+   if (is_cpu)
+   dma_sync_single_for_cpu(nandc->dev, nandc->reg_read_buf_phys,
+   MAX_REG_RD *
+   sizeof(*nandc->reg_read_buf),
+   DMA_FROM_DEVICE);
+   else
+   dma_sync_single_for_device(nandc->dev, nandc->reg_read_buf_phys,
+  MAX_REG_RD *
+  sizeof(*nandc->reg_read_buf),
+  DMA_FROM_DEVICE);
+}
+
  static __le32 *offset_to_nandc_reg(struct nandc_regs *regs, int offset)
  {
switch (offset) {
@@ -847,6 +867,7 @@ static void free_descs(struct qcom_nand_controller *nandc)
  static void clear_read_regs(struct qcom_nand_controller *nandc)
  {
nandc->reg_read_pos = 0;
+   nandc_read_buffer_sync(nandc, false);
  }
  
  static void pre_command(struct qcom_nand_host *host, int command)

@@ -876,6 +897,7 @@ static void parse_erase_write_errors(struct qcom_nand_host 
*host, int command)
int i;
  
  	num_cw = command == NAND_CMD_PAGEPROG ? ecc->steps : 1;

+   nandc_read_buffer_sync(nandc, true);
  
  	for (i = 0; i < num_cw; i++) {

u32 flash_status = le32_to_cpu(nandc->reg_read_buf[i]);
@@ -897,6 +919,7 @@ static void post_command(struct qcom_nand_host *host, int 
command)
  
  	switch (command) {

case NAND_CMD_READID:
+   nandc_read_buffer_sync(nandc, true);
memcpy(nandc->data_buffer, nandc->reg_read_buf,
   nandc->buf_count);
break;
@@ -1060,6 +1083,7 @@ static int parse_read_errors(struct qcom_nand_host *host, 
u8 *data_buf,
int i;
  
  	buf = (struct read_stats *)nandc->reg_read_buf;

+   nandc_read_buffer_sync(nandc, true);
  
  	for (i = 0; i < ecc->steps; i++, buf++) {

u32 flash, buffer, erased_cw;
@@ -1996,6 +2020,16 @@ static int qcom_nandc_alloc(struct qcom_nand_controller 
*nandc)
return -ENOMEM;
  
  	if (nandc->props->is_bam) {

+   nandc->reg_read_buf_phys =
+   dma_map_single(nandc->dev, nandc->reg_read_buf,
+  MAX_

Re: [PATCH 0/2] PCI: dwc: convert remaining dbi read/writes to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

[Kishon Vijay Abraham I]

On Friday 04 August 2017 01:42 AM, Bjorn Helgaas wrote:
> Adding Kishon & Pratyush for real this time.
> 
> On Wed, Aug 02, 2017 at 04:32:56PM -0500, Bjorn Helgaas wrote:
>> [+cc Kishon, Pratyush]
>>
>> On Fri, Jul 14, 2017 at 02:07:33PM +0200, Niklas Cassel wrote:
>>> Since the introduction of the dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros,
>>> most dw_pcie_read(pci->dbi_base, ..)/dw_pcie_write(pci->dbi_base, ..) calls
>>> have been converted to dw_pcie_readX_dbi/dw_pcie_writeX_dbi calls.
>>> Convert the remaining calls.
>>>
>>> Niklas Cassel (2):
>>>   PCI: dwc: dra7xx: utilize dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros
>>>   PCI: dwc: spear13xx: utilize dw_pcie_readX_dbi/dw_pcie_writeX_dbi
>>> macros
>>>
>>>  drivers/pci/dwc/pci-dra7xx.c | 14 ++
>>>  drivers/pci/dwc/pcie-spear13xx.c | 22 ++
>>>  2 files changed, 16 insertions(+), 20 deletions(-)
>>
>> Waiting for ack from maintainers (cc'd).

Tested this in dra7xx
Acked-by: Kishon Vijay Abraham I 

Re: [PATCH 2/2] fsnotify: use method copy_dname copying filename

[Al Viro]

On Fri, Aug 04, 2017 at 11:58:41AM +0800, 林守磊 wrote:
> Hi all
> 
> I sent this patch two months ago, then I found CVE from this link last night
> 
> http://seclists.org/oss-sec/2017/q3/240
> 
> which not only references this patch, but also provides a upstream fix
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49d31c2f389acfe83417083e1208422b4091cd9
> 
> I was wondering why @viro hadn't noticed this mail (And @viro fixed
> this). I'm new here and nobody,
> trying to do my best to help the this linux community. I was looking
> forword to your reply, because some
> insufficiency may exists in my work, I'd like to learn from you guys
> 
> Thanks and humble enough to wait your reply

Fair enough.  As for the reasons why allocation of name copy is a bad idea,
consider this: only short (embedded) names get overwritten on rename.
External ones (i.e. anything longer than 32 bytes or so) are unmodified
until freed.  And their lifetime is controlled by a refcount, so we can
trivially get a guaranteed to be stable name in that case - all it takes
is bumping the refcount and the name _will_ stay around until we drop
the reference.  So we are left with the case of short names and that
is trivial to deal with - 32-byte array is small enough, so we can bloody
well have it on caller's stack and copy the (short) name there.
That approach avoids all the headache with allocation, allocation failure
handling, etc.  Stack footprint is not much higher (especially compared
to how much idiotify and friends stomp on the stack) and it's obviously
cheaper - we only copy the name in short case and we never go into
allocator.  And it's just as easy to use as "make a dynamic copy" variant
of API...

Al, still buried in packing boxes at the moment...

Re: [PATCH v5 3/4] sched/deadline: Add support for SD_PREFER_SIBLING on find_later_rq()

[Byungchul Park]

On Thu, Aug 03, 2017 at 02:03:34PM +0200, Peter Zijlstra wrote:
> This one I'm not sure on..  at the very least we should exclude all of
> the prefer sibling domain when we do the next domain, and if there are
> multiple prefer sibling levels, we should only pick the first
> fallback_cpu -- there is no point is overriding it with a possible CPU
> further away.

I agree.

> I implemented that below -- although the find_cpu() function is really
> rather horrible.
> 
> But still this isn't quite right, because when we consider this for SMT
> (as was the intent here) we'll happily occupy a full sibling core over
> finding an empty one.
> 
> Now, the problem is that actually doing the right thing quickly ends up
> very expensive, we'd have to scan the entire cache domain at least once,
> so maybe this is good enough.. no idea :/
> 
> 
> ---
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -1793,12 +1793,35 @@ static struct task_struct *pick_earliest
>  
>  static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask_dl);
>  
> +/*
> + * Find the first cpu in: mask & sd & ~prefer
  ^
Yes, I missed it.

> + */
> +static int find_cpu(const struct cpumask *mask,
> + const struct sched_domain *sd,
> + const struct sched_domain *prefer)
> +{
> + const struct cpumask *sds = sched_domain_span(sd);
> + const struct cpumask *ps  = prefer ? sched_domain_span(prefer) : NULL;
> + int cpu = -1;
> +
> + while ((cpu = cpumask_next(cpu, mask)) < nr_cpu_ids) {
> + if (!cpumask_test_cpu(cpu, sds))
> + continue;
> + if (ps && cpumask_test_cpu(cpu, ps))
> + continue;
> + break;
> + }
> +
> + return cpu;
> +}
> +
>  static int find_later_rq(struct task_struct *task)
>  {
> - struct sched_domain *sd;
> + struct sched_domain *sd, *prefer = NULL;
>   struct cpumask *later_mask = 
> this_cpu_cpumask_var_ptr(local_cpu_mask_dl);
>   int this_cpu = smp_processor_id();
>   int cpu = task_cpu(task);
> + int fallback_cpu = -1;
>  
>   /* Make sure the mask is initialized first */
>   if (unlikely(!later_mask))
> @@ -1850,8 +1873,7 @@ static int find_later_rq(struct task_str
>   return this_cpu;
>   }
>  
> - best_cpu = cpumask_first_and(later_mask,
> - sched_domain_span(sd));
> + best_cpu = find_cpu(later_mask, sd, prefer);
>   /*
>* Last chance: if a cpu being in both later_mask
>* and current sd span is valid, that becomes our
> @@ -1859,6 +1881,17 @@ static int find_later_rq(struct task_str
>* already under consideration through later_mask.
>*/
>   if (best_cpu < nr_cpu_ids) {
> + /*
> +  * If current domain is SD_PREFER_SIBLING
> +  * flaged, we have to get more chances to
> +  * check other siblings.
> +  */
> + if (sd->flags & SD_PREFER_SIBLING) {
> + prefer = sd;
> + if (fallback_cpu == -1)
^
 I like the 'if' statement.
 I should have done this.

> + fallback_cpu = best_cpu;
> + continue;
> + }
>   rcu_read_unlock();
>   return best_cpu;
>   }

Thank you.

Re: [PATCH] cpufreq: dt: Add rk3328 compatible to use generic cpufreq driver

[Viresh Kumar]

On 04-08-17, 09:52, Finley Xiao wrote:
> This patch adds the rk3328 compatible string for supporting
> the generic cpufreq driver on RK3328.
> 
> Signed-off-by: Finley Xiao 
> ---
>  drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c 
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 096aea7..13c0c47 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -76,6 +76,7 @@ static const struct of_device_id machines[] __initconst = {
>   { .compatible = "rockchip,rk3188", },
>   { .compatible = "rockchip,rk3228", },
>   { .compatible = "rockchip,rk3288", },
> + { .compatible = "rockchip,rk3328", },
>   { .compatible = "rockchip,rk3366", },
>   { .compatible = "rockchip,rk3368", },
>   { .compatible = "rockchip,rk3399", },

Acked-by: Viresh Kumar 

-- 
viresh

[PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 +--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_kblgt2.c 
b/drivers/gpu/drm/i915/i915_oa_kblgt2.c
index 87dbd0a..c9b6751 100644
--- a/drivers/gpu/drm/i915/i915_oa_kblgt2.c
+++ b/drivers/gpu/drm/i915/i915_oa_kblgt2.c
@@ -2412,7 +2412,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "f8d677e9-ff6f-4df1-9310-0334c6efacce",
.attrs =  attrs_render_basic,
 };
@@ -2434,7 +2434,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "e17fc42a-e614-41b6-90c4-1074841a6c77",
.attrs =  attrs_compute_basic,
 };
@@ -2456,7 +2456,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "d7a17a3a-ca71-40d2-a919-ace80d50633f",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2478,7 +2478,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "57b59202-172b-477a-87de-33f85572c589",
.attrs =  attrs_memory_reads,
 };
@@ -2500,7 +2500,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "3addf8ef-8e9b-40f5-a448-3dbb5d5128b0",
.attrs =  attrs_memory_writes,
 };
@@ -2522,7 +2522,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "4af0400a-81c3-47db-a6b6-deddbd75680e",
.attrs =  attrs_compute_extended,
 };
@@ -2544,7 +2544,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "0e22f995-79ca-4f67-83ab-e9d9772488d8",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2566,7 +2566,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "bc2a00f7-cb8a-4ff2-8ad0-e241dad16937",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2588,7 +2588,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "d2bbe790-f058-42d9-81c6-cdedcf655bc2",
.attrs =  attrs_l3_1,
 };
@@ -2610,7 +2610,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "2f8e32e4-5956-46e2-af31-c8ea95887332",
.attrs =  attrs_l3_2,
 };
@@ -2632,7 +2632,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "ca046aad-b5fb-4101-adce-6473ee6e5b14",
.attrs =  attrs_l3_3,
 };
@@ -2654,7 +2654,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "605f388f-24bb-455c-88e3-8d57ae0d7e9f",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2676,7 +2676,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "31dd157c-bf4e-4bab-bf2b-f5c8174af1af",
.attrs =  attrs_sampler,
 };
@@ -2698,7 +2698,7 @@ int i915_oa_select_metric_set_kblgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct

[PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_bdw.c | 44 +++---
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c 
b/drivers/gpu/drm/i915/i915_oa_bdw.c
index d4462c2..90c96c2 100644
--- a/drivers/gpu/drm/i915/i915_oa_bdw.c
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -4669,7 +4669,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "b541bd57-0e0f-4154-b4c0-5858010a2bf7",
.attrs =  attrs_render_basic,
 };
@@ -4691,7 +4691,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "35fbc9b2-a891-40a6-a38d-022bb7057552",
.attrs =  attrs_compute_basic,
 };
@@ -4713,7 +4713,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "233d0544-fff7-4281-8291-e02f222aff72",
.attrs =  attrs_render_pipe_profile,
 };
@@ -4735,7 +4735,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "2b255d48-2117-4fef-a8f7-f151e1d25a2c",
.attrs =  attrs_memory_reads,
 };
@@ -4757,7 +4757,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "f7fd3220-b466-4a4d-9f98-b0caf3f2394c",
.attrs =  attrs_memory_writes,
 };
@@ -4779,7 +4779,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "e99ccaca-821c-4df9-97a7-96bdb7204e43",
.attrs =  attrs_compute_extended,
 };
@@ -4801,7 +4801,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "27a364dc-8225-4ecb-b607-d6f1925598d9",
.attrs =  attrs_compute_l3_cache,
 };
@@ -4823,7 +4823,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_data_port_reads_coalescing = {
+static const struct attribute_group group_data_port_reads_coalescing = {
.name = "857fc630-2f09-4804-85f1-084adfadd5ab",
.attrs =  attrs_data_port_reads_coalescing,
 };
@@ -4845,7 +4845,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_data_port_writes_coalescing = {
+static const struct attribute_group group_data_port_writes_coalescing = {
.name = "343ebc99-4a55-414c-8c17-d8e259cf5e20",
.attrs =  attrs_data_port_writes_coalescing,
 };
@@ -4867,7 +4867,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "7bdafd88-a4fa-4ed5-bc09-1a977aa5be3e",
.attrs =  attrs_hdc_and_sf,
 };
@@ -4889,7 +4889,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "9385ebb2-f34f-4aa5-aec5-7e9cbbea0f0b",
.attrs =  attrs_l3_1,
 };
@@ -4911,7 +4911,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "446ae59b-ff2e-41c9-b49e-0184a54bf00a",
.attrs =  attrs_l3_2,
 };
@@ -4933,7 +4933,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "84a7956f-1ea4-4d0d-837f-e39a0376e38c",
.attrs =  attrs_l3_3,
 };
@@ -4955,7 +4955,7 @@ int i915_oa_select_metric_set_bdw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_4 = {
+static const struct 

[PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_glk.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_glk.c 
b/drivers/gpu/drm/i915/i915_oa_glk.c
index 2f356d5..a8eea3a 100644
--- a/drivers/gpu/drm/i915/i915_oa_glk.c
+++ b/drivers/gpu/drm/i915/i915_oa_glk.c
@@ -2119,7 +2119,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "d72df5c7-5b4a-4274-a43f-00b0fd51fc68",
.attrs =  attrs_render_basic,
 };
@@ -2141,7 +2141,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "814285f6-354d-41d2-ba49-e24e622714a0",
.attrs =  attrs_compute_basic,
 };
@@ -2163,7 +2163,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "07d397a6-b3e6-49f6-9433-a4f293d55978",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2185,7 +2185,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "1a356946-5428-450b-a2f0-89f8783a302d",
.attrs =  attrs_memory_reads,
 };
@@ -2207,7 +2207,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "5299be9d-7a61-4c99-9f81-f87e6c5aaca9",
.attrs =  attrs_memory_writes,
 };
@@ -2229,7 +2229,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "bc9bcff2-459a-4cbc-986d-a84b077153f3",
.attrs =  attrs_compute_extended,
 };
@@ -2251,7 +2251,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "88ec931f-5b4a-453a-9db6-a61232b6143d",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2273,7 +2273,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "530d176d-2a18-4014-adf8-1500c6c60835",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2295,7 +2295,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "fdee5a5a-f23c-43d1-aa73-f6257c71671d",
.attrs =  attrs_l3_1,
 };
@@ -2317,7 +2317,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "6617623e-ca73-4791-b2b7-ddedd0846a0c",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2339,7 +2339,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "f3b2ea63-e82e-4234-b418-44dd20dd34d0",
.attrs =  attrs_sampler,
 };
@@ -2361,7 +2361,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct attribute_group group_tdl_1 = {
.name = "14411d35-cbf6-4f5e-b68b-190faf9a1a83",
.attrs =  attrs_tdl_1,
 };
@@ -2383,7 +2383,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_2 = {
+static const struct attribute_group group_tdl_2 = {
.name = "ffa3f263-0478-4724-8c9f-c911c5ec0f1d",
.attrs =  attrs_tdl_2,
 };
@@ -2405,7 +2405,7 @@ int i915_oa_select_metric_set_glk(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extra = {
+static const struct attribute_group group_compute_extra = {
   

[PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_bxt.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_bxt.c 
b/drivers/gpu/drm/i915/i915_oa_bxt.c
index 93864d8..db80045 100644
--- a/drivers/gpu/drm/i915/i915_oa_bxt.c
+++ b/drivers/gpu/drm/i915/i915_oa_bxt.c
@@ -2207,7 +2207,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "22b9519a-e9ba-4c41-8b54-f4f8ca14fa0a",
.attrs =  attrs_render_basic,
 };
@@ -2229,7 +2229,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "012d72cf-82a9-4d25-8ddf-74076fd30797",
.attrs =  attrs_compute_basic,
 };
@@ -2251,7 +2251,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "ce416533-e49e-4211-80af-ec513590a914",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2273,7 +2273,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "398e2452-18d7-42d0-b241-e4d0a9148ada",
.attrs =  attrs_memory_reads,
 };
@@ -2295,7 +2295,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "d324a0d6-7269-4847-a5c2-6f71ddc7fed5",
.attrs =  attrs_memory_writes,
 };
@@ -2317,7 +2317,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "caf3596a-7bb1-4dec-b3b3-2a080d283b49",
.attrs =  attrs_compute_extended,
 };
@@ -2339,7 +2339,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "49b956e2-d5b9-47e0-9d8a-cee5e8cec527",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2361,7 +2361,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "f64ef50a-bdba-4b35-8f09-203c13d8ee5a",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2383,7 +2383,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "00ad5a41-7eab-4f7a-9103-49d411c67219",
.attrs =  attrs_l3_1,
 };
@@ -2405,7 +2405,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "46dc44ca-491c-4cc1-a951-e7b3e62bf02b",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2427,7 +2427,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "8364e2a8-af63-40af-b0d5-42969a255654",
.attrs =  attrs_sampler,
 };
@@ -2449,7 +2449,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct attribute_group group_tdl_1 = {
.name = "175c8092-cb25-4d1e-8dc7-b4fdd39e2d92",
.attrs =  attrs_tdl_1,
 };
@@ -2471,7 +2471,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_2 = {
+static const struct attribute_group group_tdl_2 = {
.name = "d260f03f-b34d-4b49-a44e-436819117332",
.attrs =  attrs_tdl_2,
 };
@@ -2493,7 +2493,7 @@ int i915_oa_select_metric_set_bxt(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extra = {
+static const struct attribute_group group_compute_extra = {
   

[PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 +--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_kblgt3.c 
b/drivers/gpu/drm/i915/i915_oa_kblgt3.c
index 6ed0925..f234801 100644
--- a/drivers/gpu/drm/i915/i915_oa_kblgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_kblgt3.c
@@ -2461,7 +2461,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "0286c920-2f6d-493b-b22d-7a5280df43de",
.attrs =  attrs_render_basic,
 };
@@ -2483,7 +2483,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "9823aaa1-b06f-40ce-884b-cd798c79f0c2",
.attrs =  attrs_compute_basic,
 };
@@ -2505,7 +2505,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "c7c735f3-ce58-45cf-aa04-30b183f1faff",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2527,7 +2527,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "96ec2219-040b-428a-856a-6bc03363a057",
.attrs =  attrs_memory_reads,
 };
@@ -2549,7 +2549,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "03372b64-4996-4d3b-aa18-790e75eeb9c2",
.attrs =  attrs_memory_writes,
 };
@@ -2571,7 +2571,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "31b4ce5a-bd61-4c1f-bb5d-f2e731412150",
.attrs =  attrs_compute_extended,
 };
@@ -2593,7 +2593,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "2ce0911a-27fc-4887-96f0-11084fa807c3",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2615,7 +2615,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "546c4c1d-99b8-42fb-a107-5aaabb5314a8",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2637,7 +2637,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "4e93d156-9b39-4268-8544-a8e0480806d7",
.attrs =  attrs_l3_1,
 };
@@ -2659,7 +2659,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "de1bec86-ca92-4b43-89fa-147653221cc0",
.attrs =  attrs_l3_2,
 };
@@ -2681,7 +2681,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "e63537bb-10be-4d4a-92c4-c6b0c65e02ef",
.attrs =  attrs_l3_3,
 };
@@ -2703,7 +2703,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "7a03a9f8-ec5e-46bb-8b67-1f0ff1476281",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2725,7 +2725,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "b25d2ebf-a6e0-4b29-96be-a9b010edeeda",
.attrs =  attrs_sampler,
 };
@@ -2747,7 +2747,7 @@ int i915_oa_select_metric_set_kblgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct

[PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 +--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_sklgt3.c 
b/drivers/gpu/drm/i915/i915_oa_sklgt3.c
index 7765e22..e26f300 100644
--- a/drivers/gpu/drm/i915/i915_oa_sklgt3.c
+++ b/drivers/gpu/drm/i915/i915_oa_sklgt3.c
@@ -2460,7 +2460,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "4616d450-2393-4836-8146-53c5ed84d359",
.attrs =  attrs_render_basic,
 };
@@ -2482,7 +2482,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "4320492b-fd03-42ac-922f-dbe1ef3b7b58",
.attrs =  attrs_compute_basic,
 };
@@ -2504,7 +2504,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "bd2d9cae-b9ec-4f5b-9d2f-934bed398a2d",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2526,7 +2526,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "4ca0f3fe-7fd3-4924-98cb-1807d9879767",
.attrs =  attrs_memory_reads,
 };
@@ -2548,7 +2548,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "a0c0172c-ee13-403d-99ff-2bdf6936cf14",
.attrs =  attrs_memory_writes,
 };
@@ -2570,7 +2570,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "52435e0b-f188-42ea-8680-21a56ee20dee",
.attrs =  attrs_compute_extended,
 };
@@ -2592,7 +2592,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "27076eeb-49f3-4fed-8423-c66506005c63",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2614,7 +2614,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "8071b409-c39a-4674-94d7-32962ecfb512",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2636,7 +2636,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "5e0b391e-9ea8-4901-b2ff-b64ff616c7ed",
.attrs =  attrs_l3_1,
 };
@@ -2658,7 +2658,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "25dc828e-1d2d-426e-9546-a1d4233cdf16",
.attrs =  attrs_l3_2,
 };
@@ -2680,7 +2680,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "3dba9405-2d7e-4d70-8199-e734e82fd6bf",
.attrs =  attrs_l3_3,
 };
@@ -2702,7 +2702,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "76935d7b-09c9-46bf-87f1-c18b4a86ebe5",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2724,7 +2724,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "1b34c0d6-4f4c-4d7b-833f-4aaf236d87a6",
.attrs =  attrs_sampler,
 };
@@ -2746,7 +2746,7 @@ int i915_oa_select_metric_set_sklgt3(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct

[PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_sysfs.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_sysfs.c 
b/drivers/gpu/drm/i915/i915_sysfs.c
index 1eef3fa..3fe3e56 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -96,7 +96,7 @@ static u32 calc_residency(struct drm_i915_private *dev_priv,
NULL
 };
 
-static struct attribute_group rc6_attr_group = {
+static const struct attribute_group rc6_attr_group = {
.name = power_group_name,
.attrs =  rc6_attrs
 };
@@ -107,7 +107,7 @@ static u32 calc_residency(struct drm_i915_private *dev_priv,
NULL
 };
 
-static struct attribute_group rc6p_attr_group = {
+static const struct attribute_group rc6p_attr_group = {
.name = power_group_name,
.attrs =  rc6p_attrs
 };
@@ -117,7 +117,7 @@ static u32 calc_residency(struct drm_i915_private *dev_priv,
NULL
 };
 
-static struct attribute_group media_rc6_attr_group = {
+static const struct attribute_group media_rc6_attr_group = {
.name = power_group_name,
.attrs =  media_rc6_attrs
 };
-- 
1.9.1

[PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 +--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_sklgt4.c 
b/drivers/gpu/drm/i915/i915_oa_sklgt4.c
index 9ddab43..0671899 100644
--- a/drivers/gpu/drm/i915/i915_oa_sklgt4.c
+++ b/drivers/gpu/drm/i915/i915_oa_sklgt4.c
@@ -2514,7 +2514,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "bad77c24-cc64-480d-99bf-e7b740713800",
.attrs =  attrs_render_basic,
 };
@@ -2536,7 +2536,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "7277228f-e7f3-4743-945a-6a2049d11377",
.attrs =  attrs_compute_basic,
 };
@@ -2558,7 +2558,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "463c668c-3f60-49b6-8f85-d995b635b3b2",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2580,7 +2580,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "3ae6e74c-72c3-4040-9bd0-7961430b8cc8",
.attrs =  attrs_memory_reads,
 };
@@ -2602,7 +2602,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "055f256d-4052-467c-8dec-6064a4806433",
.attrs =  attrs_memory_writes,
 };
@@ -2624,7 +2624,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "753972d4-87cd-4460-824d-754463ac5054",
.attrs =  attrs_compute_extended,
 };
@@ -2646,7 +2646,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "4e4392e9-8f73-457b-ab44-b49f7a0c733b",
.attrs =  attrs_compute_l3_cache,
 };
@@ -2668,7 +2668,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "730d95dd-7da8-4e1c-ab8d-c0eb1e4c1805",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2690,7 +2690,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "d9e86d70-462b-462a-851e-fd63e8c13d63",
.attrs =  attrs_l3_1,
 };
@@ -2712,7 +2712,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "52200424-6ee9-48b3-b7fa-0afcf1975e4d",
.attrs =  attrs_l3_2,
 };
@@ -2734,7 +2734,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "1988315f-0a26-44df-acb0-df7ec86b1456",
.attrs =  attrs_l3_3,
 };
@@ -2756,7 +2756,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "f1f17ca7-286e-4ae5-9d15-9fccad6c665d",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2778,7 +2778,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "00a9e0fb-3d2e-4405-852c-dce6334ffb3b",
.attrs =  attrs_sampler,
 };
@@ -2800,7 +2800,7 @@ int i915_oa_select_metric_set_sklgt4(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct

[PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_hsw.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_hsw.c 
b/drivers/gpu/drm/i915/i915_oa_hsw.c
index 10f169f..93fbe33 100644
--- a/drivers/gpu/drm/i915/i915_oa_hsw.c
+++ b/drivers/gpu/drm/i915/i915_oa_hsw.c
@@ -668,7 +668,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "403d8832-1a27-4aa6-a64e-f5389ce7b212",
.attrs =  attrs_render_basic,
 };
@@ -690,7 +690,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "39ad14bc-2380-45c4-91eb-fbcb3aa7ae7b",
.attrs =  attrs_compute_basic,
 };
@@ -712,7 +712,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "3865be28-6982-49fe-9494-e4d1b4795413",
.attrs =  attrs_compute_extended,
 };
@@ -734,7 +734,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "bb5ed49b-2497-4095-94f6-26ba294db88a",
.attrs =  attrs_memory_reads,
 };
@@ -756,7 +756,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "3358d639-9b5f-45ab-976d-9b08cbfc6240",
.attrs =  attrs_memory_writes,
 };
@@ -778,7 +778,7 @@ int i915_oa_select_metric_set_hsw(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler_balance = {
+static const struct attribute_group group_sampler_balance = {
.name = "bc274488-b4b6-40c7-90da-b77d7ad16189",
.attrs =  attrs_sampler_balance,
 };
-- 
1.9.1

[PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_chv.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_chv.c 
b/drivers/gpu/drm/i915/i915_oa_chv.c
index aa6bece..85c6c36 100644
--- a/drivers/gpu/drm/i915/i915_oa_chv.c
+++ b/drivers/gpu/drm/i915/i915_oa_chv.c
@@ -2422,7 +2422,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "9d8a3af5-c02c-4a4a-b947-f1672469e0fb",
.attrs =  attrs_render_basic,
 };
@@ -2444,7 +2444,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "f522a89c-ecd1-4522-8331-3383c54af5f5",
.attrs =  attrs_compute_basic,
 };
@@ -2466,7 +2466,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "a9ccc03d-a943-4e6b-9cd6-13e063075927",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2488,7 +2488,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "2cf0c064-68df-4fac-9b3f-57f51ca8a069",
.attrs =  attrs_hdc_and_sf,
 };
@@ -2510,7 +2510,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "78a87ff9-543a-49ce-95ea-26d86071ea93",
.attrs =  attrs_l3_1,
 };
@@ -2532,7 +2532,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "9f2cece5-7bfe-4320-ad66-8c7cc526bec5",
.attrs =  attrs_l3_2,
 };
@@ -2554,7 +2554,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "d890ef38-d309-47e4-b8b5-aa779bb19ab0",
.attrs =  attrs_l3_3,
 };
@@ -2576,7 +2576,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_4 = {
+static const struct attribute_group group_l3_4 = {
.name = "5fdff4a6-9dc8-45e1-bfda-ef54869fbdd4",
.attrs =  attrs_l3_4,
 };
@@ -2598,7 +2598,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "2c0e45e1-7e2c-4a14-ae00-0b7ec868b8aa",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -2620,7 +2620,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler_1 = {
+static const struct attribute_group group_sampler_1 = {
.name = "71148d78-baf5-474f-878a-e23158d0265d",
.attrs =  attrs_sampler_1,
 };
@@ -2642,7 +2642,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler_2 = {
+static const struct attribute_group group_sampler_2 = {
.name = "b996a2b7-c59c-492d-877a-8cd54fd6df84",
.attrs =  attrs_sampler_2,
 };
@@ -2664,7 +2664,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct attribute_group group_tdl_1 = {
.name = "eb2fecba-b431-42e7-8261-fe9429a6e67a",
.attrs =  attrs_tdl_1,
 };
@@ -2686,7 +2686,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_2 = {
+static const struct attribute_group group_tdl_2 = {
.name = "60749470-a648-4a4b-9f10-dbfe1e36e44d",
.attrs =  attrs_tdl_2,
 };
@@ -2708,7 +2708,7 @@ int i915_oa_select_metric_set_chv(struct drm_i915_private 
*dev_priv)
NULL,
 };
 
-static struct attribute_group group_test_oa = {
+static const struct attribute_group group_test_oa = {
.name = "4a534b07-cba3-414d-8d60-874830e883aa",
.attrs =  attrs_test_oa,
 };
-- 
1.9.1

[PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 +--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_oa_sklgt2.c 
b/drivers/gpu/drm/i915/i915_oa_sklgt2.c
index 1268bed..80e6054 100644
--- a/drivers/gpu/drm/i915/i915_oa_sklgt2.c
+++ b/drivers/gpu/drm/i915/i915_oa_sklgt2.c
@@ -2900,7 +2900,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_basic = {
+static const struct attribute_group group_render_basic = {
.name = "f519e481-24d2-4d42-87c9-3fdd12c00202",
.attrs =  attrs_render_basic,
 };
@@ -2922,7 +2922,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_basic = {
+static const struct attribute_group group_compute_basic = {
.name = "fe47b29d-ae51-423e-bff4-27d965a95b60",
.attrs =  attrs_compute_basic,
 };
@@ -2944,7 +2944,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_render_pipe_profile = {
+static const struct attribute_group group_render_pipe_profile = {
.name = "e0ad5ae0-84ba-4f29-a723-1906c12cb774",
.attrs =  attrs_render_pipe_profile,
 };
@@ -2966,7 +2966,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_reads = {
+static const struct attribute_group group_memory_reads = {
.name = "9bc436dd-6130-4add-affc-283eb6eaa864",
.attrs =  attrs_memory_reads,
 };
@@ -2988,7 +2988,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_memory_writes = {
+static const struct attribute_group group_memory_writes = {
.name = "2ea0da8f-3527-4669-9d9d-13099a7435bf",
.attrs =  attrs_memory_writes,
 };
@@ -3010,7 +3010,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_extended = {
+static const struct attribute_group group_compute_extended = {
.name = "d97d16af-028b-4cd1-a672-6210cb5513dd",
.attrs =  attrs_compute_extended,
 };
@@ -3032,7 +3032,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_compute_l3_cache = {
+static const struct attribute_group group_compute_l3_cache = {
.name = "9fb22842-e708-43f7-9752-e0e41670c39e",
.attrs =  attrs_compute_l3_cache,
 };
@@ -3054,7 +3054,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_hdc_and_sf = {
+static const struct attribute_group group_hdc_and_sf = {
.name = "5378e2a1-4248-4188-a4ae-da25a794c603",
.attrs =  attrs_hdc_and_sf,
 };
@@ -3076,7 +3076,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_1 = {
+static const struct attribute_group group_l3_1 = {
.name = "f42cdd6a-b000-42cb-870f-5eb423a7f514",
.attrs =  attrs_l3_1,
 };
@@ -3098,7 +3098,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_2 = {
+static const struct attribute_group group_l3_2 = {
.name = "b9bf2423-d88c-4a7b-a051-627611d00dcc",
.attrs =  attrs_l3_2,
 };
@@ -3120,7 +3120,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_l3_3 = {
+static const struct attribute_group group_l3_3 = {
.name = "2414a93d-d84f-406e-99c0-472161194b40",
.attrs =  attrs_l3_3,
 };
@@ -3142,7 +3142,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_rasterizer_and_pixel_backend = {
+static const struct attribute_group group_rasterizer_and_pixel_backend = {
.name = "53a45d2d-170b-4cf5-b7bb-585120c8e2f5",
.attrs =  attrs_rasterizer_and_pixel_backend,
 };
@@ -3164,7 +3164,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_sampler = {
+static const struct attribute_group group_sampler = {
.name = "b4cff514-a91e-4798-a0b3-426ca13fc9c1",
.attrs =  attrs_sampler,
 };
@@ -3186,7 +3186,7 @@ int i915_oa_select_metric_set_sklgt2(struct 
drm_i915_private *dev_priv)
NULL,
 };
 
-static struct attribute_group group_tdl_1 = {
+static const struct

[PATCH 00/11] constify i915 attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Arvind Yadav (11):
  [PATCH 01/11] drm: i915: i915_oa_kblgt2: constify attribute_group structures.
  [PATCH 02/11] drm: i915: i915_oa_bdw: constify attribute_group structures.
  [PATCH 03/11] drm: i915: i915_oa_bxt: constify attribute_group structures.
  [PATCH 04/11] drm: i915: i915_oa_chv: constify attribute_group structures.
  [PATCH 05/11] drm: i915: i915_oa_glk: constify attribute_group structures.
  [PATCH 06/11] drm: i915: i915_oa_hsw: constify attribute_group structures.
  [PATCH 07/11] drm: i915: i915_oa_kblgt3: constify attribute_group structures.
  [PATCH 08/11] drm: i915: i915_oa_sklgt2: constify attribute_group structures.
  [PATCH 09/11] drm: i915: i915_oa_sklgt3: constify attribute_group structures.
  [PATCH 10/11] drm: i915: i915_oa_sklgt4: constify attribute_group structures.
  [PATCH 11/11] drm: i915: i915_sysfs: constify attribute_group structures.

 drivers/gpu/drm/i915/i915_oa_bdw.c| 44 +--
 drivers/gpu/drm/i915/i915_oa_bxt.c| 30 
 drivers/gpu/drm/i915/i915_oa_chv.c| 28 +++---
 drivers/gpu/drm/i915/i915_oa_glk.c| 30 
 drivers/gpu/drm/i915/i915_oa_hsw.c| 12 +-
 drivers/gpu/drm/i915/i915_oa_kblgt2.c | 36 ++--
 drivers/gpu/drm/i915/i915_oa_kblgt3.c | 36 ++--
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 36 ++--
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 36 ++--
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 36 ++--
 drivers/gpu/drm/i915/i915_sysfs.c |  6 ++---
 11 files changed, 165 insertions(+), 165 deletions(-)

-- 
1.9.1

Re: [PATCH 4.12 00/31] 4.12.5-stable review

[Guenter Roeck]

On 08/03/2017 04:17 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 4.12.5 release.
There are 31 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sat Aug  5 23:17:23 UTC 2017.
Anything received after that time might be too late.



Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[PATCH] pinctrl: add __rcu annotations to fix sparse warnings

[Masahiro Yamada]

Sparse reports "warning: incorrect type in assignment (different
address spaces)".

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/core.c   | 2 +-
 drivers/pinctrl/pinmux.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 89b9ca77daea..60f82c67b92d 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -686,7 +686,7 @@ EXPORT_SYMBOL_GPL(pinctrl_generic_remove_group);
 static void pinctrl_generic_free_groups(struct pinctrl_dev *pctldev)
 {
struct radix_tree_iter iter;
-   void **slot;
+   void __rcu **slot;
 
radix_tree_for_each_slot(slot, &pctldev->pin_group_tree, &iter, 0)
radix_tree_delete(&pctldev->pin_group_tree, iter.index);
diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
index 36d5da9dc587..55502fc4479c 100644
--- a/drivers/pinctrl/pinmux.c
+++ b/drivers/pinctrl/pinmux.c
@@ -833,7 +833,7 @@ EXPORT_SYMBOL_GPL(pinmux_generic_remove_function);
 void pinmux_generic_free_functions(struct pinctrl_dev *pctldev)
 {
struct radix_tree_iter iter;
-   void **slot;
+   void __rcu **slot;
 
radix_tree_for_each_slot(slot, &pctldev->pin_function_tree, &iter, 0)
radix_tree_delete(&pctldev->pin_function_tree, iter.index);
-- 
2.7.4

[PATCH] pinctrl: nomadik: fix incorrect type in return expression

[Masahiro Yamada]

Sparse reports "warning: incorrect type in return expression (different
address spaces)" because nmk_gpio_populate_chip() is supposed to return
(struct nmk_gpio_chip *) whereas devm_ioremap_resource() returns
(void __iomem *).  ERR_CAST() is needed to fix the warning.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/nomadik/pinctrl-nomadik.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c 
b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index d318ca055489..a53f1a9b1ed2 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -1078,7 +1078,7 @@ static struct nmk_gpio_chip 
*nmk_gpio_populate_chip(struct device_node *np,
res = platform_get_resource(gpio_pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(base))
-   return base;
+   return ERR_CAST(base);
nmk_chip->addr = base;
 
clk = clk_get(&gpio_pdev->dev, NULL);
-- 
2.7.4

[PATCH] pinctrl: sirf: add static to local data

[Masahiro Yamada]

Detected by sparse.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/sirf/pinctrl-atlas7.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/sirf/pinctrl-atlas7.c 
b/drivers/pinctrl/sirf/pinctrl-atlas7.c
index 1efa315a7dbe..b3de1eb04ec1 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas7.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas7.c
@@ -549,7 +549,7 @@ static const struct pinctrl_pin_desc atlas7_ioc_pads[] = {
PINCTRL_PIN(163, "jtag_trstn"),
 };
 
-struct atlas7_pad_config atlas7_ioc_pad_confs[] = {
+static struct atlas7_pad_config atlas7_ioc_pad_confs[] = {
/* The Configuration of IOC_RTC Pads */
PADCONF(0, 3, 0x0, 0x100, 0x200, -1, 0, 0, 0, 0),
PADCONF(1, 3, 0x0, 0x100, 0x200, -1, 4, 2, 2, 0),
@@ -1002,7 +1002,7 @@ static const unsigned int vi_vip1_high8bit_pins[] = { 82, 
83, 84, 103, 104,
105, 106, 107, 102, 97, 98, };
 
 /* definition of pin group table */
-struct atlas7_pin_group altas7_pin_groups[] = {
+static struct atlas7_pin_group altas7_pin_groups[] = {
GROUP("gnss_gpio_grp", gnss_gpio_pins),
GROUP("lcd_vip_gpio_grp", lcd_vip_gpio_pins),
GROUP("sdio_i2s_gpio_grp", sdio_i2s_gpio_pins),
@@ -4764,7 +4764,7 @@ static struct atlas7_pmx_func atlas7_pmx_functions[] = {
&vi_vip1_high8bit_grp_mux),
 };
 
-struct atlas7_pinctrl_data atlas7_ioc_data = {
+static struct atlas7_pinctrl_data atlas7_ioc_data = {
.pads = (struct pinctrl_pin_desc *)atlas7_ioc_pads,
.pads_cnt = ARRAY_SIZE(atlas7_ioc_pads),
.grps = (struct atlas7_pin_group *)altas7_pin_groups,
-- 
2.7.4

[PATCH] pinctrl: armada-37xx: add static to local data

[Masahiro Yamada]

Detected by sparse.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c 
b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
index f024e25787fc..0b263b90a9a8 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c
@@ -179,14 +179,14 @@ static struct armada_37xx_pin_group 
armada_37xx_sb_groups[] = {
PIN_GRP("mii_col", 23, 1, BIT(8), "mii", "mii_err"),
 };
 
-const struct armada_37xx_pin_data armada_37xx_pin_nb = {
+static const struct armada_37xx_pin_data armada_37xx_pin_nb = {
.nr_pins = 36,
.name = "GPIO1",
.groups = armada_37xx_nb_groups,
.ngroups = ARRAY_SIZE(armada_37xx_nb_groups),
 };
 
-const struct armada_37xx_pin_data armada_37xx_pin_sb = {
+static const struct armada_37xx_pin_data armada_37xx_pin_sb = {
.nr_pins = 29,
.name = "GPIO2",
.groups = armada_37xx_sb_groups,
-- 
2.7.4

[PATCH net-next] net: dsa: User per-cpu 64-bit statistics

[Florian Fainelli]

During testing with a background iperf pushing 1Gbit/sec worth of
traffic and having both ifconfig and ethtool collect statistics, we
could see quite frequent deadlocks. Convert the often accessed DSA slave
network devices statistics to per-cpu 64-bit statistics to remove these
deadlocks and provide fast efficient statistics updates.

Signed-off-by: Florian Fainelli 
---
 net/dsa/dsa.c  | 10 +---
 net/dsa/dsa_priv.h |  2 +-
 net/dsa/slave.c| 72 +++---
 3 files changed, 59 insertions(+), 25 deletions(-)

diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 0ba842c08dd3..a91e520e735f 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -190,6 +190,7 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct 
net_device *dev,
 {
struct dsa_switch_tree *dst = dev->dsa_ptr;
struct sk_buff *nskb = NULL;
+   struct pcpu_sw_netstats *s;
struct dsa_slave_priv *p;
 
if (unlikely(dst == NULL)) {
@@ -213,10 +214,11 @@ static int dsa_switch_rcv(struct sk_buff *skb, struct 
net_device *dev,
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, skb->dev);
 
-   u64_stats_update_begin(&p->stats64.syncp);
-   p->stats64.rx_packets++;
-   p->stats64.rx_bytes += skb->len;
-   u64_stats_update_end(&p->stats64.syncp);
+   s = this_cpu_ptr(p->stats64);
+   u64_stats_update_begin(&s->syncp);
+   s->rx_packets++;
+   s->rx_bytes += skb->len;
+   u64_stats_update_end(&s->syncp);
 
netif_receive_skb(skb);
 
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 7aa0656296c2..306cff229def 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -77,7 +77,7 @@ struct dsa_slave_priv {
struct sk_buff *(*xmit)(struct sk_buff *skb,
struct net_device *dev);
 
-   struct pcpu_sw_netstats stats64;
+   struct pcpu_sw_netstats *stats64;
 
/* DSA port data, such as switch, port index, etc. */
struct dsa_port *dp;
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index e196562035b1..605444ced06c 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -352,12 +352,14 @@ static inline netdev_tx_t dsa_netpoll_send_skb(struct 
dsa_slave_priv *p,
 static netdev_tx_t dsa_slave_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
+   struct pcpu_sw_netstats *s;
struct sk_buff *nskb;
 
-   u64_stats_update_begin(&p->stats64.syncp);
-   p->stats64.tx_packets++;
-   p->stats64.tx_bytes += skb->len;
-   u64_stats_update_end(&p->stats64.syncp);
+   s = this_cpu_ptr(p->stats64);
+   u64_stats_update_begin(&s->syncp);
+   s->tx_packets++;
+   s->tx_bytes += skb->len;
+   u64_stats_update_end(&s->syncp);
 
/* Transmit function may have to reallocate the original SKB,
 * in which case it must have freed it. Only free it here on error.
@@ -596,15 +598,26 @@ static void dsa_slave_get_ethtool_stats(struct net_device 
*dev,
 {
struct dsa_slave_priv *p = netdev_priv(dev);
struct dsa_switch *ds = p->dp->ds;
+   struct pcpu_sw_netstats *s;
unsigned int start;
-
-   do {
-   start = u64_stats_fetch_begin_irq(&p->stats64.syncp);
-   data[0] = p->stats64.tx_packets;
-   data[1] = p->stats64.tx_bytes;
-   data[2] = p->stats64.rx_packets;
-   data[3] = p->stats64.rx_bytes;
-   } while (u64_stats_fetch_retry_irq(&p->stats64.syncp, start));
+   int i;
+
+   for_each_possible_cpu(i) {
+   u64 tx_packets, tx_bytes, rx_packets, rx_bytes;
+
+   s = per_cpu_ptr(p->stats64, i);
+   do {
+   start = u64_stats_fetch_begin_irq(&s->syncp);
+   tx_packets = s->tx_packets;
+   tx_bytes = s->tx_bytes;
+   rx_packets = s->rx_packets;
+   rx_bytes = s->rx_bytes;
+   } while (u64_stats_fetch_retry_irq(&s->syncp, start));
+   data[0] += tx_packets;
+   data[1] += tx_bytes;
+   data[2] += rx_packets;
+   data[3] += rx_bytes;
+   }
if (ds->ops->get_ethtool_stats)
ds->ops->get_ethtool_stats(ds, p->dp->index, data + 4);
 }
@@ -879,16 +892,28 @@ static void dsa_slave_get_stats64(struct net_device *dev,
  struct rtnl_link_stats64 *stats)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
+   struct pcpu_sw_netstats *s;
unsigned int start;
+   int i;
 
netdev_stats_to_stats64(stats, &dev->stats);
-   do {
-   start = u64_stats_fetch_begin_irq(&p->stats64.syncp);
-   stats->tx_packets = p->stats64.tx_packets;
-   stats->tx_bytes = p->stats64.tx_bytes;
-   stats->rx_packets = p->stats64.rx_packets;
- 

Re: [linux-sunxi] [PATCH 10/13] [NOT FOR REVIEW NOW] clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock

[Chen-Yu Tsai]

On Fri, Aug 4, 2017 at 12:16 PM, Icenowy Zheng  wrote:
>
>
> 于 2017年8月4日 GMT+08:00 下午12:15:27, Chen-Yu Tsai  写到:
>>Hi,
>>
>>On Tue, Aug 1, 2017 at 9:13 PM, Icenowy Zheng  wrote:
>>> From: Jernej Skrabec 
>>>
>>> When setting the HDMI clock of H3, the PLL_VIDEO clock needs to be
>>set.
>>>
>>> Add CLK_SET_RATE_PARENT flag for H3 HDMI clock.
>>>
>>> Signed-off-by: Jernej Skrabec 
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>>b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>>> index b1127e8629d9..2ebb3d865b01 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>>> @@ -474,7 +474,7 @@ static SUNXI_CCU_GATE(avs_clk,
>>"avs",  "osc24M",
>>>
>>>  static const char * const hdmi_parents[] = { "pll-video" };
>>>  static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
>>> -0x150, 0, 4, 24, 2, BIT(31), 0);
>>> +0x150, 0, 4, 24, 2, BIT(31),
>>CLK_SET_RATE_PARENT);
>>
>>Line is longer than 80 characters.
>>
>>This looks independent enough so I've merged this for 4.14 with the
>>offending line wrapped and the following tag added:
>>
>>Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
>
> Please don't merge this now until Jernej send it.

(Dropped Rob, devicetree and dri mailing lists)

Hi Jernej,

Is it OK if we take this patch for the next release? Or rather,
if there anything blocking this patch?

Thanks
ChenYu

>
>>
>>ChenYu
>>
>>>
>>>  static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
>>>   0x154, BIT(31), 0);
>>> --
>>> 2.13.0
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>Groups "linux-sunxi" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>send an email to linux-sunxi+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH] drm/panel: simple: Fix width and height for Olimex LCD-OLinuXino-4.3TS

[Chen-Yu Tsai]

On Thu, Jul 20, 2017 at 6:29 PM, Jonathan Liu  wrote:
> The physical size of the panel is 105.5 (W) x 67.2 (H) x 4.05 (D) mm
> but the active display area is 95.04 (W) x 53.856 (H) mm.
>
> The width and height should be set to the active display area.
>
> Signed-off-by: Jonathan Liu 

You probably want:

Fixes: cf5c9e6dc70d ("drm/panel: simple: Add timings for the Olimex
  LCD-OLinuXino-4.3TS")

Otherwise,

Reviewed-by: Chen-Yu Tsai 

against the panel datasheet linked from Olimex's product page.
This should probably go in through drm-misc?

[PATCH] devfreq: replace sscanf with kstrtol

[gsantosh]

Hi,

Adding error checks to devfreq userspace governor, the current 
implementation results in setting wrong

frequency when sscanf returns error.


From 12e0a347addd70529b2c378299b27b65f0766f99 Mon Sep 17 00:00:00 2001
From: Santosh Mardi 
Date: Tue, 25 Jul 2017 18:47:11 +0530
Subject: [PATCH] devfreq: replace sscanf with kstrtol

store_freq function of devfreq userspace governor
executes further, even if error is returned from sscanf,
this will result in setting up wrong frequency value.

The usage for the sscanf is only for single variable so
replace sscanf with kstrtol along with error check to
bail out if any error is returned.

Signed-off-by: Santosh Mardi 
---
 drivers/devfreq/governor_userspace.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/governor_userspace.c 
b/drivers/devfreq/governor_userspace.c

index 77028c2..a84796d 100644
--- a/drivers/devfreq/governor_userspace.c
+++ b/drivers/devfreq/governor_userspace.c
@@ -53,12 +53,15 @@ static ssize_t store_freq(struct device *dev, struct 
device_attribute *attr,

 mutex_lock(&devfreq->lock);
 data = devfreq->data;

-sscanf(buf, "%lu", &wanted);
+err = kstrtol(buf, 0, &wanted);
+if (err < 0)
+goto out;
 data->user_frequency = wanted;
 data->valid = true;
 err = update_devfreq(devfreq);
 if (err == 0)
 err = count;
+out:
 mutex_unlock(&devfreq->lock);
 return err;
 }
--

Regards,
Santosh M G.
Qualcomm Innovation Center

Re: [linux-sunxi] [PATCH 10/13] [NOT FOR REVIEW NOW] clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock

[Icenowy Zheng]

于 2017年8月4日 GMT+08:00 下午12:15:27, Chen-Yu Tsai  写到:
>Hi,
>
>On Tue, Aug 1, 2017 at 9:13 PM, Icenowy Zheng  wrote:
>> From: Jernej Skrabec 
>>
>> When setting the HDMI clock of H3, the PLL_VIDEO clock needs to be
>set.
>>
>> Add CLK_SET_RATE_PARENT flag for H3 HDMI clock.
>>
>> Signed-off-by: Jernej Skrabec 
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>> index b1127e8629d9..2ebb3d865b01 100644
>> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
>> @@ -474,7 +474,7 @@ static SUNXI_CCU_GATE(avs_clk, 
>"avs",  "osc24M",
>>
>>  static const char * const hdmi_parents[] = { "pll-video" };
>>  static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
>> -0x150, 0, 4, 24, 2, BIT(31), 0);
>> +0x150, 0, 4, 24, 2, BIT(31),
>CLK_SET_RATE_PARENT);
>
>Line is longer than 80 characters.
>
>This looks independent enough so I've merged this for 4.14 with the
>offending line wrapped and the following tag added:
>
>Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")

Please don't merge this now until Jernej send it.

>
>ChenYu
>
>>
>>  static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
>>   0x154, BIT(31), 0);
>> --
>> 2.13.0
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 10/13] [NOT FOR REVIEW NOW] clk: sunxi: Add CLK_SET_RATE_PARENT flag for H3 HDMI clock

[Chen-Yu Tsai]

Hi,

On Tue, Aug 1, 2017 at 9:13 PM, Icenowy Zheng  wrote:
> From: Jernej Skrabec 
>
> When setting the HDMI clock of H3, the PLL_VIDEO clock needs to be set.
>
> Add CLK_SET_RATE_PARENT flag for H3 HDMI clock.
>
> Signed-off-by: Jernej Skrabec 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> index b1127e8629d9..2ebb3d865b01 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> @@ -474,7 +474,7 @@ static SUNXI_CCU_GATE(avs_clk,  "avs",
>   "osc24M",
>
>  static const char * const hdmi_parents[] = { "pll-video" };
>  static SUNXI_CCU_M_WITH_MUX_GATE(hdmi_clk, "hdmi", hdmi_parents,
> -0x150, 0, 4, 24, 2, BIT(31), 0);
> +0x150, 0, 4, 24, 2, BIT(31), 
> CLK_SET_RATE_PARENT);

Line is longer than 80 characters.

This looks independent enough so I've merged this for 4.14 with the
offending line wrapped and the following tag added:

Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")

ChenYu

>
>  static SUNXI_CCU_GATE(hdmi_ddc_clk,"hdmi-ddc", "osc24M",
>   0x154, BIT(31), 0);
> --
> 2.13.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [PATCH 06/10] clk: sunxi-ng: allow set parent clock (PLL_CPUX) for CPUX clock on H3

[Chen-Yu Tsai]

On Mon, Jul 24, 2017 at 11:10 AM, Chen-Yu Tsai  wrote:
> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng  wrote:
>> The CPUX clock, which is the main clock of the ARM core on Allwinner H3,
>> can be adjusted by changing the frequency of the PLL_CPUX clock.
>>
>> Allowing setting parent clock for the CPUX clock, thus the PLL_CPUX
>> clock can be adjusted when adjusting the CPUX clock.
>>
>> Signed-off-by: Icenowy Zheng 
>
> Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")
> Reviewed-by: Chen-Yu Tsai 

Applied for 4.14 with the Fixes tag and Stephen's ack.

ChenYu

Re: [linux-sunxi] [PATCH 05/10] clk: sunxi-ng: h3: gate then ungate PLL CPU clk after rate change

[Chen-Yu Tsai]

On Wed, Jul 26, 2017 at 3:14 PM, Chen-Yu Tsai  wrote:
> On Sun, Jul 23, 2017 at 6:27 PM, Icenowy Zheng  wrote:
>> From: Chen-Yu Tsai 
>>
>> This patch utilizes the new PLL clk notifier to gate then ungate the
>> PLL CPU clock after rate changes. This should prevent any system hangs
>> resulting from cpufreq changes to the clk.
>>
>> Reported-by: Ondrej Jirman 
>> Signed-off-by: Chen-Yu Tsai 
>> Tested-by: Icenowy Zheng 
>
> This is missing
>
> Fixes: 0577e4853bfb ("clk: sunxi-ng: Add H3 clocks")

Applied for 4.14 with the Fixes tag and Stephen's ack.

Re: [PATCH v2 4/7] ghes_edac: avoid multiple calls to dmi_walk()

[Borislav Petkov]

On Thu, Aug 03, 2017 at 03:57:50PM -0600, Toshi Kani wrote:
> ghes_edac_register() is called for each GHES platform device
> instantiated per a GHES entry in ACPI HEST table.  dmi_walk()
> counts the number of DIMMs on the system, and there is no need
> to call it multiple times.
> 
> Change ghes_edac_register() to call dmi_walk() only when
> 'num_dimm' is uninitialized.
> 
> Signed-off-by: Toshi Kani 
> Suggested-by: Borislav Petkov 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> ---
>  drivers/edac/ghes_edac.c |9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/edac/ghes_edac.c b/drivers/edac/ghes_edac.c
> index 4e61a62..2e9ce9c 100644
> --- a/drivers/edac/ghes_edac.c
> +++ b/drivers/edac/ghes_edac.c
> @@ -407,15 +407,18 @@ EXPORT_SYMBOL_GPL(ghes_edac_report_mem_error);
>  
>  int ghes_edac_register(struct ghes *ghes, struct device *dev)
>  {
> - bool fake = false;
> - int rc, num_dimm = 0;
>   struct mem_ctl_info *mci;
>   struct edac_mc_layer layers[1];
>   struct ghes_edac_pvt *pvt;
>   struct ghes_edac_dimm_fill dimm_fill;
> + int rc;
> +
> + static int num_dimm;
> + static bool fake;
>  
>   /* Get the number of DIMMs */
> - dmi_walk(ghes_edac_count_dimms, &num_dimm);
> + if (num_dimm == 0)
> + dmi_walk(ghes_edac_count_dimms, &num_dimm);

So the problem is that ghes_edac_register() gets called multiple times
depending on how many GHES platform devices are on the system. But yet
they all scan *all* DIMMs. So instead you should return if the DIMMs
have been counted already and not register a second time.

Which makes that whole mc counting kinda useless. So you could rip that
out too.

Unless I'm missing something...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] f2fs: provide f2fs_balance_fs to __write_data_page for dentry pages

[Yunlong Song]

Chao has pointed out that, maybe writebacking dentry page can redirty 
dnode page
which may be clean previously, so it is more safe to call 
f2fs_balance_fs to make sure

dirty metadatas of filesystem will not exceed the threshold.

On 2017/8/4 11:34, Jaegeuk Kim wrote:

On 08/04, Yunlong Song wrote:

Since __write_data_page will not do f2fs_balance_fs for dir inode, so there
is no lock.
- f2fs_balance_fs
 - __write_data_page (dir inode)
  - f2fs_balance_fs again?<- Can not happen!
And if let sync_dirty_inodes flush dentry page of inodeB, then inodeB will
sikp the
f2fs_balance_fs check due to the same reason above (it is dir inode).

What I wanted to say was we cannot add f2fs_balance_fs() in my proposed approach
due to livelock.


Besides, does any lock will lock the kernel writeback process? If not, when
normal
writeback of inodeB just happens before sync_dirty_inodes fetch it from the
dirty_list,
the normal writeback of indoeB will skip the f2fs_balance_fs check.

Again, I'm asking why this normal writeback should call f2fs_balance_fs().
We must flush all the dirty dentry pages in inodeB to finalize checkpoint.
Who is able to make dirty dentry pages at this moment?


f2fs_trim(,sync)_fs normal dentry page writeback
of inodeB
   -- write_checkpoint --f2fs_write_data_pages
 --block_operations --f2fs_write_cache_pages
 --SBI_BLOCK_OPS is set --__write_data_page
 --sync_dirty_inodes --test SBI_BLOCK_OPS is set and skip
f2fs_balance_fs
 --retry: write to reserved segments
inodeA <- list_first_entry(dirty_list)
filemap_fdatawrite(inodeA)
go to retry
 --SBI_BLOCK_OPS is clear

On 2017/8/4 9:57, Jaegeuk Kim wrote:

On 08/02, Yunlong Song wrote:

Hi Jay,
  The case is like this:
write_checkpoint:   normal dentry
page writeback of inodeB：
  -block_operations -f2fs_write_data_pages
  -SBI_BLOCK_OPS is set -f2fs_write_cache_pages
  -sync_dirty_inodes   -__write_data_page
 -retry:-test SBI_BLOCK_OPS is set and skip
f2fs_balance_fs
  inodeA <- list_first_entry(dirty_list)
  filemap_fdatawrite(inodeA)
  goto retry
  -SBI_BLOCK_OPS is clear

write_checkpoint flow call sync_dirty_inodes to traversal the dirty inode
list and filemap_fdatawrite each inode,
during this period, if normal dentry_page writeback is processing inodeB,
and syc_dirty_inodes is processing
inodeA, then inodeB writeback flow will skip f2fs_balance_fs and may write
the dentry page to reserved segments.

If there are not enough sections, all the possible system calls were already
blocked by gc_mutex. So, it doesn't have to do f2fs_balance_fs(), and let
sync_dirty_inodes() flush dentry pages of inodeB.

Oh, does it make livelock?

- f2fs_balance_fs
   - f2fs_gc
 - write_checkpoint
   - sync_dirty_inodes
 - filemap_fdatawrite(inodeB)
   - __write_data_page
   - f2fs_balance_fs again?


On 2017/8/2 2:22, Jaegeuk Kim wrote:

On 08/01, Yunlong Song wrote:

Hi Jay,
   The SBI_BLOCK_OPS can not cover all the case, once SBI_BLOCK_OPS is set,
all the normal writeback
(before the SBI_BLOCK_OPS is clear) of dentry pages which do not come from
write_checkpoint flow will
totally miss all the f2fs_balance_fs check.

Why not? There must be no dirty dentry pages after sync_dirty_inodes() in that
period which we grabbed the globla lock.

Thanks,


On 2017/7/31 0:05, Yunlong Song wrote:

Hi Jay,
   Chao has pointed out one reason, besides, I have another reason: we
should take care of writeback for f2fs_balance_fs carefully, because if
some bugs cause reserved segments unlikely used, which means
f2fs_balance_fs does not work or is skipped in some corner case that we
have not noticed or found out yet, then the reserved segments may be
continually used and even used up in the writeback process of dentry
page,  since current  design believe in the f2fs_balance_fs in system
call and has no check in denty page writeback. To avoid this, we can put
a f2fs_balance_fs in the dentry page writeback process to give f2fs more
robust in free segments reserved. This is worth, because free segments
reserved are so important, if they are used up, f2fs will enter a
totally wrong status and make a wrong image.

On 07/30/2017 15:31, Jaegeuk Kim  wrote:

   On 07/29, Yunlong Song wrote:
   > f2fs_balance_fs of dentry pages is skipped in __write_data_page
   due to deadlock
   > of gc_mutex in write_checkpoint flow. This patch enables
   f2fs_balance_fs for
   > normal dentry page writeback to ensure there are always enough
   free segments.

   Sorry, by the way, why do we need to do this? I subtly thought
   that dirty node
   pages can be produce by redirti

[PATCH] pinctrl: uniphier: widen all pinconf-derived arguments to u32

[Masahiro Yamada]

Since commit 58957d2edfa1 ("pinctrl: Widen the generic pinconf argument
from 16 to 24 bits"), the generic pinconf arguments are handled by u32.

UniPhier pinctrl drivers do not support debouncing, so u16 is working,
but align the argument type to u32 for consistency.

Signed-off-by: Masahiro Yamada 
---

 drivers/pinctrl/uniphier/pinctrl-uniphier-core.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c 
b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
index 5d8c9efd8135..f9267fabe6b0 100644
--- a/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
+++ b/drivers/pinctrl/uniphier/pinctrl-uniphier-core.c
@@ -198,7 +198,7 @@ static int uniphier_conf_pin_bias_get(struct pinctrl_dev 
*pctldev,
 }
 
 static int uniphier_conf_pin_drive_get(struct pinctrl_dev *pctldev,
-  unsigned int pin, u16 *strength)
+  unsigned int pin, u32 *strength)
 {
struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
const struct pin_desc *desc = pin_desc_get(pctldev, pin);
@@ -289,7 +289,7 @@ static int uniphier_conf_pin_config_get(struct pinctrl_dev 
*pctldev,
 {
enum pin_config_param param = pinconf_to_config_param(*configs);
bool has_arg = false;
-   u16 arg;
+   u32 arg;
int ret;
 
switch (param) {
@@ -393,7 +393,7 @@ static int uniphier_conf_pin_bias_set(struct pinctrl_dev 
*pctldev,
 }
 
 static int uniphier_conf_pin_drive_set(struct pinctrl_dev *pctldev,
-  unsigned int pin, u16 strength)
+  unsigned int pin, u32 strength)
 {
struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
const struct pin_desc *desc = pin_desc_get(pctldev, pin);
@@ -454,7 +454,7 @@ static int uniphier_conf_pin_drive_set(struct pinctrl_dev 
*pctldev,
 }
 
 static int uniphier_conf_pin_input_enable(struct pinctrl_dev *pctldev,
- unsigned int pin, u16 enable)
+ unsigned int pin, u32 enable)
 {
struct uniphier_pinctrl_priv *priv = pinctrl_dev_get_drvdata(pctldev);
const struct pin_desc *desc = pin_desc_get(pctldev, pin);
-- 
2.7.4

Re: [linux-sunxi] [PATCH 03/13] drm: sun4i: add support for H3's TCON

[Chen-Yu Tsai]

On Tue, Aug 1, 2017 at 9:12 PM, Icenowy Zheng  wrote:
> From: Icenowy Zheng 
>
> Allwinner H3 has two special TCONs without channel 0.
>
> Add support for this kind of TCON.
>
> Signed-off-by: Icenowy Zheng 

Ideally you would split this into two patches. The first one would add
the quirks support for TCONs without channel 0. I can also use this for
the A80. The second would add the H3 TCON.

ChenYu

[PATCH] devfreq: replace sscanf with kstrtol

[gsantosh]

Hi,

Adding error checks to devfreq userspace governor, the current 
implementation results in setting wrong

frequency when sscanf returns error.


From 12e0a347addd70529b2c378299b27b65f0766f99 Mon Sep 17 00:00:00 2001
From: Santosh Mardi 
Date: Tue, 25 Jul 2017 18:47:11 +0530
Subject: [PATCH] devfreq: replace sscanf with kstrtol

store_freq function of devfreq userspace governor
executes further, even if error is returned from sscanf,
this will result in setting up wrong frequency value.

The usage for the sscanf is only for single variable so
replace sscanf with kstrtol along with error check to
bail out if any error is returned.

Signed-off-by: Santosh Mardi 
---
 drivers/devfreq/governor_userspace.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/governor_userspace.c 
b/drivers/devfreq/governor_userspace.c

index 77028c2..a84796d 100644
--- a/drivers/devfreq/governor_userspace.c
+++ b/drivers/devfreq/governor_userspace.c
@@ -53,12 +53,15 @@ static ssize_t store_freq(struct device *dev, struct 
device_attribute *attr,

mutex_lock(&devfreq->lock);
data = devfreq->data;

-   sscanf(buf, "%lu", &wanted);
+   err = kstrtol(buf, 0, &wanted);
+   if (err < 0)
+   goto out;
data->user_frequency = wanted;
data->valid = true;
err = update_devfreq(devfreq);
if (err == 0)
err = count;
+out:
mutex_unlock(&devfreq->lock);
return err;
 }
--

Regards,
Santosh M G.
Qualcomm Innovation Center

[PATCH v4 1/2] arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2

[sean.wang]

From: Sean Wang 

The bananapi-r2 board has an SD-card controller and built-in
EMMC storage so enables those devices in the devicetree. Also
cleanup nodes in alphabetical order in the patch.

Signed-off-by: Matthias Brugger 
Signed-off-by: Sean Wang 
---
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 37 +++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts 
b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 9f3e6dd..444ed93 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -179,6 +179,32 @@
status = "okay";
 };
 
+&mmc0 {
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <&mmc0_pins_default>;
+   pinctrl-1 = <&mmc0_pins_uhs>;
+   status = "okay";
+   bus-width = <8>;
+   max-frequency = <5000>;
+   cap-mmc-highspeed;
+   vmmc-supply = <&mt6323_vemc3v3_reg>;
+   vqmmc-supply = <&mt6323_vio18_reg>;
+   non-removable;
+};
+
+&mmc1 {
+   pinctrl-names = "default", "state_uhs";
+   pinctrl-0 = <&mmc1_pins_default>;
+   pinctrl-1 = <&mmc1_pins_uhs>;
+   status = "okay";
+   bus-width = <4>;
+   max-frequency = <5000>;
+   cap-sd-highspeed;
+   cd-gpios = <&pio 261 0>;
+   vmmc-supply = <&mt6323_vmch_reg>;
+   vqmmc-supply = <&mt6323_vio18_reg>;
+};
+
 &pio {
cir_pins_a:cir@0 {
pins_cir {
@@ -314,6 +340,17 @@
bias-pull-down;
drive-strength = ;
};
+
+   pins_wp {
+   pinmux = ;
+   input-enable;
+   bias-pull-up;
+   };
+
+   pins_insert {
+   pinmux = ;
+   bias-pull-up;
+   };
};
 
mmc1_pins_uhs: mmc1 {
-- 
2.7.4

Re: [PATCH 2/2] fsnotify: use method copy_dname copying filename

[林守磊]

Hi all

I sent this patch two months ago, then I found CVE from this link last night

http://seclists.org/oss-sec/2017/q3/240

which not only references this patch, but also provides a upstream fix


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49d31c2f389acfe83417083e1208422b4091cd9

I was wondering why @viro hadn't noticed this mail (And @viro fixed
this). I'm new here and nobody,
trying to do my best to help the this linux community. I was looking
forword to your reply, because some
insufficiency may exists in my work, I'd like to learn from you guys

Thanks and humble enough to wait your reply

在 2017年5月31日 上午11:54，石祤  写道：
> From: "leilei.lin" 
>
> Kernel got panicked in inotify_handle_event, while running the rename
> operation against the same file. The root cause is that the race between
> fsnotify thread and file rename thread.  When fsnotify thread was
> copying the dentry name, another rename thread could change the dentry
> name at same time. With slub_debug=FZ boot args, this bug will trigger
> a trace like the following:
>
> [   87.733653] 
> =
> [   87.735350] BUG kmalloc-64 (Not tainted): Redzone overwritten
> [   87.736550] 
> -
>
> [   87.738466] Disabling lock debugging due to kernel taint
> [   87.739556] INFO: 0x8e487a50b0f8-0x8e487a50b0fc. First byte 0x33 
> instead of 0xcc
> [   87.741188] INFO: Slab 0xf116c0e942c0 objects=46 used=43 
> fp=0x8e487a50bf80 flags=0x800101
> [   87.743133] INFO: Object 0x8e487a50b0b8 @offset=184 
> fp=0x8e487a50b0b8
>
> [   87.744942] Redzone 8e487a50b0b0: cc cc cc cc cc cc cc cc  
> 
> [   87.746743] Object 8e487a50b0b8: b8 b0 50 7a 48 8e ff ff b8 b0 50 7a 
> 48 8e ff ff  ..PzH.PzH...
> [   87.748621] Object 8e487a50b0c8: 60 75 7e 7b 48 8e ff ff 08 00 00 08 
> 00 00 00 00  `u~{H...
> [   87.750583] Object 8e487a50b0d8: 01 00 00 00 00 00 00 00 0d 00 00 00 
> 74 64 63 5f  tdc_
> [   87.752541] Object 8e487a50b0e8: 61 64 6d 69 6e 2e 4c 4f 47 2e 31 31 
> 32 33 31 32  admin.LOG.112312
> [   87.754431] Redzone 8e487a50b0f8: 33 31 32 33 00 cc cc cc  
> 3123
> [   87.756172] Padding 8e487a50b100: 00 00 00 00 00 00 00 00  
> 
> [   87.757988] CPU: 0 PID: 286 Comm: python Tainted: GB   
> 4.11.0-rc4+ #29
> [   87.759574] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
> [   87.761878] Call Trace:
> [   87.762381]  dump_stack+0x65/0x88
> [   87.763063]  print_trailer+0x15d/0x250
> [   87.763833]  check_bytes_and_report+0xcd/0x110
> [   87.764731]  check_object+0x1ce/0x290
> [   87.765472]  free_debug_processing+0x9c/0x2e3
> [   87.766362]  ? inotify_free_event+0xe/0x10
> [   87.767191]  __slab_free+0x1ba/0x2b0
> [   87.767922]  ? async_page_fault+0x28/0x30
> [   87.768731]  ? inotify_free_event+0xe/0x10
> [   87.769558]  kfree+0x165/0x1a0
> [   87.770184]  inotify_free_event+0xe/0x10
> [   87.770974]  fsnotify_destroy_event+0x51/0x70
> [   87.771851]  inotify_read+0x1dc/0x3a0
> [   87.772582]  ? do_wait_intr_irq+0xa0/0xa0
> [   87.773388]  __vfs_read+0x37/0x150
> [   87.774078]  ? security_file_permission+0x9d/0xc0
> [   87.775009]  vfs_read+0x8c/0x130
> [   87.775657]  SyS_read+0x55/0xc0
> [   87.776328]  entry_SYSCALL_64_fastpath+0x1e/0xad
> [   87.777280] RIP: 0033:0x7fcc1375b210
> [   87.778001] RSP: 002b:7ffe2f00b838 EFLAGS: 0246 ORIG_RAX: 
> 
> [   87.779513] RAX: ffda RBX: 7fcc1303d7b8 RCX: 
> 7fcc1375b210
> [   87.780932] RDX: 5c70 RSI: 013fe9f4 RDI: 
> 0004
> [   87.782337] RBP: 7fcc1303d760 R08: 0080 R09: 
> 5c95
> [   87.783780] R10: 0073 R11: 0246 R12: 
> 5c95
> [   87.785203] R13: 2708 R14: 5ca1 R15: 
> 7fcc1303d7b8
> [   87.786636] FIX kmalloc-64: Restoring 
> 0x8e487a50b0f8-0x8e487a50b0fc=0xcc
>
> [   87.789388] FIX kmalloc-64: Object at 0x8e487a50b0b8 not freed
>
> Graph below is the flow of inotify subsystem handling
> notify event. If a rename syscall happened simultaneously,
> for example filename of "foobar" is rename to
> "foobar_longername", which would access memory illegally.
>
> CPU 1   CPU 2
>
>  fsnotify()
>inotify_handle_event()
>  strlen(file_name) // file_name -> "foobar"
>
> rename happen
> file_name -> 
> "foobar_longername"
>
>  alloc_len += len + 1;
>  event = kmalloc(alloc_len, GFP_KERNEL);
>  strcpy(event->name, fil

[PATCH v4 2/2] arm: dts: mt7623: cleanup binding file

[sean.wang]

From: Ryder Lee 

Dummy patch to sort nodes alphabetically and add some blank lines
for consistency.

Signed-off-by: Ryder Lee 
---
 arch/arm/boot/dts/mt7623.dtsi | 73 ++-
 arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 57 -
 arch/arm/boot/dts/mt7623n-rfb-nand.dts| 64 +++
 arch/arm/boot/dts/mt7623n-rfb.dtsi| 32 ++--
 4 files changed, 120 insertions(+), 106 deletions(-)

diff --git a/arch/arm/boot/dts/mt7623.dtsi b/arch/arm/boot/dts/mt7623.dtsi
index 2a877ed..ec8a074 100644
--- a/arch/arm/boot/dts/mt7623.dtsi
+++ b/arch/arm/boot/dts/mt7623.dtsi
@@ -91,6 +91,7 @@
cooling-max-level = <7>;
clock-frequency = <13>;
};
+
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
@@ -98,6 +99,7 @@
operating-points-v2 = <&cpu_opp_table>;
clock-frequency = <13>;
};
+
cpu2: cpu@2 {
device_type = "cpu";
compatible = "arm,cortex-a7";
@@ -105,6 +107,7 @@
operating-points-v2 = <&cpu_opp_table>;
clock-frequency = <13>;
};
+
cpu3: cpu@3 {
device_type = "cpu";
compatible = "arm,cortex-a7";
@@ -172,10 +175,12 @@
trip = <&cpu_passive>;
cooling-device = <&cpu0 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
+
map1 {
trip = <&cpu_active>;
cooling-device = <&cpu0 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
};
+
map2 {
trip = <&cpu_hot>;
cooling-device = <&cpu0 
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
@@ -481,6 +486,31 @@
nvmem-cell-names = "calibration-data";
};
 
+   nandc: nfi@1100d000 {
+   compatible = "mediatek,mt7623-nfc",
+"mediatek,mt2701-nfc";
+   reg = <0 0x1100d000 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
+   clocks = <&pericfg CLK_PERI_NFI>,
+<&pericfg CLK_PERI_NFI_PAD>;
+   clock-names = "nfi_clk", "pad_clk";
+   status = "disabled";
+   ecc-engine = <&bch>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   bch: ecc@1100e000 {
+   compatible = "mediatek,mt7623-ecc",
+"mediatek,mt2701-ecc";
+   reg = <0 0x1100e000 0 0x1000>;
+   interrupts = ;
+   clocks = <&pericfg CLK_PERI_NFI_ECC>;
+   clock-names = "nfiecc_clk";
+   status = "disabled";
+   };
+
spi1: spi@11016000 {
compatible = "mediatek,mt7623-spi",
 "mediatek,mt2701-spi";
@@ -509,31 +539,6 @@
status = "disabled";
};
 
-   nandc: nfi@1100d000 {
-   compatible = "mediatek,mt7623-nfc",
-"mediatek,mt2701-nfc";
-   reg = <0 0x1100d000 0 0x1000>;
-   interrupts = ;
-   power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
-   clocks = <&pericfg CLK_PERI_NFI>,
-<&pericfg CLK_PERI_NFI_PAD>;
-   clock-names = "nfi_clk", "pad_clk";
-   status = "disabled";
-   ecc-engine = <&bch>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   };
-
-   bch: ecc@1100e000 {
-   compatible = "mediatek,mt7623-ecc",
-"mediatek,mt2701-ecc";
-   reg = <0 0x1100e000 0 0x1000>;
-   interrupts = ;
-   clocks = <&pericfg CLK_PERI_NFI_ECC>;
-   clock-names = "nfiecc_clk";
-   status = "disabled";
-   };
-
afe: audio-controller@1122 {
compatible = "mediatek,mt7623-audio",
 "mediatek,mt2701-audio";
@@ -655,6 +660,15 @@
status = "disabled";
};
 
+   hifsys: syscon@1a00 {
+   compatible = "mediatek,mt7623-hifsys",
+"mediatek,mt2701-hifsys",
+"syscon";
+   reg = <0 0x1a00 0 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
usb1: usb@1a1c {
compatible = "mediatek,mt7623-xhci",

Re: [PATCH 0/3] remove rw_page() from brd, pmem and btt

[Minchan Kim]

On Thu, Aug 03, 2017 at 03:13:35PM -0600, Ross Zwisler wrote:
> On Thu, Aug 03, 2017 at 09:13:15AM +0900, Minchan Kim wrote:
> > Hi Ross,
> > 
> > On Wed, Aug 02, 2017 at 04:13:59PM -0600, Ross Zwisler wrote:
> > > On Fri, Jul 28, 2017 at 10:31:43AM -0700, Matthew Wilcox wrote:
> > > > On Fri, Jul 28, 2017 at 10:56:01AM -0600, Ross Zwisler wrote:
> > > > > Dan Williams and Christoph Hellwig have recently expressed doubt about
> > > > > whether the rw_page() interface made sense for synchronous memory 
> > > > > drivers
> > > > > [1][2].  It's unclear whether this interface has any performance 
> > > > > benefit
> > > > > for these drivers, but as we continue to fix bugs it is clear that it 
> > > > > does
> > > > > have a maintenance burden.  This series removes the rw_page()
> > > > > implementations in brd, pmem and btt to relieve this burden.
> > > > 
> > > > Why don't you measure whether it has performance benefits?  I don't
> > > > understand why zram would see performance benefits and not other 
> > > > drivers.
> > > > If it's going to be removed, then the whole interface should be removed,
> > > > not just have the implementations removed from some drivers.
> > > 
> > > Okay, I've run a bunch of performance tests with the PMEM and with BTT 
> > > entry
> > > points for rw_pages() in a swap workload, and in all cases I do see an
> > > improvement over the code when rw_pages() is removed.  Here are the 
> > > results
> > > from my random lab box:
> > > 
> > >   Average latency of swap_writepage()
> > > +--++-+-+
> > > |  | no rw_page | rw_page | Improvement |
> > > +---+
> > > | PMEM |  5.0 us|  4.7 us | 6%  |
> > > +---+
> > > |  BTT |  6.8 us|  6.1 us |10%  |
> > > +--++-+-+
> > > 
> > >   Average latency of swap_readpage()
> > > +--++-+-+
> > > |  | no rw_page | rw_page | Improvement |
> > > +---+
> > > | PMEM |  3.3 us|  2.9 us |12%  |
> > > +---+
> > > |  BTT |  3.7 us|  3.4 us | 8%  |
> > > +--++-+-+
> > > 
> > > The workload was pmbench, a memory benchmark, run on a system where I had
> > > severely restricted the amount of memory in the system with the 'mem' 
> > > kernel
> > > command line parameter.  The benchmark was set up to test more memory 
> > > than I
> > > allowed the OS to have so it spilled over into swap.
> > > 
> > > The PMEM or BTT device was set up as my swap device, and during the test 
> > > I got
> > > a few hundred thousand samples of each of swap_writepage() and
> > > swap_writepage().  The PMEM/BTT device was just memory reserved with the
> > > memmap kernel command line parameter.
> > > 
> > > Thanks, Matthew, for asking for performance data.  It looks like removing 
> > > this
> > > code would have been a mistake.
> > 
> > By suggestion of Christoph Hellwig, I made a quick patch which does IO 
> > without
> > dynamic bio allocation for swap IO. Actually, it's not formal patch to be
> > worth to send mainline yet but I believe it's enough to test the 
> > improvement.
> > 
> > Could you test patchset on pmem and btt without rw_page?
> > 
> > For working the patch, block drivers need to declare it's synchronous IO
> > device via BDI_CAP_SYNC but if it's hard, you can just make every swap IO
> > comes from (sis->flags & SWP_SYNC_IO) with removing condition check
> > 
> > if (!(sis->flags & SWP_SYNC_IO)) in swap_[read|write]page.
> > 
> > Patchset is based on 4.13-rc3.
> 
> Thanks for the patch, here are the updated results from my test box:
> 
>  Average latency of swap_writepage()
> +--++-+-+
> |  | no rw_page | minchan | rw_page |
> +
> | PMEM |  5.0 us| 4.98 us |  4.7 us |
> +
> |  BTT |  6.8 us| 6.3 us  |  6.1 us |
> +--++-+-+
>  
>  Average latency of swap_readpage()
> +--++-+-+
> |  | no rw_page | minchan | rw_page |
> +
> | PMEM |  3.3 us| 3.27 us |  2.9 us |
> +
> |  BTT |  3.7 us| 3.44 us |  3.4 us |
> +--++-+-+
> 
> I've added another digit in precision in some cases to help differentiate the
> various results.
> 
> In all cases your patches did perform better than with the regularly allocated
> BIO, but again for all cases the rw_page() path was the fastest, even if only
> marginally.

Thanks for the testing. Your testing number is within noise level?

I cannot understand why PMEM doesn't have enough gain while BTT is significant
win(8%). I guess no rw_page with BTT test

RE: [PATCH V6 net-next 0/8] Hisilicon Network Subsystem 3 Ethernet Driver

[Salil Mehta]

Thanks a ton, Dave!

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Thursday, August 03, 2017 11:10 PM
> To: Salil Mehta
> Cc: Zhuangyuzeng (Yisen); huangdaode; lipeng (Y);
> mehta.salil@gmail.com; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-r...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH V6 net-next 0/8] Hisilicon Network Subsystem 3
> Ethernet Driver
> 
> From: Salil Mehta 
> Date: Wed, 2 Aug 2017 16:59:44 +0100
> 
> > This patch-set contains the support of the HNS3 (Hisilicon Network
> Subsystem 3)
> > Ethernet driver for hip08 family of SoCs and future upcoming SoCs.
>  ...
> 
> Series applied, thanks.

Re: [PATCH] iio: imu: adis16480: Fix acceleration scale factor for adis16480

[Lars-Peter Clausen]

On 08/04/2017 12:37 AM, Dragos Bogdan wrote:
> According to the datasheet, the range of the acceleration is [-10 g, + 10 g],
> so the scale factor should be 10 instead of 5.
> 
> Signed-off-by: Dragos Bogdan 

Acked-by: Lars-Peter Clausen 

Thanks.

> ---
>  drivers/iio/imu/adis16480.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/adis16480.c b/drivers/iio/imu/adis16480.c
> index 8cf84d3488b2..12898424d838 100644
> --- a/drivers/iio/imu/adis16480.c
> +++ b/drivers/iio/imu/adis16480.c
> @@ -696,7 +696,7 @@ static const struct adis16480_chip_info 
> adis16480_chip_info[] = {
>   .gyro_max_val = IIO_RAD_TO_DEGREE(22500),
>   .gyro_max_scale = 450,
>   .accel_max_val = IIO_M_S_2_TO_G(12500),
> - .accel_max_scale = 5,
> + .accel_max_scale = 10,
>   },
>   [ADIS16485] = {
>   .channels = adis16485_channels,
> 

Re: [linux-sunxi] [PATCH] pinctrl: sunxi: fix V3s pinctrl driver IRQ bank base

[icenowy]

在 2017-08-04 10:23，Chen-Yu Tsai 写道：

On Tue, Aug 1, 2017 at 10:54 PM, Icenowy Zheng  wrote:

The V3s pin controller doesn't have the bank 0 (starts at address
0x200), which is like A33. However, this is not workarounded when


   was not worked around

"Work around" is a verb phrase. "Workaround" is a noun.


developing the driver, which makes IRQ not working.


   broke the IRQs.



Fix the IRQ bank base.

Fixes: 56d9e4a76039 ("pinctrl: sunxi: add driver for V3s SoC")
Cc: sta...@vger.kernel.org
Signed-off-by: Icenowy Zheng 


Confirmed this is the same thing we saw on A33.
The fix is the same.

Apart from the typo / grammar errors above,

Reviewed-by: Chen-Yu Tsai 


Should I send a v2 now to fix the language errors?



___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 3/7] ACPI / APEI: add OSC APEI bit check for ghes_edac

[Borislav Petkov]

On Thu, Aug 03, 2017 at 03:57:49PM -0600, Toshi Kani wrote:
> When 'osc_sb_apei_support_acked' is set, it indicates that
> the platform supports APEI, firmware-first mode, as ACPI _OSC
> capability bit 4, APEI Support, was set in query.  While _OSC
> is an optional method, platforms with APEI support should
> implement it to inform its capability to the OS properly.
> 
> Add check to 'osc_sb_apei_support_acked' before calling
> ghes_edac_register() to restrict that ghes_edac is enabled
> on platforms with APEI support capability set in _OSC.
> 
> Signed-off-by: Toshi Kani 
> Cc: "Rafael J. Wysocki" 
> Cc: Borislav Petkov 
> Cc: Mauro Carvalho Chehab 
> Cc: Tony Luck 
> ---
>  drivers/acpi/apei/ghes.c |8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index d661d45..49d75eb 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -1139,9 +1139,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
>   goto err;
>   }
>  
> - rc = ghes_edac_register(ghes, &ghes_dev->dev);
> - if (rc < 0)
> - goto err;
> + if (osc_sb_apei_support_acked) {

What for when we have the whitelist?

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH] dt-bindings: mtd: add new compatible strings for mtk nor controller

[Guochun Mao]

On Thu, 2017-08-03 at 12:47 -0500, Rob Herring wrote:
> On Thu, Aug 03, 2017 at 10:16:42AM +0800, Guochun Mao wrote:
> > Hi Cyrille,
> > 
> > On Wed, 2017-08-02 at 17:31 +0200, Cyrille Pitchen wrote:
> > > Hi Guochun,
> > > 
> > > Le 02/08/2017 à 10:36, Boris Brezillon a écrit :
> > > > Hi Matthias,
> > > > 
> > > > On Tue, 1 Aug 2017 14:33:22 +0200
> > > > Matthias Brugger  wrote:
> > > > 
> > > >> On 07/25/2017 04:10 AM, Guochun Mao wrote:
> > > >>> Add "mediatek,mt2712-nor" and "mediatek,mt7622-nor"
> > > >>> for nor flash node's compatible strings.
> > > >>>
> > > >>> Reviewed-by: Matthias Brugger 
> > > >>> Signed-off-by: Guochun Mao 
> > > >>> ---
> > > >>>   .../devicetree/bindings/mtd/mtk-quadspi.txt|2 ++
> > > >>>   1 file changed, 2 insertions(+)
> > > >>>
> > > >>> diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt 
> > > >>> b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > > >>> index 5ded66a..9845ff4 100644
> > > >>> --- a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > > >>> +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> > > >>> @@ -3,6 +3,8 @@
> > > >>>   Required properties:
> > > >>>   - compatible: The possible values are:
> > > >>> "mediatek,mt2701-nor"
> > > >>> +   "mediatek,mt2712-nor"
> > > >>> +   "mediatek,mt7622-nor"
> > > >>> "mediatek,mt7623-nor"
> > > >>> "mediatek,mt8173-nor"
> > > >>> For mt8173, compatible should be 
> > > >>> "mediatek,mt8173-nor".
> > > >>>
> > > 
> > > There should be another patch to update the mtk_nor_of_ids[] array in
> > > the mtk-quadspi.c driver, shouldn't it?
> > > 
> > > Currently, I only see the "mediatek,mt8173-nor" compatible string at the
> > > driver side. The driver and its documentation should be aligned and both
> > > patches should be applied at the same time.
> > 
> > > Best regards,
> > > 
> > > Cyrille
> > 
> > 
> > From my designer's info, these IPs' nor controller could use same
> > driver, and I had verified it. I think there's no need to update
> > mtk_nor_of_ids[], unless we find difference between these IPs(exactly
> > compared with mt8173).
> > How do you think?
> 
> That is perfectly fine, but then the documentation needs to be explicit 
> as to what are the fallback compatibles. It's one valid combination per 
> line, not 1 compatible string per line.

OK, I'll corret the description in next version.
Thanks a lot.

Guochun


> 
> Rob
> 
> > 
> > And, we will add dts patches for new SOCs, are these patches should
> > applied with this documentation?
> > 
> > Best regards,
> > Guochun
> >