[PATCH AUTOSEL for 4.14 054/135] scsi: scsi_debug: write_same: fix error report

[alexander . levin]

From: Douglas Gilbert 

[ Upstream commit e33d7c56450b0a5c7290cbf9e1581fab5174f552 ]

The scsi_debug driver incorrectly suggests there is an error with the
SCSI WRITE SAME command when the number_of_logical_blocks is greater
than 1. It will also suggest there is an error when NDOB
(no data-out buffer) is set and the number_of_logical_blocks is
greater than 0. Both are valid, fix.

Signed-off-by: Douglas Gilbert 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/scsi_debug.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 09ba494f8896..92bc5b2d24ae 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -3001,11 +3001,11 @@ static int resp_write_same(struct scsi_cmnd *scp, u64 
lba, u32 num,
if (-1 == ret) {
write_unlock_irqrestore(_rw, iflags);
return DID_ERROR << 16;
-   } else if (sdebug_verbose && (ret < (num * sdebug_sector_size)))
+   } else if (sdebug_verbose && !ndob && (ret < sdebug_sector_size))
sdev_printk(KERN_INFO, scp->device,
-   "%s: %s: cdb indicated=%u, IO sent=%d bytes\n",
+   "%s: %s: lb size=%u, IO sent=%d bytes\n",
my_name, "write same",
-   num * sdebug_sector_size, ret);
+   sdebug_sector_size, ret);
 
/* Copy first sector to remaining blocks */
for (i = 1 ; i < num ; i++)
-- 
2.11.0

[PATCH AUTOSEL for 4.9 051/156] sched/deadline: Use deadline instead of period when calculating overflow

[alexander . levin]

From: "Steven Rostedt (VMware)" 

[ Upstream commit 2317d5f1c34913bac5971d93d69fb6c31bb74670 ]

I was testing Daniel's changes with his test case, and tweaked it a
little. Instead of having the runtime equal to the deadline, I
increased the deadline ten fold.

Daniel's test case had:

attr.sched_runtime  = 2 * 1000 * 1000;  /* 2 ms */
attr.sched_deadline = 2 * 1000 * 1000;  /* 2 ms */
attr.sched_period   = 2 * 1000 * 1000 * 1000;   /* 2 s */

To make it more interesting, I changed it to:

attr.sched_runtime  =  2 * 1000 * 1000; /* 2 ms */
attr.sched_deadline = 20 * 1000 * 1000; /* 20 ms */
attr.sched_period   =  2 * 1000 * 1000 * 1000;  /* 2 s */

The results were rather surprising. The behavior that Daniel's patch
was fixing came back. The task started using much more than .1% of the
CPU. More like 20%.

Looking into this I found that it was due to the dl_entity_overflow()
constantly returning true. That's because it uses the relative period
against relative runtime vs the absolute deadline against absolute
runtime.

  runtime / (deadline - t) > dl_runtime / dl_period

There's even a comment mentioning this, and saying that when relative
deadline equals relative period, that the equation is the same as using
deadline instead of period. That comment is backwards! What we really
want is:

  runtime / (deadline - t) > dl_runtime / dl_deadline

We care about if the runtime can make its deadline, not its period. And
then we can say "when the deadline equals the period, the equation is
the same as using dl_period instead of dl_deadline".

After correcting this, now when the task gets enqueued, it can throttle
correctly, and Daniel's fix to the throttling of sleeping deadline
tasks works even when the runtime and deadline are not the same.

Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Daniel Bristot de Oliveira 
Cc: Juri Lelli 
Cc: Linus Torvalds 
Cc: Luca Abeni 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Romulo Silva de Oliveira 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Tommaso Cucinotta 
Link: 
http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.1488392936.git.bris...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/sched/deadline.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index 6d594e22bbc8..df5c32a0c6ed 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -445,13 +445,13 @@ static void replenish_dl_entity(struct sched_dl_entity 
*dl_se,
  *
  * This function returns true if:
  *
- *   runtime / (deadline - t) > dl_runtime / dl_period ,
+ *   runtime / (deadline - t) > dl_runtime / dl_deadline ,
  *
  * IOW we can't recycle current parameters.
  *
- * Notice that the bandwidth check is done against the period. For
+ * Notice that the bandwidth check is done against the deadline. For
  * task with deadline equal to period this is the same of using
- * dl_deadline instead of dl_period in the equation above.
+ * dl_period instead of dl_deadline in the equation above.
  */
 static bool dl_entity_overflow(struct sched_dl_entity *dl_se,
   struct sched_dl_entity *pi_se, u64 t)
@@ -476,7 +476,7 @@ static bool dl_entity_overflow(struct sched_dl_entity 
*dl_se,
 * of anything below microseconds resolution is actually fiction
 * (but still we want to give the user that illusion >;).
 */
-   left = (pi_se->dl_period >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
+   left = (pi_se->dl_deadline >> DL_SCALE) * (dl_se->runtime >> DL_SCALE);
right = ((dl_se->deadline - t) >> DL_SCALE) *
(pi_se->dl_runtime >> DL_SCALE);
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 049/156] sched/deadline: Make sure the replenishment timer fires in the next period

[alexander . levin]

From: Daniel Bristot de Oliveira 

[ Upstream commit 5ac69d37784b237707a7b15d199cdb6c6fdb6780 ]

Currently, the replenishment timer is set to fire at the deadline
of a task. Although that works for implicit deadline tasks because the
deadline is equals to the begin of the next period, that is not correct
for constrained deadline tasks (deadline < period).

For instance:

f.c:
 --- %< ---
int main (void)
{
for(;;);
}
 --- >% ---

  # gcc -o f f.c

  # trace-cmd record -e sched:sched_switch  \
   -e syscalls:sys_exit_sched_setattr   \
   chrt -d --sched-runtime  49000   \
   --sched-deadline 5   \
   --sched-period  10 0 ./f

  # trace-cmd report | grep "{pid of ./f}"

After setting parameters, the task is replenished and continue running
until being throttled:

 f-11295 [003] 13322.113776: sys_exit_sched_setattr: 0x0

The task is throttled after running 492318 ms, as expected:

 f-11295 [003] 13322.606094: sched_switch:   f:11295 [-1] R ==> 
watchdog/3:32 [0]

But then, the task is replenished 500719 ms after the first
replenishment:

-0 [003] 13322.614495: sched_switch:   swapper/3:0 [120] R ==> 
f:11295 [-1]

Running for 490277 ms:

 f-11295 [003] 13323.104772: sched_switch:   f:11295 [-1] R ==>  
swapper/3:0 [120]

Hence, in the first period, the task runs 2 * runtime, and that is a bug.

During the first replenishment, the next deadline is set one period away.
So the runtime / period starts to be respected. However, as the second
replenishment took place in the wrong instant, the next replenishment
will also be held in a wrong instant of time. Rather than occurring in
the nth period away from the first activation, it is taking place
in the (nth period - relative deadline).

Signed-off-by: Daniel Bristot de Oliveira 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Luca Abeni 
Reviewed-by: Steven Rostedt (VMware) 
Reviewed-by: Juri Lelli 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Romulo Silva de Oliveira 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Cc: Tommaso Cucinotta 
Link: 
http://lkml.kernel.org/r/ac50d89887c25285b47465638354b63362f8adff.1488392936.git.bris...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
---
 kernel/sched/deadline.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index b0598b2bad88..0a42be57054e 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -505,10 +505,15 @@ static void update_dl_entity(struct sched_dl_entity 
*dl_se,
}
 }
 
+static inline u64 dl_next_period(struct sched_dl_entity *dl_se)
+{
+   return dl_se->deadline - dl_se->dl_deadline + dl_se->dl_period;
+}
+
 /*
  * If the entity depleted all its runtime, and if we want it to sleep
  * while waiting for some new execution time to become available, we
- * set the bandwidth enforcement timer to the replenishment instant
+ * set the bandwidth replenishment timer to the replenishment instant
  * and try to activate it.
  *
  * Notice that it is important for the caller to know if the timer
@@ -530,7 +535,7 @@ static int start_dl_timer(struct task_struct *p)
 * that it is actually coming from rq->clock and not from
 * hrtimer's time base reading.
 */
-   act = ns_to_ktime(dl_se->deadline);
+   act = ns_to_ktime(dl_next_period(dl_se));
now = hrtimer_cb_get_time(timer);
delta = ktime_to_ns(now) - rq_clock(rq);
act = ktime_add_ns(act, delta);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 031/156] net: Resend IGMP memberships upon peer notification.

[alexander . levin]

From: Vlad Yasevich 

[ Upstream commit 37c343b4f4e70e9dc328ab04903c0ec8d154c1a4 ]

When we notify peers of potential changes,  it's also good to update
IGMP memberships.  For example, during VM migration, updating IGMP
memberships will redirect existing multicast streams to the VM at the
new location.

Signed-off-by: Vladislav Yasevich 
Acked-by: Michael S. Tsirkin 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/core/dev.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/core/dev.c b/net/core/dev.c
index c37891828e4e..09007a71c8dd 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1304,6 +1304,7 @@ void netdev_notify_peers(struct net_device *dev)
 {
rtnl_lock();
call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+   call_netdevice_notifiers(NETDEV_RESEND_IGMP, dev);
rtnl_unlock();
 }
 EXPORT_SYMBOL(netdev_notify_peers);
-- 
2.11.0

[PATCH AUTOSEL for 4.9 055/156] afs: Populate group ID from vnode status

[alexander . levin]

From: Marc Dionne 

[ Upstream commit 6186f0788b31f44affceeedc7b48eb10faea120d ]

The group was hard coded to GLOBAL_ROOT_GID; use the group
ID that was received from the server.

Signed-off-by: Marc Dionne 
Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/afs/inode.c b/fs/afs/inode.c
index 86cc7264c21c..df9fa4ddcf3a 100644
--- a/fs/afs/inode.c
+++ b/fs/afs/inode.c
@@ -70,7 +70,7 @@ static int afs_inode_map_status(struct afs_vnode *vnode, 
struct key *key)
 
set_nlink(inode, vnode->status.nlink);
inode->i_uid= vnode->status.owner;
-   inode->i_gid= GLOBAL_ROOT_GID;
+   inode->i_gid= vnode->status.group;
inode->i_size   = vnode->status.size;
inode->i_ctime.tv_sec   = vnode->status.mtime_server;
inode->i_ctime.tv_nsec  = 0;
-- 
2.11.0

[PATCH AUTOSEL for 4.9 035/156] qed: Fix mapping leak on LL2 rx flow

[alexander . levin]

From: "Mintz, Yuval" 

[ Upstream commit 752ecb2da11124a948567076b60767dc8034cfa5 ]

When receiving an Rx LL2 packet, qed fails to unmap the previous buffer.

Fixes: 0a7fb11c23c0 ("qed: Add Light L2 support");
Signed-off-by: Yuval Mintz 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/qlogic/qed/qed_ll2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_ll2.c 
b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
index 62ae55bd81b8..7f00c7b065cb 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.c
@@ -187,6 +187,8 @@ static void qed_ll2b_complete_rx_packet(struct qed_hwfn 
*p_hwfn,
/* If need to reuse or there's no replacement buffer, repost this */
if (rc)
goto out_post;
+   dma_unmap_single(>pdev->dev, buffer->phys_addr,
+cdev->ll2->rx_size, DMA_FROM_DEVICE);
 
skb = build_skb(buffer->data, 0);
if (!skb) {
-- 
2.11.0

[PATCH AUTOSEL for 4.4 024/101] scsi: hpsa: update check for logical volume status

[alexander . levin]

From: Don Brace 

[ Upstream commit 85b29008d8af6d94a0723aaa8d93cfb6e041158b ]

 - Add in a new case for volume offline. Resolves internal testing bug
   for multilun array management.
 - Return correct status for failed TURs.

Reviewed-by: Scott Benesh 
Reviewed-by: Scott Teel 
Signed-off-by: Don Brace 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/hpsa.c | 35 ---
 drivers/scsi/hpsa_cmd.h |  2 ++
 2 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index e9ce74afd13f..09f0de8fb2d9 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3466,7 +3466,7 @@ exit_failed:
  *  # (integer code indicating one of several NOT READY states
  * describing why a volume is to be kept offline)
  */
-static int hpsa_volume_offline(struct ctlr_info *h,
+static unsigned char hpsa_volume_offline(struct ctlr_info *h,
unsigned char scsi3addr[])
 {
struct CommandList *c;
@@ -3486,7 +3486,7 @@ static int hpsa_volume_offline(struct ctlr_info *h,
rc = hpsa_scsi_do_simple_cmd(h, c, DEFAULT_REPLY_QUEUE, NO_TIMEOUT);
if (rc) {
cmd_free(h, c);
-   return 0;
+   return HPSA_VPD_LV_STATUS_UNSUPPORTED;
}
sense = c->err_info->SenseInfo;
if (c->err_info->SenseLen > sizeof(c->err_info->SenseInfo))
@@ -3497,19 +3497,13 @@ static int hpsa_volume_offline(struct ctlr_info *h,
cmd_status = c->err_info->CommandStatus;
scsi_status = c->err_info->ScsiStatus;
cmd_free(h, c);
-   /* Is the volume 'not ready'? */
-   if (cmd_status != CMD_TARGET_STATUS ||
-   scsi_status != SAM_STAT_CHECK_CONDITION ||
-   sense_key != NOT_READY ||
-   asc != ASC_LUN_NOT_READY)  {
-   return 0;
-   }
 
/* Determine the reason for not ready state */
ldstat = hpsa_get_volume_status(h, scsi3addr);
 
/* Keep volume offline in certain cases: */
switch (ldstat) {
+   case HPSA_LV_FAILED:
case HPSA_LV_UNDERGOING_ERASE:
case HPSA_LV_NOT_AVAILABLE:
case HPSA_LV_UNDERGOING_RPI:
@@ -3531,7 +3525,7 @@ static int hpsa_volume_offline(struct ctlr_info *h,
default:
break;
}
-   return 0;
+   return HPSA_LV_OK;
 }
 
 /*
@@ -3615,10 +3609,10 @@ static int hpsa_update_device_info(struct ctlr_info *h,
/* Do an inquiry to the device to see what it is. */
if (hpsa_scsi_do_inquiry(h, scsi3addr, 0, inq_buff,
(unsigned char) OBDR_TAPE_INQ_SIZE) != 0) {
-   /* Inquiry failed (msg printed already) */
dev_err(>pdev->dev,
-   "hpsa_update_device_info: inquiry failed\n");
-   rc = -EIO;
+   "%s: inquiry failed, device will be skipped.\n",
+   __func__);
+   rc = HPSA_INQUIRY_FAILED;
goto bail_out;
}
 
@@ -3638,15 +3632,19 @@ static int hpsa_update_device_info(struct ctlr_info *h,
 
if (this_device->devtype == TYPE_DISK &&
is_logical_dev_addr_mode(scsi3addr)) {
-   int volume_offline;
+   unsigned char volume_offline;
 
hpsa_get_raid_level(h, scsi3addr, _device->raid_level);
if (h->fw_support & MISC_FW_RAID_OFFLOAD_BASIC)
hpsa_get_ioaccel_status(h, scsi3addr, this_device);
volume_offline = hpsa_volume_offline(h, scsi3addr);
-   if (volume_offline < 0 || volume_offline > 0xff)
-   volume_offline = HPSA_VPD_LV_STATUS_UNSUPPORTED;
-   this_device->volume_offline = volume_offline & 0xff;
+   if (volume_offline == HPSA_LV_FAILED) {
+   rc = HPSA_LV_FAILED;
+   dev_err(>pdev->dev,
+   "%s: LV failed, device will be skipped.\n",
+   __func__);
+   goto bail_out;
+   }
} else {
this_device->raid_level = RAID_UNKNOWN;
this_device->offload_config = 0;
@@ -4115,8 +4113,7 @@ static void hpsa_update_scsi_devices(struct ctlr_info *h)
goto out;
}
if (rc) {
-   dev_warn(>pdev->dev,
-   "Inquiry failed, skipping device.\n");
+   h->drv_req_rescan = 1;
continue;
}
 
diff --git a/drivers/scsi/hpsa_cmd.h b/drivers/scsi/hpsa_cmd.h
index d92ef0d352b5..26488e2a7f02 100644
--- a/drivers/scsi/hpsa_cmd.h
+++ b/drivers/scsi/hpsa_cmd.h
@@ -155,6 +155,7 @@
 #define 

[PATCH AUTOSEL for 4.9 153/156] RDMA/cma: Avoid triggering undefined behavior

[alexander . levin]

From: Bart Van Assche 

[ Upstream commit c0b64f58e8d49570aa9ee55d880f92c20ff0166b ]

According to the C standard the behavior of computations with
integer operands is as follows:
* A computation involving unsigned operands can never overflow,
  because a result that cannot be represented by the resulting
  unsigned integer type is reduced modulo the number that is one
  greater than the largest value that can be represented by the
  resulting type.
* The behavior for signed integer underflow and overflow is
  undefined.

Hence only use unsigned integers when checking for integer
overflow.

This patch is what I came up with after having analyzed the
following smatch warnings:

drivers/infiniband/core/cma.c:3448: cma_resolve_ib_udp() warn: signed overflow 
undefined. 'offset + conn_param->private_data_len < 
conn_param->private_data_len'
drivers/infiniband/core/cma.c:3505: cma_connect_ib() warn: signed overflow 
undefined. 'offset + conn_param->private_data_len < 
conn_param->private_data_len'

Signed-off-by: Bart Van Assche 
Acked-by: Sean Hefty 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
---
 drivers/infiniband/core/cma.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 809a02800102..a09d6eed3b88 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -1482,7 +1482,7 @@ static struct rdma_id_private *cma_id_from_event(struct 
ib_cm_id *cm_id,
return id_priv;
 }
 
-static inline int cma_user_data_offset(struct rdma_id_private *id_priv)
+static inline u8 cma_user_data_offset(struct rdma_id_private *id_priv)
 {
return cma_family(id_priv) == AF_IB ? 0 : sizeof(struct cma_hdr);
 }
@@ -1877,7 +1877,8 @@ static int cma_req_handler(struct ib_cm_id *cm_id, struct 
ib_cm_event *ib_event)
struct rdma_id_private *listen_id, *conn_id = NULL;
struct rdma_cm_event event;
struct net_device *net_dev;
-   int offset, ret;
+   u8 offset;
+   int ret;
 
listen_id = cma_id_from_event(cm_id, ib_event, _dev);
if (IS_ERR(listen_id))
@@ -3309,7 +3310,8 @@ static int cma_resolve_ib_udp(struct rdma_id_private 
*id_priv,
struct ib_cm_sidr_req_param req;
struct ib_cm_id *id;
void *private_data;
-   int offset, ret;
+   u8 offset;
+   int ret;
 
memset(, 0, sizeof req);
offset = cma_user_data_offset(id_priv);
@@ -3366,7 +3368,8 @@ static int cma_connect_ib(struct rdma_id_private *id_priv,
struct rdma_route *route;
void *private_data;
struct ib_cm_id *id;
-   int offset, ret;
+   u8 offset;
+   int ret;
 
memset(, 0, sizeof req);
offset = cma_user_data_offset(id_priv);
-- 
2.11.0

Re: [PATCH v3 2/6] cpufreq: schedutil: ensure max frequency while running RT/DL tasks

[Patrick Bellasi]

On 07-Dec 10:35, Viresh Kumar wrote:
> On 30-11-17, 11:47, Patrick Bellasi wrote:
> > diff --git a/kernel/sched/cpufreq_schedutil.c 
> > b/kernel/sched/cpufreq_schedutil.c
> > index 67339ccb5595..448f49de5335 100644
> > --- a/kernel/sched/cpufreq_schedutil.c
> > +++ b/kernel/sched/cpufreq_schedutil.c
> > @@ -262,6 +262,7 @@ static void sugov_update_single(struct update_util_data 
> > *hook, u64 time,
> > struct cpufreq_policy *policy = sg_policy->policy;
> > unsigned long util, max;
> > unsigned int next_f;
> > +   bool rt_mode;
> > bool busy;
> >  
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > @@ -272,7 +273,15 @@ static void sugov_update_single(struct 
> > update_util_data *hook, u64 time,
> >  
> > busy = sugov_cpu_is_busy(sg_cpu);
> >  
> > -   if (flags & SCHED_CPUFREQ_RT_DL) {
> > +   /*
> > +* While RT/DL tasks are running we do not want FAIR tasks to
> > +* overvrite this CPU's flags, still we can update utilization and
> > +* frequency (if required/possible) to be fair with these tasks.
> > +*/
> > +   rt_mode = task_has_dl_policy(current) ||
> > + task_has_rt_policy(current) ||
> > + (flags & SCHED_CPUFREQ_RT_DL);
> > +   if (rt_mode) {
> > next_f = policy->cpuinfo.max_freq;
> > } else {
> > sugov_get_util(, , sg_cpu->cpu);
> > @@ -340,6 +349,7 @@ static void sugov_update_shared(struct update_util_data 
> > *hook, u64 time,
> > struct sugov_policy *sg_policy = sg_cpu->sg_policy;
> > unsigned long util, max;
> > unsigned int next_f;
> > +   bool rt_mode;
> >  
> > sugov_get_util(, , sg_cpu->cpu);
> >  
> > @@ -353,17 +363,27 @@ static void sugov_update_shared(struct 
> > update_util_data *hook, u64 time,
> > sg_cpu->flags = 0;
> > goto done;
> > }
> > -   sg_cpu->flags = flags;
> > +
> > +   /*
> > +* While RT/DL tasks are running we do not want FAIR tasks to
> > +* overwrite this CPU's flags, still we can update utilization and
> > +* frequency (if required/possible) to be fair with these tasks.
> > +*/
> > +   rt_mode = task_has_dl_policy(current) ||
> > + task_has_rt_policy(current) ||
> > + (flags & SCHED_CPUFREQ_RT_DL);
> > +   if (rt_mode)
> > +   sg_cpu->flags |= flags;
> > +   else
> > +   sg_cpu->flags = flags;
> >  
> > sugov_set_iowait_boost(sg_cpu, time, flags);
> > sg_cpu->last_update = time;
> >  
> > if (sugov_should_update_freq(sg_policy, time)) {
> > -   if (flags & SCHED_CPUFREQ_RT_DL)
> > -   next_f = sg_policy->policy->cpuinfo.max_freq;
> > -   else
> > -   next_f = sugov_next_freq_shared(sg_cpu, time);
> > -
> > +   next_f = rt_mode
> > +   ? sg_policy->policy->cpuinfo.max_freq
> > +   : sugov_next_freq_shared(sg_cpu, time);
> > sugov_update_commit(sg_policy, time, next_f);
> > }
> 
> Same here. There are pending comments from V2 which no one objected to
> and I was looking to see those modifications here.

So, your proposal here was actually to add additional flags to clear
the RT and DL ones.

My past comment was instead that we never had a "clear bit" semantics
for flags updates. However, it seems that the most common optinion was
that we should try to add such flags.

Thus, I think I have to refresh this patch by adding in the new flags
as you proposed and give it a try.

-- 
#include 

Patrick Bellasi

Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Philippe CORNU]

Hi Brian,


On 12/06/2017 10:52 PM, Brian Norris wrote:
> Hi Nickey, others,
> 
> I just want to highlight a thing or two here. Otherwise, my
> 'Reviewed-by' still basically stands (FWIW).
> 
> On Wed, Dec 06, 2017 at 05:08:21PM +0800, Nickey Yang wrote:
>> Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
>> MIPI DSI host controller bridge.
>>
>> Signed-off-by: Nickey Yang 
>> Signed-off-by: Brian Norris 
>> Reviewed-by: Brian Norris 
>> Reviewed-by: Sean Paul 
>> ---
>> change:
>>
>> v2:
>> add err_pllref, remove unnecessary encoder.enable & disable
>> correct spelling mistakes
>> v3:
>> call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
>> fix typo, use of_device_get_match_data(),
>> change some ‘bind()’ logic into 'probe()'
>> add 'dev_set_drvdata()'
>> v4:
>>return -EINVAL when can not get best_freq
>>add a clarifying comment when get vco
>>add review tag
>> v5:
>>keep our power domain enabled while touching GRF
>> v6:
>>change func dw_mipi_encoder_disable name to
>>dw_mipi_dsi_encoder_disable
> 
> We noticed a regression w.r.t. pm_runtime_*() handling using this patch,
> hence the pm_runtime changes in v5/v6. We actually need to keep our
> power domain enabled in the mode_set() function, where we start to
> configure some Rockchip-specific registers (GRF). More on that below.
> 
>>
>>   drivers/gpu/drm/rockchip/Kconfig|2 +-
>>   drivers/gpu/drm/rockchip/Makefile   |2 +-
>>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1349 
>> ---
>>   drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c |  785 +
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c |2 +-
>>   drivers/gpu/drm/rockchip/rockchip_drm_drv.h |2 +-
>>   6 files changed, 789 insertions(+), 1353 deletions(-)
>>   delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
>>   create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>>
> 
> ...
> 
>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c 
>> b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>> new file mode 100644
>> index 000..66ab6fe
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi_rockchip.c
>> @@ -0,0 +1,785 @@
> 
> ...
> 
>> +static void dw_mipi_dsi_encoder_mode_set(struct drm_encoder *encoder,
>> + struct drm_display_mode *mode,
>> + struct drm_display_mode *adjusted)
>> +{
>> +struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
>> +const struct rockchip_dw_dsi_chip_data *cdata = dsi->cdata;
>> +int val, ret, mux;
>> +
>> +mux = drm_of_encoder_active_endpoint_id(dsi->dev->of_node,
>> +>encoder);
>> +if (mux < 0)
>> +return;
>> +/*
>> + * For the RK3399, the clk of grf must be enabled before writing grf
>> + * register. And for RK3288 or other soc, this grf_clk must be NULL,
>> + * the clk_prepare_enable return true directly.
>> + */
>> +ret = clk_prepare_enable(dsi->grf_clk);
>> +if (ret) {
>> +DRM_DEV_ERROR(dsi->dev, "Failed to enable grf_clk: %d\n", ret);
>> +return;
>> +}
>> +pm_runtime_get_sync(dsi->dev);
> 
> What happens if there's a clk_prepare_enable() failure or failure to
> retrieve the endpoint ID earlier in this function? You won't call
> pm_runtime_get_*()...but might we still see a call to
> dw_mipi_dsi_encoder_disable(), which would mean we get unbalanced
> runtime PM status?
> 
> Also (and more importantly), is it fair to do all of this in mode_set()?
> I believe Archit asked about this before, and the reason we're doing
> this stuff in mode_set() now (where previously, the Rockchip driver was
> doing it in ->enable()) is because when Philippe extracted the synopsys
> bridge driver, that code migrated to ->mode_set().

Regarding mode_set(), let's me explain more what I did:
- transform the original code from Rockchip (encoder + connector drm 
api) to a generic bridge (bridge drm api).
- add panel-bridge interface
- ... (more details in the change log 
https://www.spinics.net/lists/dri-devel/msg147167.html)

So we have:
crtc -> dw mipi dsi bridge -> panel-bridge "bridge next" -> panel

The bridge pre_enable() calls first the "bridge next" pre_enable() (ie 
the panel-bridge pre-enable) before calling the bridge pre_enable (ie 
the dw mipi dsi bridge pre-enable (not used here). see in 
drm_bridge_pre_enable() in drm_bridge.c for details

The panel-bridge pre_enable() calls drm_panel_prepare(). See in 
bridge/panel.c for details.

So in the dw mipi dsi bridge, we need to configure and start 
"everything" before the bridge pre_enable so I put the "former" encoder 
enable() source code into the new bridge mode_set().

Tell me if I am not clear enough as it is not so 

[PATCH net-next v2 0/8] phy: net: meson-gxl: clean-up and improvements

[Jerome Brunet]

The patchset is a v2 of the previous single clean-up patch [0] which was
part of larger series. I initially to send these patches separately but
adding helper function without using them did not make much sense after
all. So, here is the complete patchset.

This patchset add defines for the control registers and helpers to access
the banked registers. The goal being to make it easier to understand what
the driver actually does.

Then there is fix for the incorrect sampling of the MII LPA register which
is often breaking the auto-negotiation with this PHY. More details on this
in the related patch

CONFIG_A6 settings is removed since this statement was without effect

Finally interrupt support is added, speeding things up a little

This series has been tested on the libretech-cc and khadas VIM

Jerome Brunet (8):
  net: phy: meson-gxl: check phy_write return value
  net: phy: meson-gxl: define control registers
  net: phy: meson-gxl: add read and write helpers for bank registers
  net: phy: meson-gxl: use genphy_config_init
  net: phy: meson-gxl: detect LPA corruption
  net: phy: meson-gxl: leave CONFIG_A6 untouched
  net: phy: meson-gxl: add interrupt support
  net: phy: meson-gxl: join the authors

 drivers/net/phy/meson-gxl.c | 215 
 1 file changed, 197 insertions(+), 18 deletions(-)

-- 
2.14.3

Re: [PATCH 1/3] ath9k: remove stray backslash in Makefile

[Kalle Valo]

Jakub Kicinski  writes:

> On Mon, 27 Nov 2017 18:56:21 +0100, Matthias Schiffer wrote:
>> Signed-off-by: Matthias Schiffer 
>> ---
>>  drivers/net/wireless/ath/ath9k/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/net/wireless/ath/ath9k/Makefile 
>> b/drivers/net/wireless/ath/ath9k/Makefile
>> index 36a40ffdce15..90e4a341076c 100644
>> --- a/drivers/net/wireless/ath/ath9k/Makefile
>> +++ b/drivers/net/wireless/ath/ath9k/Makefile
>> @@ -59,7 +59,7 @@ obj-$(CONFIG_ATH9K_HW) += ath9k_hw.o
>>  obj-$(CONFIG_ATH9K_COMMON) += ath9k_common.o
>>  ath9k_common-y:=common.o \
>>  common-init.o \
>> -common-beacon.o \
>> +common-beacon.o
>>  
>
> It's not necessarily stray, there is nothing on the next line so it's
> OK, and if you add \ at the end of all lines, you don't have to touch
> the last line every time you add/remove something.  Sort of like
> putting a , after last enum value.

I agree with Jakub, I think the backslash is there on purpose so I
dropped this patch.

-- 
Kalle Valo

Re: [RFC PATCH 1/6] drm: Add Content Protection property

[Alan Cox]

> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace. 

So let me take my Intel hat off for a moment.

The upstream policy has always been that we don't merge things which
don't have an open usable user space. Is the HDCP encryption feature
useful on its own ? What do users get from it ?

If this is just an enabler for a lump of binary stuff in ChromeOS then I
don't think it belongs, if it is useful standalone then it seems it does
belong ?

Alan

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

[Tetsuo Handa]

On 2017/12/07 17:34, Michal Hocko wrote:
> On Wed 06-12-17 11:20:26, Suren Baghdasaryan wrote:
>> Slab shrinkers can be quite time consuming and when signal
>> is pending they can delay handling of the signal. If fatal
>> signal is pending there is no point in shrinking that process
>> since it will be killed anyway. This change checks for pending
>> fatal signals inside shrink_slab loop and if one is detected
>> terminates this loop early.
> 
> This is not enough. You would have to make sure the direct reclaim will
> bail out immeditally which is not at all that simple. We do check fatal
> signals in throttle_direct_reclaim and conditionally in shrink_inactive_list
> so even if you bail out from shrinkers we could still finish the full
> reclaim cycle.
> 
> Besides that shrinkers shouldn't really take very long so this looks
> like it papers over a real bug somewhere else. I am not saying the patch
> is wrong but it would deserve much more details to judge wether this is
> the right way to go for your particular problem.
> 

I wish that normal threads do not invoke direct reclaim operation.
Only dedicated kernel threads (such as filesystem's writeback) invoke
direct reclaim operation. Then, we can implement __GFP_KILLABLE for
normal threads, and hopefully get rid of distinction between GFP_NOIO/
GFP_NOFS/GFP_KERNEL because reclaim (and locking) dependency becomes
simpler.

Re: [PATCH] integrity: get rid of unneeded initializations in integrity_iint_cache entries

[Mimi Zohar]

On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote:
> On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > > Quoting Jeff Layton (jlay...@kernel.org):
> > > > From: Jeff Layton 
> > > > 
> > > > The init_once routine memsets the whole object to 0, and then
> > > > explicitly sets some of the fields to 0 again. Just remove the explicit
> > > > initializations.
> > > > 
> > > > Signed-off-by: Jeff Layton 
> > > 
> > > Reviewed-by: Serge Hallyn 
> > 
> > Thanks, queued.
> > 
> > Mimi
> > 
> 
> Hi Mimi,
> 
> I notice that this patch hasn't made the last couple of releases. Was it
> dropped for some reason?

Thanks for the reminder.  I accidentally dropped it (and Sascha
Hauer's patch).  The subject line is too long.  Assuming you don't
object, I'll replace the "get rid of" with "removed" and queue the
patch in the next-queued-testing branch.

Mimi

[PATCH v5 0/2] at24: support eeproms that do not auto-rollover reads.

[Sven Van Asbroeck]

v5:
at Rob Herring's request, renamed devicetree property:
at24,no-read-rollover -> no-read-rollover

v4:
renamed devicetree property:
no-read-rollover -> at24,no-read-rollover
dt-bindings update now a separate patch

v3:
rebased against at24 maintainer's devel staging branch:
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux.git at24/devel
clarified some of the comments and wording

v2:
kbuild test robot feedback: correct
"warning: comparison of distinct pointer types lacks a cast"
build warning on some compilers / architectures.

v1:
original patch

Sven Van Asbroeck (2):
  at24: support eeproms that do not auto-rollover reads.
  dt-bindings: add eeprom "at24,no-read-rollover" property

 .../devicetree/bindings/eeprom/eeprom.txt  |  5 +++
 drivers/misc/eeprom/at24.c | 37 +++---
 include/linux/platform_data/at24.h |  2 ++
 3 files changed, 32 insertions(+), 12 deletions(-)

-- 
1.9.1

[PATCH v5 2/2] dt-bindings: add eeprom "no-read-rollover" property

[Sven Van Asbroeck]

Adds an optional property for at24 eeproms.
This parameterless property indicates that the multi-address eeprom
does not automatically roll over reads to the next slave address.

Signed-off-by: Sven Van Asbroeck 
---
 Documentation/devicetree/bindings/eeprom/eeprom.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 27f2bc1..5bfc0ac 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -38,6 +38,11 @@ Optional properties:
 
   - size: total eeprom size in bytes
 
+  - no-read-rollover:
+   This parameterless property indicates that the 
multi-address
+   eeprom does not automatically roll over reads to the 
next
+   slave address. Please consult the manual of your device.
+
 Example:
 
 eeprom@52 {
-- 
1.9.1

Re: [PATCH v3] serial: 8250: convert to threaded IRQ

[Alan Cox]

On Mon,  4 Dec 2017 17:26:27 +0200
Denys Zagorui  wrote:

> During using virtualization it is common to see
> many "too much work for irq*" messages.

Your emulator is buggy.

NAK

You are adding a ton of overhead to an absolutely performance critical
path on real hardware. We absolutely cannot have 16450 or 16550A UARTS
being serviced via a threaded IRQ.

Fix your emulator. You are getting the problem because your serial port
emulation isn't doing timing correct queueing of characters. If you are
modelling 115,200 baud then don't queue characters faster than that or
batch them excessively. We went to 512 as the pass limit to allow
virtualization layers to get this right more easily as you don't have to
do timing on tiny batches.

(And if you need performance of any kind stop using the uart emulation
and use virtio)

Alan

Re: [PATCH v2] ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 builds

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 11:04 PM, Tony Lindgren  wrote:
> * Arnd Bergmann  [171206 21:52]:
>> In configurations without CONFIG_OMAP3 but with secure RAM support,
>> we now run into a link failure:
>>
>> arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
>> omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'
>>
>> The omap3_save_secure_ram() function is only called from the OMAP34xx
>> power management code, so we can simply hide that function in the
>> appropriate #ifdef.
>>
>> Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for 
>> save_secure_ram_context")
>> Signed-off-by: Arnd Bergmann 
>> ---
>> v2: also check for CONFIG_PM
>
> Acked-by: Tony Lindgren 

Applied now

   Arnd

Re: [PATCH V6 4/7] OF: properties: Implement get_match_data() callback

[Sinan Kaya]

On 12/7/2017 8:10 AM, Lothar Waßmann wrote:
>> +void *of_fwnode_get_match_data(const struct fwnode_handle *fwnode,
>> +   struct device *dev)
> Shouldn't this be 'const void *of_fwnode_get_match_data

OF keeps the driver data as a (const void*) internally. ACPI keeps the
driver data as kernel_ulong_t in struct acpi_device_id.

I tried to find the middle ground here by converting output to void*
but not keeping const.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH net-next v4 1/4] phylib: Add device reset delay support

[Richard Leitner]

From: Richard Leitner 

Some PHYs need a minimum time after the reset gpio was asserted and/or
deasserted. To ensure we meet these timing requirements add two new
optional devicetree parameters for the phy: reset-delay-us and
reset-post-delay-us.

Signed-off-by: Richard Leitner 
Reviewed-by: Geert Uytterhoeven 
---
 Documentation/devicetree/bindings/net/phy.txt | 10 ++
 drivers/net/phy/mdio_device.c | 13 +++--
 drivers/of/of_mdio.c  |  4 
 include/linux/mdio.h  |  2 ++
 4 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/phy.txt 
b/Documentation/devicetree/bindings/net/phy.txt
index c05479f5ac7c..72860ce7f610 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -55,6 +55,12 @@ Optional Properties:
 
 - reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
 
+- reset-delay-us: Delay after the reset was asserted in microseconds.
+  If this property is missing the delay will be skipped.
+
+- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
+  If this property is missing the delay will be skipped.
+
 Example:
 
 ethernet-phy@0 {
@@ -62,4 +68,8 @@ ethernet-phy@0 {
interrupt-parent = <>;
interrupts = <35 IRQ_TYPE_EDGE_RISING>;
reg = <0>;
+
+   reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+   reset-delay-us = <1000>;
+   reset-post-delay-us = <2000>;
 };
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index 75d97dd9fb28..0423280c88fe 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void mdio_device_free(struct mdio_device *mdiodev)
 {
@@ -118,8 +119,16 @@ EXPORT_SYMBOL(mdio_device_remove);
 
 void mdio_device_reset(struct mdio_device *mdiodev, int value)
 {
-   if (mdiodev->reset)
-   gpiod_set_value(mdiodev->reset, value);
+   unsigned int d;
+
+   if (!mdiodev->reset)
+   return;
+
+   gpiod_set_value(mdiodev->reset, value);
+
+   d = value ? mdiodev->reset_delay : mdiodev->reset_post_delay;
+   if (d)
+   usleep_range(d, d + min_t(unsigned int, d / 10, 100));
 }
 EXPORT_SYMBOL(mdio_device_reset);
 
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index 98258583abb0..7c8767176315 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -77,6 +77,10 @@ static int of_mdiobus_register_phy(struct mii_bus *mdio,
if (of_property_read_bool(child, "broken-turn-around"))
mdio->phy_ignore_ta_mask |= 1 << addr;
 
+   of_property_read_u32(child, "reset-delay-us", >mdio.reset_delay);
+   of_property_read_u32(child, "reset-post-delay-us",
+>mdio.reset_post_delay);
+
/* Associate the OF node with the device structure so it
 * can be looked up later */
of_node_get(child);
diff --git a/include/linux/mdio.h b/include/linux/mdio.h
index 92d4e55ffe67..e37c21d8eb19 100644
--- a/include/linux/mdio.h
+++ b/include/linux/mdio.h
@@ -41,6 +41,8 @@ struct mdio_device {
int addr;
int flags;
struct gpio_desc *reset;
+   unsigned int reset_delay;
+   unsigned int reset_post_delay;
 };
 #define to_mdio_device(d) container_of(d, struct mdio_device, dev)
 
-- 
2.11.0

Re: [PATCH] watchdog: core: make sure the watchdog_worker always works

[Guenter Roeck]

On 12/07/2017 02:38 AM, Christophe Leroy wrote:

When running a command like 'chrt -f 99 dd if=/dev/zero of=/dev/null',
the watchdog_worker fails to service the HW watchdog and the
HW watchdog fires long before the watchdog soft timeout.

At the moment, the watchdog_worker is invoked as a delayed work.
Delayed works are handled by non realtime kernel threads. The
WQ_HIGHPRI flag only increases the niceness of that threads.

This patchs replaces the delayed work logic by hrtimer, in order to


s/patchs/patch/


ensure that the watchdog_worker will already have priority.


always ?



Signed-off-by: Christophe Leroy 
---
  drivers/watchdog/watchdog_dev.c | 87 +++--
  1 file changed, 41 insertions(+), 46 deletions(-)

diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 1e971a50d7fb..e9b234c4ff67 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -36,7 +36,7 @@
  #include /* For the -ENODEV/... values */
  #include/* For file operations */
  #include  /* For __init/__exit/... */
-#include/* For timeout functions */
+#include 
  #include/* For printk/panic/... */
  #include  /* For data references */
  #include/* For handling misc devices */
@@ -46,7 +46,6 @@
  #include  /* For memory functions */
  #include /* For standard types (like size_t) */
  #include  /* For watchdog specific items */
-#include  /* For workqueue */
  #include   /* For copy_to_user/put_user/... */
  
  #include "watchdog_core.h"

@@ -65,9 +64,9 @@ struct watchdog_core_data {
struct cdev cdev;
struct watchdog_device *wdd;
struct mutex lock;
-   unsigned long last_keepalive;
-   unsigned long last_hw_keepalive;
-   struct delayed_work work;
+   ktime_t last_keepalive;
+   ktime_t last_hw_keepalive;
+   struct hrtimer timer;
unsigned long status;   /* Internal status bits */
  #define _WDOG_DEV_OPEN0   /* Opened ? */
  #define _WDOG_ALLOW_RELEASE   1   /* Did we receive the magic char ? */
@@ -79,8 +78,6 @@ static dev_t watchdog_devt;
  /* Reference to watchdog device behind /dev/watchdog */
  static struct watchdog_core_data *old_wd_data;
  
-static struct workqueue_struct *watchdog_wq;

-
  static bool handle_boot_enabled =
IS_ENABLED(CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED);
  
@@ -107,18 +104,19 @@ static inline bool watchdog_need_worker(struct watchdog_device *wdd)

(t && !watchdog_active(wdd) && watchdog_hw_running(wdd));
  }
  
-static long watchdog_next_keepalive(struct watchdog_device *wdd)

+static ktime_t watchdog_next_keepalive(struct watchdog_device *wdd)
  {
struct watchdog_core_data *wd_data = wdd->wd_data;
unsigned int timeout_ms = wdd->timeout * 1000;
-   unsigned long keepalive_interval;
-   unsigned long last_heartbeat;
-   unsigned long virt_timeout;
+   ktime_t keepalive_interval;
+   ktime_t last_heartbeat, latest_heartbeat;
+   ktime_t virt_timeout;
unsigned int hw_heartbeat_ms;
  
-	virt_timeout = wd_data->last_keepalive + msecs_to_jiffies(timeout_ms);

+   virt_timeout = ktime_add(wd_data->last_keepalive,
+ms_to_ktime(timeout_ms));
hw_heartbeat_ms = min_not_zero(timeout_ms, wdd->max_hw_heartbeat_ms);
-   keepalive_interval = msecs_to_jiffies(hw_heartbeat_ms / 2);
+   keepalive_interval = ms_to_ktime(hw_heartbeat_ms / 2);
  
  	if (!watchdog_active(wdd))

return keepalive_interval;
@@ -128,8 +126,11 @@ static long watchdog_next_keepalive(struct watchdog_device 
*wdd)
 * after the most recent ping from userspace, the last
 * worker ping has to come in hw_heartbeat_ms before this timeout.
 */
-   last_heartbeat = virt_timeout - msecs_to_jiffies(hw_heartbeat_ms);
-   return min_t(long, last_heartbeat - jiffies, keepalive_interval);
+   last_heartbeat = ktime_sub(virt_timeout, ms_to_ktime(hw_heartbeat_ms));
+   latest_heartbeat = ktime_sub(last_heartbeat, ktime_get());
+   if (ktime_before(latest_heartbeat, keepalive_interval))
+   return latest_heartbeat;
+   return keepalive_interval;
  }
  
  static inline void watchdog_update_worker(struct watchdog_device *wdd)

@@ -137,29 +138,33 @@ static inline void watchdog_update_worker(struct 
watchdog_device *wdd)
struct watchdog_core_data *wd_data = wdd->wd_data;
  
  	if (watchdog_need_worker(wdd)) {

-   long t = watchdog_next_keepalive(wdd);
+   ktime_t t = watchdog_next_keepalive(wdd);
  
  		if (t > 0)

-   mod_delayed_work(watchdog_wq, _data->work, t);
+   hrtimer_start(_data->timer, t, HRTIMER_MODE_REL);
} else {
-   cancel_delayed_work(_data->work);
+   

Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support

[Bjorn Helgaas]

On Wed, Dec 06, 2017 at 01:55:37AM +, Chen, Kenji wrote:
> https://pcisig.com/sites/default/files/specification_documents/ECN_L1_PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf

With all due respect, this doesn't seem to add any new information.
For example, the L1 PM Substates Control 1 register description from
the above is basically identical to the published PCIe r3.1, sec
7.33.3.

So it doesn't answer the questions of:

  1) Why coreboot sets the L1.2 threshold to a fixed value, and

  2) How "(1 << 21) | (1 << 23) | (1 << 30)" relates to the Control 1
 register

> Pls also check My Intel Doc# 545845 for the bits fields description.

I don't have access to this document.  The Linux code I'm proposing is
based on the PCIe spec and is intended to work on all hardware that
conforms to that spec.  I'm not very familiar with coreboot, but maybe
the L1 Substates code there is only intended to work on certain Intel
chipsets and doesn't need to work on other hardware?

Bjorn

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org] 
> Sent: Wednesday, December 6, 2017 3:41 AM
> To: linux-...@vger.kernel.org
> Cc: Chen, Kenji ; Thierry Reding ; 
> Manikanta Maddireddy ; David Daney 
> ; Krishna Kishore ; 
> linux-kernel@vger.kernel.org; Vidya Sagar ; Julia Lawall 
> ; linux-te...@vger.kernel.org; Patrick Georgi 
> ; Rajat Jain ; Yinghai Lu 
> ; Stefan Reinauer ; Duncan 
> Laurie 
> Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support
> 
> On Sat, Dec 02, 2017 at 03:45:38PM -0600, Bjorn Helgaas wrote:
> > The PCIe active link power state is L0.  ASPM defines two low-power
> > states: L0s and L1.  The L1 PM Substates feature defines two 
> > additional low-power states: L1.1 and L2.2.
> > 
> > The L1.2 state may have substantial entry/exit latency.  Downstream 
> > devices can use the Latency Tolerance Reporting (LTR) feature to 
> > report how much latency they can tolerate.  The L1 PM Substates 
> > capability includes a programmable L1.2 threshold register.  If the 
> > downstream devices can tolerate the latency indicated by the 
> > threshold, L1.2 may be used.
> > 
> > If LTR is not enabled, the L1.2 threshold is ignored and L1.2 can be 
> > used whenever it is enabled and CLKREQ# is de-asserted.  Linux 
> > currently never enables LTR, but firmware may have done so.
> > 
> > The current L1 PM substates support in Linux sets the L1.2 threshold 
> > to a fixed value (163.84us) copied from coreboot [1].  I don't know 
> > where that value came from, and it is incorrect for some platforms, 
> > e.g., Tegra [2].
> > 
> > These patches change that so we calculate the L1.2 threshold based on 
> > values reported by the hardware, and we enable LTR whenever possible.
> > 
> > This is all just my understanding from reading the spec.  I'd be glad 
> > to be corrected if I'm going wrong.
> > 
> > I'm particularly puzzled about the coreboot code in
> > pciexp_L1_substate_commit() that sets LTR_L1.2_THRESHOLD:
> > 
> > +   pcie_update_cfg(root, root_cap + 0x08, ~0xe3ff,
> > +   (1 << 21) | (1 << 23) | (1 << 30));
> > 
> > This is writing the L1 PM Substates Control 1 register, but the shifts 
> > don't match up with any of the fields in the register, so this is an 
> > awfully funny way to write the threshold.
> > 
> > [1] 
> > https://mail.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134.
> > html [2] 
> > https://lkml.kernel.org/r/1510492674-12786-1-git-send-email-vidyas@nvi
> > dia.com
> > 
> > ---
> > 
> > Bjorn Helgaas (2):
> >   PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics
> >   PCI/ASPM: Enable Latency Tolerance Reporting when supported
> > 
> > 
> >  drivers/pci/pcie/aspm.c |   71 
> > +++
> >  drivers/pci/probe.c |   33 ++
> >  include/linux/pci.h |2 +
> >  3 files changed, 82 insertions(+), 24 deletions(-)
> 
> I applied these with Vidya's Reviewed-by to pci/aspm for v4.16.
> 
> I'd still really like to hear from the coreboot folks about the rationale for 
> the current coreboot code.  You folks are in a much better position to 
> actually understand the hardware details.
> 
> Bjorn

Re: [PATCH 1/6] staging: pi433: Split rf69_set_crc_enabled into two functions

[Simon Sandström]

On Thu, Dec 07, 2017 at 03:38:57PM +0100, Greg KH wrote:
> On Wed, Dec 06, 2017 at 09:42:19PM +0100, Simon Sandström wrote:
> > Splits rf69_set_crc_enabled(dev, enabled) into
> > rf69_enable_crc(dev) and rf69_disable_crc(dev).
> > 
> > Signed-off-by: Simon Sandström 
> > ---
> >  drivers/staging/pi433/pi433_if.c | 22 --
> >  drivers/staging/pi433/rf69.c | 18 ++
> >  drivers/staging/pi433/rf69.h |  4 ++--
> >  3 files changed, 28 insertions(+), 16 deletions(-)
> 
> This series did not apply at all.
> 
> What tree and branch did you make it against?
> 
> Please redo it against my staging.git tree, the staging-next branch
> should be fine, or the staging-testing will work as well.
> 
> thanks,
> 
> greg k-h

Hmm. Haven't you already applied these?

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=39252a4bcf63d9dbc168b9ef56eb4ca42e045b9d

>patch "staging: pi433: Split rf69_set_crc_enabled into two functions" added to 
>staging-testing
>
>This is a note to let you know that I've just added the patch titled
>
>staging: pi433: Split rf69_set_crc_enabled into two functions
>
> ...


Regards,
Simon

Re: PI futexes + lock stealing woes

[Gratian Crisan]

Peter Zijlstra writes:
> The below compiles and boots, but is otherwise untested. Could you give
> it a spin?

Thank you! Yes, I'll start a test now.

-Gratian

> ---
>  kernel/futex.c  | 83 
> +
>  kernel/locking/rtmutex.c| 26 +
>  kernel/locking/rtmutex_common.h |  1 +
>  3 files changed, 87 insertions(+), 23 deletions(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 76ed5921117a..29ac5b64e7c7 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -2294,21 +2294,17 @@ static void unqueue_me_pi(struct futex_q *q)
>   spin_unlock(q->lock_ptr);
>  }
>  
> -/*
> - * Fixup the pi_state owner with the new owner.
> - *
> - * Must be called with hash bucket lock held and mm->sem held for non
> - * private futexes.
> - */
>  static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
> - struct task_struct *newowner)
> + struct task_struct *argowner)
>  {
> - u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
>   struct futex_pi_state *pi_state = q->pi_state;
>   u32 uval, uninitialized_var(curval), newval;
> - struct task_struct *oldowner;
> + struct task_struct *oldowner, *newowner;
> + u32 newtid;
>   int ret;
>  
> + lockdep_assert_held(q->lock_ptr);
> +
>   raw_spin_lock_irq(_state->pi_mutex.wait_lock);
>  
>   oldowner = pi_state->owner;
> @@ -2317,11 +2313,17 @@ static int fixup_pi_state_owner(u32 __user *uaddr, 
> struct futex_q *q,
>   newtid |= FUTEX_OWNER_DIED;
>  
>   /*
> -  * We are here either because we stole the rtmutex from the
> -  * previous highest priority waiter or we are the highest priority
> -  * waiter but have failed to get the rtmutex the first time.
> +  * We are here because either:
> +  *
> +  *  - we stole the lock and pi_state->owner needs updating to reflect
> +  *that (@argowner == current),
>*
> -  * We have to replace the newowner TID in the user space variable.
> +  * or:
> +  *
> +  *  - someone stole our lock and we need to fix things to point to the
> +  *new owner (@argowner == NULL).
> +  *
> +  * Either way, we have to replace the TID in the user space variable.
>* This must be atomic as we have to preserve the owner died bit here.
>*
>* Note: We write the user space value _before_ changing the pi_state
> @@ -2334,6 +2336,42 @@ static int fixup_pi_state_owner(u32 __user *uaddr, 
> struct futex_q *q,
>* in the PID check in lookup_pi_state.
>*/
>  retry:
> + if (!argowner) {
> + if (oldowner != current) {
> + /*
> +  * We raced against a concurrent self; things are
> +  * already fixed up. Nothing to do.
> +  */
> + ret = 0;
> + goto out_unlock;
> + }
> +
> + if (__rt_mutex_futex_trylock(_state->pi_mutex)) {
> + /* We got the lock after all, nothing to fix. */
> + ret = 0;
> + goto out_unlock;
> + }
> +
> + /*
> +  * Since we just failed the trylock; there must be an owner.
> +  */
> + newowner = rt_mutex_owner(_state->pi_mutex);
> + BUG_ON(!newowner);
> + } else {
> + WARN_ON_ONCE(argowner != current);
> + if (oldowner == current) {
> + /*
> +  * We raced against a concurrent self; things are
> +  * already fixed up. Nothing to do.
> +  */
> + ret = 0;
> + goto out_unlock;
> + }
> + newowner = argowner;
> + }
> +
> + newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
> +
>   if (get_futex_value_locked(, uaddr))
>   goto handle_fault;
>  
> @@ -2434,15 +2472,28 @@ static int fixup_owner(u32 __user *uaddr, struct 
> futex_q *q, int locked)
>* Got the lock. We might not be the anticipated owner if we
>* did a lock-steal - fix up the PI-state in that case:
>*
> -  * We can safely read pi_state->owner without holding wait_lock
> -  * because we now own the rt_mutex, only the owner will attempt
> -  * to change it.
> +  * Speculative pi_state->owner read (we don't hold wait_lock);
> +  * since we own the lock pi_state->owner == current is the
> +  * stable state, anything else needs more attention.
>*/
>   if (q->pi_state->owner != current)
>   ret = fixup_pi_state_owner(uaddr, q, current);
>   goto out;
>   }
>  
> + /*
> +  * If we didn't get the lock; check if anybody stole it from 

Re: [PATCH] kthread: finer-grained lockdep/cross-release completion

[Daniel Vetter]

On Thu, Dec 07, 2017 at 01:22:56PM +0100, Peter Zijlstra wrote:
> On Thu, Dec 07, 2017 at 11:08:49AM +0100, Daniel Vetter wrote:
> > Since -rc1 we're hitting a bunch of lockdep splats using the new
> > cross-release stuff around the 2 kthread completions. In all cases
> > they are because totally independent uses of kthread are mixed up by
> > lockdep into the same locking class, creating artificial deadlocks.
> > 
> > Fix this by converting kthread code in the same way as e.g.
> > alloc_workqueue already works: Use macros for the public api so we can
> > have a callsite specific lockdep key, then pass that through the
> > entire callchain. Due to the many entry points this is slightly
> > tedious.
> 
> Do you have a splat somewhere? I'm having trouble seeing how all this
> comes together. That is, I've no real idea what you're actual problem is
> and if this is the right solution.

The bugzilla link is full of them. One below as example - it ties entirely
unrelated locking chains from i915 memory management together with other
stuff, with the only common bit that the kthread completions are somewhere
in there. But neither can i915 code ever get at the cpu kthread nor the
other way round, so it's flat out impossible to ever hit a deadlock this
way. Same reasons why not all workqueues share their lockdep map either.
-Daniel

[   85.062523] Setting dangerous option reset - tainting kernel
[   85.068934] i915 :00:02.0: Resetting chip after gpu hang

[   85.069408] ==
[   85.069410] WARNING: possible circular locking dependency detected
[   85.069413] 4.15.0-rc1-CI-CI_DRM_3397+ #1 Tainted: G U  
[   85.069415] --
[   85.069417] gem_exec_captur/2810 is trying to acquire lock:
[   85.069419]  ((completion)>parked){+.+.}, at: [] 
kthread_park+0x3d/0x50
[   85.069426] 
   but task is already holding lock:
[   85.069428]  (>struct_mutex){+.+.}, at: [] 
i915_reset_device+0x1bd/0x230 [i915]
[   85.069448] 
   which lock already depends on the new lock.

[   85.069451] 
   the existing dependency chain (in reverse order) is:
[   85.069454] 
   -> #3 (>struct_mutex){+.+.}:
[   85.069460]__mutex_lock+0x81/0x9b0
[   85.069481]i915_mutex_lock_interruptible+0x47/0x130 [i915]
[   85.069502]i915_gem_fault+0x201/0x760 [i915]
[   85.069507]__do_fault+0x15/0x70
[   85.069509]__handle_mm_fault+0x7bf/0xda0
[   85.069512]handle_mm_fault+0x14f/0x2f0
[   85.069515]__do_page_fault+0x2d1/0x560
[   85.069518]page_fault+0x22/0x30
[   85.069520] 
   -> #2 (>mmap_sem){}:
[   85.069525]__might_fault+0x63/0x90
[   85.069529]_copy_to_user+0x1e/0x70
[   85.069532]perf_read+0x21d/0x290
[   85.069534]__vfs_read+0x1e/0x120
[   85.069536]vfs_read+0xa1/0x150
[   85.069539]SyS_read+0x40/0xa0
[   85.069541]entry_SYSCALL_64_fastpath+0x1c/0x89
[   85.069543] 
   -> #1 (_mutex){+.+.}:
[   85.069547]perf_event_ctx_lock_nested+0xbc/0x1d0
[   85.069549] 
   -> #0 ((completion)>parked){+.+.}:
[   85.069555]lock_acquire+0xaf/0x200
[   85.069558]wait_for_common+0x54/0x210
[   85.069560]kthread_park+0x3d/0x50
[   85.069579]i915_gem_reset_prepare_engine+0x1d/0x90 [i915]
[   85.069600]i915_gem_reset_prepare+0x2c/0x60 [i915]
[   85.069617]i915_reset+0x66/0x230 [i915]
[   85.069635]i915_reset_device+0x1cb/0x230 [i915]
[   85.069651]i915_handle_error+0x2d3/0x430 [i915]
[   85.069670]i915_wedged_set+0x79/0xc0 [i915]
[   85.069673]simple_attr_write+0xab/0xc0
[   85.069677]full_proxy_write+0x4b/0x70
[   85.069679]__vfs_write+0x1e/0x130
[   85.069682]vfs_write+0xc0/0x1b0
[   85.069684]SyS_write+0x40/0xa0
[   85.069686]entry_SYSCALL_64_fastpath+0x1c/0x89
[   85.069688] 
   other info that might help us debug this:

[   85.069692] Chain exists of:
 (completion)>parked --> >mmap_sem --> 
>struct_mutex

[   85.069698]  Possible unsafe locking scenario:

[   85.069701]CPU0CPU1
[   85.069703]
[   85.069705]   lock(>struct_mutex);
[   85.069707]lock(>mmap_sem);
[   85.069710]lock(>struct_mutex);
[   85.069713]   lock((completion)>parked);
[   85.069715] 
*** DEADLOCK ***

[   85.069718] 3 locks held by gem_exec_captur/2810:
[   85.069722]  #0:  (sb_writers#10){.+.+}, at: [] 
vfs_write+0x15e/0x1b0
[   85.069727]  #1:  (>mutex){+.+.}, at: [] 
simple_attr_write+0x36/0xc0
[   85.069732]  #2:  (>struct_mutex){+.+.}, at: [] 
i915_reset_device+0x1bd/0x230 [i915]
[   85.069751] 
   stack backtrace:
[   85.069754] CPU: 2 PID: 2810 Comm: gem_exec_captur 

Re: linux-next: build warnings after merge of the gpio tree

[Arnd Bergmann]

On Wed, Dec 6, 2017 at 9:51 PM, Rob Herring  wrote:
> On Tue, Dec 5, 2017 at 4:48 PM, Stephen Rothwell  
> wrote:
> These 2 aren't in -next and seem to have been missed:
>
> arm: dts: qcom: fix missing #phy-cells for apq8064

Apparently this is a subsect of 3191b5b332f8 ("ARM: dts: qcom-apq8064: Fix dsi
and hdmi phy cells"), which we already have

> arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv

Picked this one up now.

   Arnd

RE: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support

[Chen, Kenji]

For Intel Broadwell, SKylake, and KabyLake PCIe Root Port, the threshold is 
recommended as it is in the commit. If the BIOS/Coreboot porting between 
platforms is taken into consideration, using a build definition or variables 
from somewhere of customizable zone is preferred. Let Coreboot guys make the 
call since I am working for Intel Only.

-Original Message-
From: Bjorn Helgaas [mailto:helg...@kernel.org] 
Sent: Thursday, December 7, 2017 10:45 PM
To: Chen, Kenji 
Cc: linux-...@vger.kernel.org; Thierry Reding ; Manikanta 
Maddireddy ; David Daney ; 
Krishna Kishore ; linux-kernel@vger.kernel.org; Vidya Sagar 
; Julia Lawall ; 
linux-te...@vger.kernel.org; Patrick Georgi ; Rajat Jain 
; Yinghai Lu ; Stefan Reinauer 
; Duncan Laurie 
Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support

On Wed, Dec 06, 2017 at 01:55:37AM +, Chen, Kenji wrote:
> https://pcisig.com/sites/default/files/specification_documents/ECN_L1_
> PM_Substates_with_CLKREQ_31_May_2013_Rev10a.pdf

With all due respect, this doesn't seem to add any new information.
For example, the L1 PM Substates Control 1 register description from the above 
is basically identical to the published PCIe r3.1, sec 7.33.3.

So it doesn't answer the questions of:

  1) Why coreboot sets the L1.2 threshold to a fixed value, and

  2) How "(1 << 21) | (1 << 23) | (1 << 30)" relates to the Control 1
 register

> Pls also check My Intel Doc# 545845 for the bits fields description.

I don't have access to this document.  The Linux code I'm proposing is based on 
the PCIe spec and is intended to work on all hardware that conforms to that 
spec.  I'm not very familiar with coreboot, but maybe the L1 Substates code 
there is only intended to work on certain Intel chipsets and doesn't need to 
work on other hardware?

Bjorn

> -Original Message-
> From: Bjorn Helgaas [mailto:helg...@kernel.org]
> Sent: Wednesday, December 6, 2017 3:41 AM
> To: linux-...@vger.kernel.org
> Cc: Chen, Kenji ; Thierry Reding 
> ; Manikanta Maddireddy ; 
> David Daney ; Krishna Kishore 
> ; linux-kernel@vger.kernel.org; Vidya Sagar 
> ; Julia Lawall ; 
> linux-te...@vger.kernel.org; Patrick Georgi ; 
> Rajat Jain ; Yinghai Lu ; 
> Stefan Reinauer ; Duncan Laurie 
> 
> Subject: Re: [PATCH v1 0/2] PCI/ASPM: Refine L1 PM Substates support
> 
> On Sat, Dec 02, 2017 at 03:45:38PM -0600, Bjorn Helgaas wrote:
> > The PCIe active link power state is L0.  ASPM defines two low-power
> > states: L0s and L1.  The L1 PM Substates feature defines two 
> > additional low-power states: L1.1 and L2.2.
> > 
> > The L1.2 state may have substantial entry/exit latency.  Downstream 
> > devices can use the Latency Tolerance Reporting (LTR) feature to 
> > report how much latency they can tolerate.  The L1 PM Substates 
> > capability includes a programmable L1.2 threshold register.  If the 
> > downstream devices can tolerate the latency indicated by the 
> > threshold, L1.2 may be used.
> > 
> > If LTR is not enabled, the L1.2 threshold is ignored and L1.2 can be 
> > used whenever it is enabled and CLKREQ# is de-asserted.  Linux 
> > currently never enables LTR, but firmware may have done so.
> > 
> > The current L1 PM substates support in Linux sets the L1.2 threshold 
> > to a fixed value (163.84us) copied from coreboot [1].  I don't know 
> > where that value came from, and it is incorrect for some platforms, 
> > e.g., Tegra [2].
> > 
> > These patches change that so we calculate the L1.2 threshold based 
> > on values reported by the hardware, and we enable LTR whenever possible.
> > 
> > This is all just my understanding from reading the spec.  I'd be 
> > glad to be corrected if I'm going wrong.
> > 
> > I'm particularly puzzled about the coreboot code in
> > pciexp_L1_substate_commit() that sets LTR_L1.2_THRESHOLD:
> > 
> > +   pcie_update_cfg(root, root_cap + 0x08, ~0xe3ff,
> > +   (1 << 21) | (1 << 23) | (1 << 30));
> > 
> > This is writing the L1 PM Substates Control 1 register, but the 
> > shifts don't match up with any of the fields in the register, so 
> > this is an awfully funny way to write the threshold.
> > 
> > [1]
> > https://mail.coreboot.org/pipermail/coreboot-gerrit/2015-March/021134.
> > html [2]
> > https://lkml.kernel.org/r/1510492674-12786-1-git-send-email-vidyas@n
> > vi
> > dia.com
> > 
> > ---
> > 
> > Bjorn Helgaas (2):
> >   PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics
> >  

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Alan Stern]

On Thu, 7 Dec 2017, Geert Uytterhoeven wrote:

> Hi Alan,
> 
> On Wed, Dec 6, 2017 at 11:02 PM, Alan Stern  wrote:
> > On Wed, 6 Dec 2017, SF Markus Elfring wrote:
> >> >>> Does the existing memory allocation error message include the
> >> >>> >dev device name and driver name?  If it doesn't, there will be
> >> >>> no way for the user to tell that the error message is related to the
> >> >>> device failure.
> >> >>
> >> >> No, but the effect is similar.
> >> >>
> >> >> OOM does a dump_stack() so this function's call tree is shown.
> >> >
> >> > A call stack doesn't tell you which device was being handled.
> >>
> >> Do you find a default Linux allocation failure report insufficient then?
> >>
> >> Would you like to to achieve that the requested information can be 
> >> determined
> >> from a backtrace?
> >
> > It is not practical to do this.  The memory allocation routines do not
> > for what purpose the memory is being allocated; hence when a failure
> > occurs they cannot tell what device (or other part of the system) will
> > be affected.
> 
> If even allocation of 24 bytes fails, lots of other devices and other parts of
> the system will start failing really soon...

In fact, one wonders if the allocation routine's own error message and
stack trace would actually appear anywhere...

> > That's why we have a secondary error message.
> 
> ... and the secondary error message would still be useless.

Well, there is still a difference between GFP_ATOMIC and GFP_KERNEL 
allocations.  Failure of the first doesn't necessarily imply failure of 
the second, so perhaps the system could recover.

The real problem is that the kernel development community doesn't have
a fixed policy on how to handle memory allocation errors.  There are
several possibilities:

Ignore them on the grounds that they will never happen.
(Really?  And what is the size limit above which they
might happen?)

Ignore them on the grounds that the machine will hang or
crash in the near future.  (Is this guaranteed?)

Treat them like other errors: try to press forward (perhaps
in a degraded mode).

Treat them like other errors: log an error message and try
to press forward.

And probably a few more that haven't occurred to me.  No doubt there 
are examples of each at various places in the kernel.  Nobody seems
able to agree on a single course of action.  Maybe not even Linus.

If there was one agreed-upon policy, then we could definitively point 
to old code and say "That's wrong, and here is how it should be fixed."  
But currently this is not possible, and we end up with repetitive 
discussions like this one that aren't of general use.

Alan Stern

Re: [PATCH] integrity: get rid of unneeded initializations in integrity_iint_cache entries

[Jeff Layton]

On Thu, 2017-12-07 at 09:35 -0500, Mimi Zohar wrote:
> On Thu, 2017-12-07 at 07:01 -0500, Jeff Layton wrote:
> > On Thu, 2017-07-06 at 15:43 -0400, Mimi Zohar wrote:
> > > On Thu, 2017-07-06 at 10:04 -0500, Serge E. Hallyn wrote:
> > > > Quoting Jeff Layton (jlay...@kernel.org):
> > > > > From: Jeff Layton 
> > > > > 
> > > > > The init_once routine memsets the whole object to 0, and then
> > > > > explicitly sets some of the fields to 0 again. Just remove the 
> > > > > explicit
> > > > > initializations.
> > > > > 
> > > > > Signed-off-by: Jeff Layton 
> > > > 
> > > > Reviewed-by: Serge Hallyn 
> > > 
> > > Thanks, queued.
> > > 
> > > Mimi
> > > 
> > 
> > Hi Mimi,
> > 
> > I notice that this patch hasn't made the last couple of releases. Was it
> > dropped for some reason?
> 
> Thanks for the reminder.  I accidentally dropped it (and Sascha
> Hauer's patch).  The subject line is too long.  Assuming you don't
> object, I'll replace the "get rid of" with "removed" and queue the
> patch in the next-queued-testing branch.
> 
> Mimi
> 

Sounds good.

Thanks,
-- 
Jeff Layton 

Re: [PATCH] fs: Fix signed integer overflow for vfs_setpos

[Al Viro]

On Thu, Dec 07, 2017 at 09:19:10PM +0800, Ding Tianhong wrote:
> The undefined behaviour sanatizer detected an signed integer overflow like 
> this:
> 
> r0 = 
> memfd_create(&(0x7f002000-0x12)="2e726571756573745f6b65795f6175746800",0x0)
> lseek(r0, 0x4040, 0x1)
> setsockopt$inet6_IPV6_FLOWLABEL_MGR(r0, 0x29, 0x20,
> &(0x7f00b000-0xd)={@empty={[0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0]}, 0x9, 0x1, 0xff, 0x2, 0x6, 
> 0x1,0xd27}, 0x20)
> mmap(&(0x7f00e000/0x1000)=nil, 0x1000, 0x3, 0x32,0x, 0x0)
> ioctl$sock_SIOCGSKNS(r0, 0x894c, &(0x7f00f000-0x4)=0x1)
> -
> UBSAN: Undefined behaviour in fs/read_write.c:107:12
> signed integer overflow:
> 4629700416936869888 + 4629700416936869888 cannot be represented in type
> 'long long int'
> CPU: 0 PID: 11653 Comm: syz-executor0 Not tainted 4.x.xx+ #2
> Hardware name: linux,dummy-virt (DT)
> Call trace:
> [] dump_backtrace+0x0/0x2a0
> [] show_stack+0x20/0x30
> [] dump_stack+0x11c/0x16c
> [] ubsan_epilogue+0x18/0x70
> [] handle_overflow+0x14c/0x188
> [] __ubsan_handle_add_overflow+0x34/0x44
> [] generic_file_llseek_size+0x1f8/0x2a0
> [] shmem_file_llseek+0x7c/0x1f8
> [] SyS_lseek+0xc0/0x118
> 
> 
> The problem happened because the calculation of signed integer resulted
> an overflow for the signed integer, so use the unsigned integer to avoid
> undefined behaviour when it does overflow.

TBH, I don't like that solution - there's too much of "make UBSAN STFU" in
it.  Besides, there are very similar places elsewhere.  Right next to this
one there's default_llseek(), with its
case SEEK_CUR:
if (offset == 0) {
retval = file->f_pos;
goto out;
}
offset += file->f_pos;
break;
and offset is loff_t there.  Exact same issue, IOW.  Grepping around shows
tons of similar places.  E.g. ceph_llseek() has
if (offset == 0) {
ret = file->f_pos;
goto out;
}
offset += file->f_pos;
break;
with offset being loff_t and ocfs2_file_llseek() is the same.  memory_lseek()
does something very similar, except that it doesn't use vfs_setpos(),
ditto for xillybus_llseek(), wil_pmc_llseek(), hmcdrv_dev_seek(), etc.

That kind of whack-a-mole ("UBSAN has stepped on that one, let's plug it",
while the other places like that keep breeding) is, IMO, the wrong approach ;-/

BTW, a fun unrelated bogosity:
static loff_t scom_llseek(struct file *file, loff_t offset, int whence)
{
switch (whence) {
case SEEK_CUR:
break;
case SEEK_SET:
file->f_pos = offset;
break;
default:
return -EINVAL;
}

return offset;
}
IOW, lseek(fd, SEEK_CUR, n) quietly returns n there.  Separate issue, though...

Re: [PATCH net-next v2 5/8] net: phy: meson-gxl: detect LPA corruption

[Andrew Lunn]

On Thu, Dec 07, 2017 at 03:27:12PM +0100, Jerome Brunet wrote:
> The purpose of this change is to fix the incorrect detection of the link
> partner (LP) advertised capabilities which sometimes happens with this PHY
> (roughly 1 time in a dozen)

Hi Jerome

Since this is a real fix, please send it alone. Base it on net, not
net-next.  David will then get it applied to stable, so it will be
backported.

Thanks
Andrew

Re: Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown

[Alan Cox]

> I am curious though, is the above notion of having hardware require signed
> firmware an implication brought down by UEFI? If so do you have any pointers
> to where this is stipulated? Or is it just a best practice we assume some
> manufacturers are implementing?

It's a mix of best practice and meeting the so called 'secure boot'
requirements. In the non Linux space exactly the same problems exist in
terms of trusting devices and firmware, building a root of trust and even
more so when producing 'hardened' platforms.

Some stuff isn't - USB devices for example don't get to pee on random
memory so often isn't signed.

Alan

[PATCH v3 07/10] ASoC: tlv320aic31xx: Add short circuit detection support

[Andrew F. Davis]

These devices support detecting and reporting short circuits across
the output stages. Add support for reporting these issue. Do this
by registering an interrupt if available and enabling this error
to trigger that interrupt in the device.

Signed-off-by: Andrew F. Davis 
---
 sound/soc/codecs/tlv320aic31xx.c | 42 
 sound/soc/codecs/tlv320aic31xx.h | 16 +++
 2 files changed, 58 insertions(+)

diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index 6cbe5820ce60..500284853a5c 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -159,6 +159,7 @@ struct aic31xx_priv {
unsigned int sysclk;
u8 p_div;
int rate_div_line;
+   int irq;
 };
 
 struct aic31xx_rate_divs {
@@ -1253,6 +1254,27 @@ static const struct acpi_device_id aic31xx_acpi_match[] 
= {
 MODULE_DEVICE_TABLE(acpi, aic31xx_acpi_match);
 #endif
 
+static irqreturn_t aic31xx_irq(int irq, void *data)
+{
+   struct aic31xx_priv *aic31xx = data;
+   struct device *dev = aic31xx->dev;
+   unsigned int value;
+   int ret;
+
+   ret = regmap_read(aic31xx->regmap, AIC31XX_INTRDACFLAG, );
+   if (ret) {
+   dev_err(dev, "Failed to read interrupt mask: %d\n", ret);
+   return IRQ_NONE;
+   }
+
+   if (value & AIC31XX_HPLSCDETECT)
+   dev_err(dev, "Short circuit on Left output is detected\n");
+   if (value & AIC31XX_HPRSCDETECT)
+   dev_err(dev, "Short circuit on Right output is detected\n");
+
+   return IRQ_HANDLED;
+}
+
 static int aic31xx_i2c_probe(struct i2c_client *i2c,
 const struct i2c_device_id *id)
 {
@@ -1275,6 +1297,7 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c,
return ret;
}
aic31xx->dev = >dev;
+   aic31xx->irq = i2c->irq;
 
aic31xx->codec_type = id->driver_data;
 
@@ -1313,6 +1336,25 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c,
return ret;
}
 
+   if (aic31xx->irq > 0) {
+   regmap_update_bits(aic31xx->regmap, AIC31XX_GPIO1,
+  AIC31XX_GPIO1_FUNC_MASK,
+  AIC31XX_GPIO1_INT1 <<
+  AIC31XX_GPIO1_FUNC_SHIFT);
+
+   regmap_write(aic31xx->regmap, AIC31XX_INT1CTRL,
+AIC31XX_SC);
+
+   ret = devm_request_threaded_irq(aic31xx->dev, aic31xx->irq,
+   NULL, aic31xx_irq,
+   IRQF_ONESHOT, "aic31xx-irq",
+   aic31xx);
+   if (ret) {
+   dev_err(aic31xx->dev, "Unable to request IRQ\n");
+   return ret;
+   }
+   }
+
if (aic31xx->codec_type & DAC31XX_BIT)
return snd_soc_register_codec(>dev,
_codec_driver_aic31xx,
diff --git a/sound/soc/codecs/tlv320aic31xx.h b/sound/soc/codecs/tlv320aic31xx.h
index ab94e6a0c742..9dc85b6f6ad3 100644
--- a/sound/soc/codecs/tlv320aic31xx.h
+++ b/sound/soc/codecs/tlv320aic31xx.h
@@ -184,6 +184,22 @@ enum aic31xx_type {
 #define AIC31XX_SC BIT(3)
 #define AIC31XX_ENGINE BIT(2)
 
+/* AIC31XX_GPIO1 */
+#define AIC31XX_GPIO1_FUNC_MASKGENMASK(5, 2)
+#define AIC31XX_GPIO1_FUNC_SHIFT   2
+#define AIC31XX_GPIO1_DISABLED 0x00
+#define AIC31XX_GPIO1_INPUT0x01
+#define AIC31XX_GPIO1_GPI  0x02
+#define AIC31XX_GPIO1_GPO  0x03
+#define AIC31XX_GPIO1_CLKOUT   0x04
+#define AIC31XX_GPIO1_INT1 0x05
+#define AIC31XX_GPIO1_INT2 0x06
+#define AIC31XX_GPIO1_ADC_WCLK 0x07
+#define AIC31XX_GPIO1_SBCLK0x08
+#define AIC31XX_GPIO1_SWCLK0x09
+#define AIC31XX_GPIO1_ADC_MOD_CLK  0x10
+#define AIC31XX_GPIO1_SDOUT0x11
+
 /* AIC31XX_DACSETUP */
 #define AIC31XX_SOFTSTEP_MASK  GENMASK(1, 0)
 
-- 
2.15.0

Re: [PATCH v2 16/19] ASoC: tlv320aic31xx: Add short circuit detection support

[Andrew F. Davis]

On 12/07/2017 06:03 AM, Mark Brown wrote:
> On Wed, Dec 06, 2017 at 02:22:39PM -0600, Andrew F. Davis wrote:
>> On 12/01/2017 09:32 AM, Andrew F. Davis wrote:
> 
 This will report the interrupt as handled even if we didn't see an
 interrupt we understand which will break shared interrupt lines.  At the
 very least we should log other interrupt sources numerically.
> 
>>> Okay, I think I can make that work by checking if no bits are set in the
>>> interrupt regs and returning early if not, IRQ_NONE.
> 
>> This turned out to be more difficult than I expected, plus if I do
>> handle an interrupt it doesn't mean the other device did not right? So
>> this wouldn't fix shared lines as far as I can tell, but I don't
>> register it as shared so this should be fine.
> 
> It'll mean that we don't offer the interrupt to anything else sharing
> the line.
> 
>> As for your other suggestion of "log other interrupt sources
>> numerically", could you explain this or point to an example of what you
>> mean?
> 
> Just print out the bits that were set.
> 

I don't see anyone else doing this, what would that solve? Maybe I still
don't get what you mean here. :(

[PATCH v3 10/10] ASoC: tlv320aic31xx: Add button press detection

[Andrew F. Davis]

This device can optionally detect headset or microphone button presses.
Add support for this by passing this event to the jack layer.

Signed-off-by: Andrew F. Davis 
---
 sound/soc/codecs/tlv320aic31xx.c | 14 +-
 sound/soc/codecs/tlv320aic31xx.h |  3 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/tlv320aic31xx.c b/sound/soc/codecs/tlv320aic31xx.c
index fef402e0f9e8..8f5dec414628 100644
--- a/sound/soc/codecs/tlv320aic31xx.c
+++ b/sound/soc/codecs/tlv320aic31xx.c
@@ -1290,9 +1290,20 @@ static irqreturn_t aic31xx_irq(int irq, void *data)
if (value & AIC31XX_HPRSCDETECT)
dev_err(dev, "Short circuit on Right output is detected\n");
 
-   if (value & AIC31XX_HSPLUG) {
+   if (value & (AIC31XX_HSPLUG | AIC31XX_BUTTONPRESS)) {
int status = 0;
 
+   ret = regmap_read(aic31xx->regmap, AIC31XX_INTRDACFLAG2,
+ );
+   if (ret) {
+   dev_err(dev, "Failed to read interrupt mask: %d\n",
+   ret);
+   return IRQ_NONE;
+   }
+
+   if (value & AIC31XX_BUTTONPRESS)
+   status |= SND_JACK_BTN_0;
+
ret = regmap_read(aic31xx->regmap, AIC31XX_HSDETECT, );
if (ret) {
dev_err(dev, "Failed to read headset type: %d\n", ret);
@@ -1405,6 +1416,7 @@ static int aic31xx_i2c_probe(struct i2c_client *i2c,
 
regmap_write(aic31xx->regmap, AIC31XX_INT1CTRL,
 AIC31XX_HSPLUGDET |
+AIC31XX_BUTTONPRESSDET |
 AIC31XX_SC |
 AIC31XX_ENGINE);
 
diff --git a/sound/soc/codecs/tlv320aic31xx.h b/sound/soc/codecs/tlv320aic31xx.h
index 66c85df4d5be..7fce278eadac 100644
--- a/sound/soc/codecs/tlv320aic31xx.h
+++ b/sound/soc/codecs/tlv320aic31xx.h
@@ -21,7 +21,8 @@
 #define DAC31XX_BITBIT(3)
 
 #define AIC31XX_JACK_MASK (SND_JACK_HEADPHONE | \
-  SND_JACK_HEADSET)
+  SND_JACK_HEADSET | \
+  SND_JACK_BTN_0)
 
 enum aic31xx_type {
AIC3100 = 0,
-- 
2.15.0

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[Tetsuo Handa]

Michal Hocko wrote:
> David, could you test with this patch please?

Even if this patch solved David's case, you need to update

 * tsk_is_oom_victim() cannot be set from under us
 * either because current->mm is already set to NULL
 * under task_lock before calling mmput and oom_mm is
 * set not NULL by the OOM killer only if current->mm
 * is found not NULL while holding the task_lock.

part as well, for it is the explanation of why
tsk_is_oom_victim() test was expected to work.

Also, do we need to do

  set_bit(MMF_OOM_SKIP, >flags);

if mm_is_oom_victim(mm) == false?

exit_mmap() is called means that nobody can reach this mm
except ->signal->oom_mm, and mm_is_oom_victim(mm) == false
means that this mm cannot be reached by ->signal->oom_mm .

Then, I think we do not need to set MMF_OOM_SKIP on this mm
at exit_mmap() if mm_is_oom_victim(mm) == false.

Re: ipmi null pointer oops in 4.15-rc2+ on HP DL360G6

[Meelis Roos]

> > Tried current 4.15 git on HP DL360G6 (working fine in 4.14), got null
> > pointer dereference oops from ipmi_pci_probe (or so it seems from the
> > backtrace).
> 
> I have a fix for this at https://bugzilla.kernel.org/show_bug.cgi?id=197999,
> but
> the reported hasn't reported if the patch there fixes the issue.  If you could
> test
> this, that would be very helpful.

It works. no errors. I hve not tested if ipmi communication actually 
works though.

$ dmesg |grep -i pmi
[0.00] ACPI: SPMI 0xD761F2C0 40 (v05 HP ProLiant 
0001 \xd2?   162E)
[4.563949] ipmi message handler version 39.2
[4.578919] ipmi device interface
[4.580438] IPMI System Interface driver.
[4.580503] ipmi_si dmi-ipmi-si.0: ipmi_platform: probing via SMBIOS
[4.580561] ipmi_si: SMBIOS: io 0xca2 regsize 1 spacing 1 irq 0
[4.580618] ipmi_si: Adding SMBIOS-specified kcs state machine
[4.580687] ipmi_si IPI0001:00: ipmi_platform: probing via ACPI
[4.580758] ipmi_si IPI0001:00: [io  0x0ca2-0x0ca3] regsize 1 spacing 1 irq 0
[4.580817] ipmi_si dmi-ipmi-si.0: Removing SMBIOS-specified kcs state 
machine in favor of ACPI
[4.580894] ipmi_si: Adding ACPI-specified kcs state machine
[4.580964] ipmi_platform: probing via SPMI
[4.581018] ipmi_si: SPMI: io 0xca2 regsize 2 spacing 2 irq 0
[4.581074] (NULL device *): SPMI-specified kcs state machine: duplicate
[4.581142] ipmi_si :01:04.6: probing via PCI
[4.581282] ipmi_si :01:04.6: [mem 0xf5ef-0xf5ef00ff] regsize 1 
spacing 1 irq 21
[4.581356] ipmi_si: Adding PCI-specified kcs state machine
[4.581428] ipmi_si: Trying PCI-specified kcs state machine at mem address 
0xf5ef, slave address 0x0, irq 21
[5.112453] ipmi_si :01:04.6: Using irq 21
[5.127593] ipmi_si :01:04.6: Found new BMC (man_id: 0x0b, prod_id: 
0x2000, dev_id: 0x11)
[5.139340] ipmi_si :01:04.6: IPMI kcs interface initialized
[5.148318] IPMI SSIF Interface driver
[6.126894] ACPI Error: SMBus/IPMI/GenericSerialBus write requires Buffer of 
length 66, found length 32 (20170831/exfield-427)
[6.127233] ACPI Error: Method parse/execution failed \_SB.PMI0._PMM, 
AE_AML_BUFFER_LIMIT (20170831/psparse-550)


-- 
Meelis Roos (mr...@linux.ee)

Re: [RFC][PATCH] printk: add console_msg_format command line option

[Petr Mladek]

On Thu 2017-12-07 23:01:04, Sergey Senozhatsky wrote:
> Hi,
> 
> On (12/07/17 14:48), Petr Mladek wrote:
> [..]
> > > This patch introduces a `console_msg_format=' command line option,
> > > to switch between different message formatting on serial consoles.
> > > For the time being we have just one option - syslog. This option
> > > makes serial console messages to appear in syslog format, matching
> > > the `dmesg --raw' and `cat /proc/kmsg' output formats:
> > 
> > I have realized that 'cat /proc/kmsg' did not work. It can be done using:
> 
> hm, it does work on my system. what do you mean by 'did not work'?
> 
> 
> > Also the format is more comlicated here, see printk.c:
> > 
> >  * /dev/kmsg exports the structured data in the following line format:
> >  *   ",,,[,additional_values, ... 
> > ];\n"
> 
> that's /dev/kmsg. /dev/kmsg != /proc/kmsg. I never mentioned /dev/kmsg
> in my commit. /dev/kmsg prints the extended stuff, /proc/kmsg does not.

Ah, I have messed /dev/kmsg and /proc/kmsg.

> 
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> > > b/Documentation/admin-guide/kernel-parameters.txt
> > > index 28467638488d..2dd91c5073f9 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -643,6 +643,16 @@
> > >   console=brl,ttyS0
> > >   For now, only VisioBraille is supported.
> > >  
> > > + console_msg_format=
> > > + [KNL] Control message format
> > > + By default we print messages in "[time stamp] text\n"
> > > + format (time stamp may not be printed, depending on
> > > + CONFIG_PRINTK_TIME or `printk_time' param).
> > > + syslog
> > > + Switch to syslog format (similar to "dmesg --raw" or
> > > + reading from /proc/kmsg): "<%u>[time stamp] text\n"
> > 
> > To be precise, it exactly the same as "dmesg -S --raw". Also it is the
> > format used by SYSLOG_ACTION_READ* actions of the syslog syscall.
> 
> hmm... `dmesg -S --raw' doesn't show anything on my system. `dmesg --raw'
> matches the console_msg_format=syslog.

Huh, I am confused now. I thought that I saw the extended, /dev/kmsg - like,
output with "dmesg --raw" but I do not see it now.

Anyway, I can see a difference related to
/sys/module/printk/parameters/time. The command "dmesg --raw" always
shows the timestamp help because it reads the messages via /dev/kmsg.
But "dmesg -S --raw" shows the timestamp only when the "time"
parameter is enabled:

$> echo 0 >/sys/module/printk/parameters/time
$> dmesg -S --raw | head -n 3
<5>Linux version 4.15.0-rc2-5-default+ (pmladek@pathway) (gcc version 4.8.5 
(SUSE Linux)) #4180 SMP Thu Dec 7 16:06:42 CET 2017
<6>Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc2-5-default+ 
root=UUID=9ba368bb-c323-4131-ad94-c29cf3add76f resume=/dev/sda2 
earlyprintk=ttyS0,115200 console=tty0 console=ttyS0,115200 
console_msg_format=syslog ignore_loglevel nosplash showopts 
crashkernel=256M,high crashkernel=128M,low
<6>x86/fpu: x87 FPU will use FXSAVE
$> echo 1 >/sys/module/printk/parameters/time
$> dmesg -S --raw | head -n 3
<5>[0.00] Linux version 4.15.0-rc2-5-default+ (pmladek@pathway) (gcc 
version 4.8.5 (SUSE Linux)) #4180 SMP Thu Dec 7 16:06:42 CET 2017
<6>[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc2-5-default+ 
root=UUID=9ba368bb-c323-4131-ad94-c29cf3add76f resume=/dev/sda2 
earlyprintk=ttyS0,115200 console=tty0 console=ttyS0,115200 
console_msg_format=syslog ignore_loglevel nosplash showopts 
crashkernel=256M,high crashkernel=128M,low
<6>[0.00] x86/fpu: x87 FPU will use FXSAVE

Note that the -S option has been added in util-linux, v2.22
by the commit
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ed61acc2542ebb0d9b8f5600c38fbe0d77933345

I guess that dmesg fallbacks to the classic syslog mode
when /dev/kmsg is not available.


To be honest, I am somehow confused by the terminology.
We should make it clear that the "syslog" console format
is the same as the format used by the syslog syscall.

dmesg --raw might show something different when it gets the data
from /dev/kmsg as shown above.

Best Regards,
Petr

Re: [PATCH] perf: qcom_l2_pmu: don't allow guest access

[Leeder, Neil]

On 12/7/2017 8:38 AM, Will Deacon wrote:
> On Wed, Dec 06, 2017 at 04:19:24PM -0500, Leeder, Neil wrote:
>> On 12/6/2017 11:11 AM, Mark Rutland wrote:
>>> On Wed, Dec 06, 2017 at 10:55:33AM -0500, Neil Leeder wrote:
 Guests cannot access IMPDEF system registers, which are used
 by this driver. Disable the driver if it's running in a guest VM.

 Signed-off-by: Neil Leeder 
 ---
  drivers/perf/qcom_l2_pmu.c | 4 
  1 file changed, 4 insertions(+)
>>>
>>> I'm a little confused by this. Why is this hypervisor providing a
>>> QCOM8130 device to the guest that it cannot use?
>>>
>>> Could you elaborate on what's going on?
>>>
>>
>> While there's an argument that the guest shouldn't be loading the driver
>> in the first place, we can't control everyone's guest configuration or what
>> their hypervisor does.
> 
> Ok, but why is the hypervisor advertising a device that effectively doesn't
> exist? Most drivers trust the firmware tables they are given, so this makes
> it sound like we should start annotating all drivers for devices that we
> don't expect to see in a guest with is_hyp_mode_available() checks.
> 
> That doesn't feel quite right to me.

Hi Will,

I suspect that most mis-configured drivers don't fail until they're used, or are
otherwise Mostly Harmless. The problem here is that this driver uses IMPDEF 
system
registers in its init, and I'd guess only a minority of drivers do that. So it
crashed the kernel with an illegal instruction on boot. I'm trying to be a good
citizen here and not allow my driver to stop a kernel from booting because 
someone
misconfigured something out of my control.

Neil
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH AUTOSEL for 4.14 011/135] PM / s2idle: Clear the events_check_enabled flag

[alexander . levin]

From: Rajat Jain 

[ Upstream commit 95b982b45122c57da2ee0b46cce70775e1d987af ]

Problem: This flag does not get cleared currently in the suspend or
resume path in the following cases:

 * In case some driver's suspend routine returns an error.
 * Successful s2idle case
 * etc?

Why is this a problem: What happens is that the next suspend attempt
could fail even though the user did not enable the flag by writing to
/sys/power/wakeup_count. This is 1 use case how the issue can be seen
(but similar use case with driver suspend failure can be thought of):

 1. Read /sys/power/wakeup_count
 2. echo count > /sys/power/wakeup_count
 3. echo freeze > /sys/power/wakeup_count
 4. Let the system suspend, and wakeup the system using some wake source
that calls pm_wakeup_event() e.g. power button or something.
 5. Note that the combined wakeup count would be incremented due
to the pm_wakeup_event() in the resume path.
 6. After resuming the events_check_enabled flag is still set.

At this point if the user attempts to freeze again (without writing to
/sys/power/wakeup_count), the suspend would fail even though there has
been no wake event since the past resume.

Address that by clearing the flag just before a resume is completed,
so that it is always cleared for the corner cases mentioned above.

Signed-off-by: Rajat Jain 
Acked-by: Pavel Machek 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 kernel/power/suspend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c
index ccd2d20e6b06..0685c4499431 100644
--- a/kernel/power/suspend.c
+++ b/kernel/power/suspend.c
@@ -437,7 +437,6 @@ static int suspend_enter(suspend_state_t state, bool 
*wakeup)
error = suspend_ops->enter(state);
trace_suspend_resume(TPS("machine_suspend"),
state, false);
-   events_check_enabled = false;
} else if (*wakeup) {
error = -EBUSY;
}
@@ -582,6 +581,7 @@ static int enter_state(suspend_state_t state)
pm_restore_gfp_mask();
 
  Finish:
+   events_check_enabled = false;
pm_pr_dbg("Finishing wakeup.\n");
suspend_finish();
  Unlock:
-- 
2.11.0

[PATCH AUTOSEL for 4.9 078/156] NFSv4.1 respect server's max size in CREATE_SESSION

[alexander . levin]

From: Olga Kornievskaia 

[ Upstream commit 033853325fe3bdc70819a8b97915bd3bca41d3af ]

Currently client doesn't respect max sizes server returns in CREATE_SESSION.
nfs4_session_set_rwsize() gets called and server->rsize, server->wsize are 0
so they never get set to the sizes returned by the server.

Signed-off-by: Olga Kornievskaia 
Signed-off-by: Anna Schumaker 
Signed-off-by: Sasha Levin 
---
 fs/nfs/nfs4client.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c
index 074ac7131459..f6b0848cc831 100644
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -1004,9 +1004,9 @@ static void nfs4_session_set_rwsize(struct nfs_server 
*server)
server_resp_sz = sess->fc_attrs.max_resp_sz - nfs41_maxread_overhead;
server_rqst_sz = sess->fc_attrs.max_rqst_sz - nfs41_maxwrite_overhead;
 
-   if (server->rsize > server_resp_sz)
+   if (!server->rsize || server->rsize > server_resp_sz)
server->rsize = server_resp_sz;
-   if (server->wsize > server_rqst_sz)
+   if (!server->wsize || server->wsize > server_rqst_sz)
server->wsize = server_rqst_sz;
 #endif /* CONFIG_NFS_V4_1 */
 }
-- 
2.11.0

[PATCH AUTOSEL for 4.9 072/156] net: mpls: Fix nexthop alive tracking on down events

[alexander . levin]

From: David Ahern 

[ Upstream commit 61733c91c454a61be0ffc93fe46a5d5f2f048c1c ]

Alive tracking of nexthops can account for a link twice if the carrier
goes down followed by an admin down of the same link rendering multipath
routes useless. This is similar to 79099aab38c8 for UNREGISTER events and
DOWN events.

Fix by tracking number of alive nexthops in mpls_ifdown similar to the
logic in mpls_ifup. Checking the flags per nexthop once after all events
have been processed is simpler than trying to maintian a running count
through all event combinations.

Also, WRITE_ONCE is used instead of ACCESS_ONCE to set rt_nhn_alive
per a comment from checkpatch:
WARNING: Prefer WRITE_ONCE(, ) over ACCESS_ONCE() = 

Fixes: c89359a42e2a4 ("mpls: support for dead routes")
Signed-off-by: David Ahern 
Acked-by: Robert Shearman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/mpls/af_mpls.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index 1309e2c34764..c5a5a6959c1b 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -937,6 +937,8 @@ static void mpls_ifdown(struct net_device *dev, int event)
 {
struct mpls_route __rcu **platform_label;
struct net *net = dev_net(dev);
+   unsigned int nh_flags = RTNH_F_DEAD | RTNH_F_LINKDOWN;
+   unsigned int alive;
unsigned index;
 
platform_label = rtnl_dereference(net->mpls.platform_label);
@@ -946,9 +948,11 @@ static void mpls_ifdown(struct net_device *dev, int event)
if (!rt)
continue;
 
+   alive = 0;
change_nexthops(rt) {
if (rtnl_dereference(nh->nh_dev) != dev)
-   continue;
+   goto next;
+
switch (event) {
case NETDEV_DOWN:
case NETDEV_UNREGISTER:
@@ -956,13 +960,16 @@ static void mpls_ifdown(struct net_device *dev, int event)
/* fall through */
case NETDEV_CHANGE:
nh->nh_flags |= RTNH_F_LINKDOWN;
-   if (event != NETDEV_UNREGISTER)
-   ACCESS_ONCE(rt->rt_nhn_alive) = 
rt->rt_nhn_alive - 1;
break;
}
if (event == NETDEV_UNREGISTER)
RCU_INIT_POINTER(nh->nh_dev, NULL);
+next:
+   if (!(nh->nh_flags & nh_flags))
+   alive++;
} endfor_nexthops(rt);
+
+   WRITE_ONCE(rt->rt_nhn_alive, alive);
}
 }
 
-- 
2.11.0

[PATCH AUTOSEL for 4.9 073/156] rxrpc: Ignore BUSY packets on old calls

[alexander . levin]

From: David Howells 

[ Upstream commit 4d4a6ac73e7466c2085c307fac41f74ce4568a45 ]

If we receive a BUSY packet for a call we think we've just completed, the
packet is handed off to the connection processor to deal with - but the
connection processor doesn't expect a BUSY packet and so flags a protocol
error.

Fix this by simply ignoring the BUSY packet for the moment.

The symptom of this may appear as a system call failing with EPROTO.  This
may be triggered by pressing ctrl-C under some circumstances.

This comes about we abort calls due to interruption by a signal (which we
shouldn't do, but that's going to be a large fix and mostly in fs/afs/).
What happens is that we abort the call and may also abort follow up calls
too (this needs offloading somehoe).  So we see a transmission of something
like the following sequence of packets:

DATA for call N
ABORT call N
DATA for call N+1
ABORT call N+1

in very quick succession on the same channel.  However, the peer may have
deferred the processing of the ABORT from the call N to a background thread
and thus sees the DATA message from the call N+1 coming in before it has
cleared the channel.  Thus it sends a BUSY packet[*].

[*] Note that some implementations (OpenAFS, for example) mark the BUSY
packet with one plus the callNumber of the call prior to call N.
Ordinarily, this would be call N, but there's no requirement for the
calls on a channel to be numbered strictly sequentially (the number is
required to increase).

This is wrong and means that the callNumber in the BUSY packet should
be ignored (it really ought to be N+1 since that's what it's in
response to).

Signed-off-by: David Howells 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/rxrpc/conn_event.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/net/rxrpc/conn_event.c b/net/rxrpc/conn_event.c
index 3f9d8d7ec632..b099b64366f3 100644
--- a/net/rxrpc/conn_event.c
+++ b/net/rxrpc/conn_event.c
@@ -275,6 +275,10 @@ static int rxrpc_process_event(struct rxrpc_connection 
*conn,
rxrpc_conn_retransmit_call(conn, skb);
return 0;
 
+   case RXRPC_PACKET_TYPE_BUSY:
+   /* Just ignore BUSY packets for now. */
+   return 0;
+
case RXRPC_PACKET_TYPE_ABORT:
if (skb_copy_bits(skb, sizeof(struct rxrpc_wire_header),
  , sizeof(wtmp)) < 0)
-- 
2.11.0

Re: [RESEND PATCH v3 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC

[Kevin Hilman]

On Wed, Dec 6, 2017 at 5:44 PM, Yixun Lan  wrote:
> Hi Kevin
>
>
> On 12/07/17 04:18, Kevin Hilman wrote:
>> Yixun Lan  writes:
>>
>>> From: Xingyu Chen 
>>>
>>> Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
>>>
>>> Reviewed-by: Neil Armstrong 
>>> Signed-off-by: Xingyu Chen 
>>> Signed-off-by: Yixun Lan 
>>> ---
>>>  arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 
>>> ++
>>>  1 file changed, 44 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi 
>>> b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> index 5fc33b76b91c..e0fb860e12c5 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>>> @@ -9,6 +9,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>
>> This doesn't apply because this aoclkc.h header does not exist in
>> mainline.
>>
>> Kevin
>>
>
> this is due to I create the patch in serial sequence (first clk, then
> pinctrl), I probably will fix my work flow next time - to rebase all the
> patch separately on the -rc version
>
> but here, the pinctrl DT part has no dependency on DT clk patch..
> you could drop the above two #include and just apply the reset
>
> could you amend & apply this? or do you want me to send another updated
> version?

I prefer that you rebase (either on -rc or my v4.16/dt64 branch[1]) and resend.

Thanks,

Kevin

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/log/?h=v4.16/dt64

[PATCH AUTOSEL for 4.9 150/156] scsi: bfa: integer overflow in debugfs

[alexander . levin]

From: Dan Carpenter 

[ Upstream commit 3e351275655d3c84dc28abf170def9786db5176d ]

We could allocate less memory than intended because we do:

bfad->regdata = kzalloc(len << 2, GFP_KERNEL);

The shift can overflow leading to a crash.  This is debugfs code so the
impact is very small.  I fixed the network version of this in March with
commit 13e2d5187f6b ("bna: integer overflow bug in debugfs").

Fixes: ab2a9ba189e8 ("[SCSI] bfa: add debugfs support")
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin 
---
 drivers/scsi/bfa/bfad_debugfs.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/bfa/bfad_debugfs.c b/drivers/scsi/bfa/bfad_debugfs.c
index 8dcd8c70c7ee..05f523971348 100644
--- a/drivers/scsi/bfa/bfad_debugfs.c
+++ b/drivers/scsi/bfa/bfad_debugfs.c
@@ -255,7 +255,8 @@ bfad_debugfs_write_regrd(struct file *file, const char 
__user *buf,
struct bfad_s *bfad = port->bfad;
struct bfa_s *bfa = >bfa;
struct bfa_ioc_s *ioc = >ioc;
-   int addr, len, rc, i;
+   int addr, rc, i;
+   u32 len;
u32 *regbuf;
void __iomem *rb, *reg_addr;
unsigned long flags;
@@ -266,7 +267,7 @@ bfad_debugfs_write_regrd(struct file *file, const char 
__user *buf,
return PTR_ERR(kern_buf);
 
rc = sscanf(kern_buf, "%x:%x", , );
-   if (rc < 2) {
+   if (rc < 2 || len > (UINT_MAX >> 2)) {
printk(KERN_INFO
"bfad[%d]: %s failed to read user buf\n",
bfad->inst_no, __func__);
-- 
2.11.0

Re: [PATCH net-next v2 3/8] net: phy: meson-gxl: add read and write helpers for bank registers

[Jerome Brunet]

On Thu, 2017-12-07 at 16:46 +0100, Andrew Lunn wrote:
> On Thu, Dec 07, 2017 at 03:27:10PM +0100, Jerome Brunet wrote:
> > Add read and write helpers to manipulate banked registers on this PHY
> > This helps clarify the settings applied to these registers in the init
> > function and upcoming changes.
> > 
> > Signed-off-by: Jerome Brunet 
> > ---
> >  drivers/net/phy/meson-gxl.c | 103 -
> > ---
> >  1 file changed, 67 insertions(+), 36 deletions(-)
> > 
> > diff --git a/drivers/net/phy/meson-gxl.c b/drivers/net/phy/meson-gxl.c
> > index d82aa8cea401..05054770aefb 100644
> > --- a/drivers/net/phy/meson-gxl.c
> > +++ b/drivers/net/phy/meson-gxl.c
> > @@ -45,11 +45,13 @@
> >  #define FR_PLL_DIV00x1c
> >  #define FR_PLL_DIV10x1d
> >  
> > -static int meson_gxl_config_init(struct phy_device *phydev)
> > +static int meson_gxl_open_banks(struct phy_device *phydev)
> 
> Hi Jerome
> 
> Does the word bank come from the datasheet? Most of the phy drives use
> page instead.
> 
> Also, we have discovered a race condition which affects drivers using
> pages, which can lead to corruption of registers. At some point, i
> expect we will be adding helpers to access paged registers, which do
> the right thing with respect to locks.
> 
> So it would be nice if you used the work page, not bank.

Banks actually comes from the datasheet, Yes.
I don't mind renaming it but I would be making things up. As you wish ?

Does the usual pages comes with this weird toggle thing to open the access ?
Would we able to use these generic helpers with our this kind of quirks ?

> 
>Thanks
> 
>   Andrew

[PATCH AUTOSEL for 4.9 118/156] ASoC: rsnd: rsnd_ssi_run_mods() needs to care ssi_parent_mod

[alexander . levin]

From: Kuninori Morimoto 

[ Upstream commit 21781e87881f9c420871b1d1f3f29d4cd7bffb10 ]

SSI parent mod might be NULL. ssi_parent_mod() needs to care
about it. Otherwise, it uses negative shift.
This patch fixes it.

Signed-off-by: Kuninori Morimoto 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 sound/soc/sh/rcar/ssi.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/sound/soc/sh/rcar/ssi.c b/sound/soc/sh/rcar/ssi.c
index 6cb6db005fc4..560cf4b51a99 100644
--- a/sound/soc/sh/rcar/ssi.c
+++ b/sound/soc/sh/rcar/ssi.c
@@ -172,10 +172,15 @@ static u32 rsnd_ssi_run_mods(struct rsnd_dai_stream *io)
 {
struct rsnd_mod *ssi_mod = rsnd_io_to_mod_ssi(io);
struct rsnd_mod *ssi_parent_mod = rsnd_io_to_mod_ssip(io);
+   u32 mods;
 
-   return rsnd_ssi_multi_slaves_runtime(io) |
-   1 << rsnd_mod_id(ssi_mod) |
-   1 << rsnd_mod_id(ssi_parent_mod);
+   mods = rsnd_ssi_multi_slaves_runtime(io) |
+   1 << rsnd_mod_id(ssi_mod);
+
+   if (ssi_parent_mod)
+   mods |= 1 << rsnd_mod_id(ssi_parent_mod);
+
+   return mods;
 }
 
 u32 rsnd_ssi_multi_slaves_runtime(struct rsnd_dai_stream *io)
-- 
2.11.0

[PATCH AUTOSEL for 3.18 02/59] net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values

[alexander . levin]

From: Doug Berger 

[ Upstream commit 71328a3c321f7c14cc1edd33577717037744 ]

The location of the RBUF overflow and error counters has moved between
different version of the GENET MAC.  This commit corrects the driver to
read from the correct locations depending on the version of the GENET
MAC.

Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
Signed-off-by: Doug Berger 
Reviewed-by: Florian Fainelli 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 +++---
 drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 +++--
 2 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 936448e4894c..ecce5d16f6e7 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1,7 +1,7 @@
 /*
  * Broadcom GENET (Gigabit Ethernet) controller driver
  *
- * Copyright (c) 2014 Broadcom Corporation
+ * Copyright (c) 2014-2017 Broadcom
  *
  * 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
@@ -610,8 +610,9 @@ static const struct bcmgenet_stats 
bcmgenet_gstrings_stats[] = {
STAT_GENET_RUNT("rx_runt_bytes", mib.rx_runt_bytes),
/* Misc UniMAC counters */
STAT_GENET_MISC("rbuf_ovflow_cnt", mib.rbuf_ovflow_cnt,
-   UMAC_RBUF_OVFL_CNT),
-   STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt, UMAC_RBUF_ERR_CNT),
+   UMAC_RBUF_OVFL_CNT_V1),
+   STAT_GENET_MISC("rbuf_err_cnt", mib.rbuf_err_cnt,
+   UMAC_RBUF_ERR_CNT_V1),
STAT_GENET_MISC("mdf_err_cnt", mib.mdf_err_cnt, UMAC_MDF_ERR_CNT),
 };
 
@@ -651,6 +652,45 @@ static void bcmgenet_get_strings(struct net_device *dev, 
u32 stringset,
}
 }
 
+static u32 bcmgenet_update_stat_misc(struct bcmgenet_priv *priv, u16 offset)
+{
+   u16 new_offset;
+   u32 val;
+
+   switch (offset) {
+   case UMAC_RBUF_OVFL_CNT_V1:
+   if (GENET_IS_V2(priv))
+   new_offset = RBUF_OVFL_CNT_V2;
+   else
+   new_offset = RBUF_OVFL_CNT_V3PLUS;
+
+   val = bcmgenet_rbuf_readl(priv, new_offset);
+   /* clear if overflowed */
+   if (val == ~0)
+   bcmgenet_rbuf_writel(priv, 0, new_offset);
+   break;
+   case UMAC_RBUF_ERR_CNT_V1:
+   if (GENET_IS_V2(priv))
+   new_offset = RBUF_ERR_CNT_V2;
+   else
+   new_offset = RBUF_ERR_CNT_V3PLUS;
+
+   val = bcmgenet_rbuf_readl(priv, new_offset);
+   /* clear if overflowed */
+   if (val == ~0)
+   bcmgenet_rbuf_writel(priv, 0, new_offset);
+   break;
+   default:
+   val = bcmgenet_umac_readl(priv, offset);
+   /* clear if overflowed */
+   if (val == ~0)
+   bcmgenet_umac_writel(priv, 0, offset);
+   break;
+   }
+
+   return val;
+}
+
 static void bcmgenet_update_mib_counters(struct bcmgenet_priv *priv)
 {
int i, j = 0;
@@ -674,10 +714,16 @@ static void bcmgenet_update_mib_counters(struct 
bcmgenet_priv *priv)
  UMAC_MIB_START + j + offset);
break;
case BCMGENET_STAT_MISC:
-   val = bcmgenet_umac_readl(priv, s->reg_offset);
-   /* clear if overflowed */
-   if (val == ~0)
-   bcmgenet_umac_writel(priv, 0, s->reg_offset);
+   if (GENET_IS_V1(priv)) {
+   val = bcmgenet_umac_readl(priv, s->reg_offset);
+   /* clear if overflowed */
+   if (val == ~0)
+   bcmgenet_umac_writel(priv, 0,
+s->reg_offset);
+   } else {
+   val = bcmgenet_update_stat_misc(priv,
+   s->reg_offset);
+   }
break;
}
 
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.h 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
index eeda0281c684..942271f9ab19 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.h
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2014 Broadcom Corporation
+ * Copyright (c) 2014-2017 Broadcom
  *
  * This program is free software; you can redistribute it and/or 

[PATCH AUTOSEL for 3.18 01/59] usb: phy: isp1301: Add OF device ID table

[alexander . levin]

From: Javier Martinez Canillas 

[ Upstream commit fd567653bdb908009b650f079bfd4b63169e2ac4 ]

The driver doesn't have a struct of_device_id table but supported devices
are registered via Device Trees. This is working on the assumption that a
I2C device registered via OF will always match a legacy I2C device ID and
that the MODALIAS reported will always be of the form i2c:.

But this could change in the future so the correct approach is to have an
OF device ID table if the devices are registered via OF.

Signed-off-by: Javier Martinez Canillas 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
---
 drivers/usb/phy/phy-isp1301.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/phy/phy-isp1301.c b/drivers/usb/phy/phy-isp1301.c
index 8a55b37d1a02..d2ed59a38354 100644
--- a/drivers/usb/phy/phy-isp1301.c
+++ b/drivers/usb/phy/phy-isp1301.c
@@ -32,6 +32,12 @@ static const struct i2c_device_id isp1301_id[] = {
{ }
 };
 
+static const struct of_device_id isp1301_of_match[] = {
+   {.compatible = "nxp,isp1301" },
+   { },
+};
+MODULE_DEVICE_TABLE(of, isp1301_of_match);
+
 static struct i2c_client *isp1301_i2c_client;
 
 static int __isp1301_write(struct isp1301 *isp, u8 reg, u8 value, u8 clear)
@@ -129,6 +135,7 @@ static int isp1301_remove(struct i2c_client *client)
 static struct i2c_driver isp1301_driver = {
.driver = {
.name = DRV_NAME,
+   .of_match_table = of_match_ptr(isp1301_of_match),
},
.probe = isp1301_probe,
.remove = isp1301_remove,
-- 
2.11.0

[PATCH AUTOSEL for 4.4 042/101] afs: Fix afs_kill_pages()

[alexander . levin]

From: David Howells 

[ Upstream commit 7286a35e893176169b09715096a4aca557e2ccd2 ]

Fix afs_kill_pages() in two ways:

 (1) If a writeback has been partially flushed, then if we try and kill the
 pages it contains, some of them may no longer be undergoing writeback
 and end_page_writeback() will assert.

 Fix this by checking to see whether the page in question is actually
 undergoing writeback before ending that writeback.

 (2) The loop that scans for pages to kill doesn't increase the first page
 index, and so the loop may not terminate, but it will try to process
 the same pages over and over again.

 Fix this by increasing the first page index to one after the last page
 we processed.

Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
---
 fs/afs/write.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/fs/afs/write.c b/fs/afs/write.c
index d89595155ec9..5cfc05ca184c 100644
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -299,10 +299,14 @@ static void afs_kill_pages(struct afs_vnode *vnode, bool 
error,
ASSERTCMP(pv.nr, ==, count);
 
for (loop = 0; loop < count; loop++) {
-   ClearPageUptodate(pv.pages[loop]);
+   struct page *page = pv.pages[loop];
+   ClearPageUptodate(page);
if (error)
-   SetPageError(pv.pages[loop]);
-   end_page_writeback(pv.pages[loop]);
+   SetPageError(page);
+   if (PageWriteback(page))
+   end_page_writeback(page);
+   if (page->index >= first)
+   first = page->index + 1;
}
 
__pagevec_release();
-- 
2.11.0

[PATCH AUTOSEL for 4.4 080/101] l2tp: cleanup l2tp_tunnel_delete calls

[alexander . levin]

From: Jiri Slaby 

[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]

l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete").  But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.

Kill these now useless casts.

Signed-off-by: Jiri Slaby 
Cc: Sabrina Dubroca 
Cc: Guillaume Nault 
Cc: David S. Miller 
Cc: net...@vger.kernel.org
Acked-by: Guillaume Nault 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 net/l2tp/l2tp_core.c| 2 +-
 net/l2tp/l2tp_netlink.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index d48281ca9c72..ec8f6a6485e3 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1856,7 +1856,7 @@ static __net_exit void l2tp_exit_net(struct net *net)
 
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, >l2tp_tunnel_list, list) {
-   (void)l2tp_tunnel_delete(tunnel);
+   l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
 }
diff --git a/net/l2tp/l2tp_netlink.c b/net/l2tp/l2tp_netlink.c
index 665cc74df5c5..fb3248ff8b48 100644
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -285,7 +285,7 @@ static int l2tp_nl_cmd_tunnel_delete(struct sk_buff *skb, 
struct genl_info *info
l2tp_tunnel_notify(_nl_family, info,
   tunnel, L2TP_CMD_TUNNEL_DELETE);
 
-   (void) l2tp_tunnel_delete(tunnel);
+   l2tp_tunnel_delete(tunnel);
 
 out:
return ret;
-- 
2.11.0

Re: [PATCH net-next v2 8/8] net: phy: meson-gxl: join the authors

[Andrew Lunn]

On Thu, Dec 07, 2017 at 03:27:15PM +0100, Jerome Brunet wrote:
> Following previous changes, join the other authors of this driver and
> take the blame with them

:-)

Reviewed-by: Andrew Lunn 

Andrew

Re: 4.14: WARNING: CPU: 4 PID: 2895 at block/blk-mq.c:1144 with virtio-blk (also 4.12 stable)

[Christian Borntraeger]

On 12/07/2017 12:29 AM, Christoph Hellwig wrote:
> On Wed, Dec 06, 2017 at 01:25:11PM +0100, Christian Borntraeger wrote:
> t > commit 11b2025c3326f7096ceb588c3117c7883850c068-> bad
>> blk-mq: create a blk_mq_ctx for each possible CPU
>> does not boot on DASD and 
>> commit 9c6ae239e01ae9a9f8657f05c55c4372e9fc8bcc-> good
>>genirq/affinity: assign vectors to all possible CPUs
>> does boot with DASD disks.
>>
>> Also adding Stefan Haberland if he has an idea why this fails on DASD and 
>> adding Martin (for the
>> s390 irq handling code).
> 
> That is interesting as it really isn't related to interrupts at all,
> it just ensures that possible CPUs are set in ->cpumask.
> 
> I guess we'd really want:
> 
> e005655c389e3d25bf3e43f71611ec12f3012de0
> "blk-mq: only select online CPUs in blk_mq_hctx_next_cpu"
> 
> before this commit, but it seems like the whole stack didn't work for
> your either.
> 
> I wonder if there is some weird thing about nr_cpu_ids in s390?

The problem starts as soon as NR_CPUS is larger than the number
of real CPUs.

Aquestions Wouldnt your change in blk_mq_hctx_next_cpu fail if there is more 
than 1 non-online cpu:

e.g. dont we need something like (whitespace and indent damaged)

@@ -1241,11 +1241,11 @@ static int blk_mq_hctx_next_cpu(struct blk_mq_hw_ctx 
*hctx)
if (--hctx->next_cpu_batch <= 0) {
int next_cpu;
 
+   do  {
next_cpu = cpumask_next(hctx->next_cpu, hctx->cpumask);
-   if (!cpu_online(next_cpu))
-   next_cpu = cpumask_next(next_cpu, hctx->cpumask);
if (next_cpu >= nr_cpu_ids)
next_cpu = cpumask_first(hctx->cpumask);
+   } while (!cpu_online(next_cpu));
 
hctx->next_cpu = next_cpu;
hctx->next_cpu_batch = BLK_MQ_CPU_WORK_BATCH;

it does not fix the issue, though (and it would be pretty inefficient for large 
NR_CPUS)

Re: [PATCH v2 04/11] staging: pi433: Rename enum optionOnOff in rf69_enum.h

[Dan Carpenter]

On Thu, Dec 07, 2017 at 12:17:32AM +0200, Marcus Wolf wrote:
> To be honest, I am a little bit astonished about that question. Don't you do
> a regression test after such a redesign? I would be a little bit afraid to
> offer such redesign without testing.

He probably doesn't have the hardware...  That's fine.  Most patches to
staging are like this.  We have a pretty good track record for rarely
introducing bugs.

This patchset is pretty easy to review with confidence because it's
mostly just renames so there are only a few bits to review by hand.
I've attached the perl script I use for reviewing renames and indent
changes.

regards,
dan carpenter
#!/usr/bin/perl

# This is a tool to help review variable rename patches. The goal is
# to strip out the automatic sed renames and the white space changes
# and leaves the interesting code changes.
#
# Example 1: A patch renames openInfo to open_info:
# cat diff | rename_review.pl openInfo open_info
#
# Example 2: A patch swaps the first two arguments to some_func():
# cat diff | rename_review.pl \
#-e 's/some_func\((.*?),(.*?),/some_func\($2, $1,/'
#
# Example 3: A patch removes the xkcd_ prefix from some but not all the
# variables.  Instead of trying to figure out which variables were renamed
# just remove the prefix from them all:
# cat diff | rename_review.pl -ea 's/xkcd_//g'
#
# Example 4: A patch renames 20 CamelCase variables.  To review this let's
# just ignore all case changes and all '_' chars.
# cat diff | rename_review -ea 'tr/[A-Z]/[a-z]/' -ea 's/_//g'
#
# The other arguments are:
# -nc removes comments
# -ns removes '\' chars if they are at the end of the line.

use strict;
use File::Temp qw/ :mktemp  /;

sub usage() {
print "usage: cat diff | $0 old new old new old new...\n";
print "   or: cat diff | $0 -e 's/old/new/g'\n";
print " -a : auto";
print " -e : execute on old lines\n";
print " -ea: execute on all lines\n";
print " -nc: no comments\n";
print " -nb: no unneeded braces\n";
print " -ns: no slashes at the end of a line\n";
print " -pull: for function pull.  deletes context.\n";
print " -r : NULL, bool";
exit(1);
}
my @subs;
my @strict_subs;
my @cmds;
my $strip_comments;
my $strip_braces;
my $strip_slashes;
my $pull_context;
my $auto;

sub filter($) {
my $line = shift();
my $old = 0;
if ($line =~ /^-/) {
$old = 1;
}
# remove the first char
$line =~ s/^[ +-]//;
if ($strip_comments) {
$line =~ s/\/\*.*?\*\///g;
$line =~ s/\/\/.*//;
}
foreach my $cmd (@cmds) {
if ($old || $cmd->[0] =~ /^-ea$/) {
eval "\$line =~ $cmd->[1]";
}
}
foreach my $sub (@subs) {
if ($old) {
$line =~ s/$sub->[0]/$sub->[1]/g;
}
}
foreach my $sub (@strict_subs) {
if ($old) {
$line =~ s/\b$sub->[0]\b/$sub->[1]/g;
}
}

# remove the newline so we can move curly braces here if we want.
$line =~ s/\n//;
return $line;
}

while (my $param1 = shift()) {
if ($param1 =~ /^-a$/) {
$auto = 1;
next;
}
if ($param1 =~ /^-nc$/) {
$strip_comments = 1;
next;
}
if ($param1 =~ /^-nb$/) {
$strip_braces = 1;
next;
}
if ($param1 =~ /^-ns$/) {
$strip_slashes = 1;
next;
}
if ($param1 =~ /^-pull$/) {
$pull_context = 1;
next;
}
my $param2 = shift();
if ($param2 =~ /^$/) {
usage();
}
if ($param1 =~ /^-e(a|)$/) {
push @cmds, [$param1, $param2];
next;
}
if ($param1 =~ /^-r$/) {
if ($param2 =~ /bool/) {
push @cmds, ["-e", "s/== true//"];
push @cmds, ["-e", "s/true ==//"];
push @cmds, ["-e", "s/([a-zA-Z\-\>\._]+) == false/!\$1/"];
next;
} elsif ($param2 =~ /NULL/) {
push @cmds, ["-e", "s/ != NULL//"];
push @cmds, ["-e", "s/([a-zA-Z\-\>\._0-9]+) == NULL/!\$1/"];
next;
} elsif ($param2 =~ /BIT/) {
push @cmds, ["-e", 's/1[uU]* *<< *(\d+)/BIT($1)/'];
push @cmds, ["-e", 's/\(1 *<< *(\w+)\)/BIT($1)/'];
push @cmds, ["-e", 's/\(BIT\((.*?)\)\)/BIT($1)/'];
next;
}
usage();
}

push @subs, [$param1, $param2];
}

my ($oldfh, $oldfile) = mkstemp("/tmp/oldX");
my ($newfh, $newfile) = mkstemp("/tmp/newX");

my @input = ;

# auto works on the observation that the - line comes before the + line when we
# rename variables.  Take the first - line.  Find the first + line.  Find the
# one word difference.  Test that the old word never occurs in the new text.
if ($auto) {
my %c_keywords = (  auto => 1,
break => 1,
case => 1,
char => 1,
const => 1,
continue => 1,
default => 1,
  

[tip:x86/urgent] x86/smpboot: Do not use smp_num_siblings in __max_logical_packages calculation

[tip-bot for Prarit Bhargava]

Commit-ID:  947134d9b00f342415af7eddd42a5fce7262a1b9
Gitweb: https://git.kernel.org/tip/947134d9b00f342415af7eddd42a5fce7262a1b9
Author: Prarit Bhargava 
AuthorDate: Mon, 4 Dec 2017 11:45:21 -0500
Committer:  Thomas Gleixner 
CommitDate: Thu, 7 Dec 2017 10:28:22 +0100

x86/smpboot: Do not use smp_num_siblings in __max_logical_packages calculation

Documentation/x86/topology.txt defines smp_num_siblings as "The number of
threads in a core".  Since commit bbb65d2d365e ("x86: use cpuid vector 0xb
when available for detecting cpu topology") smp_num_siblings is the
maximum number of threads in a core.  If Simultaneous MultiThreading
(SMT) is disabled on a system, smp_num_siblings is 2 and not 1 as
expected.

Use topology_max_smt_threads(), which contains the active numer of threads,
in the __max_logical_packages calculation.

On a single socket, single core, single thread system __max_smt_threads has
not been updated when the __max_logical_packages calculation happens, so its
zero which makes the package estimate fail. Initialize it to one, which is
the minimum number of threads on a core.

[ tglx: Folded the __max_smt_threads fix in ]

Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
Reported-by: Jakub Kicinski 
Signed-off-by: Prarit Bhargava 
Tested-by: Jakub Kicinski 
Cc: net...@vger.kernel.org
Cc: "net...@vger.kernel.org"
Cc: Clark Williams 
Link: https://lkml.kernel.org/r/20171204164521.17870-1-pra...@redhat.com
---
 arch/x86/kernel/smpboot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 05a97d5..35cb20994 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -106,7 +106,7 @@ EXPORT_SYMBOL(__max_logical_packages);
 static unsigned int logical_packages __read_mostly;
 
 /* Maximum number of SMT threads on any online core */
-int __max_smt_threads __read_mostly;
+int __read_mostly __max_smt_threads = 1;
 
 /* Flag to indicate if a complete sched domain rebuild is required */
 bool x86_topology_update;
@@ -1304,7 +1304,7 @@ void __init native_smp_cpus_done(unsigned int max_cpus)
 * Today neither Intel nor AMD support heterogenous systems so
 * extrapolate the boot cpu's data to all packages.
 */
-   ncpus = cpu_data(0).booted_cores * smp_num_siblings;
+   ncpus = cpu_data(0).booted_cores * topology_max_smt_threads();
__max_logical_packages = DIV_ROUND_UP(nr_cpu_ids, ncpus);
pr_info("Max logical packages: %u\n", __max_logical_packages);
 

[tip:x86/urgent] x86/boot/compressed/64: Detect and handle 5-level paging at boot-time

[tip-bot for Kirill A. Shutemov]

Commit-ID:  08529078d8d9adf689bf39cc38d53979a0869970
Gitweb: https://git.kernel.org/tip/08529078d8d9adf689bf39cc38d53979a0869970
Author: Kirill A. Shutemov 
AuthorDate: Mon, 4 Dec 2017 15:40:55 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 7 Dec 2017 10:34:39 +0100

x86/boot/compressed/64: Detect and handle 5-level paging at boot-time

Prerequisite for fixing the current problem of instantaneous reboots when a
5-level paging kernel is booted on 4-level paging hardware.

At the same time this change prepares the decompression code to boot-time
switching between 4- and 5-level paging.

[ tglx: Folded the GCC < 5 fix. ]

Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via 
CONFIG_X86_5LEVEL=y")
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Thomas Gleixner 
Cc: Andi Kleen 
Cc: sta...@vger.kernel.org
Cc: Andy Lutomirski 
Cc: linux...@kvack.org
Cc: Cyrill Gorcunov 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Link: 
https://lkml.kernel.org/r/20171204124059.63515-2-kirill.shute...@linux.intel.com
---
 arch/x86/boot/compressed/Makefile |  1 +
 arch/x86/boot/compressed/head_64.S| 16 
 arch/x86/boot/compressed/pgtable_64.c | 28 
 3 files changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 1e9c322..f25e153 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -80,6 +80,7 @@ vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
 ifdef CONFIG_X86_64
vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/pagetable.o
vmlinux-objs-y += $(obj)/mem_encrypt.o
+   vmlinux-objs-y += $(obj)/pgtable_64.o
 endif
 
 $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index 20919b4..fc313e2 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -305,10 +305,18 @@ ENTRY(startup_64)
leaqboot_stack_end(%rbx), %rsp
 
 #ifdef CONFIG_X86_5LEVEL
-   /* Check if 5-level paging has already enabled */
-   movq%cr4, %rax
-   testl   $X86_CR4_LA57, %eax
-   jnz lvl5
+   /*
+* Check if we need to enable 5-level paging.
+* RSI holds real mode data and need to be preserved across
+* a function call.
+*/
+   pushq   %rsi
+   calll5_paging_required
+   popq%rsi
+
+   /* If l5_paging_required() returned zero, we're done here. */
+   cmpq$0, %rax
+   je  lvl5
 
/*
 * At this point we are in long mode with 4-level paging enabled,
diff --git a/arch/x86/boot/compressed/pgtable_64.c 
b/arch/x86/boot/compressed/pgtable_64.c
new file mode 100644
index 000..b4469a3
--- /dev/null
+++ b/arch/x86/boot/compressed/pgtable_64.c
@@ -0,0 +1,28 @@
+#include 
+
+/*
+ * __force_order is used by special_insns.h asm code to force instruction
+ * serialization.
+ *
+ * It is not referenced from the code, but GCC < 5 with -fPIE would fail
+ * due to an undefined symbol. Define it to make these ancient GCCs work.
+ */
+unsigned long __force_order;
+
+int l5_paging_required(void)
+{
+   /* Check if leaf 7 is supported. */
+
+   if (native_cpuid_eax(0) < 7)
+   return 0;
+
+   /* Check if la57 is supported. */
+   if (!(native_cpuid_ecx(7) & (1 << (X86_FEATURE_LA57 & 31
+   return 0;
+
+   /* Check if 5-level paging has already been enabled. */
+   if (native_read_cr4() & X86_CR4_LA57)
+   return 0;
+
+   return 1;
+}

Re: [PATCH] mm: terminate shrink_slab loop if signal is pending

[Sergey Senozhatsky]

On (12/06/17 11:20), Suren Baghdasaryan wrote:
> Slab shrinkers can be quite time consuming and when signal
> is pending they can delay handling of the signal. If fatal
> signal is pending there is no point in shrinking that process
> since it will be killed anyway. This change checks for pending
> fatal signals inside shrink_slab loop and if one is detected
> terminates this loop early.
> 
> Signed-off-by: Suren Baghdasaryan 
> ---
>  mm/vmscan.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index c02c850ea349..69296528ff33 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -486,6 +486,13 @@ static unsigned long shrink_slab(gfp_t gfp_mask, int nid,
>   .memcg = memcg,
>   };
>  
> + /*
> +  * We are about to die and free our memory.
> +  * Stop shrinking which might delay signal handling.
> +  */
> + if (unlikely(fatal_signal_pending(current))

-   if (unlikely(fatal_signal_pending(current))
+   if (unlikely(fatal_signal_pending(current)))

-ss

Re: [patch 43/60] x86/fixmap: Add debugstore entries to cpu_entry_area

[Borislav Petkov]

On Mon, Dec 04, 2017 at 03:07:49PM +0100, Thomas Gleixner wrote:
> From: Thomas Gleixner 
> 
> The intel PEBS/BTS debug store is a design trainwreck as is expects virtual
> addresses which must be visible in any execution context.

Sure, what can possibly go wrong?! :-\

> So it is required to make these mappings visible to user space when kernel
> page table isolation is active.
> 
> Provide enough room for the buffer mappings in the cpu_entry_area so the
> buffers are available in the user space visible fixmap.
> 
> At the point where the kernel side fixmap is populated there is no buffer
> available yet, but the kernel PMD must be populated. To achieve this set
> the fixmap entries for these buffers to non present.
> 
> Signed-off-by: Thomas Gleixner 
> ---
>  arch/x86/events/intel/ds.c  |5 +++--
>  arch/x86/events/perf_event.h|   21 ++---
>  arch/x86/include/asm/fixmap.h   |   13 +
>  arch/x86/include/asm/intel_ds.h |   36 
>  arch/x86/kernel/cpu/common.c|   21 +
>  5 files changed, 75 insertions(+), 21 deletions(-)

...

> @@ -592,6 +603,16 @@ static void __init setup_cpu_entry_area(
>   __set_fixmap(get_cpu_entry_area_index(cpu, entry_trampoline),
>__pa_symbol(_entry_trampoline), PAGE_KERNEL_RX);
>  #endif
> +
> +#ifdef CONFIG_CPU_SUP_INTEL
> + BUILD_BUG_ON(sizeof(struct debug_store) % PAGE_SIZE != 0);
> + set_percpu_fixmap_pages(get_cpu_entry_area_index(cpu, cpu_debug_store),
> + _cpu(cpu_debug_store, cpu),
> + sizeof(struct debug_store) / PAGE_SIZE,
> + PAGE_KERNEL);
> + set_percpu_fixmap_ptes(get_cpu_entry_area_index(cpu, cpu_debug_buffers),
> +sizeof(struct debug_store_buffers) / PAGE_SIZE);
> +#endif

I guess we can do that additionally, so as not to setup the mappings on
distro kernels running !INTEL:

---
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 1364a8f378f8..5cfb68090a24 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -606,12 +606,16 @@ static void __init setup_cpu_entry_area(int cpu)
 
 #ifdef CONFIG_CPU_SUP_INTEL
BUILD_BUG_ON(sizeof(struct debug_store) % PAGE_SIZE != 0);
-   set_percpu_fixmap_pages(get_cpu_entry_area_index(cpu, cpu_debug_store),
-   _cpu(cpu_debug_store, cpu),
-   sizeof(struct debug_store) / PAGE_SIZE,
-   PAGE_KERNEL);
-   set_percpu_fixmap_ptes(get_cpu_entry_area_index(cpu, cpu_debug_buffers),
-  sizeof(struct debug_store_buffers) / PAGE_SIZE);
+
+   if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) {
+   set_percpu_fixmap_pages(get_cpu_entry_area_index(cpu, 
cpu_debug_store),
+   _cpu(cpu_debug_store, cpu),
+   sizeof(struct debug_store) / PAGE_SIZE,
+   PAGE_KERNEL);
+
+   set_percpu_fixmap_ptes(get_cpu_entry_area_index(cpu, 
cpu_debug_buffers),
+  sizeof(struct debug_store_buffers) / 
PAGE_SIZE);
+   }
 #endif
 }

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH][next] HID: quirks: make array hid_quirks static

[Jiri Kosina]

On Mon, 4 Dec 2017, Colin King wrote:

> From: Colin Ian King 
> 
> Array hid_quirks is local to the source and does not need to be in
> global scope, so make it static.
> 
> Cleans up sparse warning:
> drivers/hid/hid-quirks.c:29:28: warning: symbol 'hid_quirks' was not
> declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

Applied to for-4.16/hid-quirks-cleanup/_base. Thanks,

-- 
Jiri Kosina
SUSE Labs

[PATCH RESEND 0/4] i2c: mpc: Clean up clock selection

[Arseny Solokha]

This series cleans up I2C clock selection for Freescale/NXP MPC SoCs during
the controller initialization for cases when clock settings are not to be
preserved from the bootloader.

Patch 1/4 fixes division by zero which happens during controller
initialization when (1) clock frequency is not specified in the Device
Tree, (2) preservation of clock settings from the bootloader is not
requested, and (3) the clock prescaler (which may actually depend
on the POR configuration) is not explicitly specified. It simply moves
obtaining the prescaler value before the clock computation.

Patch 2/4 unifies obtaining the prescaler value for MPC8544 with other
SoCs. It moves the relevant code to the helper function introduced
in commit 8ce795cb0c6b ("i2c: mpc: assign the correct prescaler from SVR")
and also adds handling of MPC8533 is similar to MPC8544 in this regard.

Patch 3/4 fixes checking the relevant bit in a controller's register used
for selecting the prescaler value for MPC8533 and MPC8544.

Patch 4/4 removes the facility for setting the clock prescaler value
at compile time. This facility is not used in the majority of cases. Getting
the prescaler value at run time currently covers more SoCs. Hardcoding it
is also wrong for some SoCs as it can be configured on board during POR.

This series is an exact copy of [1] which has received no feedback so far.

[1] https://marc.info/?l=linux-i2c=151030076114573=2

Arseny Solokha (4):
  i2c: mpc: get MPC8xxx I2C clock prescaler before using it in
calculations
  i2c: mpc: unify obtaining the MPC8533/44 I2C clock prescaler w/
MPC8xxx
  i2c: mpc: fix PORDEVSR2 mask for MPC8533/44
  i2c: mpc: always determine I2C clock prescaler at runtime

 drivers/i2c/busses/i2c-mpc.c | 72 ++--
 1 file changed, 30 insertions(+), 42 deletions(-)

-- 
2.15.1

[PATCH RESEND 2/4] i2c: mpc: unify obtaining the MPC8533/44 I2C clock prescaler w/ MPC8xxx

[Arseny Solokha]

Commit 8ce795cb0c6b ("i2c: mpc: assign the correct prescaler from SVR")
introduced the common helper function for obtaining the actual clock
prescaler value for MPC85xx. However, getting the prescaler for MPC8544
which depends on the SEC frequency ratio on this platform, has been always
performed separately based on the corresponding Device Tree configuration.

Move special handling of MPC8544 into that common helper. Make it dependent
on the SoC version and not on Device Tree compatible node, as is the case
with all other SoCs. Handle MPC8533 the same way which is similar
to MPC8544 in this regard, according to AN2919 "Determining the I2C
Frequency Divider Ratio for SCL".

Signed-off-by: Arseny Solokha 
---
 drivers/i2c/busses/i2c-mpc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 6ad87555f71e..648a5afded64 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -350,7 +350,11 @@ static u32 mpc_i2c_get_sec_cfg_8xxx(void)
 
 static u32 mpc_i2c_get_prescaler_8xxx(void)
 {
-   /* mpc83xx and mpc82xx all have prescaler 1 */
+   /*
+* According to the AN2919 all MPC824x have prescaler 1, while MPC83xx
+* may have prescaler 1, 2, or 3, depending on the power-on
+* configuration.
+*/
u32 prescaler = 1;
 
/* mpc85xx */
@@ -367,6 +371,10 @@ static u32 mpc_i2c_get_prescaler_8xxx(void)
|| (SVR_SOC_VER(svr) == SVR_8610))
/* the above 85xx SoCs have prescaler 1 */
prescaler = 1;
+   else if ((SVR_SOC_VER(svr) == SVR_8533)
+   || (SVR_SOC_VER(svr) == SVR_8544))
+   /* the above 85xx SoCs have prescaler 3 or 2 */
+   prescaler = mpc_i2c_get_sec_cfg_8xxx() ? 3 : 2;
else
/* all the other 85xx have prescaler 2 */
prescaler = 2;
@@ -383,8 +391,6 @@ static int mpc_i2c_get_fdr_8xxx(struct device_node *node, 
u32 clock,
int i;
 
/* Determine proper divider value */
-   if (of_device_is_compatible(node, "fsl,mpc8544-i2c"))
-   prescaler = mpc_i2c_get_sec_cfg_8xxx() ? 3 : 2;
if (!prescaler)
prescaler = mpc_i2c_get_prescaler_8xxx();
 
-- 
2.15.1

[PATCH v6 0/5] scsi: ufs: add ufs driver code for Hisilicon Hi3660 SoC

[Li Wei]

This patchset adds driver support for UFS for Hi3660 SoC. It is verified on 
HiKey960 board.

Li Wei (5):
  scsi: ufs: add Hisilicon ufs driver code
  dt-bindings: scsi: ufs: add document for hisi-ufs
  arm64: dts: add ufs dts node
  arm64: defconfig: enable configs for Hisilicon ufs
  arm64: defconfig: enable f2fs and squashfs

 Documentation/devicetree/bindings/ufs/ufs-hisi.txt |  38 ++
 arch/arm64/boot/dts/hisilicon/hi3660.dtsi  |  20 +
 arch/arm64/configs/defconfig   |  11 +
 drivers/scsi/ufs/Kconfig   |   9 +
 drivers/scsi/ufs/Makefile  |   1 +
 drivers/scsi/ufs/ufs-hisi.c| 624 +
 drivers/scsi/ufs/ufs-hisi.h| 122 
 7 files changed, 825 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
 create mode 100644 drivers/scsi/ufs/ufs-hisi.c
 create mode 100644 drivers/scsi/ufs/ufs-hisi.h

-- 
2.15.0

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Gary Lin]

On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> 
> * Gary Lin  wrote:
> 
> > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > 
> > > * Gary Lin  wrote:
> > > 
> > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > 
> > > > > * Gary Lin  wrote:
> > > > > 
> > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > >
> > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > designed to
> > > > > > > > prevent the user from loading an insecure kernel accidentally. 
> > > > > > > > The
> > > > > > > > bootloader maintains a list of security versions corresponding 
> > > > > > > > to
> > > > > > > > different distributions. After fixing a critical vulnerability, 
> > > > > > > > the
> > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > bootloader
> > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > kernel
> > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > prompt
> > > > > > > > to notify the user the potential risk.
> > > > > > > 
> > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > version and
> > > > > > > that it automatically updated on boot, what happens if that kernel
> > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > critical functionality?  At that point, the user's machine would 
> > > > > > > be in
> > > > > > > a state where the higher security version is enforced but the only
> > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > older
> > > > > > > SV kernel boot physically at the machine?
> > > > > > > 
> > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > 
> > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > kernel
> > > > > > manually anyway, and there will be an option in the warning prompt 
> > > > > > to
> > > > > > lower SV.
> > > > > 
> > > > > And what if the firmware does not support a lowering of the SV?
> > > > > 
> > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > provides the interface to the storage, i.e. non-volatile flash.
> > > 
> > > What about systems where the bootloader is part of the system and users 
> > > only have 
> > > the ability to provide kernel images, but no ability to change the boot 
> > > loader?
> > 
> > It depends on how the bootloader works. If the system uses my
> > implementation of shim loader, it surely has the ability to lower SV,
> > but it requires physical access on purpose.
> 
> And that's my problem: if in practice the bootloader is 'part of the system', 
> is 
> signed and is updated like the firmware, then putting a "Security Version" 
> into 
> the kernel image and architecting a boot protocol for a monotonic method for 
> the 
> bootloader to restrict the loading of kernel images is an obviously bad idea.
> 
Even though the bootloader doesn't actually block the booting?

If the bootloader loads a kernel with lower SV, by default, the warning
prompt lasts for 30 seconds, and the system continues booting if the
user doesn't intervene. For the paranoid user, a variable can be set to
make the bootloader wait forever. Is it acceptable?

Thanks,

Gary Lin

Re: [PATCH v2 0/4] i2c: pca-platform: additional improvements

[Wolfram Sang]

On Sun, Oct 29, 2017 at 06:29:18PM +0100, Wolfram Sang wrote:
> On Wed, Jul 05, 2017 at 10:13:54PM +1200, Chris Packham wrote:
> > This series addresses some of the points identified by Andy. The series is
> > based on top of i2c/for-next. 2 of the patches from v1 have already been
> > applied so I've dropped them from this version.
> > 
> > I have compile tested patch 1/1 but I don't have access to sh hardware
> > to actually test the changes on.
> > 
> > Chris Packham (4):
> >   sh: sh7785lcr: add GPIO lookup table for i2c controller reset
> >   i2c: pca-platform: unconditionally use devm_gpiod_get_optional
> >   i2c: pca-platform: use device_property_read_u32
> >   i2c: pca-platform: drop gpio from platform data
> > 
> >  arch/blackfin/mach-bf561/boards/acvilon.c |  1 -
> >  arch/sh/boards/board-sh7785lcr.c  | 11 +-
> >  drivers/i2c/busses/i2c-pca-platform.c | 34 
> > +--
> >  include/linux/i2c-pca-platform.h  |  3 ---
> >  4 files changed, 20 insertions(+), 29 deletions(-)
> 
> Series looks good to me, too. I'd need ACKs from the SH maintainers,
> though. Technically, from Blackfin maintainers as well. But I haven't
> heard from them in months, so I could go without that.

Adding Rich Felker to CC...



signature.asc
Description: PGP signature

Re: [patch V4 02/11] LICENSES: Add the GPL 2.0 license

[Jonas Oberg]

On Mon, Dec 04, 2017 at 10:19:29PM +0100, Thomas Gleixner wrote:
> Add the full text of the GPL 2.0 license to the LICENSES directory.  It was
> copied directly from the COPYING file in the kernel source tree as it
> differs from the public available version of the license in various places
> including the FSF.
> 
> Philippe did some research on the GPL2.0 history:
> 
>   There is NO trustworthy version of an official GPL 2.0 text: the FSF
>   official texts are all fubar (if only in small and subtle ways). The FSF
>   texts should be authoritative, but then which one? They published more
>   GPL 2.0 versions than most. So we would be hard pressed to blame SPDX or
>   the OSI for having their own minor variant.
> 
>   Then in digging further, I found the ONE true original GPL with a file
>   time stamp on June 2 1991, 01:50 (AM?, PM? unknown time zone?)  ! in an
>   old GCC archive.
> 
>   For the posterity and everyone's enjoyment I have built a git history
>   of GPL 2.0 Mark1 to Mark6
> 
>   See https://github.com/pombredanne/gpl-history/commits/master/COPYING
> 
>   I also added a shorter history of the Linux COPYING text. The first
>   version in Linus's git tree is based on the very fine and well tuned GPL
>   2 Mark4, the first fully Y2K compliant version of the GPL 2, as you can
>   see from the diffs with the former Mark3: that was dangerously stuck in
>   the last century.
> 
>   The current version in is based on a rare GPL 2.0 Mark5.1 aka "Franklin
>   St", that I do not have in my history yet and spells "Franklin St."
>   rather than "Franklin Street."  Therefore there is likely another GPL 2.0
>   version between Mark4 and Mark5 that I have yet to find and may not have
>   been caught by the archive.org spiders. Here help and patches welcomed:
>   this is likely an important missing link.
> 
>   Further information about this archaelogical research;
>   
>   
> http://lkml.kernel.org/r/CAOFm3uEzRMf261+O-Nm+9HDoEn9RbFjH=5j9i1c2ggmug2g...@mail.gmail.com
> 
> Add the required tags for reference and tooling.
> 
> Signed-off-by: Thomas Gleixner 

Reviewed-by: Jonas Oberg 

-- 
Jonas Öberg
Executive Director

FSFE e.V. - keeping the power of technology in your hands. Your
support enables our work, please join us today http://fsfe.org/join

Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support

[Maxime Ripard]

Hi,

On Thu, Dec 07, 2017 at 11:14:27AM +0100, Philippe Ombredanne wrote:
> On Tue, Dec 5, 2017 at 4:10 PM, Maxime Ripard
>  wrote:
> > The TCON supports the LVDS interface to output to a panel or a bridge.
> > Let's add support for it.
> >
> > Signed-off-by: Maxime Ripard 
> []
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sun4i/sun4i_lvds.c
> > @@ -0,0 +1,183 @@
> > +/*
> > + * Copyright (C) 2015 NextThing Co
> > + * Copyright (C) 2015-2017 Free Electrons
> > + *
> > + * Maxime Ripard 
> > + *
> > + * 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.
> > + */
> 
> Would you consider using the new SPDX ids instead of this fine legalese?
> e.g. this as the top line:
> 
> // SPDX-License-Identifier: GPL-2.0+

I did, and then forgot about it.

This will be in my next iteration, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

[PATCH v3] leds: trigger: Introduce a NETDEV trigger

[Ben Whitten]

From: Ben Whitten 

This commit introduces a NETDEV trigger for named device
activity. Available triggers are link, rx, and tx.

Signed-off-by: Ben Whitten 

---
Changes in v3:
Cancel the software blink prior to a oneshot re-queue
Changes in v2:
Sort includes and redate documentation
Correct licence
Remove macro and replace with generic function using enums
Convert blink logic in stats work to use led_blink_oneshot
Uses configured brightness instead of FULL
---
 .../ABI/testing/sysfs-class-led-trigger-netdev |  45 ++
 drivers/leds/trigger/Kconfig   |   7 +
 drivers/leds/trigger/Makefile  |   1 +
 drivers/leds/trigger/ledtrig-netdev.c  | 503 +
 4 files changed, 556 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-led-trigger-netdev
 create mode 100644 drivers/leds/trigger/ledtrig-netdev.c

diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev 
b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
new file mode 100644
index 000..451af6d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
@@ -0,0 +1,45 @@
+What:  /sys/class/leds//device_name
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Specifies the network device name to monitor.
+
+What:  /sys/class/leds//interval
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Specifies the duration of the LED blink in milliseconds.
+   Defaults to 50 ms.
+
+What:  /sys/class/leds//link
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal the link state of the named network device.
+   If set to 0 (default), the LED's normal state is off.
+   If set to 1, the LED's normal state reflects the link state
+   of the named network device.
+   Setting this value also immediately changes the LED state.
+
+What:  /sys/class/leds//tx
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal transmission of data on the named network device.
+   If set to 0 (default), the LED will not blink on transmission.
+   If set to 1, the LED will blink for the milliseconds specified
+   in interval to signal transmission.
+
+What:  /sys/class/leds//rx
+Date:  Dec 2017
+KernelVersion: 4.16
+Contact:   linux-l...@vger.kernel.org
+Description:
+   Signal reception of data on the named network device.
+   If set to 0 (default), the LED will not blink on reception.
+   If set to 1, the LED will blink for the milliseconds specified
+   in interval to signal reception.
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index 3f9ddb9..4ec1853 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -126,4 +126,11 @@ config LEDS_TRIGGER_PANIC
  a different trigger.
  If unsure, say Y.
 
+config LEDS_TRIGGER_NETDEV
+   tristate "LED Netdev Trigger"
+   depends on NET && LEDS_TRIGGERS
+   help
+ This allows LEDs to be controlled by network device activity.
+ If unsure, say Y.
+
 endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 9f2e868..59e163d 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
 obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT)   += ledtrig-transient.o
 obj-$(CONFIG_LEDS_TRIGGER_CAMERA)  += ledtrig-camera.o
 obj-$(CONFIG_LEDS_TRIGGER_PANIC)   += ledtrig-panic.o
+obj-$(CONFIG_LEDS_TRIGGER_NETDEV)  += ledtrig-netdev.o
diff --git a/drivers/leds/trigger/ledtrig-netdev.c 
b/drivers/leds/trigger/ledtrig-netdev.c
new file mode 100644
index 000..fb36b08
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-netdev.c
@@ -0,0 +1,503 @@
+/*
+ * LED Kernel Netdev Trigger
+ *
+ * Toggles the LED to reflect the link and traffic state of a named net device
+ *
+ * Copyright 2017 Ben Whitten 
+ *
+ * Copyright 2007 Oliver Jowett 
+ *
+ * Derived from ledtrig-timer.c which is:
+ *  Copyright 2005-2006 Openedhand Ltd.
+ *  Author: Richard Purdie 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "../leds.h"
+
+/*
+ * Configurable sysfs 

[PATCH v2] iio: adc: ina2xx: Make calibration register value fixed

[Maciej Purski]

Calibration register is used for calculating current register in
hardware according to datasheet:
current = shunt_volt * calib_register / 2048 (ina 226)
current = shunt_volt * calib_register / 4096 (ina 219)

Fix calib_register value to 2048 for ina226 and 4096 for ina 219 in
order to avoid truncation error and provide best precision allowed
by shunt_voltage measurement. Make current scale value follow changes
of shunt_resistor from sysfs as calib_register value is now fixed.

Power_lsb value should also follow shunt_resistor changes as stated in
datasheet:
power_lsb = 25 * current_lsb (ina 226)
power_lsb = 20 * current_lsb (ina 219)

This is a part of the patchset: https://lkml.org/lkml/2017/11/22/394

Signed-off-by: Maciej Purski 

---
Changes in v2:
- rebase on top of the latest next
- remove a redundant variable - power_lsb_uW
- fix comments
---
 drivers/iio/adc/ina2xx-adc.c | 58 +++-
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/drivers/iio/adc/ina2xx-adc.c b/drivers/iio/adc/ina2xx-adc.c
index ddf8781..3e4972f 100644
--- a/drivers/iio/adc/ina2xx-adc.c
+++ b/drivers/iio/adc/ina2xx-adc.c
@@ -124,11 +124,11 @@ enum ina2xx_ids { ina219, ina226 };
 
 struct ina2xx_config {
u16 config_default;
-   int calibration_factor;
+   int calibration_value;
int shunt_voltage_lsb;  /* nV */
int bus_voltage_shift;  /* position of lsb */
int bus_voltage_lsb;/* uV */
-   int power_lsb;  /* uW */
+   int power_lsb_factor;
enum ina2xx_ids chip_id;
 };
 
@@ -138,6 +138,7 @@ struct ina2xx_chip_info {
const struct ina2xx_config *config;
struct mutex state_lock;
unsigned int shunt_resistor_uohm;
+   unsigned int current_lsb_uA;
int avg;
int int_time_vbus; /* Bus voltage integration time uS */
int int_time_vshunt; /* Shunt voltage integration time uS */
@@ -149,20 +150,20 @@ struct ina2xx_chip_info {
 static const struct ina2xx_config ina2xx_config[] = {
[ina219] = {
.config_default = INA219_CONFIG_DEFAULT,
-   .calibration_factor = 4096,
+   .calibration_value = 4096,
.shunt_voltage_lsb = 1,
.bus_voltage_shift = INA219_BUS_VOLTAGE_SHIFT,
.bus_voltage_lsb = 4000,
-   .power_lsb = 2,
+   .power_lsb_factor = 20,
.chip_id = ina219,
},
[ina226] = {
.config_default = INA226_CONFIG_DEFAULT,
-   .calibration_factor = 512,
+   .calibration_value = 2048,
.shunt_voltage_lsb = 2500,
.bus_voltage_shift = 0,
.bus_voltage_lsb = 1250,
-   .power_lsb = 25000,
+   .power_lsb_factor = 25,
.chip_id = ina226,
},
 };
@@ -229,14 +230,16 @@ static int ina2xx_read_raw(struct iio_dev *indio_dev,
 
case INA2XX_POWER:
/* processed (mW) = raw*lsb (uW) / 1000 */
-   *val = chip->config->power_lsb;
+   *val = chip->config->power_lsb_factor *
+  chip->current_lsb_uA;
*val2 = 1000;
return IIO_VAL_FRACTIONAL;
 
case INA2XX_CURRENT:
-   /* processed (mA) = raw (mA) */
-   *val = 1;
-   return IIO_VAL_INT;
+   /* processed (mA) = raw*lsb (uA) / 1000 */
+   *val = chip->current_lsb_uA;
+   *val2 = 1000;
+   return IIO_VAL_FRACTIONAL;
}
 
case IIO_CHAN_INFO_HARDWAREGAIN:
@@ -541,28 +544,34 @@ static ssize_t ina2xx_allow_async_readout_store(struct 
device *dev,
 }
 
 /*
- * Set current LSB to 1mA, shunt is in uOhms
- * (equation 13 in datasheet). We hardcode a Current_LSB
- * of 1.0 x10-3. The only remaining parameter is RShunt.
- * There is no need to expose the CALIBRATION register
- * to the user for now. But we need to reset this register
- * if the user updates RShunt after driver init, e.g upon
- * reading an EEPROM/Probe-type value.
+ * Calibration register is set to the best value, which eliminates
+ * truncation errors on calculating current register in hardware.
+ * According to datasheet (INA 226: eq. 3, INA219: eq. 4) the best values
+ * are 2048 for ina226 and 4096 for ina219. They are hardcoded as
+ * calibration_value.
  */
 static int ina2xx_set_calibration(struct ina2xx_chip_info *chip)
 {
-   u16 regval = DIV_ROUND_CLOSEST(chip->config->calibration_factor,
-  chip->shunt_resistor_uohm);
-
-   return regmap_write(chip->regmap, INA2XX_CALIBRATION, regval);
+   return regmap_write(chip->regmap, INA2XX_CALIBRATION,
+   chip->config->calibration_value);
 }
 

Re: [PATCH v2 16/19] ASoC: tlv320aic31xx: Add short circuit detection support

[Mark Brown]

On Wed, Dec 06, 2017 at 02:22:39PM -0600, Andrew F. Davis wrote:
> On 12/01/2017 09:32 AM, Andrew F. Davis wrote:

> >> This will report the interrupt as handled even if we didn't see an
> >> interrupt we understand which will break shared interrupt lines.  At the
> >> very least we should log other interrupt sources numerically.

> > Okay, I think I can make that work by checking if no bits are set in the
> > interrupt regs and returning early if not, IRQ_NONE.

> This turned out to be more difficult than I expected, plus if I do
> handle an interrupt it doesn't mean the other device did not right? So
> this wouldn't fix shared lines as far as I can tell, but I don't
> register it as shared so this should be fine.

It'll mean that we don't offer the interrupt to anything else sharing
the line.

> As for your other suggestion of "log other interrupt sources
> numerically", could you explain this or point to an example of what you
> mean?

Just print out the bits that were set.


signature.asc
Description: PGP signature

Re: [PATCH 1/2] mm: introduce MAP_FIXED_SAFE

[Pavel Machek]

Hi!

> MAP_FIXED is used quite often to enforce mapping at the particular
> range. The main problem of this flag is, however, that it is inherently
> dangerous because it unmaps existing mappings covered by the requested
> range. This can cause silent memory corruptions. Some of them even with
> serious security implications. While the current semantic might be
> really desiderable in many cases there are others which would want to
> enforce the given range but rather see a failure than a silent memory
> corruption on a clashing range. Please note that there is no guarantee
> that a given range is obeyed by the mmap even when it is free - e.g.
> arch specific code is allowed to apply an alignment.
> 
> Introduce a new MAP_FIXED_SAFE flag for mmap to achieve this behavior.
> It has the same semantic as MAP_FIXED wrt. the given address request

Could we get some better name? Functionality seems reasonable, but
_SAFE suffix does not really explain what is going on to the user.

MAP_ADD_FIXED ?

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH v1 1/5] siox: new driver framework for eckelmann SIOX

[Uwe Kleine-König]

SIOX is a bus system invented at Eckelmann AG to control their building
management and refrigeration systems. Traditionally the bus was
implemented on custom microcontrollers, today Linux based machines are
in use, too.

The topology on a SIOX bus looks as follows:

  ,--->--DCLK-->---+--.
  ^v  v
 ,.,--.   ,--
 |||   ,--.   |   |
 ||--->--DOUT-->---|->-|shift register|->-|--->---|
 |||   `--'   |   |
 | master ||device|   |  device
 |||   ,--.   |   |
 ||---<--DIN---<---|-<-|shift register|-<-|---<---|
 |||   `--'   |   |
 `'`--'   `--
  v^  ^
  `--DLD---+--'

There are two control lines (DCLK and DLD) driven from the bus master to
all devices in parallel and two daisy chained data lines, one for input
and one for output. DCLK is the clock to shift both chains by a single
bit. On an edge of DLD the devices latch both their input and output
shift registers.

This patch adds a framework for this bus type.

Acked-by: Gavin Schenk 
Signed-off-by: Uwe Kleine-König 
---
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/siox/Kconfig |   9 +
 drivers/siox/Makefile|   1 +
 drivers/siox/siox-core.c | 924 +++
 drivers/siox/siox.h  |  49 +++
 include/linux/siox.h |  77 
 7 files changed, 1063 insertions(+)
 create mode 100644 drivers/siox/Kconfig
 create mode 100644 drivers/siox/Makefile
 create mode 100644 drivers/siox/siox-core.c
 create mode 100644 drivers/siox/siox.h
 create mode 100644 include/linux/siox.h

diff --git a/drivers/Kconfig b/drivers/Kconfig
index 152744c5ef0f..5458b623c00c 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -211,4 +211,6 @@ source "drivers/mux/Kconfig"
 
 source "drivers/opp/Kconfig"
 
+source "drivers/siox/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 1d034b680431..c90f8acd0fd1 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -183,3 +183,4 @@ obj-$(CONFIG_FPGA)  += fpga/
 obj-$(CONFIG_FSI)  += fsi/
 obj-$(CONFIG_TEE)  += tee/
 obj-$(CONFIG_MULTIPLEXER)  += mux/
+obj-$(CONFIG_SIOX) += siox/
diff --git a/drivers/siox/Kconfig b/drivers/siox/Kconfig
new file mode 100644
index ..bd24d9b50dc6
--- /dev/null
+++ b/drivers/siox/Kconfig
@@ -0,0 +1,9 @@
+menuconfig SIOX
+   tristate "Eckelmann SIOX Support"
+   help
+ SIOX stands for Serial Input Output eXtension and is a synchronous
+ bus system invented by Eckelmann AG. It is used in their control and
+ remote monitoring systems for commercial and industrial refrigeration
+ to drive additional I/O units.
+
+ Unless you know better, it is probably safe to say "no" here.
diff --git a/drivers/siox/Makefile b/drivers/siox/Makefile
new file mode 100644
index ..d55cb5e08868
--- /dev/null
+++ b/drivers/siox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SIOX) += siox-core.o
diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
new file mode 100644
index ..8578972ba18b
--- /dev/null
+++ b/drivers/siox/siox-core.c
@@ -0,0 +1,924 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015-2017 Pengutronix, Uwe Kleine-König 

+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "siox.h"
+
+/*
+ * The lowest bit in the SIOX status word signals if the in-device watchdog is
+ * ok. If the bit is set, the device is functional.
+ *
+ * On writing the watchdog timer is reset when this bit toggles.
+ */
+#define SIOX_STATUS_WDG0x01
+
+/*
+ * Bits 1 to 3 of the status word read as the bitwise negation of what was
+ * clocked in before. The value clocked in is changed in each cycle and so
+ * allows to detect transmit/receive problems.
+ */
+#define SIOX_STATUS_COUNTER0x0e
+
+/*
+ * Each Siox-Device has a 4 bit type number that is neither 0 nor 15. This is
+ * available in the upper nibble of the read status.
+ *
+ * On write these bits are DC.
+ */
+#define SIOX_STATUS_TYPE   0xf0
+
+static bool siox_is_registered;
+
+static void siox_master_lock(struct siox_master *smaster)
+{
+   mutex_lock(>lock);
+}
+
+static void siox_master_unlock(struct siox_master *smaster)
+{
+   mutex_unlock(>lock);
+}
+
+static inline u8 siox_status_clean(u8 status_read, u8 status_written)
+{
+   /*
+* bits 3:1 of status sample the respective bit in 

[PATCH v1 5/5] MAINTAINERS: Add entry for SIOX

[Uwe Kleine-König]

Maintenance is split between Gavin who works for Eckelmann and so has
the functional authority, knows the background and history of this bus
system and me who designed most of the actual code with the old
microcontroller code as reference.

Acked-by: Gavin Schenk 
Signed-off-by: Uwe Kleine-König 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..303999fa964c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12449,6 +12449,14 @@ F: lib/siphash.c
 F: lib/test_siphash.c
 F: include/linux/siphash.h
 
+SIOX
+M: Gavin Schenk 
+M: Uwe Kleine-König 
+S: Supported
+F: drivers/siox/*
+F: drivers/gpio/gpio-siox.c
+F: include/trace/events/siox.h
+
 SIS 190 ETHERNET DRIVER
 M: Francois Romieu 
 L: net...@vger.kernel.org
-- 
2.11.0

[PATCH v1 2/5] siox: add support for tracing

[Uwe Kleine-König]

Implement tracing for SIOX. There are events for the data that is
written to the bus and for data being read from it.

Acked-by: Gavin Schenk 
Signed-off-by: Uwe Kleine-König 
---
 drivers/siox/siox-core.c| 13 +
 include/trace/events/siox.h | 66 +
 2 files changed, 79 insertions(+)
 create mode 100644 include/trace/events/siox.h

diff --git a/drivers/siox/siox-core.c b/drivers/siox/siox-core.c
index 8578972ba18b..1a6383df9f32 100644
--- a/drivers/siox/siox-core.c
+++ b/drivers/siox/siox-core.c
@@ -33,6 +33,9 @@
  */
 #define SIOX_STATUS_TYPE   0xf0
 
+#define CREATE_TRACE_POINTS
+#include 
+
 static bool siox_is_registered;
 
 static void siox_master_lock(struct siox_master *smaster)
@@ -126,6 +129,7 @@ static void siox_poll(struct siox_master *smaster)
 {
struct siox_device *sdevice;
size_t i = smaster->setbuf_len;
+   unsigned int devno = 0;
int unsync_error = 0;
 
smaster->last_poll = jiffies;
@@ -172,9 +176,14 @@ static void siox_poll(struct siox_master *smaster)
sdevice->status_written &= ~SIOX_STATUS_WDG;
 
smaster->buf[i] = sdevice->status_written;
+
+   trace_siox_set_data(smaster, sdevice, devno, i);
+
+   devno++;
}
 
WARN_ON(i);
+   WARN_ON(devno != smaster->num_devices);
 
smaster->pushpull(smaster, smaster->setbuf_len, smaster->buf,
  smaster->getbuf_len,
@@ -183,6 +192,7 @@ static void siox_poll(struct siox_master *smaster)
unsync_error = 0;
 
/* interpret data pulled in from devices in buf[setbuf_len..] */
+   devno = 0;
i = smaster->setbuf_len;
list_for_each_entry(sdevice, >devices, node) {
struct siox_driver *sdriver =
@@ -257,10 +267,13 @@ static void siox_poll(struct siox_master *smaster)
sdevice->status_written_lastcycle = sdevice->status_written;
sdevice->connected = connected;
 
+   trace_siox_get_data(smaster, sdevice, devno, status_clean, i);
+
/* only give data read to driver if the device is connected */
if (sdriver && connected)
sdriver->get_data(sdevice, >buf[i]);
 
+   devno++;
i += sdevice->outbytes;
}
 }
diff --git a/include/trace/events/siox.h b/include/trace/events/siox.h
new file mode 100644
index ..6ab0b2cc37fe
--- /dev/null
+++ b/include/trace/events/siox.h
@@ -0,0 +1,66 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM siox
+
+#if !defined(_TRACE_SIOX_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_SIOX_H
+
+#include 
+
+TRACE_EVENT(siox_set_data,
+   TP_PROTO(const struct siox_master *smaster,
+const struct siox_device *sdevice,
+unsigned int devno, size_t bufoffset),
+   TP_ARGS(smaster, sdevice, devno, bufoffset),
+   TP_STRUCT__entry(
+__field(int, busno)
+__field(unsigned int, devno)
+__field(size_t, inbytes)
+__dynamic_array(u8, buf, sdevice->inbytes)
+   ),
+   TP_fast_assign(
+  __entry->busno = smaster->busno;
+  __entry->devno = devno;
+  __entry->inbytes = sdevice->inbytes;
+  memcpy(__get_dynamic_array(buf),
+ smaster->buf + bufoffset, sdevice->inbytes);
+ ),
+   TP_printk("siox-%d-%u [%*phD]",
+ __entry->busno,
+ __entry->devno,
+ __entry->inbytes, __get_dynamic_array(buf)
+)
+);
+
+TRACE_EVENT(siox_get_data,
+   TP_PROTO(const struct siox_master *smaster,
+const struct siox_device *sdevice,
+unsigned int devno, u8 status_clean,
+size_t bufoffset),
+   TP_ARGS(smaster, sdevice, devno, status_clean, bufoffset),
+   TP_STRUCT__entry(
+__field(int, busno)
+__field(unsigned int, devno)
+__field(u8, status_clean)
+__field(size_t, outbytes)
+__dynamic_array(u8, buf, sdevice->outbytes)
+   ),
+   TP_fast_assign(
+  __entry->busno = smaster->busno;
+  __entry->devno = devno;
+  __entry->status_clean = status_clean;
+  __entry->outbytes = sdevice->outbytes;
+  memcpy(__get_dynamic_array(buf),
+ smaster->buf + bufoffset, sdevice->outbytes);
+ 

[PATCH v1 0/5] siox: add support for new bus type

[Uwe Kleine-König]

Hello,

this series adds a new bus type for SIOX devices. I already sent a
similar series a few years ago; since then the subsystem got more mature
and is operated with this code base in the field.

For the device tree doc changes I'm unsure if I should split them in
separate patches, please advice.

Best regards
Uwe

Uwe Kleine-König (5):
  siox: new driver framework for eckelmann SIOX
  siox: add support for tracing
  siox: add gpio bus driver
  gpio: new driver to work with a 8x12 siox
  MAINTAINERS: Add entry for SIOX

 .../bindings/siox/eckelmann,siox-gpio.txt  |  19 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   8 +
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/gpio/Kconfig   |   8 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-siox.c   | 293 +++
 drivers/siox/Kconfig   |  18 +
 drivers/siox/Makefile  |   2 +
 drivers/siox/siox-bus-gpio.c   | 172 
 drivers/siox/siox-core.c   | 937 +
 drivers/siox/siox.h|  49 ++
 include/linux/siox.h   |  77 ++
 include/trace/events/siox.h|  66 ++
 15 files changed, 1654 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/siox/eckelmann,siox-gpio.txt
 create mode 100644 drivers/gpio/gpio-siox.c
 create mode 100644 drivers/siox/Kconfig
 create mode 100644 drivers/siox/Makefile
 create mode 100644 drivers/siox/siox-bus-gpio.c
 create mode 100644 drivers/siox/siox-core.c
 create mode 100644 drivers/siox/siox.h
 create mode 100644 include/linux/siox.h
 create mode 100644 include/trace/events/siox.h

-- 
2.11.0

Re: USB: hub: Delete an error message for a failed memory allocation in usb_hub_clear_tt_buffer()

[Dan Carpenter]

On Thu, Dec 07, 2017 at 09:45:38AM +0100, Geert Uytterhoeven wrote:
> >
> > Small allocations never fail in the current kernel.
> 
> A few comments (this is in response to a patch from Markus, so there have
> to be lots of questions and uncertainties ;-)
> 1. In the current kernel. What about the future?

Right.  No one can predict.  And the small allocations don't fail rule
causes some problems.

> 2. If a small allocation cannot fail, what happens if the small memory slab
>is exhausted? A new page must be allocated, which will trigger an OOM,
>and some other part of the system will be killed and fail.

Right.


> 3. This driver uses GFP_ATOMIC, is that guaranteed to succeed? I think not.
> 

Right again.  I was missing the first email in the thread because of my
email filters so I didn't see this was atomic.

regards,
dan carpenter

[PATCH V2] cpufreq: longhaul: Revert transition_delay_us to 200 ms

[Viresh Kumar]

The commit e948bc8fbee0 ("cpufreq: Cap the default transition delay
value to 10 ms") caused a regression on EPIA-M min-ITX computer where
shutdown or reboot hangs occasionally with a print message like:

longhaul: Warning: Timeout while waiting for idle PCI bus
cpufreq: __target_index: Failed to change cpu frequency: -16

This probably happens because the cpufreq governor tries to change the
frequency of the CPU faster than allowed by the hardware.

Before the above commit, the default transition delay was set to 200 ms
for a transition_latency of 20 ns. Lets revert back to that
transition delay value to fix it. Note that several other transition
delay values were tested like 20 ms and 30 ms and none of them have
resolved system hang issue completely.

Fixes: e948bc8fbee0 ("cpufreq: Cap the default transition delay value to 10 ms")
Cc: 4.14+  # 4.14+
Reported-by: Meelis Roos 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Viresh Kumar 
---
V1->V2:
- s/20 ms/200 ms.

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

diff --git a/drivers/cpufreq/longhaul.c b/drivers/cpufreq/longhaul.c
index c46a12df40dd..5faa37c5b091 100644
--- a/drivers/cpufreq/longhaul.c
+++ b/drivers/cpufreq/longhaul.c
@@ -894,7 +894,7 @@ static int longhaul_cpu_init(struct cpufreq_policy *policy)
if ((longhaul_version != TYPE_LONGHAUL_V1) && (scale_voltage != 0))
longhaul_setup_voltagescaling();
 
-   policy->cpuinfo.transition_latency = 20;/* nsec */
+   policy->transition_delay_us = 20;   /* usec */
 
return cpufreq_table_validate_and_show(policy, longhaul_table);
 }
-- 
2.14.1

[tip:x86/urgent] x86/boot/compressed/64: Print error if 5-level paging is not supported

[tip-bot for Kirill A. Shutemov]

Commit-ID:  6d7e0ba2d2be9e50cccba213baf07e0e183c1b24
Gitweb: https://git.kernel.org/tip/6d7e0ba2d2be9e50cccba213baf07e0e183c1b24
Author: Kirill A. Shutemov 
AuthorDate: Mon, 4 Dec 2017 15:40:56 +0300
Committer:  Thomas Gleixner 
CommitDate: Thu, 7 Dec 2017 10:36:26 +0100

x86/boot/compressed/64: Print error if 5-level paging is not supported

If the machine does not support the paging mode for which the kernel was
compiled, the boot process cannot continue.

It's not possible to let the kernel detect the mismatch as it does not even
reach the point where cpu features can be evaluted due to a triple fault in
the KASLR setup.

Instead of instantaneous silent reboot, emit an error message which gives
the user the information why the boot fails.

Fixes: 77ef56e4f0fb ("x86: Enable 5-level paging support via 
CONFIG_X86_5LEVEL=y")
Reported-by: Borislav Petkov 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Thomas Gleixner 
Tested-by: Borislav Petkov 
Cc: Andi Kleen 
Cc: sta...@vger.kernel.org
Cc: Andy Lutomirski 
Cc: linux...@kvack.org
Cc: Cyrill Gorcunov 
Cc: Linus Torvalds 
Link: 
https://lkml.kernel.org/r/20171204124059.63515-3-kirill.shute...@linux.intel.com

---
 arch/x86/boot/compressed/misc.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index b50c424..98761a1 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -169,6 +169,16 @@ void __puthex(unsigned long value)
}
 }
 
+static bool l5_supported(void)
+{
+   /* Check if leaf 7 is supported. */
+   if (native_cpuid_eax(0) < 7)
+   return 0;
+
+   /* Check if la57 is supported. */
+   return native_cpuid_ecx(7) & (1 << (X86_FEATURE_LA57 & 31));
+}
+
 #if CONFIG_X86_NEED_RELOCS
 static void handle_relocations(void *output, unsigned long output_len,
   unsigned long virt_addr)
@@ -362,6 +372,12 @@ asmlinkage __visible void *extract_kernel(void *rmode, 
memptr heap,
console_init();
debug_putstr("early console in extract_kernel\n");
 
+   if (IS_ENABLED(CONFIG_X86_5LEVEL) && !l5_supported()) {
+   error("This linux kernel as configured requires 5-level 
paging\n"
+   "This CPU does not support the required 'cr4.la57' 
feature\n"
+   "Unable to boot - please use a kernel appropriate for 
your CPU\n");
+   }
+
free_mem_ptr = heap;/* Heap */
free_mem_end_ptr = heap + BOOT_HEAP_SIZE;
 

[PATCH v9 3/4] [media] platform: Add Synopsys DesignWare HDMI RX PHY e405 Driver

[Jose Abreu]

This adds support for the Synopsys DesignWare HDMI RX PHY e405. This
phy receives and decodes HDMI video that is delivered to a controller.

Main features included in this driver are:
- Equalizer algorithm that chooses the phy best settings
according to the detected HDMI cable characteristics.
- Support for scrambling
- Support for HDMI 2.0 modes up to 6G (HDMI 4k@60Hz).

The driver was implemented as a standalone V4L2 subdevice and the
phy interface with the controller was implemented using V4L2 ioctls. I
do not know if this is the best option but it is not possible to use the
existing API functions directly as we need specific functions that will
be called by the controller at specific configuration stages.

There is also a bidirectional communication between controller and phy:
The phy must provide functions that the controller will call (i.e.
configuration functions) and the controller must provide read/write
callbacks, as well as other specific functions.

Signed-off-by: Jose Abreu 
Cc: Joao Pinto 
Cc: Mauro Carvalho Chehab 
Cc: Hans Verkuil 
Cc: Sylwester Nawrocki 
---
Changes from v4:
- Use usleep_range (Sylwester)
- Remove some comments (Sylwester)
- Parse phy version from of_device_id (Sylwester)
- Use "cfg" instead of "cfg-clk" (Sylwester, Rob)
- Change some messages to dev_dbg (Sylwester)
Changes from v3:
- Use v4l2 async API (Sylwester)
- Use clock API (Sylwester)
- Add compatible string (Sylwester)
Changes from RFC:
- Remove a bunch of functions that can be collapsed into
a single config() function
- Add comments for the callbacks and structures (Hans)
---
 drivers/media/platform/Kconfig|   2 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/dwc/Kconfig|   8 +
 drivers/media/platform/dwc/Makefile   |   1 +
 drivers/media/platform/dwc/dw-hdmi-phy-e405.c | 844 ++
 drivers/media/platform/dwc/dw-hdmi-phy-e405.h |  63 ++
 include/media/dwc/dw-hdmi-phy-pdata.h | 128 
 7 files changed, 1048 insertions(+)
 create mode 100644 drivers/media/platform/dwc/Kconfig
 create mode 100644 drivers/media/platform/dwc/Makefile
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.c
 create mode 100644 drivers/media/platform/dwc/dw-hdmi-phy-e405.h
 create mode 100644 include/media/dwc/dw-hdmi-phy-pdata.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fd0c998..0187cbd 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -33,6 +33,8 @@ source "drivers/media/platform/omap/Kconfig"
 
 source "drivers/media/platform/blackfin/Kconfig"
 
+source "drivers/media/platform/dwc/Kconfig"
+
 config VIDEO_SH_VOU
tristate "SuperH VOU video output driver"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 003b0bb..2e879c6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -97,3 +97,5 @@ obj-$(CONFIG_VIDEO_QCOM_CAMSS)+= 
qcom/camss-8x16/
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
 
 obj-y  += meson/
+
+obj-y  += dwc/
diff --git a/drivers/media/platform/dwc/Kconfig 
b/drivers/media/platform/dwc/Kconfig
new file mode 100644
index 000..361d38d
--- /dev/null
+++ b/drivers/media/platform/dwc/Kconfig
@@ -0,0 +1,8 @@
+config VIDEO_DWC_HDMI_PHY_E405
+   tristate "Synopsys Designware HDMI RX PHY e405 driver"
+   depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   help
+ Support for Synopsys Designware HDMI RX PHY. Version is e405.
+
+ To compile this driver as a module, choose M here. The module
+ will be called dw-hdmi-phy-e405.
diff --git a/drivers/media/platform/dwc/Makefile 
b/drivers/media/platform/dwc/Makefile
new file mode 100644
index 000..fc3b62c
--- /dev/null
+++ b/drivers/media/platform/dwc/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_DWC_HDMI_PHY_E405) += dw-hdmi-phy-e405.o
diff --git a/drivers/media/platform/dwc/dw-hdmi-phy-e405.c 
b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
new file mode 100644
index 000..26d70ca
--- /dev/null
+++ b/drivers/media/platform/dwc/dw-hdmi-phy-e405.c
@@ -0,0 +1,844 @@
+/*
+ * Synopsys Designware HDMI PHY E405 driver
+ *
+ * This Synopsys dw-phy-e405 software and associated documentation
+ * (hereinafter the "Software") is an unsupported proprietary work of
+ * Synopsys, Inc. unless otherwise expressly agreed to in writing between
+ * Synopsys and you. The Software IS NOT an item of Licensed Software or a
+ * Licensed Product under any End User Software License Agreement or
+ * Agreement for Licensed Products with Synopsys or any supplement 

staging: pi433: Plans from Smarthome-Wolf

[Marcus Wolf]

Am 06.12.2017 um 14:47 schrieb Dan Carpenter:
> On Wed, Dec 06, 2017 at 11:11:27AM +0200, Marcus Wolf wrote:
>>
>> Since the rule for kernel development seems to be, not to care about future,
>> most probably you patch is fine, anyway.
>>
> 
> Yeah.  Deleting code if there is no user is required to move this code
> out of staging...
> 
> I've worked in staging for a long time and I've seen patches from
> thousands of people.  Simon really seems to understand kernel style and
> that's less common than one might think.  It's a valuable skill.  If you
> would just leave him to work then this driver would get fixed...
> 
> You're making it very difficult because you're complaining about the
> work which *needs* to be done.  It's discouraging for people sending
> patches.  This is very frustrating...  :(
> 
> On the naming, I think having a function which is named "enable" but
> actually disables a feature is a non-starter.  What about we do either
> one of these:
>  pi433_enable_(spi);
>  pi433_disable_(spi);
> Or:
>  pi433_set_(spi, SETTING);
> 
> It's still a standard and we'll just decide on a case by case basis what
> to use.  This is a tiny driver and it's really easy to grep for the
> feature name to find the functions you want.  Plus all the config is
> done in one location so it's really not that hard.
> 
> regards,
> dan carpenter
> 

Hi Greg, Dan, Simon and all others,

yesterday we had a project meeting. Though I am the boss, I was
"punished" that I spend such a bunch of time to discuss here, instead of
finishing stuff from my todo list :-P

I get the point, that I am not really deep in the kernel style guide and
it is better, if I don't disturb the nerds.

Both facts in combination tell me, that I should lean back, wait a while
and see, what the driver will become.


On the other hand, my team was - like me - a little bit in worry about
this "closing a door", that happend a few times during the last weeks
and the possible redesign of the driver architecture. It would be pitty,
if the effort for integration of new features will be complicated a lot.


We finally decided, that I actually should reduce focussing on the
driver for the moment and let things go. We'd like to use this mail, to
tell our ideas and the plan for next year:

When submitting the driver, we wanted to add support to the kernel for
the technical really good modules from HopeRf. The idea was to support
serveral chips and several modules (carrying those chips). Due to
financial and time restrictions, we finally had to reduce to rfm69cw and
focused on Pi433.
Plan for the next year:
* Tweak the driver (if needed) to enable the reception of telegrams
without preamble and sync pattern. We never tested this before. This
feature will be needed aprox. in March'18.
* Support for the rfm69cw-868 - Almost the same module as the current,
but for the 868MHz ISM band. Will be needed approx. end of summer next year.
* We would like to add support for some more features of the chip (e. g.
AES) - you can see, there are lots of so far not covered registers
(commented lines in rf69_registers.h). No shedule for this.
* If we will have a (financially) successfull 2018, we think about
integration of the rf95 chip.

>From third parties we were asked about the follwoing features:
* Implement support for continuous mode (e. g. from projects fhem,
domotics).
* Do a little bit more generic inteface implementation, to also support
other hardware setups, using the rf69 chip.
Second sounds very interesting - especially in terms of a real Linux
driver. But both topics so far aren't on our agenda.


So I will withdraw from the development of pi433 driver for the next
monthes and will be back at the beginning of spring. I hope, there are
not too many closed doors, so I can easily start over with head rev. and
don't have to fall back to my old base. To ease a start over, I would
love the following things (as much, as possible without breaking the rules):
* do not modify the register abstraction in a way, that it doesn't
represent the real hardware any more (e. g. the stuff with amp - the
chip does not have two registers, taking chipnumbers, but 3 bits, taking
on/off information). In doubt have a look at the data sheet.
* stay with the naming convention for the register abstraction
(rf69_set_... and rf69_get_...). If for some reason a register (or bit)
needs to be read back for some reason in future, it is unlovely to have
rf69_do_something and you need to find a adequate name for the getter.
rf69_get_do_something is ugly most times.
* if possible, do not remove my tiny "debug system" in the register
abstraction. It's very powerfull, if you work on config changes.
* try to keep the current or find a new way, that a setting from user
space could be mapped to (not identical) register sets of different chips.


If you have any questions - especially concerning the hardware facts -
feel free to ask. To be sure, I don't miss the mail between others from

[PATCH v3 0/4] Add coupled regulators mechanism

[Maciej Purski]

Hi all,

this patchset adds a new mechanism to the framework - regulators' coupling.

On Odroid XU3/4 and other Exynos5422 based boards there is a case, that
different devices on the board are supplied by different regulators
with non-fixed voltages. If one of these devices temporarily requires 
higher voltage, there might occur a situation that the spread between 
devices' voltages is so high, that there is a risk of changing
'high' and 'low' states on the interconnection between devices powered
by those regulators. 

Algorithmicaly the problem was solved by: 
Inderpal Singh 
Doug Anderson 

The discussion on that subject can be found here:
https://lkml.org/lkml/2014/4/29/28

Therefore this patchset is an attempt to apply the idea to regulators core
as concluded in the discussion by Mark Brown and Doug Anderson.

This feature is required to enable support for generic CPUfreq 
and devfreq drivers for the mentioned boards. 

Note on the locking model:
When balancing voltage of a group of coupled regulators, we lock all
of them for the whole operation. When voltage of an individual regulator
is about to change, its suppliers are additionally locked.


Best regards,

Maciej Purski

---
Changes in v3:
- move dts parsing code to of_regulator.c, in order to the so,
  add a new commit in which of_regulator_find_by_node() is moved
  to of_regulator.c as well
- improve error messages
- move max_spread variable to constraints
- perform resolving of coupled regulators under a list mutex
- remove useless locking functions
- some minor refactorization
- improve commit messages

Changes in RFC v2:
- allow coupling n regulators (in fact up to constant value, now
  set to 10)
- change algorithm to be more readable
- introduce better locking
- add more comments
- split first patch into two
- update commit messages
- change sequence of the patches

Maciej Purski (4):
  regulator: core: Move of_find_regulator_by_node() to of_regulator.c
  regulator: bindings: Add properties for coupled regulators
  regulator: core: Parse coupled regulators properties
  regulator: core: Balance coupled regulators voltages

 .../devicetree/bindings/regulator/regulator.txt|   5 +
 drivers/regulator/core.c   | 424 +++--
 drivers/regulator/internal.h   |  16 +
 drivers/regulator/of_regulator.c   |  74 
 include/linux/regulator/driver.h   |  16 +
 include/linux/regulator/machine.h  |   4 +
 6 files changed, 501 insertions(+), 38 deletions(-)

-- 
2.7.4

Re: [PATCH net-next] bnxt: Don't print message, if DAC isn't connected on both ends

[Michael Chan]

On Thu, Dec 7, 2017 at 1:39 AM, Thomas Bogendoerfer
 wrote:
> On Thu, 7 Dec 2017 01:24:43 -0800
> Michael Chan  wrote:
>
>> On Thu, Dec 7, 2017 at 1:14 AM, Thomas Bogendoerfer
>>  wrote:
>> > well, it will print the forced rate, if there is one configured and -1 
>> > otherwise,
>> > if the link is lost or will not come up because of a cable problem. I 
>> > don't see much
>> > value in that...
>> >
>> The main purpose is to tell the user that the speed he selected for a
>> port is no longer supported due to an incompatible speed configured on
>> the other port.  This is useful for the user so that he can either
>> take action to change the speed or do nothing as he sees fit.
>
> just out of curiosity what's meant my imcompatible speed on the other port ?
> Does the message show up continously like in the problem case I already know ?
>

On some dual-port cards, 10G and 25G are not compatible.  If one port
links up at 25G, for example, the other port will never link up if it
is set to 10G.  In this case the 10G port gets a message from the
firmware and the driver will print the "10G no longer supported"
message.  It's supposed to be a one time message.

Re: [PATCH v5 0/6] enable creating [k,u]probe with perf_event_open

[Philippe Ombredanne]

Song,

On Wed, Dec 6, 2017 at 11:45 PM, Song Liu  wrote:
> Changes PATCH v4 to PATCH v5:
>   Remove PERF_PROBE_CONFIG_IS_RETPROBE from uapi, use PMU_FORMAT_ATTR
>   instead.
>
> Changes PATCH v3 to PATCH v4:
>   Remove uapi define MAX_PROBE_FUNC_NAME_LEN, use KSYM_NAME_LEN instead.
>   Add flag PERF_PROBE_CONFIG_IS_RETPROBE for config field of [k,u]probe.
>   Optimize ifdef's of CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS.
>   Optimize checks in perf_event_is_tracing().
>   Optimize perf_tp_register().
>
> Changes PATCH v2 to PATCH v3:
>   Remove fixed type PERF_TYPE_KPROBE and PERF_TYPE_UPROBE, use dynamic
>   type instead.
>   Update userspace (samples/bpf, bcc) to look up type from sysfs.
>   Change License info in test_many_kprobe_user.c as Philippe Ombredanne
>   suggested.
>
> Changes PATCH v1 to PATCH v2:
>   Split PERF_TYPE_PROBE into PERF_TYPE_KPROBE and PERF_TYPE_UPROBE.
>   Split perf_probe into perf_kprobe and perf_uprobe.
>   Remove struct probe_desc, use config1 and config2 instead.
>
> Changes RFC v2 to PATCH v1:
>   Check type PERF_TYPE_PROBE in perf_event_set_filter().
>   Rebase on to tip perf/core.
>
> Changes RFC v1 to RFC v2:
>   Fix build issue reported by kbuild test bot by adding ifdef of
>   CONFIG_KPROBE_EVENTS, and CONFIG_UPROBE_EVENTS.
>
> RFC v1 cover letter:
>
> This is to follow up the discussion over "new kprobe api" at Linux
> Plumbers 2017:
>
> https://www.linuxplumbersconf.org/2017/ocw/proposals/4808
>
> With current kernel, user space tools can only create/destroy [k,u]probes
> with a text-based API (kprobe_events and uprobe_events in tracefs). This
> approach relies on user space to clean up the [k,u]probe after using them.
> However, this is not easy for user space to clean up properly.
>
> To solve this problem, we introduce a file descriptor based API.
> Specifically, we extended perf_event_open to create [k,u]probe, and attach
> this [k,u]probe to the file descriptor created by perf_event_open. These
> [k,u]probe are associated with this file descriptor, so they are not
> available in tracefs.
>
> We reuse large portion of existing trace_kprobe and trace_uprobe code.
> Currently, the file descriptor API does not support arguments as the
> text-based API does. This should not be a problem, as user of the file
> decriptor based API read data through other methods (bpf, etc.).
>
> I also include a patch to to bcc, and a patch to man-page perf_even_open.
> Please see the list below. A fork of bcc with this patch is also available
> on github:
>
>   https://github.com/liu-song-6/bcc/tree/perf_event_open
>
> Thanks,
> Song
>
> man-pages patch:
>   perf_event_open.2: add type kprobe and uprobe
>
> bcc patch:
>   bcc: Try use new API to create [k,u]probe with perf_event_open
>
> kernel patches:
>
> Song Liu (6):
>   perf: prepare perf_event.h for new types perf_kprobe and perf_uprobe
>   perf: copy new perf_event.h to tools/include/uapi
>   perf: implement pmu perf_kprobe
>   perf: implement pmu perf_uprobe
>   bpf: add option for bpf_load.c to use perf_kprobe
>   bpf: add new test test_many_kprobe
>
>  include/linux/trace_events.h  |   8 ++
>  include/uapi/linux/perf_event.h   |   4 +
>  kernel/events/core.c  | 131 +++-
>  kernel/trace/trace_event_perf.c   | 102 +++
>  kernel/trace/trace_kprobe.c   |  91 +++--
>  kernel/trace/trace_probe.h|  11 ++
>  kernel/trace/trace_uprobe.c   |  86 ++--
>  samples/bpf/Makefile  |   3 +
>  samples/bpf/bpf_load.c|  66 ++--
>  samples/bpf/bpf_load.h|  14 +++
>  samples/bpf/test_many_kprobe_user.c   | 186 
> ++
>  tools/include/uapi/linux/perf_event.h |   4 +
>  12 files changed, 677 insertions(+), 29 deletions(-)
>  create mode 100644 samples/bpf/test_many_kprobe_user.c
>
> --
> 2.9.5


Thank you for using the SPDX ids!
For this:
Acked-by:  Philippe Ombredanne 

[PATCH RESEND 3/4] i2c: mpc: fix PORDEVSR2 mask for MPC8533/44

[Arseny Solokha]

According to the reference manuals for the corresponding SoCs, SEC
frequency ratio configuration is indicated by bit 26 of the POR Device
Status Register 2. Consequently, SEC_CFG bit should be tested by mask 0x20,
not 0x80. Testing the wrong bit leads to selection of wrong I2C clock
prescaler on those SoCs.

Signed-off-by: Arseny Solokha 
---
 drivers/i2c/busses/i2c-mpc.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 648a5afded64..aac0ec6dc5fc 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -332,14 +332,18 @@ static u32 mpc_i2c_get_sec_cfg_8xxx(void)
if (prop) {
/*
 * Map and check POR Device Status Register 2
-* (PORDEVSR2) at 0xE0014
+* (PORDEVSR2) at 0xE0014. Note than while MPC8533
+* and MPC8544 indicate SEC frequency ratio
+* configuration as bit 26 in PORDEVSR2, other MPC8xxx
+* parts may store it differently or may not have it
+* at all.
 */
reg = ioremap(get_immrbase() + *prop + 0x14, 0x4);
if (!reg)
printk(KERN_ERR
   "Error: couldn't map PORDEVSR2\n");
else
-   val = in_be32(reg) & 0x0080; /* sec-cfg */
+   val = in_be32(reg) & 0x0020; /* sec-cfg */
iounmap(reg);
}
}
-- 
2.15.1

[PATCH RESEND 4/4] i2c: mpc: always determine I2C clock prescaler at runtime

[Arseny Solokha]

Remove the facility for setting the prescaler value at compile time
entirely. It was only used for two SoCs, duplicating the actual value
for one of them and setting sometimes bogus value for another. Make all
MPC8xxx SoCs obtain their actual I2C clock prescaler from a single place
in the code.

Signed-off-by: Arseny Solokha 
---
 drivers/i2c/busses/i2c-mpc.c | 52 +---
 1 file changed, 15 insertions(+), 37 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index aac0ec6dc5fc..ad9af3ca35aa 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -78,9 +78,7 @@ struct mpc_i2c_divider {
 };
 
 struct mpc_i2c_data {
-   void (*setup)(struct device_node *node, struct mpc_i2c *i2c,
- u32 clock, u32 prescaler);
-   u32 prescaler;
+   void (*setup)(struct device_node *node, struct mpc_i2c *i2c, u32 clock);
 };
 
 static inline void writeccr(struct mpc_i2c *i2c, u32 x)
@@ -201,7 +199,7 @@ static const struct mpc_i2c_divider mpc_i2c_dividers_52xx[] 
= {
 };
 
 static int mpc_i2c_get_fdr_52xx(struct device_node *node, u32 clock,
- int prescaler, u32 *real_clk)
+ u32 *real_clk)
 {
const struct mpc_i2c_divider *div = NULL;
unsigned int pvr = mfspr(SPRN_PVR);
@@ -236,7 +234,7 @@ static int mpc_i2c_get_fdr_52xx(struct device_node *node, 
u32 clock,
 
 static void mpc_i2c_setup_52xx(struct device_node *node,
 struct mpc_i2c *i2c,
-u32 clock, u32 prescaler)
+u32 clock)
 {
int ret, fdr;
 
@@ -246,7 +244,7 @@ static void mpc_i2c_setup_52xx(struct device_node *node,
return;
}
 
-   ret = mpc_i2c_get_fdr_52xx(node, clock, prescaler, >real_clk);
+   ret = mpc_i2c_get_fdr_52xx(node, clock, >real_clk);
fdr = (ret >= 0) ? ret : 0x3f; /* backward compatibility */
 
writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
@@ -258,7 +256,7 @@ static void mpc_i2c_setup_52xx(struct device_node *node,
 #else /* !(CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x) */
 static void mpc_i2c_setup_52xx(struct device_node *node,
 struct mpc_i2c *i2c,
-u32 clock, u32 prescaler)
+u32 clock)
 {
 }
 #endif /* CONFIG_PPC_MPC52xx || CONFIG_PPC_MPC512x */
@@ -266,7 +264,7 @@ static void mpc_i2c_setup_52xx(struct device_node *node,
 #ifdef CONFIG_PPC_MPC512x
 static void mpc_i2c_setup_512x(struct device_node *node,
 struct mpc_i2c *i2c,
-u32 clock, u32 prescaler)
+u32 clock)
 {
struct device_node *node_ctrl;
void __iomem *ctrl;
@@ -289,12 +287,12 @@ static void mpc_i2c_setup_512x(struct device_node *node,
}
 
/* The clock setup for the 52xx works also fine for the 512x */
-   mpc_i2c_setup_52xx(node, i2c, clock, prescaler);
+   mpc_i2c_setup_52xx(node, i2c, clock);
 }
 #else /* CONFIG_PPC_MPC512x */
 static void mpc_i2c_setup_512x(struct device_node *node,
 struct mpc_i2c *i2c,
-u32 clock, u32 prescaler)
+u32 clock)
 {
 }
 #endif /* CONFIG_PPC_MPC512x */
@@ -388,16 +386,13 @@ static u32 mpc_i2c_get_prescaler_8xxx(void)
 }
 
 static int mpc_i2c_get_fdr_8xxx(struct device_node *node, u32 clock,
- u32 prescaler, u32 *real_clk)
+ u32 *real_clk)
 {
const struct mpc_i2c_divider *div = NULL;
+   u32 prescaler = mpc_i2c_get_prescaler_8xxx();
u32 divider;
int i;
 
-   /* Determine proper divider value */
-   if (!prescaler)
-   prescaler = mpc_i2c_get_prescaler_8xxx();
-
if (clock == MPC_I2C_CLOCK_LEGACY) {
/* see below - default fdr = 0x1031 -> div = 16 * 3072 */
*real_clk = fsl_get_sys_freq() / prescaler / (16 * 3072);
@@ -425,7 +420,7 @@ static int mpc_i2c_get_fdr_8xxx(struct device_node *node, 
u32 clock,
 
 static void mpc_i2c_setup_8xxx(struct device_node *node,
 struct mpc_i2c *i2c,
-u32 clock, u32 prescaler)
+u32 clock)
 {
int ret, fdr;
 
@@ -436,7 +431,7 @@ static void mpc_i2c_setup_8xxx(struct device_node *node,
return;
}
 
-   ret = mpc_i2c_get_fdr_8xxx(node, clock, prescaler, >real_clk);
+   ret = mpc_i2c_get_fdr_8xxx(node, clock, >real_clk);
fdr = (ret >= 0) ? ret : 0x1031; /* backward compatibility */
 
writeb(fdr & 

[PATCH RESEND 1/4] i2c: mpc: get MPC8xxx I2C clock prescaler before using it in calculations

[Arseny Solokha]

Obtaining the actual I2C clock prescaler value in mpc_i2c_setup_8xxx() only
happens when the clock parameter is set to something other than
MPC_I2C_CLOCK_LEGACY. When the clock parameter is exactly
MPC_I2C_CLOCK_LEGACY, the prescaler parameter is used in arithmetic
division as provided by the caller, resulting in a division by zero
for the majority of processors supported by the module.

Avoid division by zero by obtaining the actual I2C clock prescaler
in mpc_i2c_setup_8xxx() unconditionally regardless of the passed clock
value.

Signed-off-by: Arseny Solokha 
---
 drivers/i2c/busses/i2c-mpc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 950a9d74f54d..6ad87555f71e 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -382,18 +382,18 @@ static int mpc_i2c_get_fdr_8xxx(struct device_node *node, 
u32 clock,
u32 divider;
int i;
 
-   if (clock == MPC_I2C_CLOCK_LEGACY) {
-   /* see below - default fdr = 0x1031 -> div = 16 * 3072 */
-   *real_clk = fsl_get_sys_freq() / prescaler / (16 * 3072);
-   return -EINVAL;
-   }
-
/* Determine proper divider value */
if (of_device_is_compatible(node, "fsl,mpc8544-i2c"))
prescaler = mpc_i2c_get_sec_cfg_8xxx() ? 3 : 2;
if (!prescaler)
prescaler = mpc_i2c_get_prescaler_8xxx();
 
+   if (clock == MPC_I2C_CLOCK_LEGACY) {
+   /* see below - default fdr = 0x1031 -> div = 16 * 3072 */
+   *real_clk = fsl_get_sys_freq() / prescaler / (16 * 3072);
+   return -EINVAL;
+   }
+
divider = fsl_get_sys_freq() / clock / prescaler;
 
pr_debug("I2C: src_clock=%d clock=%d divider=%d\n",
-- 
2.15.1

[PATCH v6 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs

[Li Wei]

add ufs node document for Hisilicon.

Signed-off-by: Li Wei 
---
 Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 38 ++
 1 file changed, 38 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt

diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt 
b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
new file mode 100644
index ..73e10698960e
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
@@ -0,0 +1,38 @@
+* Hisilicon Universal Flash Storage (UFS) Host Controller
+
+UFS nodes are defined to describe on-chip UFS hardware macro.
+Each UFS Host Controller should have its own node.
+
+Required properties:
+- compatible: compatible list, contains one of the following -
+   "hisilicon,hi3660-ufs", "jedec,ufs-1.1" 
for hisi ufs
+   host controller present on Hi36xx 
chipset.
+- reg   : should contain UFS register address space & UFS SYS CTRL 
register address,
+- interrupt-parent  : interrupt device
+- interrupts: interrupt number
+- clocks   : List of phandle and clock specifier pairs
+- clock-names   : List of clock input name strings sorted in the same
+   order as the clocks property. 
"ref_clk", "phy_clk" is optional
+- resets: reset node register, one reset the clk and the other 
reset the controller
+- reset-names   : describe reset node register
+
+Example:
+
+   ufs: ufs@ff3b {
+   compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1";
+   /* 0: HCI standard */
+   /* 1: UFS SYS CTRL */
+   reg = <0x0 0xff3b 0x0 0x1000>,
+   <0x0 0xff3b1000 0x0 0x1000>;
+   interrupt-parent = <>;
+   interrupts = ;
+   clocks = <_ctrl HI3660_CLK_GATE_UFSIO_REF>,
+   <_ctrl HI3660_CLK_GATE_UFSPHY_CFG>;
+   clock-names = "ref_clk", "phy_clk";
+   freq-table-hz = <0 0>, <0 0>;
+   /* offset: 0x84; bit: 12 */
+   /* offset: 0x84; bit: 7  */
+   resets = <_rst 0x84 12>,
+   <_rst 0x84 7>;
+   reset-names = "rst", "assert";
+   };
-- 
2.15.0

[PATCH v9 04/13] slimbus: core: Add slim controllers support

[srinivas . kandagatla]

From: Sagar Dharia 

This patch adds support to slim controllers in the slim core,
including some utility functions invoked by the controller and
slim device drivers.

Signed-off-by: Srinivas Kandagatla 
---
 drivers/slimbus/core.c| 306 ++
 drivers/slimbus/slimbus.h | 106 
 include/linux/slimbus.h   |   8 ++
 3 files changed, 420 insertions(+)
 create mode 100644 drivers/slimbus/slimbus.h

diff --git a/drivers/slimbus/core.c b/drivers/slimbus/core.c
index f4e6bfdeef92..a59a88a7a52d 100644
--- a/drivers/slimbus/core.c
+++ b/drivers/slimbus/core.c
@@ -5,7 +5,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include "slimbus.h"
+
+static DEFINE_IDA(ctrl_ida);
 
 static const struct slim_device_id *slim_match(const struct slim_device_id *id,
   const struct slim_device *sbdev)
@@ -90,6 +94,308 @@ void slim_driver_unregister(struct slim_driver *drv)
 }
 EXPORT_SYMBOL_GPL(slim_driver_unregister);
 
+static void slim_dev_release(struct device *dev)
+{
+   struct slim_device *sbdev = to_slim_device(dev);
+
+   kfree(sbdev);
+}
+
+static int slim_add_device(struct slim_controller *ctrl,
+  struct slim_device *sbdev,
+  struct device_node *node)
+{
+   sbdev->dev.bus = _bus;
+   sbdev->dev.parent = ctrl->dev;
+   sbdev->dev.release = slim_dev_release;
+   sbdev->dev.driver = NULL;
+   sbdev->ctrl = ctrl;
+
+   dev_set_name(>dev, "%x:%x:%x:%x",
+ sbdev->e_addr.manf_id,
+ sbdev->e_addr.prod_code,
+ sbdev->e_addr.dev_index,
+ sbdev->e_addr.instance);
+
+   return device_register(>dev);
+}
+
+static struct slim_device *slim_alloc_device(struct slim_controller *ctrl,
+struct slim_eaddr *eaddr,
+struct device_node *node)
+{
+   struct slim_device *sbdev;
+   int ret;
+
+   sbdev = kzalloc(sizeof(*sbdev), GFP_KERNEL);
+   if (!sbdev)
+   return NULL;
+
+   sbdev->e_addr = *eaddr;
+   ret = slim_add_device(ctrl, sbdev, node);
+   if (ret) {
+   kfree(sbdev);
+   return NULL;
+   }
+
+   return sbdev;
+}
+
+/*
+ * slim_register_controller() - Controller bring-up and registration.
+ *
+ * @ctrl: Controller to be registered.
+ *
+ * A controller is registered with the framework using this API.
+ * If devices on a controller were registered before controller,
+ * this will make sure that they get probed when controller is up
+ */
+int slim_register_controller(struct slim_controller *ctrl)
+{
+   int id;
+
+   id = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+   if (id < 0)
+   return id;
+
+   ctrl->id = id;
+
+   if (!ctrl->min_cg)
+   ctrl->min_cg = SLIM_MIN_CLK_GEAR;
+   if (!ctrl->max_cg)
+   ctrl->max_cg = SLIM_MAX_CLK_GEAR;
+
+   ida_init(>laddr_ida);
+   idr_init(>tid_idr);
+   mutex_init(>lock);
+
+   dev_dbg(ctrl->dev, "Bus [%s] registered:dev:%p\n",
+   ctrl->name, ctrl->dev);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(slim_register_controller);
+
+/* slim_remove_device: Remove the effect of slim_add_device() */
+static void slim_remove_device(struct slim_device *sbdev)
+{
+   device_unregister(>dev);
+}
+
+static int slim_ctrl_remove_device(struct device *dev, void *null)
+{
+   slim_remove_device(to_slim_device(dev));
+   return 0;
+}
+
+/**
+ * slim_unregister_controller() - Controller tear-down.
+ *
+ * @ctrl: Controller to tear-down.
+ */
+int slim_unregister_controller(struct slim_controller *ctrl)
+{
+   /* Remove all clients */
+   device_for_each_child(ctrl->dev, NULL, slim_ctrl_remove_device);
+   ida_simple_remove(_ida, ctrl->id);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(slim_unregister_controller);
+
+static void slim_device_update_status(struct slim_device *sbdev,
+ enum slim_device_status status)
+{
+   struct slim_driver *sbdrv;
+
+   if (sbdev->status == status)
+   return;
+
+   sbdev->status = status;
+   if (!sbdev->dev.driver)
+   return;
+
+   sbdrv = to_slim_driver(sbdev->dev.driver);
+   if (sbdrv->device_status)
+   sbdrv->device_status(sbdev, sbdev->status);
+}
+
+/**
+ * slim_report_absent() - Controller calls this function when a device
+ * reports absent, OR when the device cannot be communicated with
+ *
+ * @sbdev: Device that cannot be reached, or sent report absent
+ */
+void slim_report_absent(struct slim_device *sbdev)
+{
+   struct slim_controller *ctrl = sbdev->ctrl;
+
+   if (!ctrl)
+   return;
+
+   /* invalidate 

Re: [PATCH] tpm: return a TPM_RC_COMMAND_CODE response if a command isn't implemented

[Jarkko Sakkinen]

On Thu, Dec 07, 2017 at 03:32:16AM +0200, Jarkko Sakkinen wrote:
> Reviewed-by: Jarkko Sakkinen 
> 
> /Jarkko


```
$ python -m unittest -v tpm2_smoke.SpaceTest.test_invalid_cc
test_invalid_cc (tpm2_smoke.SpaceTest) ... ok

--
Ran 1 test in 5.833s

OK
``` [1]

Tested-by: Jarkko Sakkinen 

/Jarkko

Philip, are you sure you don't want to give tested-by?

[1] 
https://github.com/jsakkine-intel/tpm2-scripts/commit/4398af02a90442a85751148aebf725992a2949f3

/Jarkko

Re: [RFC v3 PATCH 0/2] Introduce Security Version to EFI Stub

[Ingo Molnar]

* Gary Lin  wrote:

> On Thu, Dec 07, 2017 at 09:18:16AM +0100, Ingo Molnar wrote:
> > 
> > * Gary Lin  wrote:
> > 
> > > On Thu, Dec 07, 2017 at 07:09:27AM +0100, Ingo Molnar wrote:
> > > > 
> > > > * Gary Lin  wrote:
> > > > 
> > > > > On Wed, Dec 06, 2017 at 07:37:34PM +0100, Ingo Molnar wrote:
> > > > > > 
> > > > > > * Gary Lin  wrote:
> > > > > > 
> > > > > > > On Tue, Dec 05, 2017 at 04:14:26PM -0500, Josh Boyer wrote:
> > > > > > > > On Tue, Dec 5, 2017 at 5:01 AM, Gary Lin  wrote:
> > > > > > > > > The series of patches introduce Security Version to EFI stub.
> > > > > > > > >
> > > > > > > > > Security Version is a monotonically increasing number and 
> > > > > > > > > designed to
> > > > > > > > > prevent the user from loading an insecure kernel 
> > > > > > > > > accidentally. The
> > > > > > > > > bootloader maintains a list of security versions 
> > > > > > > > > corresponding to
> > > > > > > > > different distributions. After fixing a critical 
> > > > > > > > > vulnerability, the
> > > > > > > > > distribution kernel maintainer bumps the "version", and the 
> > > > > > > > > bootloader
> > > > > > > > > updates the list automatically. When the user tries to load a 
> > > > > > > > > kernel
> > > > > > > > > with a lower security version, the bootloader shows a warning 
> > > > > > > > > prompt
> > > > > > > > > to notify the user the potential risk.
> > > > > > > > 
> > > > > > > > If a distribution releases a kernel with a higher security 
> > > > > > > > version and
> > > > > > > > that it automatically updated on boot, what happens if that 
> > > > > > > > kernel
> > > > > > > > contains a different bug that causes it to fail to boot or break
> > > > > > > > critical functionality?  At that point, the user's machine 
> > > > > > > > would be in
> > > > > > > > a state where the higher security version is enforced but the 
> > > > > > > > only
> > > > > > > > kernel that provides that is broken.  Wouldn't that make a bad
> > > > > > > > situation even worse by now requiring manual acceptance of the 
> > > > > > > > older
> > > > > > > > SV kernel boot physically at the machine?
> > > > > > > > 
> > > > > > > > I feel like I'm missing a detail here or something.
> > > > > > > > 
> > > > > > > If the new kernel fails to boot, then the user has to choose the 
> > > > > > > kernel
> > > > > > > manually anyway, and there will be an option in the warning 
> > > > > > > prompt to
> > > > > > > lower SV.
> > > > > > 
> > > > > > And what if the firmware does not support a lowering of the SV?
> > > > > > 
> > > > > The SV list is manipulated by the bootloader, and the firmware only
> > > > > provides the interface to the storage, i.e. non-volatile flash.
> > > > 
> > > > What about systems where the bootloader is part of the system and users 
> > > > only have 
> > > > the ability to provide kernel images, but no ability to change the boot 
> > > > loader?
> > > 
> > > It depends on how the bootloader works. If the system uses my
> > > implementation of shim loader, it surely has the ability to lower SV,
> > > but it requires physical access on purpose.
> > 
> > And that's my problem: if in practice the bootloader is 'part of the 
> > system', is 
> > signed and is updated like the firmware, then putting a "Security Version" 
> > into 
> > the kernel image and architecting a boot protocol for a monotonic method 
> > for the 
> > bootloader to restrict the loading of kernel images is an obviously bad 
> > idea.
> > 
> Even though the bootloader doesn't actually block the booting?

We don't know that for sure, in that scenario *how* the bootloader interprets 
the 
SV is not under the user's control...

Thanks,

Ingo

Re: [PATCH v2] mfd: stm32: Adopt SPDX identifier

[Lee Jones]

On Tue, 05 Dec 2017, Benjamin Gaignard wrote:

> Add SPDX identifier
> 
> Signed-off-by: Benjamin Gaignard 
> ---
>  drivers/mfd/stm32-lptimer.c   | 6 +-
>  drivers/mfd/stm32-timers.c| 4 +---
>  include/linux/mfd/stm32-lptimer.h | 6 +-
>  include/linux/mfd/stm32-timers.h  | 4 +---
>  4 files changed, 4 insertions(+), 16 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: PI futexes + lock stealing woes

[Peter Zijlstra]

On Wed, Dec 06, 2017 at 08:09:28PM -0600, Gratian Crisan wrote:
> 
> Peter Zijlstra writes:
> 
> > On Wed, Nov 29, 2017 at 11:56:05AM -0600, Julia Cartwright wrote:
> >
> >> fixup_owner() used to have additional seemingly relevant checks in place
> >> that were removed 73d786bd043eb ("futex: Rework inconsistent
> >> rt_mutex/futex_q state").
> >
> > *groan*... yes. I completely missed that extra case also applied to
> > requeue_pi (requeue always did hurt my brain).
> 
> FWIW I have been testing for about two days now with the fixup_owner()
> hunk of 73d786bd043eb ("futex: Rework inconsistent rt_mutex/futex_q
> state") reverted. So far it hasn't hit the race/deadlock. It normally
> takes around 8 hours to reproduce.

Yeah, that should more-or-less work I think. But I'm trying to see if
there's anything saner we can do, but so far my brain keeps slipping
off.

At the very least I want to kill the various wait_lock lockbreaks in
there, those hurt my brain and make me nervous as hell.  That fixup does
_3_ consecutive wait_lock sections, and it becomes a very complicated
story to argue why that's not riddled with holes.

For now I have something like the below; which obviously doesn't
compile yet. Let me grab lunch and such things before attempting more.

---
 kernel/futex.c  | 33 -
 kernel/locking/rtmutex.c| 27 +++
 kernel/locking/rtmutex_common.h |  1 +
 3 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index 76ed5921117a..8ad5221fbd84 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2303,14 +2303,35 @@ static void unqueue_me_pi(struct futex_q *q)
 static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
struct task_struct *newowner)
 {
-   u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
struct futex_pi_state *pi_state = q->pi_state;
u32 uval, uninitialized_var(curval), newval;
struct task_struct *oldowner;
+   u32 newtid;
int ret;
 
raw_spin_lock_irq(_state->pi_mutex.wait_lock);
 
+   if (!newowner) {
+   if (__rt_mutex_futex_trylock(_state->pi_mutex)) {
+   ret = 0;
+   goto out_unlock;
+   }
+
+   newowner = rt_mutex_owner(_state->pi_mutex);
+   if (WARN_ON_ONCE(!newowner)) {
+   /*
+* We just attempted a trylock; since that failed there
+* must be an owner, right?
+*/
+   ret = -EFUCKED; /* XXX: check return paths */
+   goto out_unlock;
+   }
+
+   /* OK we have a newowner, fixup uval */
+   }
+
+   newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
+
oldowner = pi_state->owner;
/* Owner died? */
if (!pi_state->owner)
@@ -2443,6 +2464,16 @@ static int fixup_owner(u32 __user *uaddr, struct futex_q 
*q, int locked)
goto out;
}
 
+   /*
+* If we didn't get the lock; check if nobody stole it from us.
+* In that case, we need to fix up the uval to point to them
+* instead of us, otherwise bad things happen.
+*/
+   if (q->pi_state->owner == current) {
+   ret = fixup_pi_state_owner(uaddr, q, NULL);
+   goto out;
+   }
+
/*
 * Paranoia check. If we did not take the lock, then we should not be
 * the owner of the rt_mutex.
diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c
index 6f3dba6e4e9e..21705f2fae1c 100644
--- a/kernel/locking/rtmutex.c
+++ b/kernel/locking/rtmutex.c
@@ -1290,13 +1290,25 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state,
return ret;
 }
 
+static inline int __rt_mutex_slowtrylock(struct rt_mutex *lock)
+{
+   int ret = try_to_take_rt_mutex(lock, current, NULL);
+
+   /*
+* try_to_take_rt_mutex() sets the lock waiters bit
+* unconditionally. Clean this up.
+*/
+   fixup_rt_mutex_waiters(lock);
+
+   return ret;
+}
+
 /*
  * Slow path try-lock function:
  */
 static inline int rt_mutex_slowtrylock(struct rt_mutex *lock)
 {
unsigned long flags;
-   int ret;
 
/*
 * If the lock already has an owner we fail to get the lock.
@@ -1312,13 +1324,7 @@ static inline int rt_mutex_slowtrylock(struct rt_mutex 
*lock)
 */
raw_spin_lock_irqsave(>wait_lock, flags);
 
-   ret = try_to_take_rt_mutex(lock, current, NULL);
-
-   /*
-* try_to_take_rt_mutex() sets the lock waiters bit
-* unconditionally. Clean this up.
-*/
-   fixup_rt_mutex_waiters(lock);
+   ret = __rt_mutex_slowtrylock(lock);
 
raw_spin_unlock_irqrestore(>wait_lock, flags);
 
@@ -1505,6 +1511,11 @@ int __sched rt_mutex_futex_trylock(struct rt_mutex *lock)
return 

Re: Multiple oom_reaper BUGs: unmap_page_range racing with exit_mmap

[Tetsuo Handa]

Michal Hocko wrote:
> Hmm, so you are creating a separate process (from the signal point of
> view) and I suspect it is one of those that holds the last reference to
> the mm_struct which is released here and it has tsk_oom_victim = F

Right.

> So we need a more robust test for the oom victim. Your suggestion is
> basically what I came up with originally [1] and which was deemed
> ineffective because we took the mmap_sem even for regular paths and
> Kirill was afraid this adds some unnecessary cycles to the exit path
> which is quite hot.
> 
> So I guess we have to do something else instead. We have to store the
> oom flag to the mm struct as well. Something like the patch below.

Yes, adding a new flag for this purpose will work.

Also, setting MMF_UNSTABLE flag between after sending SIGKILL and before
victim->mm becomes NULL and testing MMF_UNSTABLE at exit_mm() should work.

But I prefer simple revert + mmget()/mmput_async() approach at
http://lkml.kernel.org/r/201712062037.daf90168.svfqojfmoot...@i-love.sakura.ne.jp
 , for
my approach not only saves lines but also fixes unexpected change for nommu at
http://lkml.kernel.org/r/201711091949.bdb73475.oshfomqtlfo...@i-love.sakura.ne.jp
 .
Also, if we replace asynchronous OOM reaping by the OOM reaper kernel thread 
with
synchronous OOM reaping by the OOM killer, we can close MMF_OOM_SKIP race window
because it is guaranteed that __oom_reap_task_mm() is called before __mmput() is
called.

Re: [PATCH] i2c-cht-wc: constify platform_device_id

[Wolfram Sang]

On Tue, Nov 28, 2017 at 03:55:07PM +0530, Arvind Yadav wrote:
> platform_device_id are not supposed to change at runtime. All functions
> working with platform_device_id provided by 
> work with const platform_device_id. So mark the non-const structs as
> const.
> 
> Signed-off-by: Arvind Yadav 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH v2] clocksource: tcb_clksrc: Fix clock speed message

[Daniel Lezcano]

On 01/12/2017 13:22, Romain Izard wrote:
> The clock speed displayed at boot in an information message was 500 kHz
> too high compared to its real value. As the value is not used anywhere,
> there is no functional impact.
> 
> Fix the rounding formula to display the correct value.
> 
> Signed-off-by: Romain Izard 
> ---
> v2: rebase over v4.15-rc1
> 
> There is no specified maintainer for this file, only supporters.

That is not correct, it defaults to Thomas and me, the maintainers of
drivers/clocksource :)

> Nicolas, could you pick this through the at91 tree as the TCB block
> is an AT91 peripheral ?

Nicolas, do you agree with this change ? If yes, I will take it.

>  drivers/clocksource/tcb_clksrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/tcb_clksrc.c 
> b/drivers/clocksource/tcb_clksrc.c
> index 9de47d4d2d9e..43f4d5c4d6fa 100644
> --- a/drivers/clocksource/tcb_clksrc.c
> +++ b/drivers/clocksource/tcb_clksrc.c
> @@ -384,7 +384,7 @@ static int __init tcb_clksrc_init(void)
>  
>   printk(bootinfo, clksrc.name, CONFIG_ATMEL_TCB_CLKSRC_BLOCK,
>   divided_rate / 100,
> - ((divided_rate + 50) % 100) / 1000);
> + ((divided_rate % 100) + 500) / 1000);
>   if (tc->tcb_config && tc->tcb_config->counter_width == 32) {
>   /* use apropriate function to read 32 bit counter */
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[PATCH] arm64: allwinner: a64: orangepi-zero-plus2: add usb otg

[Jagan Teki]

Add usb otg support for orangepi-zero-plus2 board:
- Add usb_otg node with dr_mode as 'otg'
- USB0-IDDET connected to PA21
- VBUS connected through DCIN which always on

Tested mass storage function.

Signed-off-by: Jagan Teki 
---
Note: Anyone please check vbus connection [1]
Since it is connected through DCIN of vcc-5v, I've added vcc-5v0
regulator for the same and attached to usb0_vbus-supply but it is
disabling during kernel boot.
[1.887854] vcc5v0: disabling

[1] http://linux-sunxi.org/File:ORANGE_PI-ZERO-PLUS2_V1_0.pdf

 .../dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts| 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
index d349399..7f298ee 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts
@@ -73,6 +73,10 @@
};
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -111,6 +115,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
@@ -122,3 +130,13 @@
pinctrl-0 = <_pins>, <_rts_cts_pins>;
status = "okay";
 };
+
+_otg {
+   dr_mode = "otg";
+   status = "okay";
+};
+
+ {
+   usb0_id_det-gpios = < 0 21 GPIO_ACTIVE_HIGH>; /* PA21 */
+   status = "okay";
+};
-- 
2.7.4

Re: [kernel-hardening][PATCH v5 1/3] arm: mm: dump: make page table dumping reusable

[Philippe Ombredanne]

Dear Jinbum,

On Thu, Dec 7, 2017 at 11:53 AM, Jinbum Park  wrote:
> This patch refactors the arm page table dumping code,
> so multiple tables may be registered with the framework.
>
> This patch refers below commits of arm64.
> (4674fdb9f149 ("arm64: mm: dump: make page table dumping reusable"))
> (4ddb9bf83349 ("arm64: dump: Make ptdump debugfs a separate option"))
>
> Tested-by: Laura Abbott 
> Reviewed-by: Laura Abbott 
> Signed-off-by: Jinbum Park 
[]
> diff --git a/arch/arm/include/asm/ptdump.h b/arch/arm/include/asm/ptdump.h
> new file mode 100644
> index 000..3a6c0b7
> --- /dev/null
> +++ b/arch/arm/include/asm/ptdump.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (C) 2014 ARM Ltd.
> + *
> + * 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.
> + *
> + * 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 .
> + */

Sorry if I am nitpicking, but have you considered replacing this
beautiful piece of fine legalese with the new SPDX ids?
e.g. this:
// SPDX-License-Identifier: GPL-2.0
// Copyright (C) 2014 ARM Ltd.

Or if this does not work and your includes break something if they are
used in assembly, then this can work out too

> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2014 ARM Ltd. */

See Thomas doc patches, and Greg and Linus comments on these topics.

This is much leaner, is it?
Less legalese comment also means more code and a better, smaller
boilerplate lines/total lines ratio!
Thank you for your kind consideration.

-- 
Cordially
Philippe Ombredanne

[PATCH 3/3] phy: phy-mtk-tphy: use of_device_get_match_data()

[Chunfeng Yun]

reduce the boilerplate code to get the specific data

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index d99f79b1..bd26de3 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -995,7 +996,6 @@ static struct phy *mtk_phy_xlate(struct device *dev,
 
 static int mtk_tphy_probe(struct platform_device *pdev)
 {
-   const struct of_device_id *match;
struct device *dev = >dev;
struct device_node *np = dev->of_node;
struct device_node *child_np;
@@ -1005,15 +1005,14 @@ static int mtk_tphy_probe(struct platform_device *pdev)
struct resource res;
int port, retval;
 
-   match = of_match_node(mtk_tphy_id_table, pdev->dev.of_node);
-   if (!match)
-   return -EINVAL;
-
tphy = devm_kzalloc(dev, sizeof(*tphy), GFP_KERNEL);
if (!tphy)
return -ENOMEM;
 
-   tphy->pdata = match->data;
+   tphy->pdata = of_device_get_match_data(dev);
+   if (!tphy->pdata)
+   return -EINVAL;
+
tphy->nphys = of_get_child_count(np);
tphy->phys = devm_kcalloc(dev, tphy->nphys,
  sizeof(*tphy->phys), GFP_KERNEL);
-- 
1.9.1

[PATCH 2/3] phy: phy-mtk-tphy: make shared banks optional for V1 TPHY

[Chunfeng Yun]

V1 TPHY for SATA doesn't have shared banks if it isn't shared
with PCIe or USB, so make it optional.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 5d9d7f3..d99f79b1 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1023,9 +1023,10 @@ static int mtk_tphy_probe(struct platform_device *pdev)
tphy->dev = dev;
platform_set_drvdata(pdev, tphy);
 
-   if (tphy->pdata->version == MTK_PHY_V1) {
+   sif_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   /* SATA phy of V1 needn't it if not shared with PCIe or USB */
+   if (sif_res && tphy->pdata->version == MTK_PHY_V1) {
/* get banks shared by multiple phys */
-   sif_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
tphy->sif_base = devm_ioremap_resource(dev, sif_res);
if (IS_ERR(tphy->sif_base)) {
dev_err(dev, "failed to remap sif regs\n");
-- 
1.9.1

[PATCH 1/3] phy: phy-mtk-tphy: use auto instead of force to bypass utmi signals

[Chunfeng Yun]

When system is running, if usb2 phy is forced to bypass utmi signals,
all PLL will be turned off, and it can't detect device connection
anymore, so replace force mode with auto mode which can bypass utmi
signals automatically if no device attached for normal flow.
But keep the force mode to fix RX sensitivity degradation issue.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/phy-mtk-tphy.c | 19 +++
 1 file changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index fb8aba4..5d9d7f3 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -440,9 +440,9 @@ static void u2_phy_instance_init(struct mtk_tphy *tphy,
u32 index = instance->index;
u32 tmp;
 
-   /* switch to USB function. (system register, force ip into usb mode) */
+   /* switch to USB function, and enable usb pll */
tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~P2C_FORCE_UART_EN;
+   tmp &= ~(P2C_FORCE_UART_EN | P2C_FORCE_SUSPENDM);
tmp |= P2C_RG_XCVRSEL_VAL(1) | P2C_RG_DATAIN_VAL(0);
writel(tmp, com + U3P_U2PHYDTM0);
 
@@ -502,10 +502,8 @@ static void u2_phy_instance_power_on(struct mtk_tphy *tphy,
u32 index = instance->index;
u32 tmp;
 
-   /* (force_suspendm=0) (let suspendm=1, enable usb 480MHz pll) */
tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~(P2C_FORCE_SUSPENDM | P2C_RG_XCVRSEL);
-   tmp &= ~(P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
+   tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN | P2C_DTM0_PART_MASK);
writel(tmp, com + U3P_U2PHYDTM0);
 
/* OTG Enable */
@@ -540,7 +538,6 @@ static void u2_phy_instance_power_off(struct mtk_tphy *tphy,
 
tmp = readl(com + U3P_U2PHYDTM0);
tmp &= ~(P2C_RG_XCVRSEL | P2C_RG_DATAIN);
-   tmp |= P2C_FORCE_SUSPENDM;
writel(tmp, com + U3P_U2PHYDTM0);
 
/* OTG Disable */
@@ -548,18 +545,16 @@ static void u2_phy_instance_power_off(struct mtk_tphy 
*tphy,
tmp &= ~PA6_RG_U2_OTG_VBUSCMP_EN;
writel(tmp, com + U3P_USBPHYACR6);
 
-   /* let suspendm=0, set utmi into analog power down */
-   tmp = readl(com + U3P_U2PHYDTM0);
-   tmp &= ~P2C_RG_SUSPENDM;
-   writel(tmp, com + U3P_U2PHYDTM0);
-   udelay(1);
-
tmp = readl(com + U3P_U2PHYDTM1);
tmp &= ~(P2C_RG_VBUSVALID | P2C_RG_AVALID);
tmp |= P2C_RG_SESSEND;
writel(tmp, com + U3P_U2PHYDTM1);
 
if (tphy->pdata->avoid_rx_sen_degradation && index) {
+   tmp = readl(com + U3P_U2PHYDTM0);
+   tmp &= ~(P2C_RG_SUSPENDM | P2C_FORCE_SUSPENDM);
+   writel(tmp, com + U3P_U2PHYDTM0);
+
tmp = readl(com + U3D_U2PHYDCR0);
tmp &= ~P2C_RG_SIF_U2PLL_FORCE_ON;
writel(tmp, com + U3D_U2PHYDCR0);
-- 
1.9.1