This is a note to let you know that I've just added the patch titled
target: Use system workqueue for ALUA transitions
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-use-system-workqueue-for-alua-transitions.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Mike Christie <mchristi(a)redhat.com>
Date: Wed, 1 Mar 2017 23:13:26 -0600
Subject: target: Use system workqueue for ALUA transitions
From: Mike Christie <mchristi(a)redhat.com>
[ Upstream commit 207ee84133c00a8a2a5bdec94df4a5b37d78881c ]
If tcmu-runner is processing a STPG and needs to change the kernel's
ALUA state then we cannot use the same work queue for task management
requests and ALUA transitions, because we could deadlock. The problem
occurs when a STPG times out before tcmu-runner is able to
call into target_tg_pt_gp_alua_access_state_store->
core_alua_do_port_transition -> core_alua_do_transition_tg_pt ->
queue_work. In this case, the tmr is on the work queue waiting for
the STPG to complete, but the STPG transition is now queued behind
the waiting tmr.
Note:
This bug will also be fixed by this patch:
http://www.spinics.net/lists/target-devel/msg14560.html
which switches the tmr code to use the system workqueues.
For both, I am not sure if we need a dedicated workqueue since
it is not a performance path and I do not think we need WQ_MEM_RECLAIM
to make forward progress to free up memory like the block layer does.
Signed-off-by: Mike Christie <mchristi(a)redhat.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_alua.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/target/target_core_alua.c
+++ b/drivers/target/target_core_alua.c
@@ -1126,13 +1126,11 @@ static int core_alua_do_transition_tg_pt
unsigned long transition_tmo;
transition_tmo = tg_pt_gp->tg_pt_gp_implicit_trans_secs * HZ;
- queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq,
- &tg_pt_gp->tg_pt_gp_transition_work,
- transition_tmo);
+ schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work,
+ transition_tmo);
} else {
tg_pt_gp->tg_pt_gp_transition_complete = &wait;
- queue_delayed_work(tg_pt_gp->tg_pt_gp_dev->tmr_wq,
- &tg_pt_gp->tg_pt_gp_transition_work, 0);
+ schedule_delayed_work(&tg_pt_gp->tg_pt_gp_transition_work, 0);
wait_for_completion(&wait);
tg_pt_gp->tg_pt_gp_transition_complete = NULL;
}
Patches currently in stable-queue which might be from mchristi(a)redhat.com are
queue-3.18/target-use-system-workqueue-for-alua-transitions.patch
queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
This is a note to let you know that I've just added the patch titled
target:fix condition return in core_pr_dump_initiator_port()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-fix-condition-return-in-core_pr_dump_initiator_port.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Thu, 24 Aug 2017 19:59:37 +0800
Subject: target:fix condition return in core_pr_dump_initiator_port()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 24528f089d0a444070aa4f715ace537e8d6bf168 ]
When is pr_reg->isid_present_at_reg is false,this function should return.
This fixes a regression originally introduced by:
commit d2843c173ee53cf4c12e7dfedc069a5bc76f0ac5
Author: Andy Grover <agrover(a)redhat.com>
Date: Thu May 16 10:40:55 2013 -0700
target: Alter core_pr_dump_initiator_port for ease of use
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_pr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/target/target_core_pr.c
+++ b/drivers/target/target_core_pr.c
@@ -58,8 +58,10 @@ void core_pr_dump_initiator_port(
char *buf,
u32 size)
{
- if (!pr_reg->isid_present_at_reg)
+ if (!pr_reg->isid_present_at_reg) {
buf[0] = '\0';
+ return;
+ }
snprintf(buf, size, ",i,0x%s", pr_reg->pr_reg_isid);
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-3.18/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-3.18/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
This is a note to let you know that I've just added the patch titled
target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Bart Van Assche <bart.vanassche(a)wdc.com>
Date: Tue, 31 Oct 2017 11:03:17 -0700
Subject: target/iscsi: Fix a race condition in iscsit_add_reject_from_cmd()
From: Bart Van Assche <bart.vanassche(a)wdc.com>
[ Upstream commit cfe2b621bb18d86e93271febf8c6e37622da2d14 ]
Avoid that cmd->se_cmd.se_tfo is read after a command has already been
freed.
Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Mike Christie <mchristi(a)redhat.com>
Reviewed-by: Hannes Reinecke <hare(a)suse.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target.c
+++ b/drivers/target/iscsi/iscsi_target.c
@@ -674,6 +674,7 @@ static int iscsit_add_reject_from_cmd(
unsigned char *buf)
{
struct iscsi_conn *conn;
+ const bool do_put = cmd->se_cmd.se_tfo != NULL;
if (!cmd->conn) {
pr_err("cmd->conn is NULL for ITT: 0x%08x\n",
@@ -704,7 +705,7 @@ static int iscsit_add_reject_from_cmd(
* Perform the kref_put now if se_cmd has already been setup by
* scsit_setup_scsi_cmd()
*/
- if (cmd->se_cmd.se_tfo != NULL) {
+ if (do_put) {
pr_debug("iscsi reject: calling target_put_sess_cmd >>>>>>\n");
target_put_sess_cmd(&cmd->se_cmd);
}
Patches currently in stable-queue which might be from bart.vanassche(a)wdc.com are
queue-3.18/target-iscsi-fix-a-race-condition-in-iscsit_add_reject_from_cmd.patch
This is a note to let you know that I've just added the patch titled
target/file: Do not return error for UNMAP if length is zero
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Jiang Yi <jiangyilism(a)gmail.com>
Date: Fri, 11 Aug 2017 11:29:44 +0800
Subject: target/file: Do not return error for UNMAP if length is zero
From: Jiang Yi <jiangyilism(a)gmail.com>
[ Upstream commit 594e25e73440863981032d76c9b1e33409ceff6e ]
The function fd_execute_unmap() in target_core_file.c calles
ret = file->f_op->fallocate(file, mode, pos, len);
Some filesystems implement fallocate() to return error if
length is zero (e.g. btrfs) but according to SCSI Block
Commands spec UNMAP should return success for zero length.
Signed-off-by: Jiang Yi <jiangyilism(a)gmail.com>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/target_core_file.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/target/target_core_file.c
+++ b/drivers/target/target_core_file.c
@@ -592,6 +592,10 @@ fd_do_unmap(struct se_cmd *cmd, void *pr
struct inode *inode = file->f_mapping->host;
int ret;
+ if (!nolb) {
+ return 0;
+ }
+
if (cmd->se_dev->dev_attrib.pi_prot_type) {
ret = fd_do_prot_unmap(cmd, lba, nolb);
if (ret)
Patches currently in stable-queue which might be from jiangyilism(a)gmail.com are
queue-3.18/target-file-do-not-return-error-for-unmap-if-length-is-zero.patch
This is a note to let you know that I've just added the patch titled
scsi: bfa: integer overflow in debugfs
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-bfa-integer-overflow-in-debugfs.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 4 Oct 2017 10:50:37 +0300
Subject: scsi: bfa: integer overflow in debugfs
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ 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 <dan.carpenter(a)oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/bfa/bfad_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/scsi/bfa/bfad_debugfs.c
+++ b/drivers/scsi/bfa/bfad_debugfs.c
@@ -254,7 +254,8 @@ bfad_debugfs_write_regrd(struct file *fi
struct bfad_s *bfad = port->bfad;
struct bfa_s *bfa = &bfad->bfa;
struct bfa_ioc_s *ioc = &bfa->ioc;
- int addr, len, rc, i;
+ int addr, rc, i;
+ u32 len;
u32 *regbuf;
void __iomem *rb, *reg_addr;
unsigned long flags;
@@ -274,7 +275,7 @@ bfad_debugfs_write_regrd(struct file *fi
}
rc = sscanf(kern_buf, "%x:%x", &addr, &len);
- 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__);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-3.18/scsi-bfa-integer-overflow-in-debugfs.patch
queue-3.18/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
This is a note to let you know that I've just added the patch titled
scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Kurt Garloff <garloff(a)suse.de>
Date: Tue, 17 Oct 2017 09:10:45 +0200
Subject: scsi: scsi_devinfo: Add REPORTLUN2 to EMC SYMMETRIX blacklist entry
From: Kurt Garloff <garloff(a)suse.de>
[ Upstream commit 909cf3e16a5274fe2127cf3cea5c8dba77b2c412 ]
All EMC SYMMETRIX support REPORT_LUNS, even if configured to report
SCSI-2 for whatever reason.
Signed-off-by: Kurt Garloff <garloff(a)suse.de>
Signed-off-by: Hannes Reinecke <hare(a)suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_devinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -160,7 +160,7 @@ static struct {
{"DGC", "RAID", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, storage on LUN 0 */
{"DGC", "DISK", NULL, BLIST_SPARSELUN}, /* Dell PV 650F, no storage on LUN 0 */
{"EMC", "Invista", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
- {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_FORCELUN},
+ {"EMC", "SYMMETRIX", NULL, BLIST_SPARSELUN | BLIST_LARGELUN | BLIST_REPORTLUN2},
{"EMULEX", "MD21/S2 ESDI", NULL, BLIST_SINGLELUN},
{"easyRAID", "16P", NULL, BLIST_NOREPORTLUN},
{"easyRAID", "X6P", NULL, BLIST_NOREPORTLUN},
Patches currently in stable-queue which might be from garloff(a)suse.de are
queue-3.18/scsi-scsi_devinfo-add-reportlun2-to-emc-symmetrix-blacklist-entry.patch
This is a note to let you know that I've just added the patch titled
sched/deadline: Use deadline instead of period when calculating overflow
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
Date: Thu, 2 Mar 2017 15:10:59 +0100
Subject: sched/deadline: Use deadline instead of period when calculating overflow
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
[ 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) <rostedt(a)goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Reviewed-by: Daniel Bristot de Oliveira <bristot(a)redhat.com>
Cc: Juri Lelli <juri.lelli(a)arm.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Luca Abeni <luca.abeni(a)santannapisa.it>
Cc: Mike Galbraith <efault(a)gmx.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Romulo Silva de Oliveira <romulo.deoliveira(a)ufsc.br>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tommaso Cucinotta <tommaso.cucinotta(a)sssup.it>
Link: http://lkml.kernel.org/r/02135a27f1ae3fe5fd032568a5a2f370e190e8d7.148839293…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/sched/deadline.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -368,13 +368,13 @@ static void replenish_dl_entity(struct s
*
* 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)
@@ -399,7 +399,7 @@ static bool dl_entity_overflow(struct sc
* 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);
Patches currently in stable-queue which might be from rostedt(a)goodmis.org are
queue-3.18/sched-deadline-use-deadline-instead-of-period-when-calculating-overflow.patch
This is a note to let you know that I've just added the patch titled
raid5: Set R5_Expanded on parity devices as well as data.
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: NeilBrown <neilb(a)suse.com>
Date: Tue, 17 Oct 2017 16:18:36 +1100
Subject: raid5: Set R5_Expanded on parity devices as well as data.
From: NeilBrown <neilb(a)suse.com>
[ Upstream commit 235b6003fb28f0dd8e7ed8fbdb088bb548291766 ]
When reshaping a fully degraded raid5/raid6 to a larger
nubmer of devices, the new device(s) are not in-sync
and so that can make the newly grown stripe appear to be
"failed".
To avoid this, we set the R5_Expanded flag to say "Even though
this device is not fully in-sync, this block is safe so
don't treat the device as failed for this stripe".
This flag is set for data devices, not not for parity devices.
Consequently, if you have a RAID6 with two devices that are partly
recovered and a spare, and start a reshape to include the spare,
then when the reshape gets past the point where the recovery was
up to, it will think the stripes are failed and will get into
an infinite loop, failing to make progress.
So when contructing parity on an EXPAND_READY stripe,
set R5_Expanded.
Reported-by: Curt <lightspd(a)gmail.com>
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid5.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1454,8 +1454,11 @@ static void ops_complete_reconstruct(voi
struct r5dev *dev = &sh->dev[i];
if (dev->written || i == pd_idx || i == qd_idx) {
- if (!discard && !test_bit(R5_SkipCopy, &dev->flags))
+ if (!discard && !test_bit(R5_SkipCopy, &dev->flags)) {
set_bit(R5_UPTODATE, &dev->flags);
+ if (test_bit(STRIPE_EXPAND_READY, &sh->state))
+ set_bit(R5_Expanded, &dev->flags);
+ }
if (fua)
set_bit(R5_WantFUA, &dev->flags);
if (sync)
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-3.18/autofs-fix-careless-error-in-recent-commit.patch
queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch
queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch
This is a note to let you know that I've just added the patch titled
ppp: Destroy the mutex when cleanup
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ppp-destroy-the-mutex-when-cleanup.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Gao Feng <gfree.wind(a)vip.163.com>
Date: Tue, 31 Oct 2017 18:25:37 +0800
Subject: ppp: Destroy the mutex when cleanup
From: Gao Feng <gfree.wind(a)vip.163.com>
[ Upstream commit f02b2320b27c16b644691267ee3b5c110846f49e ]
The mutex_destroy only makes sense when enable DEBUG_MUTEX. For the
good readbility, it's better to invoke it in exit func when the init
func invokes mutex_init.
Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com>
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ppp/ppp_generic.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -916,6 +916,7 @@ static __net_exit void ppp_exit_net(stru
{
struct ppp_net *pn = net_generic(net, ppp_net_id);
+ mutex_destroy(&pn->all_ppp_mutex);
idr_destroy(&pn->units_idr);
}
Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are
queue-3.18/ppp-destroy-the-mutex-when-cleanup.patch
This is a note to let you know that I've just added the patch titled
powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Shriya <shriyak(a)linux.vnet.ibm.com>
Date: Fri, 13 Oct 2017 10:06:41 +0530
Subject: powerpc/powernv/cpufreq: Fix the frequency read by /proc/cpuinfo
From: Shriya <shriyak(a)linux.vnet.ibm.com>
[ Upstream commit cd77b5ce208c153260ed7882d8910f2395bfaabd ]
The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which
returns the last frequency requested by the kernel, but may not
reflect the actual frequency the processor is running at. This patch
makes a call to cpufreq_get() instead which returns the current
frequency reported by the hardware.
Fixes: fb5153d05a7d ("powerpc: powernv: Implement ppc_md.get_proc_freq()")
Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/powernv/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -319,7 +319,7 @@ static unsigned long pnv_get_proc_freq(u
{
unsigned long ret_freq;
- ret_freq = cpufreq_quick_get(cpu) * 1000ul;
+ ret_freq = cpufreq_get(cpu) * 1000ul;
/*
* If the backend cpufreq driver does not exist,
Patches currently in stable-queue which might be from shriyak(a)linux.vnet.ibm.com are
queue-3.18/powerpc-powernv-cpufreq-fix-the-frequency-read-by-proc-cpuinfo.patch
This is a note to let you know that I've just added the patch titled
powerpc/opal: Fix EBUSY bug in acquiring tokens
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: "William A. Kennington III" <wak(a)google.com>
Date: Fri, 22 Sep 2017 16:58:00 -0700
Subject: powerpc/opal: Fix EBUSY bug in acquiring tokens
From: "William A. Kennington III" <wak(a)google.com>
[ Upstream commit 71e24d7731a2903b1ae2bba2b2971c654d9c2aa6 ]
The current code checks the completion map to look for the first token
that is complete. In some cases, a completion can come in but the
token can still be on lease to the caller processing the completion.
If this completed but unreleased token is the first token found in the
bitmap by another tasks trying to acquire a token, then the
__test_and_set_bit call will fail since the token will still be on
lease. The acquisition will then fail with an EBUSY.
This patch reorganizes the acquisition code to look at the
opal_async_token_map for an unleased token. If the token has no lease
it must have no outstanding completions so we should never see an
EBUSY, unless we have leased out too many tokens. Since
opal_async_get_token_inrerruptible is protected by a semaphore, we
will practically never see EBUSY anymore.
Fixes: 8d7248232208 ("powerpc/powernv: Infrastructure to support OPAL async completion")
Signed-off-by: William A. Kennington III <wak(a)google.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/platforms/powernv/opal-async.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/powerpc/platforms/powernv/opal-async.c
+++ b/arch/powerpc/platforms/powernv/opal-async.c
@@ -39,18 +39,18 @@ int __opal_async_get_token(void)
int token;
spin_lock_irqsave(&opal_async_comp_lock, flags);
- token = find_first_bit(opal_async_complete_map, opal_max_async_tokens);
+ token = find_first_zero_bit(opal_async_token_map, opal_max_async_tokens);
if (token >= opal_max_async_tokens) {
token = -EBUSY;
goto out;
}
- if (__test_and_set_bit(token, opal_async_token_map)) {
+ if (!__test_and_clear_bit(token, opal_async_complete_map)) {
token = -EBUSY;
goto out;
}
- __clear_bit(token, opal_async_complete_map);
+ __set_bit(token, opal_async_token_map);
out:
spin_unlock_irqrestore(&opal_async_comp_lock, flags);
Patches currently in stable-queue which might be from wak(a)google.com are
queue-3.18/powerpc-opal-fix-ebusy-bug-in-acquiring-tokens.patch
This is a note to let you know that I've just added the patch titled
platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Markus Elfring <elfring(a)users.sourceforge.net>
Date: Wed, 1 Nov 2017 18:42:45 +0100
Subject: platform/x86: sony-laptop: Fix error handling in sony_nc_setup_rfkill()
From: Markus Elfring <elfring(a)users.sourceforge.net>
[ Upstream commit f6c8a317ab208aee223776327c06f23342492d54 ]
Source code review for a specific software refactoring showed the need
for another correction because the error code "-1" was returned so far
if a call of the function "sony_call_snc_handle" failed here.
Thus assign the return value from these two function calls also to
the variable "err" and provide it in case of a failure.
Fixes: d6f15ed876b83a1a0eba1d0473eef58acc95444a ("sony-laptop: use soft rfkill status stored in hw")
Suggested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com>
Link: https://lkml.org/lkml/2017/10/31/463
Link: https://lkml.kernel.org/r/<CAHp75VcMkXCioCzmLE0+BTmkqc5RSOx9yPO0ectVHMrMvewgwg(a)mail.gmail.com>
Signed-off-by: Markus Elfring <elfring(a)users.sourceforge.net>
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/platform/x86/sony-laptop.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1654,17 +1654,19 @@ static int sony_nc_setup_rfkill(struct a
if (!rfk)
return -ENOMEM;
- if (sony_call_snc_handle(sony_rfkill_handle, 0x200, &result) < 0) {
+ err = sony_call_snc_handle(sony_rfkill_handle, 0x200, &result);
+ if (err < 0) {
rfkill_destroy(rfk);
- return -1;
+ return err;
}
hwblock = !(result & 0x1);
- if (sony_call_snc_handle(sony_rfkill_handle,
- sony_rfkill_address[nc_type],
- &result) < 0) {
+ err = sony_call_snc_handle(sony_rfkill_handle,
+ sony_rfkill_address[nc_type],
+ &result);
+ if (err < 0) {
rfkill_destroy(rfk);
- return -1;
+ return err;
}
swblock = !(result & 0x2);
Patches currently in stable-queue which might be from elfring(a)users.sourceforge.net are
queue-3.18/platform-x86-sony-laptop-fix-error-handling-in-sony_nc_setup_rfkill.patch
This is a note to let you know that I've just added the patch titled
pinctrl: adi2: Fix Kconfig build problem
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pinctrl-adi2-fix-kconfig-build-problem.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Linus Walleij <linus.walleij(a)linaro.org>
Date: Wed, 11 Oct 2017 11:57:15 +0200
Subject: pinctrl: adi2: Fix Kconfig build problem
From: Linus Walleij <linus.walleij(a)linaro.org>
[ Upstream commit 1c363531dd814dc4fe10865722bf6b0f72ce4673 ]
The build robot is complaining on Blackfin:
drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
>> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
pointer to incomplete type 'struct gpio_port_t'
writew(readw(®s->port_fer) & ~BIT(offset),
^~
drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
>> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
pointer to incomplete type 'struct bfin_pint_regs'
if (readl(®s->invert_set) & pintbit)
^~
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.
The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.
Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.
Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.
This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.
Cc: Steven Miao <realmz6(a)gmail.com>
Cc: Huanhuan Feng <huanhuan.feng(a)analog.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/blackfin/Kconfig | 7 +++++--
arch/blackfin/Kconfig.debug | 1 +
drivers/pinctrl/Kconfig | 3 ++-
3 files changed, 8 insertions(+), 3 deletions(-)
--- a/arch/blackfin/Kconfig
+++ b/arch/blackfin/Kconfig
@@ -318,11 +318,14 @@ config BF53x
config GPIO_ADI
def_bool y
+ depends on !PINCTRL
depends on (BF51x || BF52x || BF53x || BF538 || BF539 || BF561)
-config PINCTRL
+config PINCTRL_BLACKFIN_ADI2
def_bool y
- depends on BF54x || BF60x
+ depends on (BF54x || BF60x)
+ select PINCTRL
+ select PINCTRL_ADI2
config MEM_MT48LC64M4A2FB_7E
bool
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -17,6 +17,7 @@ config DEBUG_VERBOSE
config DEBUG_MMRS
tristate "Generate Blackfin MMR tree"
+ depends on !PINCTRL
select DEBUG_FS
help
Create a tree of Blackfin MMRs via the debugfs tree. If
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -28,7 +28,8 @@ config DEBUG_PINCTRL
config PINCTRL_ADI2
bool "ADI pin controller driver"
- depends on BLACKFIN
+ depends on (BF54x || BF60x)
+ depends on !GPIO_ADI
select PINMUX
select IRQ_DOMAIN
help
Patches currently in stable-queue which might be from linus.walleij(a)linaro.org are
queue-3.18/pinctrl-adi2-fix-kconfig-build-problem.patch
This is a note to let you know that I've just added the patch titled
powerpc/ipic: Fix status get and status clear
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-ipic-fix-status-get-and-status-clear.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Wed, 18 Oct 2017 11:16:47 +0200
Subject: powerpc/ipic: Fix status get and status clear
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
[ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ]
IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
which is the mask register.
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/sysdev/ipic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -844,12 +844,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq
u32 ipic_get_mcp_status(void)
{
- return ipic_read(primary_ipic->regs, IPIC_SERMR);
+ return ipic_read(primary_ipic->regs, IPIC_SERSR);
}
void ipic_clear_mcp_status(u32 mask)
{
- ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
+ ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
}
/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
Patches currently in stable-queue which might be from christophe.leroy(a)c-s.fr are
queue-3.18/powerpc-ipic-fix-status-get-and-status-clear.patch
This is a note to let you know that I've just added the patch titled
perf symbols: Fix symbols__fixup_end heuristic for corner cases
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Daniel Borkmann <daniel(a)iogearbox.net>
Date: Wed, 15 Mar 2017 22:53:37 +0100
Subject: perf symbols: Fix symbols__fixup_end heuristic for corner cases
From: Daniel Borkmann <daniel(a)iogearbox.net>
[ Upstream commit e7ede72a6d40cb3a30c087142d79381ca8a31dab ]
The current symbols__fixup_end() heuristic for the last entry in the rb
tree is suboptimal as it leads to not being able to recognize the symbol
in the call graph in a couple of corner cases, for example:
i) If the symbol has a start address (f.e. exposed via kallsyms)
that is at a page boundary, then the roundup(curr->start, 4096)
for the last entry will result in curr->start == curr->end with
a symbol length of zero.
ii) If the symbol has a start address that is shortly before a page
boundary, then also here, curr->end - curr->start will just be
very few bytes, where it's unrealistic that we could perform a
match against.
Instead, change the heuristic to roundup(curr->start, 4096) + 4096, so
that we can catch such corner cases and have a better chance to find
that specific symbol. It's still just best effort as the real end of the
symbol is unknown to us (and could even be at a larger offset than the
current range), but better than the current situation.
Alexei reported that he recently run into case i) with a JITed eBPF
program (these are all page aligned) as the last symbol which wasn't
properly shown in the call graph (while other eBPF program symbols in
the rb tree were displayed correctly). Since this is a generic issue,
lets try to improve the heuristic a bit.
Reported-and-Tested-by: Alexei Starovoitov <ast(a)kernel.org>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Fixes: 2e538c4a1847 ("perf tools: Improve kernel/modules symbol lookup")
Link: http://lkml.kernel.org/r/bb5c80d27743be6f12afc68405f1956a330e1bc9.148961436…
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
tools/perf/util/symbol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -191,7 +191,7 @@ void symbols__fixup_end(struct rb_root *
/* Last entry */
if (curr->end == curr->start)
- curr->end = roundup(curr->start, 4096);
+ curr->end = roundup(curr->start, 4096) + 4096;
}
void __map_groups__fixup_end(struct map_groups *mg, enum map_type type)
Patches currently in stable-queue which might be from daniel(a)iogearbox.net are
queue-3.18/perf-symbols-fix-symbols__fixup_end-heuristic-for-corner-cases.patch
This is a note to let you know that I've just added the patch titled
PCI/PME: Handle invalid data when reading Root Status
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-pme-handle-invalid-data-when-reading-root-status.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Qiang <zhengqiang10(a)huawei.com>
Date: Thu, 28 Sep 2017 11:54:34 +0800
Subject: PCI/PME: Handle invalid data when reading Root Status
From: Qiang <zhengqiang10(a)huawei.com>
[ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ]
PCIe PME and native hotplug share the same interrupt number, so hotplug
interrupts are also processed by PME. In some cases, e.g., a Link Down
interrupt, a device may be present but unreachable, so when we try to
read its Root Status register, the read fails and we get all ones data
(0xffffffff).
Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
"some device has asserted PME," so we scheduled pcie_pme_work_fn(). This
caused an infinite loop because pcie_pme_work_fn() tried to handle PME
requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
PCI_EXP_RTSTA_PME can't be cleared.
Check for the invalid 0xffffffff data everywhere we read the Root Status
register.
1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
non-existent devices") added similar checks in the hotplug driver.
Signed-off-by: Qiang Zheng <zhengqiang10(a)huawei.com>
[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
other similar checks]
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/pcie/pme.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -233,6 +233,9 @@ static void pcie_pme_work_fn(struct work
break;
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
+ if (rtsta == (u32) ~0)
+ break;
+
if (rtsta & PCI_EXP_RTSTA_PME) {
/*
* Clear PME status of the port. If there are other
@@ -280,7 +283,7 @@ static irqreturn_t pcie_pme_irq(int irq,
spin_lock_irqsave(&data->lock, flags);
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (!(rtsta & PCI_EXP_RTSTA_PME)) {
+ if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
spin_unlock_irqrestore(&data->lock, flags);
return IRQ_NONE;
}
Patches currently in stable-queue which might be from zhengqiang10(a)huawei.com are
queue-3.18/pci-pme-handle-invalid-data-when-reading-root-status.patch
This is a note to let you know that I've just added the patch titled
PCI: Detach driver before procfs & sysfs teardown on device remove
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Alex Williamson <alex.williamson(a)redhat.com>
Date: Wed, 11 Oct 2017 15:35:56 -0600
Subject: PCI: Detach driver before procfs & sysfs teardown on device remove
From: Alex Williamson <alex.williamson(a)redhat.com>
[ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ]
When removing a device, for example a VF being removed due to SR-IOV
teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
hot-unplug, we first remove the procfs and sysfs attributes for the device
before attempting to release the device from any driver bound to it.
Unbinding the driver from the device can take time. The device might need
to write out data or it might be actively in use. If it's in use by
userspace through a vfio driver, the unbind might block until the user
releases the device. This leads to a potentially non-trivial amount of
time where the device exists, but we've torn down the interfaces that
userspace uses to examine devices, for instance lspci might generate this
sort of error:
pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
lspci: Unable to read the standard configuration space header of device 0000:01:0a.3
We don't seem to have any dependence on this teardown ordering in the
kernel, so let's unbind the driver first, which is also more symmetric with
the instantiation of the device in pci_bus_add_device().
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/remove.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -20,9 +20,9 @@ static void pci_stop_dev(struct pci_dev
pci_pme_active(dev, false);
if (dev->is_added) {
+ device_release_driver(&dev->dev);
pci_proc_detach_device(dev);
pci_remove_sysfs_dev_files(dev);
- device_release_driver(&dev->dev);
dev->is_added = 0;
}
Patches currently in stable-queue which might be from alex.williamson(a)redhat.com are
queue-3.18/pci-detach-driver-before-procfs-sysfs-teardown-on-device-remove.patch
This is a note to let you know that I've just added the patch titled
openrisc: fix issue handling 8 byte get_user calls
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
openrisc-fix-issue-handling-8-byte-get_user-calls.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Stafford Horne <shorne(a)gmail.com>
Date: Mon, 13 Mar 2017 07:44:45 +0900
Subject: openrisc: fix issue handling 8 byte get_user calls
From: Stafford Horne <shorne(a)gmail.com>
[ Upstream commit 154e67cd8e8f964809d0e75e44bb121b169c75b3 ]
Was getting the following error with allmodconfig:
ERROR: "__get_user_bad" [lib/test_user_copy.ko] undefined!
This was simply a missing break statement, causing an unwanted fall
through.
Signed-off-by: Stafford Horne <shorne(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/openrisc/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/openrisc/include/asm/uaccess.h
+++ b/arch/openrisc/include/asm/uaccess.h
@@ -215,7 +215,7 @@ do { \
case 1: __get_user_asm(x, ptr, retval, "l.lbz"); break; \
case 2: __get_user_asm(x, ptr, retval, "l.lhz"); break; \
case 4: __get_user_asm(x, ptr, retval, "l.lwz"); break; \
- case 8: __get_user_asm2(x, ptr, retval); \
+ case 8: __get_user_asm2(x, ptr, retval); break; \
default: (x) = __get_user_bad(); \
} \
} while (0)
Patches currently in stable-queue which might be from shorne(a)gmail.com are
queue-3.18/openrisc-fix-issue-handling-8-byte-get_user-calls.patch
This is a note to let you know that I've just added the patch titled
dmaengine: rcar-dmac: use TCRB instead of TCR for residue
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 13:28:59 CET 2017
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
Date: Thu, 19 Oct 2017 01:15:13 +0000
Subject: dmaengine: rcar-dmac: use TCRB instead of TCR for residue
From: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[ Upstream commit 847449f23dcbff68234525f90dd53c7c7db18cad ]
SYS/RT/Audio DMAC includes independent data buffers for reading
and writing. Therefore, the read transfer counter and write transfer
counter have different values.
TCR indicates read counter, and TCRB indicates write counter.
The relationship is like below.
TCR TCRB
[SOURCE] -> [DMAC] -> [SINK]
In the MEM_TO_DEV direction, what really matters is how much data has
been written to the device. If the DMA is interrupted between read and
write, then, the data doesn't end up in the destination, so shouldn't
be counted. TCRB is thus the register we should use in this cases.
In the DEV_TO_MEM direction, the situation is more complex. Both the
read and write side are important. What matters from a data consumer
point of view is how much data has been written to memory.
On the other hand, if the transfer is interrupted between read and
write, we'll end up losing data. It can also be important to report.
In the MEM_TO_MEM direction, what matters is of course how much data
has been written to memory from data consumer point of view.
Here, because read and write have independent data buffers, it will
take a while for TCR and TCRB to become equal. Thus we should check
TCRB in this case, too.
Thus, all cases we should check TCRB instead of TCR.
Without this patch, Sound Capture has noise after PluseAudio support
(= 07b7acb51d2 ("ASoC: rsnd: update pointer more accurate")), because
the recorder will use wrong residue counter which indicates transferred
from sound device, but in reality the data was not yet put to memory
and recorder will record it.
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx(a)renesas.com>
[Kuninori: added detail information in log]
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Signed-off-by: Vinod Koul <vinod.koul(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/dma/sh/rcar-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/dma/sh/rcar-dmac.c
+++ b/drivers/dma/sh/rcar-dmac.c
@@ -1310,7 +1310,7 @@ static unsigned int rcar_dmac_chan_get_r
}
/* Add the residue for the current chunk. */
- residue += rcar_dmac_chan_read(chan, RCAR_DMATCR) << desc->xfer_shift;
+ residue += rcar_dmac_chan_read(chan, RCAR_DMATCRB) << desc->xfer_shift;
return residue;
}
Patches currently in stable-queue which might be from hiroyuki.yokoyama.vx(a)renesas.com are
queue-4.14/dmaengine-rcar-dmac-use-tcrb-instead-of-tcr-for-residue.patch
This is a note to let you know that I've just added the patch titled
NFSv4.1 respect server's max size in CREATE_SESSION
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsv4.1-respect-server-s-max-size-in-create_session.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Olga Kornievskaia <kolga(a)netapp.com>
Date: Wed, 8 Mar 2017 14:39:15 -0500
Subject: NFSv4.1 respect server's max size in CREATE_SESSION
From: Olga Kornievskaia <kolga(a)netapp.com>
[ 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 <kolga(a)netapp.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker(a)Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfs/nfs4client.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/fs/nfs/nfs4client.c
+++ b/fs/nfs/nfs4client.c
@@ -894,9 +894,9 @@ static void nfs4_session_set_rwsize(stru
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 */
}
Patches currently in stable-queue which might be from kolga(a)netapp.com are
queue-3.18/nfsv4.1-respect-server-s-max-size-in-create_session.patch
This is a note to let you know that I've just added the patch titled
NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: NeilBrown <neilb(a)suse.com>
Date: Fri, 10 Mar 2017 11:36:39 +1100
Subject: NFSD: fix nfsd_minorversion(.., NFSD_AVAIL)
From: NeilBrown <neilb(a)suse.com>
[ Upstream commit 928c6fb3a9bfd6c5b287aa3465226add551c13c0 ]
Current code will return 1 if the version is supported,
and -1 if it isn't.
This is confusing and inconsistent with the one place where this
is used.
So change to return 1 if it is supported, and zero if not.
i.e. an error is never returned.
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfssvc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -150,7 +150,8 @@ int nfsd_vers(int vers, enum vers_op cha
int nfsd_minorversion(u32 minorversion, enum vers_op change)
{
- if (minorversion > NFSD_SUPPORTED_MINOR_VERSION)
+ if (minorversion > NFSD_SUPPORTED_MINOR_VERSION &&
+ change != NFSD_AVAIL)
return -1;
switch(change) {
case NFSD_SET:
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-3.18/autofs-fix-careless-error-in-recent-commit.patch
queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch
queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch
This is a note to let you know that I've just added the patch titled
NFSD: fix nfsd_reset_versions for NFSv4.
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
nfsd-fix-nfsd_reset_versions-for-nfsv4.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: NeilBrown <neilb(a)suse.com>
Date: Fri, 10 Mar 2017 11:36:39 +1100
Subject: NFSD: fix nfsd_reset_versions for NFSv4.
From: NeilBrown <neilb(a)suse.com>
[ Upstream commit 800a938f0bf9130c8256116649c0cc5806bfb2fd ]
If you write "-2 -3 -4" to the "versions" file, it will
notice that no versions are enabled, and nfsd_reset_versions()
is called.
This enables all major versions, not no minor versions.
So we lose the invariant that NFSv4 is only advertised when
at least one minor is enabled.
Fix the code to explicitly enable minor versions for v4,
change it to use nfsd_vers() to test and set, and simplify
the code.
Signed-off-by: NeilBrown <neilb(a)suse.com>
Signed-off-by: J. Bruce Fields <bfields(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
fs/nfsd/nfssvc.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
--- a/fs/nfsd/nfssvc.c
+++ b/fs/nfsd/nfssvc.c
@@ -329,23 +329,20 @@ static void nfsd_last_thread(struct svc_
void nfsd_reset_versions(void)
{
- int found_one = 0;
int i;
- for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++) {
- if (nfsd_program.pg_vers[i])
- found_one = 1;
- }
+ for (i = 0; i < NFSD_NRVERS; i++)
+ if (nfsd_vers(i, NFSD_TEST))
+ return;
- if (!found_one) {
- for (i = NFSD_MINVERS; i < NFSD_NRVERS; i++)
- nfsd_program.pg_vers[i] = nfsd_version[i];
-#if defined(CONFIG_NFSD_V2_ACL) || defined(CONFIG_NFSD_V3_ACL)
- for (i = NFSD_ACL_MINVERS; i < NFSD_ACL_NRVERS; i++)
- nfsd_acl_program.pg_vers[i] =
- nfsd_acl_version[i];
-#endif
- }
+ for (i = 0; i < NFSD_NRVERS; i++)
+ if (i != 4)
+ nfsd_vers(i, NFSD_SET);
+ else {
+ int minor = 0;
+ while (nfsd_minorversion(minor, NFSD_SET) >= 0)
+ minor++;
+ }
}
/*
Patches currently in stable-queue which might be from neilb(a)suse.com are
queue-3.18/autofs-fix-careless-error-in-recent-commit.patch
queue-3.18/raid5-set-r5_expanded-on-parity-devices-as-well-as-data.patch
queue-3.18/nfsd-fix-nfsd_reset_versions-for-nfsv4.patch
queue-3.18/nfsd-fix-nfsd_minorversion-..-nfsd_avail.patch
This is a note to let you know that I've just added the patch titled
net: wimax/i2400m: fix NULL-deref at probe
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-wimax-i2400m-fix-null-deref-at-probe.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Johan Hovold <johan(a)kernel.org>
Date: Mon, 13 Mar 2017 13:42:03 +0100
Subject: net: wimax/i2400m: fix NULL-deref at probe
From: Johan Hovold <johan(a)kernel.org>
[ Upstream commit 6e526fdff7be4f13b24f929a04c0e9ae6761291e ]
Make sure to check the number of endpoints to avoid dereferencing a
NULL-pointer or accessing memory beyond the endpoint array should a
malicious device lack the expected endpoints.
The endpoints are specifically dereferenced in the i2400m_bootrom_init
path during probe (e.g. in i2400mu_tx_bulk_out).
Fixes: f398e4240fce ("i2400m/USB: probe/disconnect, dev init/shutdown
and reset backends")
Cc: Inaky Perez-Gonzalez <inaky(a)linux.intel.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/wimax/i2400m/usb.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/net/wimax/i2400m/usb.c
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -467,6 +467,9 @@ int i2400mu_probe(struct usb_interface *
struct i2400mu *i2400mu;
struct usb_device *usb_dev = interface_to_usbdev(iface);
+ if (iface->cur_altsetting->desc.bNumEndpoints < 4)
+ return -ENODEV;
+
if (usb_dev->speed != USB_SPEED_HIGH)
dev_err(dev, "device not connected as high speed\n");
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-3.18/net-wimax-i2400m-fix-null-deref-at-probe.patch
This is a note to let you know that I've just added the patch titled
net: Resend IGMP memberships upon peer notification.
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-resend-igmp-memberships-upon-peer-notification.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Vlad Yasevich <vyasevich(a)gmail.com>
Date: Tue, 14 Mar 2017 08:58:08 -0400
Subject: net: Resend IGMP memberships upon peer notification.
From: Vlad Yasevich <vyasevich(a)gmail.com>
[ 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 <vyasevic(a)redhat.com>
Acked-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/core/dev.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1248,6 +1248,7 @@ void netdev_notify_peers(struct net_devi
{
rtnl_lock();
call_netdevice_notifiers(NETDEV_NOTIFY_PEERS, dev);
+ call_netdevice_notifiers(NETDEV_RESEND_IGMP, dev);
rtnl_unlock();
}
EXPORT_SYMBOL(netdev_notify_peers);
Patches currently in stable-queue which might be from vyasevich(a)gmail.com are
queue-3.18/net-resend-igmp-memberships-upon-peer-notification.patch
This is a note to let you know that I've just added the patch titled
net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Mon Dec 18 15:03:25 CET 2017
From: Doug Berger <opendmb(a)gmail.com>
Date: Thu, 9 Mar 2017 16:58:43 -0800
Subject: net: bcmgenet: correct the RBUF_OVFL_CNT and RBUF_ERR_CNT MIB values
From: Doug Berger <opendmb(a)gmail.com>
[ Upstream commit ffff71328a3c321f7c14cc1edd33577717037744 ]
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 <opendmb(a)gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 60 ++++++++++++++++++++++---
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 10 ++--
2 files changed, 60 insertions(+), 10 deletions(-)
--- 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 bcmge
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
}
}
+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
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;
}
--- 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 modify
* it under the terms of the GNU General Public License version 2 as
@@ -196,7 +196,9 @@ struct bcmgenet_mib_counters {
#define MDIO_REG_SHIFT 16
#define MDIO_REG_MASK 0x1F
-#define UMAC_RBUF_OVFL_CNT 0x61C
+#define UMAC_RBUF_OVFL_CNT_V1 0x61C
+#define RBUF_OVFL_CNT_V2 0x80
+#define RBUF_OVFL_CNT_V3PLUS 0x94
#define UMAC_MPD_CTRL 0x620
#define MPD_EN (1 << 0)
@@ -206,7 +208,9 @@ struct bcmgenet_mib_counters {
#define UMAC_MPD_PW_MS 0x624
#define UMAC_MPD_PW_LS 0x628
-#define UMAC_RBUF_ERR_CNT 0x634
+#define UMAC_RBUF_ERR_CNT_V1 0x634
+#define RBUF_ERR_CNT_V2 0x84
+#define RBUF_ERR_CNT_V3PLUS 0x98
#define UMAC_MDF_ERR_CNT 0x638
#define UMAC_MDF_CTRL 0x650
#define UMAC_MDF_ADDR 0x654
Patches currently in stable-queue which might be from opendmb(a)gmail.com are
queue-3.18/net-bcmgenet-correct-the-rbuf_ovfl_cnt-and-rbuf_err_cnt-mib-values.patch
queue-3.18/net-bcmgenet-correct-mib-access-of-unimac-runt-counters.patch
queue-3.18/net-bcmgenet-power-up-the-internal-phy-before-probing-the-mii.patch