* [Intel-wired-lan] [PATCH v2 05/13] ice: Clean control queues only when they are initialized
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723220520.16678-1-anirudh.venkataramanan@intel.com>
From: Preethi Banala <preethi.banala@intel.com>
Clean control queues only when they are initialized. One of the ways to
validate if the basic initialization is done is by checking value of
cq->sq.head and cq->rq.head variables that specify the register address.
This patch adds a check to avoid NULL pointer dereference crash when tried
to shutdown uninitialized control queue.
Signed-off-by: Preethi Banala <preethi.banala@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_controlq.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_controlq.c b/drivers/net/ethernet/intel/ice/ice_controlq.c
index 7c511f144ed6..c064416080e7 100644
--- a/drivers/net/ethernet/intel/ice/ice_controlq.c
+++ b/drivers/net/ethernet/intel/ice/ice_controlq.c
@@ -597,10 +597,14 @@ static enum ice_status ice_init_check_adminq(struct ice_hw *hw)
return 0;
init_ctrlq_free_rq:
- ice_shutdown_rq(hw, cq);
- ice_shutdown_sq(hw, cq);
- mutex_destroy(&cq->sq_lock);
- mutex_destroy(&cq->rq_lock);
+ if (cq->rq.head) {
+ ice_shutdown_rq(hw, cq);
+ mutex_destroy(&cq->rq_lock);
+ }
+ if (cq->sq.head) {
+ ice_shutdown_sq(hw, cq);
+ mutex_destroy(&cq->sq_lock);
+ }
return status;
}
@@ -706,10 +710,14 @@ static void ice_shutdown_ctrlq(struct ice_hw *hw, enum ice_ctl_q q_type)
return;
}
- ice_shutdown_sq(hw, cq);
- ice_shutdown_rq(hw, cq);
- mutex_destroy(&cq->sq_lock);
- mutex_destroy(&cq->rq_lock);
+ if (cq->sq.head) {
+ ice_shutdown_sq(hw, cq);
+ mutex_destroy(&cq->sq_lock);
+ }
+ if (cq->rq.head) {
+ ice_shutdown_rq(hw, cq);
+ mutex_destroy(&cq->rq_lock);
+ }
}
/**
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v2 04/13] ice: Report stats for allocated queues via ethtool stats
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723220520.16678-1-anirudh.venkataramanan@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
It is not safe to have the string table for statistics change order or
size over the lifetime of a given netdevice. This is because of the
nature of the 3-step process for obtaining stats. First, userspace
performs a request for the size of the strings table. Second it performs
a separate request for the strings themselves, after allocating space
for the table. Third, it requests the stats themselves, also allocating
space for the table.
If the size decreased, there is potential to see garbage data or stats
values. In the worst case, we could potentially see stats values become
mis-aligned with their strings, so that it looks like a statistic is
being reported differently than it actually is.
Even worse, if the size increased, there is potential that the strings
table or stats table was not allocated large enough and the stats code
could access and write to memory it should not, potentially resulting in
undefined behavior and system crashes.
It isn't even safe if the size always changes under the RTNL lock. This
is because the calls take place over multiple userspace commands, so it
is not possible to hold the RTNL lock for the entire duration of
obtaining strings and stats. Further, not all consumers of the ethtool
API are the userspace ethtool program, and it is possible that one
assumes the strings will not change (valid under the current contract),
and thus only requests the stats values when requesting stats in a loop.
Finally, it's not possible in the general case to detect when the size
changes, because it is quite possible that one value which could impact
the stat size increased, while another decreased. This would result in
the same total number of stats, but reordering them so that stats no
longer line up with the strings they belong to. Since only size changes
aren't enough, we would need some sort of hash or token to determine
when the strings no longer match. This would require extending the
ethtool stats commands, but there is no more space in the relevant
structures.
The real solution to resolve this would be to add a completely new API
for stats, probably over netlink.
In the ice driver, the only thing impacting the stats that is not
constant is the number of queues. Instead of reporting stats for each
used queue, report stats for each allocated queue. We do not change the
number of queues allocated for a given netdevice, as we pass this into
the alloc_etherdev_mq() function to set the num_tx_queues and
num_rx_queues.
This resolves the potential bugs at the slight cost of displaying many
queue statistics which will not be activated.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
---
drivers/net/ethernet/intel/ice/ice.h | 7 ++++
drivers/net/ethernet/intel/ice/ice_ethtool.c | 52 +++++++++++++++++++++-------
2 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index d8b5fff581e7..ed071ea75f20 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -89,6 +89,13 @@ extern const char ice_drv_ver[];
#define ice_for_each_rxq(vsi, i) \
for ((i) = 0; (i) < (vsi)->num_rxq; (i)++)
+/* Macros for each allocated tx/rx ring whether used or not in a VSI */
+#define ice_for_each_alloc_txq(vsi, i) \
+ for ((i) = 0; (i) < (vsi)->alloc_txq; (i)++)
+
+#define ice_for_each_alloc_rxq(vsi, i) \
+ for ((i) = 0; (i) < (vsi)->alloc_rxq; (i)++)
+
struct ice_tc_info {
u16 qoffset;
u16 qcount;
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index 1db304c01d10..807b683a5707 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -26,7 +26,7 @@ static int ice_q_stats_len(struct net_device *netdev)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
- return ((np->vsi->num_txq + np->vsi->num_rxq) *
+ return ((np->vsi->alloc_txq + np->vsi->alloc_rxq) *
(sizeof(struct ice_q_stats) / sizeof(u64)));
}
@@ -218,7 +218,7 @@ static void ice_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
p += ETH_GSTRING_LEN;
}
- ice_for_each_txq(vsi, i) {
+ ice_for_each_alloc_txq(vsi, i) {
snprintf(p, ETH_GSTRING_LEN,
"tx-queue-%u.tx_packets", i);
p += ETH_GSTRING_LEN;
@@ -226,7 +226,7 @@ static void ice_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
p += ETH_GSTRING_LEN;
}
- ice_for_each_rxq(vsi, i) {
+ ice_for_each_alloc_rxq(vsi, i) {
snprintf(p, ETH_GSTRING_LEN,
"rx-queue-%u.rx_packets", i);
p += ETH_GSTRING_LEN;
@@ -253,6 +253,24 @@ static int ice_get_sset_count(struct net_device *netdev, int sset)
{
switch (sset) {
case ETH_SS_STATS:
+ /* The number (and order) of strings reported *must* remain
+ * constant for a given netdevice. This function must not
+ * report a different number based on run time parameters
+ * (such as the number of queues in use, or the setting of
+ * a private ethtool flag). This is due to the nature of the
+ * ethtool stats API.
+ *
+ * Userspace programs such as ethtool must make 3 separate
+ * ioctl requests, one for size, one for the strings, and
+ * finally one for the stats. Since these cross into
+ * userspace, changes to the number or size could result in
+ * undefined memory access or incorrect string<->value
+ * correlations for statistics.
+ *
+ * Even if it appears to be safe, changes to the size or
+ * order of strings will suffer from race conditions and are
+ * not safe.
+ */
return ICE_ALL_STATS_LEN(netdev);
default:
return -EOPNOTSUPP;
@@ -280,18 +298,26 @@ ice_get_ethtool_stats(struct net_device *netdev,
/* populate per queue stats */
rcu_read_lock();
- ice_for_each_txq(vsi, j) {
+ ice_for_each_alloc_txq(vsi, j) {
ring = READ_ONCE(vsi->tx_rings[j]);
- if (!ring)
- continue;
- data[i++] = ring->stats.pkts;
- data[i++] = ring->stats.bytes;
+ if (ring) {
+ data[i++] = ring->stats.pkts;
+ data[i++] = ring->stats.bytes;
+ } else {
+ data[i++] = 0;
+ data[i++] = 0;
+ }
}
- ice_for_each_rxq(vsi, j) {
+ ice_for_each_alloc_rxq(vsi, j) {
ring = READ_ONCE(vsi->rx_rings[j]);
- data[i++] = ring->stats.pkts;
- data[i++] = ring->stats.bytes;
+ if (ring) {
+ data[i++] = ring->stats.pkts;
+ data[i++] = ring->stats.bytes;
+ } else {
+ data[i++] = 0;
+ data[i++] = 0;
+ }
}
rcu_read_unlock();
@@ -519,7 +545,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring)
goto done;
}
- for (i = 0; i < vsi->num_txq; i++) {
+ for (i = 0; i < vsi->alloc_txq; i++) {
/* clone ring and setup updated count */
tx_rings[i] = *vsi->tx_rings[i];
tx_rings[i].count = new_tx_cnt;
@@ -551,7 +577,7 @@ ice_set_ringparam(struct net_device *netdev, struct ethtool_ringparam *ring)
goto done;
}
- for (i = 0; i < vsi->num_rxq; i++) {
+ for (i = 0; i < vsi->alloc_rxq; i++) {
/* clone ring and setup updated count */
rx_rings[i] = *vsi->rx_rings[i];
rx_rings[i].count = new_rx_cnt;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v2 03/13] ice: Fix missing shift
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723220520.16678-1-anirudh.venkataramanan@intel.com>
From: Bruce Allan <bruce.w.allan@intel.com>
The ITR index of the interrupt cause for OICR and FW interrupts is not
being shifted correctly so when masked with PFINT_*_CTL_ITR_INDX_M it
will always be zero. Luckily, ICE_RX_ITR is zero anyway so the end result
is the same, but the shift should be fixed in case the value of ICE_RX_ITR
ever changes or it is substituted with another value that needs to be
shifted properly.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
[Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> cleaned up commit message]
---
drivers/net/ethernet/intel/ice/ice_main.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 78756853ade1..450911345144 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2058,15 +2058,17 @@ static int ice_req_irq_msix_misc(struct ice_pf *pf)
skip_req_irq:
ice_ena_misc_vector(pf);
- val = (pf->oicr_idx & PFINT_OICR_CTL_MSIX_INDX_M) |
- (ICE_RX_ITR & PFINT_OICR_CTL_ITR_INDX_M) |
- PFINT_OICR_CTL_CAUSE_ENA_M;
+ val = ((pf->oicr_idx & PFINT_OICR_CTL_MSIX_INDX_M) |
+ ((ICE_RX_ITR << PFINT_OICR_CTL_ITR_INDX_S) &
+ PFINT_OICR_CTL_ITR_INDX_M) |
+ PFINT_OICR_CTL_CAUSE_ENA_M);
wr32(hw, PFINT_OICR_CTL, val);
/* This enables Admin queue Interrupt causes */
- val = (pf->oicr_idx & PFINT_FW_CTL_MSIX_INDX_M) |
- (ICE_RX_ITR & PFINT_FW_CTL_ITR_INDX_M) |
- PFINT_FW_CTL_CAUSE_ENA_M;
+ val = ((pf->oicr_idx & PFINT_FW_CTL_MSIX_INDX_M) |
+ ((ICE_RX_ITR << PFINT_FW_CTL_ITR_INDX_S) &
+ PFINT_FW_CTL_ITR_INDX_M) |
+ PFINT_FW_CTL_CAUSE_ENA_M);
wr32(hw, PFINT_FW_CTL, val);
itr_gran = hw->itr_gran_200;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v2 02/13] ice: Cleanup magic number
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723220520.16678-1-anirudh.venkataramanan@intel.com>
Use define for the unit size shift of the Rx LAN context descriptor base
address instead of the magic number 7.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 1 +
drivers/net/ethernet/intel/ice/ice_main.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h b/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
index d23a91665b46..068dbc740b76 100644
--- a/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
+++ b/drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h
@@ -265,6 +265,7 @@ enum ice_rx_flex_desc_status_error_0_bits {
struct ice_rlan_ctx {
u16 head;
u16 cpuid; /* bigger than needed, see above for reason */
+#define ICE_RLAN_BASE_S 7
u64 base;
u16 qlen;
#define ICE_RLAN_CTX_DBUF_S 7
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 5299caf55a7f..78756853ade1 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3986,7 +3986,7 @@ static int ice_setup_rx_ctx(struct ice_ring *ring)
/* clear the context structure first */
memset(&rlan_ctx, 0, sizeof(rlan_ctx));
- rlan_ctx.base = ring->dma >> 7;
+ rlan_ctx.base = ring->dma >> ICE_RLAN_BASE_S;
rlan_ctx.qlen = ring->count;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v2 01/13] ice: Fix static analyser warning
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <20180723220520.16678-1-anirudh.venkataramanan@intel.com>
This patch fixes one of the smatch (a static analysis tool) warnings
reported by Dan Carpenter. ICE_LG_ACT_GENERIC_OFFSET_M is the right mask
to use but it appears that ICE_LG_ACT_GENERIC_VALUE_M was used instead,
which resulted in the following smatch warning:
ice_add_marker_act() warn: odd binop '0x380000 & 0x7fff8'
Additionally, use a new define ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX
instead of magic number '7'.
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
---
drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 +
drivers/net/ethernet/intel/ice/ice_switch.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
index 7541ec2270b3..6d3e11659ba5 100644
--- a/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
+++ b/drivers/net/ethernet/intel/ice/ice_adminq_cmd.h
@@ -594,6 +594,7 @@ struct ice_sw_rule_lg_act {
#define ICE_LG_ACT_GENERIC_OFFSET_M (0x7 << ICE_LG_ACT_GENERIC_OFFSET_S)
#define ICE_LG_ACT_GENERIC_PRIORITY_S 22
#define ICE_LG_ACT_GENERIC_PRIORITY_M (0x7 << ICE_LG_ACT_GENERIC_PRIORITY_S)
+#define ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX 7
/* Action = 7 - Set Stat count */
#define ICE_LG_ACT_STAT_COUNT 0x7
diff --git a/drivers/net/ethernet/intel/ice/ice_switch.c b/drivers/net/ethernet/intel/ice/ice_switch.c
index 723d15f1e90b..750d2051a976 100644
--- a/drivers/net/ethernet/intel/ice/ice_switch.c
+++ b/drivers/net/ethernet/intel/ice/ice_switch.c
@@ -645,7 +645,8 @@ ice_add_marker_act(struct ice_hw *hw, struct ice_fltr_mgmt_list_entry *m_ent,
act |= (1 << ICE_LG_ACT_GENERIC_VALUE_S) & ICE_LG_ACT_GENERIC_VALUE_M;
lg_act->pdata.lg_act.act[1] = cpu_to_le32(act);
- act = (7 << ICE_LG_ACT_GENERIC_OFFSET_S) & ICE_LG_ACT_GENERIC_VALUE_M;
+ act = (ICE_LG_ACT_GENERIC_OFF_RX_DESC_PROF_IDX <<
+ ICE_LG_ACT_GENERIC_OFFSET_S) & ICE_LG_ACT_GENERIC_OFFSET_M;
/* Third action Marker value */
act |= ICE_LG_ACT_GENERIC;
--
2.14.3
^ permalink raw reply related
* [Intel-wired-lan] [PATCH v2 00/13] Bug fixes for ice
From: Anirudh Venkataramanan @ 2018-07-23 22:05 UTC (permalink / raw)
To: intel-wired-lan
This patch set fixes multiple bugs for the ice driver.
Anirudh Venkataramanan (4):
ice: Fix static analyser warning
ice: Cleanup magic number
ice: Fix bugs in control queue processing
ice: Fix couple of null pointer dereference issues
Brett Creeley (2):
ice: Don't explicitly set port_vlan_bits to 0
ice: Set VLAN flags correctly
Bruce Allan (3):
ice: Fix missing shift
ice: Update to interrupts enabled in OICR
ice: Change struct members from bool to u8
Jacob Keller (2):
ice: Report stats for allocated queues via ethtool stats
ice: Use order_base_2 to calculate higher power of 2
Jesse Brandeburg (1):
ice: Fix potential return of uninitialized value
Preethi Banala (1):
ice: Clean control queues only when they are initialized
drivers/net/ethernet/intel/ice/ice.h | 15 ++--
drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 1 +
drivers/net/ethernet/intel/ice/ice_controlq.c | 29 +++++---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 52 ++++++++++----
drivers/net/ethernet/intel/ice/ice_hw_autogen.h | 8 ---
drivers/net/ethernet/intel/ice/ice_lan_tx_rx.h | 1 +
drivers/net/ethernet/intel/ice/ice_main.c | 91 +++++++++++++++----------
drivers/net/ethernet/intel/ice/ice_switch.c | 3 +-
drivers/net/ethernet/intel/ice/ice_switch.h | 6 +-
drivers/net/ethernet/intel/ice/ice_txrx.h | 2 +-
drivers/net/ethernet/intel/ice/ice_type.h | 16 ++---
11 files changed, 141 insertions(+), 83 deletions(-)
--
2.14.3
^ permalink raw reply
* Re: bisected: 4.18-rc* regression: x86-32 troubles (with timers?)
From: Daniel Borkmann @ 2018-07-23 22:04 UTC (permalink / raw)
To: Meelis Roos; +Cc: Arnd Bergmann, Linux Kernel list, Networking
In-Reply-To: <alpine.LRH.2.21.1807232322430.11834@math.ut.ee>
On 07/23/2018 10:34 PM, Meelis Roos wrote:
>>>> Now this seems more relevant:
>>>>
>>>> mroos@rx100s2:~/linux$ nice git bisect good
>>>> 24dea04767e6e5175f4750770281b0c17ac6a2fb is the first bad commit
>>>> commit 24dea04767e6e5175f4750770281b0c17ac6a2fb
>>>> Author: Daniel Borkmann <daniel@iogearbox.net>
>>>> Date: Fri May 4 01:08:23 2018 +0200
>>>>
>>>> bpf, x32: remove ld_abs/ld_ind
>>>>
>>>> Since LD_ABS/LD_IND instructions are now removed from the core and
>>>> reimplemented through a combination of inlined BPF instructions and
>>>> a slow-path helper, we can get rid of the complexity from x32 JIT.
>>>
>>> This does seem much more likely than the previous bisection, given
>>> that you ended up in an x86-32 specific commit (the subject says x32,
>>> but that is a mistake). I also checked that systemd indeed does
>>> call into bpf in a number of places, possibly for the journald socket.
>>>
>>> OTOH, it's still hard to tell how that commit can have ended up
>>> corrupting the clock read function in systemd. To cross-check,
>>> could you try reverting that commit on the latest kernel and see
>>> if it still works?
>>
>> I would be curious as well about that whether revert would make it
>> work. What's the value of sysctl net.core.bpf_jit_enable ? Does it
>> change anything if you set it to 0 (only interpreter) or 1 (JIT
>> enabled). Seems a bit strange to me that bisect ended at this commit
>> given the issue you have. The JIT itself was also new in this window
>> fwiw. In any case some more debug info would be great to have.
>
> net.core.bpf_jit_enable is 1.
>
> Since it breaks bootup, I can not easily change the value at runtime (it
> would be postfactum). Do you mean changing the
> CONFIG_BPF_JIT_ALWAYS_ON=y option?
Yeah if you chance it to N, and don't have any fixed /etc/sysctl.conf
setting, then you'll boot up with interpreter first (net.core.bpf_jit_enable
as 0). Curious whether that works just fine for you.
> Anyway, I started compile of v4.18-rc5 that was the latest I tested,
> with the commit in question reverted. Will see if I can test tomorrow
> morning. But I will leave tomorrow for a week and can only test further
> things if they happen to boot fine (no manual reboot possible for a
> week).
Ok, thanks, please keep us posted on the outcome with the revert. Right
now I would doubt it's related resp. changes anything on the issue, but
lets see.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support
From: Boris Ostrovsky @ 2018-07-23 22:04 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel
Cc: Sergey Dyasli, Wei Liu, Jan Beulich, Suravee Suthikulpanit,
Brian Woods, Roger Pau Monné
In-Reply-To: <c8e0c512-8dae-f7ad-81d0-4b6a33911e59@oracle.com>
On 07/23/2018 06:02 PM, Boris Ostrovsky wrote:
> On 07/23/2018 10:42 AM, Andrew Cooper wrote:
>> Because of a bug in 2010, LMSL support didn't functioned in Xen.
>>
>> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
>> addition to migration problems, changes to the segmentation logic for
>> emulation would be needed before the feature could be enabled.
>>
>> This feature is entirely unused by operating systems (probably owing to its
>> semantics which only cover half the segment registers), and no one has
>> commented on its absence from Xen. As supporting it would involve a large
>> amount of effort, it seems better to remove the code entirely.
>>
>> If someone finds a valid usecase, we can resurrecting the code and
>> implementing the remaining parts, but I doubt anyone will.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> ---
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>> CC: Brian Woods <brian.woods@amd.com>
>> CC: Wei Liu <wei.liu2@citrix.com>
>> CC: Roger Pau Monné <roger.pau@citrix.com>
>> CC: Sergey Dyasli <sergey.dyasli@citrix.com>
>> ---
>> xen/arch/x86/hvm/hvm.c | 3 ---
>> xen/arch/x86/hvm/svm/svm.c | 23 -----------------------
>> xen/arch/x86/pv/emul-priv-op.c | 2 +-
>> xen/include/asm-x86/hvm/hvm.h | 1 -
>> xen/include/asm-x86/msr-index.h | 4 +---
>> 5 files changed, 2 insertions(+), 31 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index c099c61..67b99af 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -925,9 +925,6 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
>> if ( (value & EFER_SVME) && (!p->extd.svm || !nestedhvm_enabled(d)) )
>> return "SVME without nested virt";
>>
>> - if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
>> - return "LMSLE without support";
>> -
> So we are silently dropping the bit? Should we still warn?
Nevermind.
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>
> -boris
>
>
>> if ( (value & EFER_FFXSE) && !p->extd.ffxsr )
>> return "FFXSE without feature";
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH net-next] net: remove redundant input checks in SIOCSIFTXQLEN case of dev_ifsioc
From: David Miller @ 2018-07-23 21:00 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: tariqt, netdev, eranbe
In-Reply-To: <CAM_iQpUo-Rp5OhbtLVGOG_HPYZYuPXeqVMZ3ip=VMUJ42Cg4PQ@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 23 Jul 2018 13:37:22 -0700
> On Sun, Jul 22, 2018 at 12:29 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>>
>>
>>
>> On 19/07/2018 8:21 PM, Cong Wang wrote:
>> > On Thu, Jul 19, 2018 at 7:50 AM Tariq Toukan <tariqt@mellanox.com> wrote:
>> >> --- a/net/core/dev_ioctl.c
>> >> +++ b/net/core/dev_ioctl.c
>> >> @@ -282,14 +282,7 @@ static int dev_ifsioc(struct net *net, struct ifreq *ifr, unsigned int cmd)
>> >> return dev_mc_del_global(dev, ifr->ifr_hwaddr.sa_data);
>> >>
>> >> case SIOCSIFTXQLEN:
>> >> - if (ifr->ifr_qlen < 0)
>> >> - return -EINVAL;
>> >
>> > Are you sure we can remove this if check too?
>> >
>> > The other one is safe to remove.
>> >
>>
>> Hmm, let's see:
>> dev_change_tx_queue_len gets unsigned long new_len, any negative value
>> passed is interpreted as a very large number, then we test:
>> if (new_len != (unsigned int)new_len)
>>
>> This test returns true if range of unsigned long is larger than range of
>> unsigned int. AFAIK these ranges are Arch dependent and there is no
>> guarantee this holds.
>
> I am not sure either, you probably have to give it a test.
> And at least, explain it in changelog if you still want to remove it.
On 64-bit we will fail with -ERANGE. The 32-bit int ifr_qlen will be sign
extended to 64-bits when it is passed into dev_change_tx_queue_len(). And
then for negative values this test triggers:
if (new_len != (unsigned int)new_len)
return -ERANGE;
because:
if (0xffffffffWHATEVER != 0x00000000WHATEVER)
On 32-bit the signed value will be accepted, changing behavior.
I think, therefore, that the < 0 check should be retained.
Thank you.
^ permalink raw reply
* Re: Linux RT 4.14 Merge conflict
From: Dan Murphy @ 2018-07-23 20:59 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linux-rt-users@vger.kernel.org
In-Reply-To: <20180723165903.4d93070d@gandalf.local.home>
Steven
On 07/23/2018 03:59 PM, Steven Rostedt wrote:
> On Mon, 23 Jul 2018 15:25:34 -0500
> Dan Murphy <dmurphy@ti.com> wrote:
>
>> Hello!
>>
>> There is a merge conflict when merging in the latest 4.14 stable
>> release into the current 4.14 rt stable release.
>>
>> Attached is the merge conflict that is seen.
>>
>> We appreciate it if the merge conflict resolution can come from the
>> RT stable branch.
>>
>
> Hi Dan,
>
> I just came back from vacation. I was planning on getting to a new
> release of 4.14 next week. I'll be sorting out all the merge conflicts
> then.
>
Thank you for the attention on this.
Dan
> Thanks!
>
> -- Steve
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH v4 2/5] compress/zlib: add device PMD ops
From: De Lara Guarch, Pablo @ 2018-07-23 22:02 UTC (permalink / raw)
To: Shally Verma
Cc: dev@dpdk.org, pathreya@caviumnetworks.com,
mchalla@caviumnetworks.com, Ashish Gupta, Sunila Sahu
In-Reply-To: <1532357474-9544-3-git-send-email-shally.verma@caviumnetworks.com>
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> Sent: Monday, July 23, 2018 3:51 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> mchalla@caviumnetworks.com; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>
> Subject: [PATCH v4 2/5] compress/zlib: add device PMD ops
>
> From: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>
> Implement device configure and queue pair setup PMD ops
>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
...
> --- /dev/null
> +++ b/drivers/compress/zlib/zlib_pmd_ops.c
> @@ -0,0 +1,238 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(c) 2018 Cavium Networks
> + */
> +
> +#include <string.h>
> +
> +#include <rte_common.h>
> +#include <rte_malloc.h>
> +
> +#include "zlib_pmd_private.h"
> +
> +static const struct rte_compressdev_capabilities zlib_pmd_capabilities[] = {
> + { /* Deflate */
> + .algo = RTE_COMP_ALGO_DEFLATE,
> + .comp_feature_flags =
> (RTE_COMP_FF_NONCOMPRESSED_BLOCKS |
> + RTE_COMP_FF_HUFFMAN_FIXED |
> + RTE_COMP_FF_HUFFMAN_DYNAMIC |
> +
> RTE_COMP_FF_OOP_SGL_IN_SGL_OUT),
As said in the document patch, I think you should add the other two SGL cases here.
^ permalink raw reply
* [PATCH] vxge: Remove unnecessary include of <linux/pci_hotplug.h>
From: Bjorn Helgaas @ 2018-07-23 20:59 UTC (permalink / raw)
To: Jon Mason; +Cc: David S. Miller, netdev, linux-pci, linux-kernel
From: Bjorn Helgaas <bhelgaas@google.com>
The vxge driver doesn't need anything provided by pci_hotplug.h, so remove
the unnecessary include of it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/net/ethernet/neterion/vxge/vxge-config.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.c b/drivers/net/ethernet/neterion/vxge/vxge-config.c
index 358ed6118881..a2c0a93ca8b6 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.c
@@ -14,7 +14,6 @@
#include <linux/vmalloc.h>
#include <linux/etherdevice.h>
#include <linux/pci.h>
-#include <linux/pci_hotplug.h>
#include <linux/slab.h>
#include "vxge-traffic.h"
^ permalink raw reply related
* Re: [PATCH] x86/svm: Drop the suggestion of Long Mode Segment Limit support
From: Boris Ostrovsky @ 2018-07-23 22:02 UTC (permalink / raw)
To: Andrew Cooper, Xen-devel
Cc: Sergey Dyasli, Wei Liu, Jan Beulich, Suravee Suthikulpanit,
Brian Woods, Roger Pau Monné
In-Reply-To: <1532356957-1706-1-git-send-email-andrew.cooper3@citrix.com>
On 07/23/2018 10:42 AM, Andrew Cooper wrote:
> Because of a bug in 2010, LMSL support didn't functioned in Xen.
>
> c/s f2c608444 noticed but avoided fixing the issue for migration reasons. In
> addition to migration problems, changes to the segmentation logic for
> emulation would be needed before the feature could be enabled.
>
> This feature is entirely unused by operating systems (probably owing to its
> semantics which only cover half the segment registers), and no one has
> commented on its absence from Xen. As supporting it would involve a large
> amount of effort, it seems better to remove the code entirely.
>
> If someone finds a valid usecase, we can resurrecting the code and
> implementing the remaining parts, but I doubt anyone will.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> CC: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> CC: Brian Woods <brian.woods@amd.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Sergey Dyasli <sergey.dyasli@citrix.com>
> ---
> xen/arch/x86/hvm/hvm.c | 3 ---
> xen/arch/x86/hvm/svm/svm.c | 23 -----------------------
> xen/arch/x86/pv/emul-priv-op.c | 2 +-
> xen/include/asm-x86/hvm/hvm.h | 1 -
> xen/include/asm-x86/msr-index.h | 4 +---
> 5 files changed, 2 insertions(+), 31 deletions(-)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index c099c61..67b99af 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -925,9 +925,6 @@ const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
> if ( (value & EFER_SVME) && (!p->extd.svm || !nestedhvm_enabled(d)) )
> return "SVME without nested virt";
>
> - if ( (value & EFER_LMSLE) && !cpu_has_lmsl )
> - return "LMSLE without support";
> -
So we are silently dropping the bit? Should we still warn?
-boris
> if ( (value & EFER_FFXSE) && !p->extd.ffxsr )
> return "FFXSE without feature";
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: Linux RT 4.14 Merge conflict
From: Steven Rostedt @ 2018-07-23 20:59 UTC (permalink / raw)
To: Dan Murphy; +Cc: linux-rt-users@vger.kernel.org
In-Reply-To: <d4d7832c-857f-a531-7836-61065a9686d4@ti.com>
On Mon, 23 Jul 2018 15:25:34 -0500
Dan Murphy <dmurphy@ti.com> wrote:
> Hello!
>
> There is a merge conflict when merging in the latest 4.14 stable
> release into the current 4.14 rt stable release.
>
> Attached is the merge conflict that is seen.
>
> We appreciate it if the merge conflict resolution can come from the
> RT stable branch.
>
Hi Dan,
I just came back from vacation. I was planning on getting to a new
release of 4.14 next week. I'll be sorting out all the merge conflicts
then.
Thanks!
-- Steve
^ permalink raw reply
* [Qemu-devel] [PATCH for-3.0?] target/arm: Add sve-max-vq cpu property to -cpu max
From: Richard Henderson @ 2018-07-23 22:00 UTC (permalink / raw)
To: qemu-devel; +Cc: armbru, peter.maydell, alex.bennee, mdroth
This allows the default (and maximum) vector length to be set
from the command-line. Which is extraordinarily helpful in
debuging problems depending on vector length without having to
bake knowledge of PR_SET_SVE_VL into every guest binary.
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
The argument for inclding this in 3.0 is that there appear to be
several groups experimenting with SVE and using fixed vector lengths.
While this is oddly against the design of SVE, it's probably going
to keep happening. Plus, the wildly useful debugging aspect.
I'm not 100% sure I've tickled all of the qapi parts in the proper
order, but it appears to work ok:
$ cat ~/z.c
#include <stdio.h>
int main() {
int i;
asm("rdvl %0, 1" : "=r"(i));
printf("%d\n", i);
return 0;
}
$ ./aarch64-linux-user/qemu-aarch64 ~/a.out
256
$ ./aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=1 ~/a.out
16
$ ./aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=8 ~/a.out
128
$ ./aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=33 ~/a.out
can't apply global max-arm-cpu.sve-max-vq=33: unsupported SVE vector length
Valid sve-max-vq in range [1-16]
$ ./aarch64-linux-user/qemu-aarch64 -cpu max,sve-max-vq=-1 ~/a.out
can't apply global max-arm-cpu.sve-max-vq=-1: Parameter 'sve-max-vq' expects uint32_t
r~
---
target/arm/cpu.h | 3 +++
linux-user/syscall.c | 19 +++++++++++++------
target/arm/cpu.c | 6 +++---
target/arm/cpu64.c | 29 +++++++++++++++++++++++++++++
target/arm/helper.c | 7 +++++--
5 files changed, 53 insertions(+), 11 deletions(-)
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index e310ffc29d..9526ed27cb 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -857,6 +857,9 @@ struct ARMCPU {
/* Used to synchronize KVM and QEMU in-kernel device levels */
uint8_t device_irq_level;
+
+ /* Used to set the maximum vector length the cpu will support. */
+ uint32_t sve_max_vq;
};
static inline ARMCPU *arm_env_get_cpu(CPUARMState *env)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index dfc851cc35..5a4af76c03 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10848,15 +10848,22 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
#endif
#ifdef TARGET_AARCH64
case TARGET_PR_SVE_SET_VL:
- /* We cannot support either PR_SVE_SET_VL_ONEXEC
- or PR_SVE_VL_INHERIT. Therefore, anything above
- ARM_MAX_VQ results in EINVAL. */
+ /*
+ * We cannot support either PR_SVE_SET_VL_ONEXEC or
+ * PR_SVE_VL_INHERIT. Note the kernel definition
+ * of sve_vl_valid allows for VQ=512, i.e. VL=8192,
+ * even though the current architectural maximum is VQ=16.
+ */
ret = -TARGET_EINVAL;
if (arm_feature(cpu_env, ARM_FEATURE_SVE)
- && arg2 >= 0 && arg2 <= ARM_MAX_VQ * 16 && !(arg2 & 15)) {
+ && arg2 >= 0 && arg2 <= 512 * 16 && !(arg2 & 15)) {
CPUARMState *env = cpu_env;
- int old_vq = (env->vfp.zcr_el[1] & 0xf) + 1;
- int vq = MAX(arg2 / 16, 1);
+ ARMCPU *cpu = arm_env_get_cpu(env);
+ uint32_t vq, old_vq;
+
+ old_vq = (env->vfp.zcr_el[1] & 0xf) + 1;
+ vq = MAX(arg2 / 16, 1);
+ vq = MIN(vq, cpu->sve_max_vq);
if (vq < old_vq) {
aarch64_sve_narrow_vq(env, vq);
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 64a8005a4b..b25898ed4c 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -168,9 +168,9 @@ static void arm_cpu_reset(CPUState *s)
env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 16, 2, 3);
env->cp15.cptr_el[3] |= CPTR_EZ;
/* with maximum vector length */
- env->vfp.zcr_el[1] = ARM_MAX_VQ - 1;
- env->vfp.zcr_el[2] = ARM_MAX_VQ - 1;
- env->vfp.zcr_el[3] = ARM_MAX_VQ - 1;
+ env->vfp.zcr_el[1] = cpu->sve_max_vq - 1;
+ env->vfp.zcr_el[2] = env->vfp.zcr_el[1];
+ env->vfp.zcr_el[3] = env->vfp.zcr_el[1];
#else
/* Reset into the highest available EL */
if (arm_feature(env, ARM_FEATURE_EL3)) {
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index d0581d59d8..800bff780e 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -29,6 +29,7 @@
#include "sysemu/sysemu.h"
#include "sysemu/kvm.h"
#include "kvm_arm.h"
+#include "qapi/visitor.h"
static inline void set_feature(CPUARMState *env, int feature)
{
@@ -217,6 +218,29 @@ static void aarch64_a53_initfn(Object *obj)
define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
}
+static void cpu_max_get_sve_vq(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ ARMCPU *cpu = ARM_CPU(obj);
+ visit_type_uint32(v, name, &cpu->sve_max_vq, errp);
+}
+
+static void cpu_max_set_sve_vq(Object *obj, Visitor *v, const char *name,
+ void *opaque, Error **errp)
+{
+ ARMCPU *cpu = ARM_CPU(obj);
+ Error *err = NULL;
+
+ visit_type_uint32(v, name, &cpu->sve_max_vq, &err);
+
+ if (!err && (cpu->sve_max_vq == 0 || cpu->sve_max_vq > ARM_MAX_VQ)) {
+ error_setg(&err, "unsupported SVE vector length");
+ error_append_hint(&err, "Valid sve-max-vq in range [1-%d]\n",
+ ARM_MAX_VQ);
+ }
+ error_propagate(errp, err);
+}
+
/* -cpu max: if KVM is enabled, like -cpu host (best possible with this host);
* otherwise, a CPU with as many features enabled as our emulation supports.
* The version of '-cpu max' for qemu-system-arm is defined in cpu.c;
@@ -253,6 +277,10 @@ static void aarch64_max_initfn(Object *obj)
cpu->ctr = 0x80038003; /* 32 byte I and D cacheline size, VIPT icache */
cpu->dcz_blocksize = 7; /* 512 bytes */
#endif
+
+ cpu->sve_max_vq = ARM_MAX_VQ;
+ object_property_add(obj, "sve-max-vq", "uint32", cpu_max_get_sve_vq,
+ cpu_max_set_sve_vq, NULL, NULL, &error_fatal);
}
}
@@ -405,6 +433,7 @@ void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq)
uint64_t pmask;
assert(vq >= 1 && vq <= ARM_MAX_VQ);
+ assert(vq <= arm_env_get_cpu(env)->sve_max_vq);
/* Zap the high bits of the zregs. */
for (i = 0; i < 32; i++) {
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 22d812240a..bc274bb6e7 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -12414,9 +12414,12 @@ void cpu_get_tb_cpu_state(CPUARMState *env, target_ulong *pc,
zcr_len = 0;
} else {
int current_el = arm_current_el(env);
+ ARMCPU *cpu = arm_env_get_cpu(env);
- zcr_len = env->vfp.zcr_el[current_el <= 1 ? 1 : current_el];
- zcr_len &= 0xf;
+ zcr_len = cpu->sve_max_vq - 1;
+ if (current_el <= 1) {
+ zcr_len = MIN(zcr_len, 0xf & (uint32_t)env->vfp.zcr_el[1]);
+ }
if (current_el < 2 && arm_feature(env, ARM_FEATURE_EL2)) {
zcr_len = MIN(zcr_len, 0xf & (uint32_t)env->vfp.zcr_el[2]);
}
--
2.17.1
^ permalink raw reply related
* Re: [RFC v5 0/2] mm: zap pages with read mmap_sem in munmap for large mapping
From: Yang Shi @ 2018-07-23 22:00 UTC (permalink / raw)
To: mhocko, willy, ldufour, kirill, akpm; +Cc: linux-mm, linux-kernel
In-Reply-To: <1531956101-8526-1-git-send-email-yang.shi@linux.alibaba.com>
Hi folks,
Any comment on this version?
Thanks,
Yang
On 7/18/18 4:21 PM, Yang Shi wrote:
> Background:
> Recently, when we ran some vm scalability tests on machines with large memory,
> we ran into a couple of mmap_sem scalability issues when unmapping large memory
> space, please refer to https://lkml.org/lkml/2017/12/14/733 and
> https://lkml.org/lkml/2018/2/20/576.
>
>
> History:
> Then akpm suggested to unmap large mapping section by section and drop mmap_sem
> at a time to mitigate it (see https://lkml.org/lkml/2018/3/6/784).
>
> V1 patch series was submitted to the mailing list per Andrew's suggestion
> (see https://lkml.org/lkml/2018/3/20/786). Then I received a lot great feedback
> and suggestions.
>
> Then this topic was discussed on LSFMM summit 2018. In the summit, Michal Hocko
> suggested (also in the v1 patches review) to try "two phases" approach. Zapping
> pages with read mmap_sem, then doing via cleanup with write mmap_sem (for
> discussion detail, see https://lwn.net/Articles/753269/)
>
>
> Approach:
> Zapping pages is the most time consuming part, according to the suggestion from
> Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> what MADV_DONTNEED does. Then re-acquire write mmap_sem to cleanup vmas.
>
> But, we can't call MADV_DONTNEED directly, since there are two major drawbacks:
> * The unexpected state from PF if it wins the race in the middle of munmap.
> It may return zero page, instead of the content or SIGSEGV.
> * Cana??t handle VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe mappings, which
> is a showstopper from akpm
>
> But, some part may need write mmap_sem, for example, vma splitting. So,
> the design is as follows:
> acquire write mmap_sem
> lookup vmas (find and split vmas)
> detach vmas
> deal with special mappings
> downgrade_write
>
> zap pages
> free page tables
> release mmap_sem
>
> The vm events with read mmap_sem may come in during page zapping, but
> since vmas have been detached before, they, i.e. page fault, gup, etc,
> will not be able to find valid vma, then just return SIGSEGV or -EFAULT
> as expected.
>
> If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
> considered as special mappings. They will be dealt with before zapping
> pages with write mmap_sem held. Basically, just update vm_flags.
>
> And, since they are also manipulated by unmap_single_vma() which is
> called by unmap_vma() with read mmap_sem held in this case, to
> prevent from updating vm_flags in read critical section, a new
> parameter, called "skip_flags" is added to unmap_region(), unmap_vmas()
> and unmap_single_vma(). If it is true, then just skip unmap those
> special mappings. Currently, the only place which pass true to this
> parameter is us.
>
> With this approach we don't have to re-acquire mmap_sem again to clean
> up vmas to avoid race window which might get the address space changed.
>
> And, since the lock acquire/release cost is managed to the minimum and
> almost as same as before, the optimization could be extended to any size
> of mapping without incuring significant penalty to small mappings.
>
> For the time being, just do this in munmap syscall path. Other vm_munmap() or
> do_munmap() call sites (i.e mmap, mremap, etc) remain intact for stability
> reason.
>
> Changelog:
> v4 -> v5:
> * Detach vmas before zapping pages so that we don't have to use VM_DEAD to mark
> a being unmapping vma since they have been detached from rbtree when zapping
> pages. Per Kirill
> * Eliminate VM_DEAD stuff
> * With this change we don't have to re-acquire write mmap_sem to do cleanup.
> So, we could eliminate a potential race window
> * Eliminate PUD_SIZE check, and extend this optimization to all size
>
> v3 -> v4:
> * Extend check_stable_address_space to check VM_DEAD as Michal suggested
> * Deal with vm_flags update of VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe
> mappings with exclusive lock held. The actual unmapping is still done with read
> mmap_sem to solve akpm's concern
> * Clean up vmas with calling do_munmap to prevent from race condition by not
> carrying vmas as Kirill suggested
> * Extracted more common code
> * Solved some code cleanup comments from akpm
> * Dropped uprobe and arch specific code, now all the changes are mm only
> * Still keep PUD_SIZE threshold, if everyone thinks it is better to extend to all
> sizes or smaller size, will remove it
> * Make this optimization 64 bit only explicitly per akpm's suggestion
>
> v2 -> v3:
> * Refactor do_munmap code to extract the common part per Peter's sugestion
> * Introduced VM_DEAD flag per Michal's suggestion. Just handled VM_DEAD in
> x86's page fault handler for the time being. Other architectures will be covered
> once the patch series is reviewed
> * Now lookup vma (find and split) and set VM_DEAD flag with write mmap_sem, then
> zap mapping with read mmap_sem, then clean up pgtables and vmas with write
> mmap_sem per Peter's suggestion
>
> v1 -> v2:
> * Re-implemented the code per the discussion on LSFMM summit
>
>
> Regression and performance data:
> Did the below regression test with setting thresh to 4K manually in the code:
> * Full LTP
> * Trinity (munmap/all vm syscalls)
> * Stress-ng: mmap/mmapfork/mmapfixed/mmapaddr/mmapmany/vm
> * mm-tests: kernbench, phpbench, sysbench-mariadb, will-it-scale
> * vm-scalability
>
> With the patches, exclusive mmap_sem hold time when munmap a 80GB address
> space on a machine with 32 cores of E5-2680 @ 2.70GHz dropped to us level
> from second.
>
> munmap_test-15002 [008] 594.380138: funcgraph_entry: | vm_munmap_zap_rlock() {
> munmap_test-15002 [008] 594.380146: funcgraph_entry: !2485684 us | unmap_region();
> munmap_test-15002 [008] 596.865836: funcgraph_exit: !2485692 us | }
>
> Here the excution time of unmap_region() is used to evaluate the time of
> holding read mmap_sem, then the remaining time is used with holding
> exclusive lock.
>
> Yang Shi (2):
> mm: refactor do_munmap() to extract the common part
> mm: mmap: zap pages with read mmap_sem in munmap
>
> include/linux/mm.h | 2 +-
> mm/memory.c | 35 +++++++++++++-----
> mm/mmap.c | 219 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------
> 3 files changed, 199 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: [RFC v5 0/2] mm: zap pages with read mmap_sem in munmap for large mapping
From: Yang Shi @ 2018-07-23 22:00 UTC (permalink / raw)
To: mhocko, willy, ldufour, kirill, akpm; +Cc: linux-mm, linux-kernel
In-Reply-To: <1531956101-8526-1-git-send-email-yang.shi@linux.alibaba.com>
Hi folks,
Any comment on this version?
Thanks,
Yang
On 7/18/18 4:21 PM, Yang Shi wrote:
> Background:
> Recently, when we ran some vm scalability tests on machines with large memory,
> we ran into a couple of mmap_sem scalability issues when unmapping large memory
> space, please refer to https://lkml.org/lkml/2017/12/14/733 and
> https://lkml.org/lkml/2018/2/20/576.
>
>
> History:
> Then akpm suggested to unmap large mapping section by section and drop mmap_sem
> at a time to mitigate it (see https://lkml.org/lkml/2018/3/6/784).
>
> V1 patch series was submitted to the mailing list per Andrew's suggestion
> (see https://lkml.org/lkml/2018/3/20/786). Then I received a lot great feedback
> and suggestions.
>
> Then this topic was discussed on LSFMM summit 2018. In the summit, Michal Hocko
> suggested (also in the v1 patches review) to try "two phases" approach. Zapping
> pages with read mmap_sem, then doing via cleanup with write mmap_sem (for
> discussion detail, see https://lwn.net/Articles/753269/)
>
>
> Approach:
> Zapping pages is the most time consuming part, according to the suggestion from
> Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> what MADV_DONTNEED does. Then re-acquire write mmap_sem to cleanup vmas.
>
> But, we can't call MADV_DONTNEED directly, since there are two major drawbacks:
> * The unexpected state from PF if it wins the race in the middle of munmap.
> It may return zero page, instead of the content or SIGSEGV.
> * Can’t handle VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe mappings, which
> is a showstopper from akpm
>
> But, some part may need write mmap_sem, for example, vma splitting. So,
> the design is as follows:
> acquire write mmap_sem
> lookup vmas (find and split vmas)
> detach vmas
> deal with special mappings
> downgrade_write
>
> zap pages
> free page tables
> release mmap_sem
>
> The vm events with read mmap_sem may come in during page zapping, but
> since vmas have been detached before, they, i.e. page fault, gup, etc,
> will not be able to find valid vma, then just return SIGSEGV or -EFAULT
> as expected.
>
> If the vma has VM_LOCKED | VM_HUGETLB | VM_PFNMAP or uprobe, they are
> considered as special mappings. They will be dealt with before zapping
> pages with write mmap_sem held. Basically, just update vm_flags.
>
> And, since they are also manipulated by unmap_single_vma() which is
> called by unmap_vma() with read mmap_sem held in this case, to
> prevent from updating vm_flags in read critical section, a new
> parameter, called "skip_flags" is added to unmap_region(), unmap_vmas()
> and unmap_single_vma(). If it is true, then just skip unmap those
> special mappings. Currently, the only place which pass true to this
> parameter is us.
>
> With this approach we don't have to re-acquire mmap_sem again to clean
> up vmas to avoid race window which might get the address space changed.
>
> And, since the lock acquire/release cost is managed to the minimum and
> almost as same as before, the optimization could be extended to any size
> of mapping without incuring significant penalty to small mappings.
>
> For the time being, just do this in munmap syscall path. Other vm_munmap() or
> do_munmap() call sites (i.e mmap, mremap, etc) remain intact for stability
> reason.
>
> Changelog:
> v4 -> v5:
> * Detach vmas before zapping pages so that we don't have to use VM_DEAD to mark
> a being unmapping vma since they have been detached from rbtree when zapping
> pages. Per Kirill
> * Eliminate VM_DEAD stuff
> * With this change we don't have to re-acquire write mmap_sem to do cleanup.
> So, we could eliminate a potential race window
> * Eliminate PUD_SIZE check, and extend this optimization to all size
>
> v3 -> v4:
> * Extend check_stable_address_space to check VM_DEAD as Michal suggested
> * Deal with vm_flags update of VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe
> mappings with exclusive lock held. The actual unmapping is still done with read
> mmap_sem to solve akpm's concern
> * Clean up vmas with calling do_munmap to prevent from race condition by not
> carrying vmas as Kirill suggested
> * Extracted more common code
> * Solved some code cleanup comments from akpm
> * Dropped uprobe and arch specific code, now all the changes are mm only
> * Still keep PUD_SIZE threshold, if everyone thinks it is better to extend to all
> sizes or smaller size, will remove it
> * Make this optimization 64 bit only explicitly per akpm's suggestion
>
> v2 -> v3:
> * Refactor do_munmap code to extract the common part per Peter's sugestion
> * Introduced VM_DEAD flag per Michal's suggestion. Just handled VM_DEAD in
> x86's page fault handler for the time being. Other architectures will be covered
> once the patch series is reviewed
> * Now lookup vma (find and split) and set VM_DEAD flag with write mmap_sem, then
> zap mapping with read mmap_sem, then clean up pgtables and vmas with write
> mmap_sem per Peter's suggestion
>
> v1 -> v2:
> * Re-implemented the code per the discussion on LSFMM summit
>
>
> Regression and performance data:
> Did the below regression test with setting thresh to 4K manually in the code:
> * Full LTP
> * Trinity (munmap/all vm syscalls)
> * Stress-ng: mmap/mmapfork/mmapfixed/mmapaddr/mmapmany/vm
> * mm-tests: kernbench, phpbench, sysbench-mariadb, will-it-scale
> * vm-scalability
>
> With the patches, exclusive mmap_sem hold time when munmap a 80GB address
> space on a machine with 32 cores of E5-2680 @ 2.70GHz dropped to us level
> from second.
>
> munmap_test-15002 [008] 594.380138: funcgraph_entry: | vm_munmap_zap_rlock() {
> munmap_test-15002 [008] 594.380146: funcgraph_entry: !2485684 us | unmap_region();
> munmap_test-15002 [008] 596.865836: funcgraph_exit: !2485692 us | }
>
> Here the excution time of unmap_region() is used to evaluate the time of
> holding read mmap_sem, then the remaining time is used with holding
> exclusive lock.
>
> Yang Shi (2):
> mm: refactor do_munmap() to extract the common part
> mm: mmap: zap pages with read mmap_sem in munmap
>
> include/linux/mm.h | 2 +-
> mm/memory.c | 35 +++++++++++++-----
> mm/mmap.c | 219 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------
> 3 files changed, 199 insertions(+), 57 deletions(-)
^ permalink raw reply
* [PATCH] tpm: add support for partial reads
From: Tadeusz Struk @ 2018-07-23 22:00 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <20180723215620.GH532@ziepe.ca>
On 07/23/2018 02:56 PM, Jason Gunthorpe wrote:
> The proposed patch doesn't clear the data_pending if the entire buffer
> is not consumed, so of course it is ABI breaking, that really isn't OK.
The data_pending will be cleared by the timeout handler if the user doesn't
read the response fully before the timeout expires. The is the same situation
if the user would not read the response at all.
Thanks,
--
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/9] Always use the url specified in the recipe as a base for the git shallow tarball naming
From: Richard Purdie @ 2018-07-23 22:00 UTC (permalink / raw)
To: Urs Fässler, bitbake-devel
In-Reply-To: <20180723154259.9076-1-urs.fassler@bbv.ch>
On Mon, 2018-07-23 at 17:42 +0200, Urs Fässler wrote:
> The existing behavior was to use the url where the repository was
> cloned from.
> It happened that the tarball was not found when a mirror rewrite rule
> was active.
>
> We now use the url specified in the recipe to name the shallow
> tarball. It fixes that the tarball is not found under certain
> conditions. In addition, the naming is independent of network/server
> failure and the mapping of the name is easier to understand.
I'm not sure why but throughout this patch series you've used function
names and variables prefixed with "__". We don't do this with any of
our other code so it seems out of keeping with the rest of the coding
style.
With regard to the function "__has_up_to_date_clonedir" you added, its
very unclear why some checks would go in that function and some checks
would go in the other. The commit description helps understand it a bit
more but that doesn't help the function naming or someone looking at
the code in future.
Finally, I'm still not convinced that passing around the original url
and forcing the original url naming into any mirroring code is the
right solution to the problem. I said that at the start and looking at
this code change, I'm still not convinced this is right. Part of the
reason I continue to believe that is you just added a N*N testing
problem to the fetcher where the fetchers now behave differently
depending on two urls passed in rather than just one :(.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 0/3] PTI for x86-32 Fixes and Updates
From: Josh Poimboeuf @ 2018-07-23 21:59 UTC (permalink / raw)
To: Pavel Machek
Cc: Linus Torvalds, Joerg Roedel, Thomas Gleixner, Ingo Molnar,
Peter Anvin, the arch/x86 maintainers, Linux Kernel Mailing List,
linux-mm, Andrew Lutomirski, Dave Hansen, Jürgen Groß,
Peter Zijlstra, Borislav Petkov, Jiri Kosina, Boris Ostrovsky,
Brian Gerst, David Laight, Denys Vlasenko, Eduardo Valentin,
Greg Kroah-Hartman, Will Deacon, Liguori, Anthony, Daniel Gruss,
Hugh Dickins, Kees Cook, Andrea Arcangeli, Waiman Long,
David H . Gutteridge, Joerg Roedel, Arnaldo Carvalho de Melo,
Alexander Shishkin, Jiri Olsa, Namhyung Kim
In-Reply-To: <20180723213830.GA4632@amd>
On Mon, Jul 23, 2018 at 11:38:30PM +0200, Pavel Machek wrote:
> But for now I'd like at least "global" option of turning pti on/off
> during runtime for benchmarking. Let me see...
>
> Something like this, or is it going to be way more complex? Does
> anyone have patch by chance?
RHEL/CentOS has a global PTI enable/disable, which uses stop_machine().
--
Josh
^ permalink raw reply
* [PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
From: kbuild test robot @ 2018-07-23 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1532315945-1094-2-git-send-email-tony.xie@rock-chips.com>
Hi Tony,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.18-rc6 next-20180723]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Tony-Xie/mfd-rk808-Add-RK817-and-RK809-support/20180724-040547
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//mfd/rk808.c: In function 'rk808_probe':
>> drivers//mfd/rk808.c:715:16: warning: 'pm_pwroff_fn' may be used uninitialized in this function [-Wmaybe-uninitialized]
pm_power_off = pm_pwroff_fn;
~~~~~~~~~~~~~^~~~~~~~~~~~~~
vim +/pm_pwroff_fn +715 drivers//mfd/rk808.c
2eedcbfc0 Wadim Egorov 2016-08-29 581
f69a7cf74 Chris Zhong 2014-09-03 582 static int rk808_probe(struct i2c_client *client,
f69a7cf74 Chris Zhong 2014-09-03 583 const struct i2c_device_id *id)
f69a7cf74 Chris Zhong 2014-09-03 584 {
f69a7cf74 Chris Zhong 2014-09-03 585 struct device_node *np = client->dev.of_node;
f69a7cf74 Chris Zhong 2014-09-03 586 struct rk808 *rk808;
2eedcbfc0 Wadim Egorov 2016-08-29 587 const struct rk808_reg_data *pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 588 const struct mfd_cell *cells;
b2e2c8509 Jianhong Chen 2016-10-17 589 void (*pm_pwroff_fn)(void);
2eedcbfc0 Wadim Egorov 2016-08-29 590 int nr_pre_init_regs;
2eedcbfc0 Wadim Egorov 2016-08-29 591 int nr_cells;
9d6105e19 Elaine Zhang 2017-08-21 592 int pm_off = 0, msb, lsb;
1e99c2e53 Tony Xie 2018-07-23 593 unsigned char pmic_id_msb = RK808_ID_MSB, pmic_id_lsb = RK808_ID_LSB;
f69a7cf74 Chris Zhong 2014-09-03 594 int ret;
f69a7cf74 Chris Zhong 2014-09-03 595 int i;
f69a7cf74 Chris Zhong 2014-09-03 596
f69a7cf74 Chris Zhong 2014-09-03 597 rk808 = devm_kzalloc(&client->dev, sizeof(*rk808), GFP_KERNEL);
f69a7cf74 Chris Zhong 2014-09-03 598 if (!rk808)
f69a7cf74 Chris Zhong 2014-09-03 599 return -ENOMEM;
f69a7cf74 Chris Zhong 2014-09-03 600
1e99c2e53 Tony Xie 2018-07-23 601 if (of_device_is_compatible(np, "rockchip,rk817") ||
1e99c2e53 Tony Xie 2018-07-23 602 of_device_is_compatible(np, "rockchip,rk809")) {
1e99c2e53 Tony Xie 2018-07-23 603 pmic_id_msb = RK817_ID_MSB;
1e99c2e53 Tony Xie 2018-07-23 604 pmic_id_lsb = RK817_ID_LSB;
1e99c2e53 Tony Xie 2018-07-23 605 }
9d6105e19 Elaine Zhang 2017-08-21 606 /* Read chip variant */
1e99c2e53 Tony Xie 2018-07-23 607 msb = i2c_smbus_read_byte_data(client, pmic_id_msb);
9d6105e19 Elaine Zhang 2017-08-21 608 if (msb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 609 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
2eedcbfc0 Wadim Egorov 2016-08-29 610 RK808_ID_MSB);
9d6105e19 Elaine Zhang 2017-08-21 611 return msb;
2eedcbfc0 Wadim Egorov 2016-08-29 612 }
2eedcbfc0 Wadim Egorov 2016-08-29 613
1e99c2e53 Tony Xie 2018-07-23 614 lsb = i2c_smbus_read_byte_data(client, pmic_id_lsb);
9d6105e19 Elaine Zhang 2017-08-21 615 if (lsb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 616 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
9d6105e19 Elaine Zhang 2017-08-21 617 RK808_ID_LSB);
9d6105e19 Elaine Zhang 2017-08-21 618 return lsb;
9d6105e19 Elaine Zhang 2017-08-21 619 }
9d6105e19 Elaine Zhang 2017-08-21 620
9d6105e19 Elaine Zhang 2017-08-21 621 rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
9d6105e19 Elaine Zhang 2017-08-21 622 dev_info(&client->dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 623
2eedcbfc0 Wadim Egorov 2016-08-29 624 switch (rk808->variant) {
990f05f6a Elaine Zhang 2017-08-21 625 case RK805_ID:
990f05f6a Elaine Zhang 2017-08-21 626 rk808->regmap_cfg = &rk805_regmap_config;
990f05f6a Elaine Zhang 2017-08-21 627 rk808->regmap_irq_chip = &rk805_irq_chip;
990f05f6a Elaine Zhang 2017-08-21 628 pre_init_reg = rk805_pre_init_reg;
990f05f6a Elaine Zhang 2017-08-21 629 nr_pre_init_regs = ARRAY_SIZE(rk805_pre_init_reg);
990f05f6a Elaine Zhang 2017-08-21 630 cells = rk805s;
990f05f6a Elaine Zhang 2017-08-21 631 nr_cells = ARRAY_SIZE(rk805s);
990f05f6a Elaine Zhang 2017-08-21 632 pm_pwroff_fn = rk805_device_shutdown;
990f05f6a Elaine Zhang 2017-08-21 633 break;
2eedcbfc0 Wadim Egorov 2016-08-29 634 case RK808_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 635 rk808->regmap_cfg = &rk808_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 636 rk808->regmap_irq_chip = &rk808_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 637 pre_init_reg = rk808_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 638 nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 639 cells = rk808s;
2eedcbfc0 Wadim Egorov 2016-08-29 640 nr_cells = ARRAY_SIZE(rk808s);
b2e2c8509 Jianhong Chen 2016-10-17 641 pm_pwroff_fn = rk808_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 642 break;
2eedcbfc0 Wadim Egorov 2016-08-29 643 case RK818_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 644 rk808->regmap_cfg = &rk818_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 645 rk808->regmap_irq_chip = &rk818_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 646 pre_init_reg = rk818_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 647 nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 648 cells = rk818s;
2eedcbfc0 Wadim Egorov 2016-08-29 649 nr_cells = ARRAY_SIZE(rk818s);
b2e2c8509 Jianhong Chen 2016-10-17 650 pm_pwroff_fn = rk818_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 651 break;
1e99c2e53 Tony Xie 2018-07-23 652 case RK809_ID:
1e99c2e53 Tony Xie 2018-07-23 653 case RK817_ID:
1e99c2e53 Tony Xie 2018-07-23 654 rk808->regmap_cfg = &rk817_regmap_config;
1e99c2e53 Tony Xie 2018-07-23 655 rk808->regmap_irq_chip = &rk817_irq_chip;
1e99c2e53 Tony Xie 2018-07-23 656 pre_init_reg = rk817_pre_init_reg;
1e99c2e53 Tony Xie 2018-07-23 657 nr_pre_init_regs = ARRAY_SIZE(rk817_pre_init_reg);
1e99c2e53 Tony Xie 2018-07-23 658 cells = rk817s;
1e99c2e53 Tony Xie 2018-07-23 659 nr_cells = ARRAY_SIZE(rk817s);
1e99c2e53 Tony Xie 2018-07-23 660 pm_power_off_prepare = rk8xx_device_shutdown_prepare;
1e99c2e53 Tony Xie 2018-07-23 661 break;
2eedcbfc0 Wadim Egorov 2016-08-29 662 default:
2eedcbfc0 Wadim Egorov 2016-08-29 663 dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
2eedcbfc0 Wadim Egorov 2016-08-29 664 rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 665 return -EINVAL;
2eedcbfc0 Wadim Egorov 2016-08-29 666 }
2eedcbfc0 Wadim Egorov 2016-08-29 667
2eedcbfc0 Wadim Egorov 2016-08-29 668 rk808->i2c = client;
2eedcbfc0 Wadim Egorov 2016-08-29 669 i2c_set_clientdata(client, rk808);
2eedcbfc0 Wadim Egorov 2016-08-29 670
2eedcbfc0 Wadim Egorov 2016-08-29 671 rk808->regmap = devm_regmap_init_i2c(client, rk808->regmap_cfg);
f69a7cf74 Chris Zhong 2014-09-03 672 if (IS_ERR(rk808->regmap)) {
f69a7cf74 Chris Zhong 2014-09-03 673 dev_err(&client->dev, "regmap initialization failed\n");
f69a7cf74 Chris Zhong 2014-09-03 674 return PTR_ERR(rk808->regmap);
f69a7cf74 Chris Zhong 2014-09-03 675 }
f69a7cf74 Chris Zhong 2014-09-03 676
2eedcbfc0 Wadim Egorov 2016-08-29 677 if (!client->irq) {
2eedcbfc0 Wadim Egorov 2016-08-29 678 dev_err(&client->dev, "No interrupt support, no core IRQ\n");
2eedcbfc0 Wadim Egorov 2016-08-29 679 return -EINVAL;
f69a7cf74 Chris Zhong 2014-09-03 680 }
f69a7cf74 Chris Zhong 2014-09-03 681
f69a7cf74 Chris Zhong 2014-09-03 682 ret = regmap_add_irq_chip(rk808->regmap, client->irq,
f69a7cf74 Chris Zhong 2014-09-03 683 IRQF_ONESHOT, -1,
2eedcbfc0 Wadim Egorov 2016-08-29 684 rk808->regmap_irq_chip, &rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 685 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 686 dev_err(&client->dev, "Failed to add irq_chip %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 687 return ret;
f69a7cf74 Chris Zhong 2014-09-03 688 }
f69a7cf74 Chris Zhong 2014-09-03 689
2eedcbfc0 Wadim Egorov 2016-08-29 690 for (i = 0; i < nr_pre_init_regs; i++) {
2eedcbfc0 Wadim Egorov 2016-08-29 691 ret = regmap_update_bits(rk808->regmap,
2eedcbfc0 Wadim Egorov 2016-08-29 692 pre_init_reg[i].addr,
2eedcbfc0 Wadim Egorov 2016-08-29 693 pre_init_reg[i].mask,
2eedcbfc0 Wadim Egorov 2016-08-29 694 pre_init_reg[i].value);
2eedcbfc0 Wadim Egorov 2016-08-29 695 if (ret) {
2eedcbfc0 Wadim Egorov 2016-08-29 696 dev_err(&client->dev,
2eedcbfc0 Wadim Egorov 2016-08-29 697 "0x%x write err\n",
2eedcbfc0 Wadim Egorov 2016-08-29 698 pre_init_reg[i].addr);
2eedcbfc0 Wadim Egorov 2016-08-29 699 return ret;
2eedcbfc0 Wadim Egorov 2016-08-29 700 }
2eedcbfc0 Wadim Egorov 2016-08-29 701 }
f69a7cf74 Chris Zhong 2014-09-03 702
2eedcbfc0 Wadim Egorov 2016-08-29 703 ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
2eedcbfc0 Wadim Egorov 2016-08-29 704 cells, nr_cells, NULL, 0,
d5623161a Laxman Dewangan 2016-04-08 705 regmap_irq_get_domain(rk808->irq_data));
f69a7cf74 Chris Zhong 2014-09-03 706 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 707 dev_err(&client->dev, "failed to add MFD devices %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 708 goto err_irq;
f69a7cf74 Chris Zhong 2014-09-03 709 }
f69a7cf74 Chris Zhong 2014-09-03 710
f69a7cf74 Chris Zhong 2014-09-03 711 pm_off = of_property_read_bool(np,
f69a7cf74 Chris Zhong 2014-09-03 712 "rockchip,system-power-controller");
f69a7cf74 Chris Zhong 2014-09-03 713 if (pm_off && !pm_power_off) {
f69a7cf74 Chris Zhong 2014-09-03 714 rk808_i2c_client = client;
b2e2c8509 Jianhong Chen 2016-10-17 @715 pm_power_off = pm_pwroff_fn;
f69a7cf74 Chris Zhong 2014-09-03 716 }
f69a7cf74 Chris Zhong 2014-09-03 717
f69a7cf74 Chris Zhong 2014-09-03 718 return 0;
f69a7cf74 Chris Zhong 2014-09-03 719
f69a7cf74 Chris Zhong 2014-09-03 720 err_irq:
f69a7cf74 Chris Zhong 2014-09-03 721 regmap_del_irq_chip(client->irq, rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 722 return ret;
f69a7cf74 Chris Zhong 2014-09-03 723 }
f69a7cf74 Chris Zhong 2014-09-03 724
:::::: The code at line 715 was first introduced by commit
:::::: b2e2c85091710159b305735d557f4ef4695f5dff mfd: rk808: RK818 uses DEV_OFF to power off supplies
:::::: TO: Jianhong Chen <chenjh@rock-chips.com>
:::::: CC: Lee Jones <lee.jones@linaro.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 54212 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180724/3d22d6cb/attachment-0001.gz>
^ permalink raw reply
* Re: [PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
From: kbuild test robot @ 2018-07-23 21:59 UTC (permalink / raw)
Cc: linux-rtc, a.zummo, alexandre.belloni, tony.xie, huangtao, heiko,
devicetree, sboyd, zhangqing, linux-kernel, xsf, linux-rockchip,
broonie, kbuild-all, lee.jones, linux-clk, linux-arm-kernel,
chenjh
In-Reply-To: <1532315945-1094-2-git-send-email-tony.xie@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 11770 bytes --]
Hi Tony,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.18-rc6 next-20180723]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Tony-Xie/mfd-rk808-Add-RK817-and-RK809-support/20180724-040547
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//mfd/rk808.c: In function 'rk808_probe':
>> drivers//mfd/rk808.c:715:16: warning: 'pm_pwroff_fn' may be used uninitialized in this function [-Wmaybe-uninitialized]
pm_power_off = pm_pwroff_fn;
~~~~~~~~~~~~~^~~~~~~~~~~~~~
vim +/pm_pwroff_fn +715 drivers//mfd/rk808.c
2eedcbfc0 Wadim Egorov 2016-08-29 581
f69a7cf74 Chris Zhong 2014-09-03 582 static int rk808_probe(struct i2c_client *client,
f69a7cf74 Chris Zhong 2014-09-03 583 const struct i2c_device_id *id)
f69a7cf74 Chris Zhong 2014-09-03 584 {
f69a7cf74 Chris Zhong 2014-09-03 585 struct device_node *np = client->dev.of_node;
f69a7cf74 Chris Zhong 2014-09-03 586 struct rk808 *rk808;
2eedcbfc0 Wadim Egorov 2016-08-29 587 const struct rk808_reg_data *pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 588 const struct mfd_cell *cells;
b2e2c8509 Jianhong Chen 2016-10-17 589 void (*pm_pwroff_fn)(void);
2eedcbfc0 Wadim Egorov 2016-08-29 590 int nr_pre_init_regs;
2eedcbfc0 Wadim Egorov 2016-08-29 591 int nr_cells;
9d6105e19 Elaine Zhang 2017-08-21 592 int pm_off = 0, msb, lsb;
1e99c2e53 Tony Xie 2018-07-23 593 unsigned char pmic_id_msb = RK808_ID_MSB, pmic_id_lsb = RK808_ID_LSB;
f69a7cf74 Chris Zhong 2014-09-03 594 int ret;
f69a7cf74 Chris Zhong 2014-09-03 595 int i;
f69a7cf74 Chris Zhong 2014-09-03 596
f69a7cf74 Chris Zhong 2014-09-03 597 rk808 = devm_kzalloc(&client->dev, sizeof(*rk808), GFP_KERNEL);
f69a7cf74 Chris Zhong 2014-09-03 598 if (!rk808)
f69a7cf74 Chris Zhong 2014-09-03 599 return -ENOMEM;
f69a7cf74 Chris Zhong 2014-09-03 600
1e99c2e53 Tony Xie 2018-07-23 601 if (of_device_is_compatible(np, "rockchip,rk817") ||
1e99c2e53 Tony Xie 2018-07-23 602 of_device_is_compatible(np, "rockchip,rk809")) {
1e99c2e53 Tony Xie 2018-07-23 603 pmic_id_msb = RK817_ID_MSB;
1e99c2e53 Tony Xie 2018-07-23 604 pmic_id_lsb = RK817_ID_LSB;
1e99c2e53 Tony Xie 2018-07-23 605 }
9d6105e19 Elaine Zhang 2017-08-21 606 /* Read chip variant */
1e99c2e53 Tony Xie 2018-07-23 607 msb = i2c_smbus_read_byte_data(client, pmic_id_msb);
9d6105e19 Elaine Zhang 2017-08-21 608 if (msb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 609 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
2eedcbfc0 Wadim Egorov 2016-08-29 610 RK808_ID_MSB);
9d6105e19 Elaine Zhang 2017-08-21 611 return msb;
2eedcbfc0 Wadim Egorov 2016-08-29 612 }
2eedcbfc0 Wadim Egorov 2016-08-29 613
1e99c2e53 Tony Xie 2018-07-23 614 lsb = i2c_smbus_read_byte_data(client, pmic_id_lsb);
9d6105e19 Elaine Zhang 2017-08-21 615 if (lsb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 616 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
9d6105e19 Elaine Zhang 2017-08-21 617 RK808_ID_LSB);
9d6105e19 Elaine Zhang 2017-08-21 618 return lsb;
9d6105e19 Elaine Zhang 2017-08-21 619 }
9d6105e19 Elaine Zhang 2017-08-21 620
9d6105e19 Elaine Zhang 2017-08-21 621 rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
9d6105e19 Elaine Zhang 2017-08-21 622 dev_info(&client->dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 623
2eedcbfc0 Wadim Egorov 2016-08-29 624 switch (rk808->variant) {
990f05f6a Elaine Zhang 2017-08-21 625 case RK805_ID:
990f05f6a Elaine Zhang 2017-08-21 626 rk808->regmap_cfg = &rk805_regmap_config;
990f05f6a Elaine Zhang 2017-08-21 627 rk808->regmap_irq_chip = &rk805_irq_chip;
990f05f6a Elaine Zhang 2017-08-21 628 pre_init_reg = rk805_pre_init_reg;
990f05f6a Elaine Zhang 2017-08-21 629 nr_pre_init_regs = ARRAY_SIZE(rk805_pre_init_reg);
990f05f6a Elaine Zhang 2017-08-21 630 cells = rk805s;
990f05f6a Elaine Zhang 2017-08-21 631 nr_cells = ARRAY_SIZE(rk805s);
990f05f6a Elaine Zhang 2017-08-21 632 pm_pwroff_fn = rk805_device_shutdown;
990f05f6a Elaine Zhang 2017-08-21 633 break;
2eedcbfc0 Wadim Egorov 2016-08-29 634 case RK808_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 635 rk808->regmap_cfg = &rk808_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 636 rk808->regmap_irq_chip = &rk808_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 637 pre_init_reg = rk808_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 638 nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 639 cells = rk808s;
2eedcbfc0 Wadim Egorov 2016-08-29 640 nr_cells = ARRAY_SIZE(rk808s);
b2e2c8509 Jianhong Chen 2016-10-17 641 pm_pwroff_fn = rk808_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 642 break;
2eedcbfc0 Wadim Egorov 2016-08-29 643 case RK818_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 644 rk808->regmap_cfg = &rk818_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 645 rk808->regmap_irq_chip = &rk818_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 646 pre_init_reg = rk818_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 647 nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 648 cells = rk818s;
2eedcbfc0 Wadim Egorov 2016-08-29 649 nr_cells = ARRAY_SIZE(rk818s);
b2e2c8509 Jianhong Chen 2016-10-17 650 pm_pwroff_fn = rk818_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 651 break;
1e99c2e53 Tony Xie 2018-07-23 652 case RK809_ID:
1e99c2e53 Tony Xie 2018-07-23 653 case RK817_ID:
1e99c2e53 Tony Xie 2018-07-23 654 rk808->regmap_cfg = &rk817_regmap_config;
1e99c2e53 Tony Xie 2018-07-23 655 rk808->regmap_irq_chip = &rk817_irq_chip;
1e99c2e53 Tony Xie 2018-07-23 656 pre_init_reg = rk817_pre_init_reg;
1e99c2e53 Tony Xie 2018-07-23 657 nr_pre_init_regs = ARRAY_SIZE(rk817_pre_init_reg);
1e99c2e53 Tony Xie 2018-07-23 658 cells = rk817s;
1e99c2e53 Tony Xie 2018-07-23 659 nr_cells = ARRAY_SIZE(rk817s);
1e99c2e53 Tony Xie 2018-07-23 660 pm_power_off_prepare = rk8xx_device_shutdown_prepare;
1e99c2e53 Tony Xie 2018-07-23 661 break;
2eedcbfc0 Wadim Egorov 2016-08-29 662 default:
2eedcbfc0 Wadim Egorov 2016-08-29 663 dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
2eedcbfc0 Wadim Egorov 2016-08-29 664 rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 665 return -EINVAL;
2eedcbfc0 Wadim Egorov 2016-08-29 666 }
2eedcbfc0 Wadim Egorov 2016-08-29 667
2eedcbfc0 Wadim Egorov 2016-08-29 668 rk808->i2c = client;
2eedcbfc0 Wadim Egorov 2016-08-29 669 i2c_set_clientdata(client, rk808);
2eedcbfc0 Wadim Egorov 2016-08-29 670
2eedcbfc0 Wadim Egorov 2016-08-29 671 rk808->regmap = devm_regmap_init_i2c(client, rk808->regmap_cfg);
f69a7cf74 Chris Zhong 2014-09-03 672 if (IS_ERR(rk808->regmap)) {
f69a7cf74 Chris Zhong 2014-09-03 673 dev_err(&client->dev, "regmap initialization failed\n");
f69a7cf74 Chris Zhong 2014-09-03 674 return PTR_ERR(rk808->regmap);
f69a7cf74 Chris Zhong 2014-09-03 675 }
f69a7cf74 Chris Zhong 2014-09-03 676
2eedcbfc0 Wadim Egorov 2016-08-29 677 if (!client->irq) {
2eedcbfc0 Wadim Egorov 2016-08-29 678 dev_err(&client->dev, "No interrupt support, no core IRQ\n");
2eedcbfc0 Wadim Egorov 2016-08-29 679 return -EINVAL;
f69a7cf74 Chris Zhong 2014-09-03 680 }
f69a7cf74 Chris Zhong 2014-09-03 681
f69a7cf74 Chris Zhong 2014-09-03 682 ret = regmap_add_irq_chip(rk808->regmap, client->irq,
f69a7cf74 Chris Zhong 2014-09-03 683 IRQF_ONESHOT, -1,
2eedcbfc0 Wadim Egorov 2016-08-29 684 rk808->regmap_irq_chip, &rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 685 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 686 dev_err(&client->dev, "Failed to add irq_chip %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 687 return ret;
f69a7cf74 Chris Zhong 2014-09-03 688 }
f69a7cf74 Chris Zhong 2014-09-03 689
2eedcbfc0 Wadim Egorov 2016-08-29 690 for (i = 0; i < nr_pre_init_regs; i++) {
2eedcbfc0 Wadim Egorov 2016-08-29 691 ret = regmap_update_bits(rk808->regmap,
2eedcbfc0 Wadim Egorov 2016-08-29 692 pre_init_reg[i].addr,
2eedcbfc0 Wadim Egorov 2016-08-29 693 pre_init_reg[i].mask,
2eedcbfc0 Wadim Egorov 2016-08-29 694 pre_init_reg[i].value);
2eedcbfc0 Wadim Egorov 2016-08-29 695 if (ret) {
2eedcbfc0 Wadim Egorov 2016-08-29 696 dev_err(&client->dev,
2eedcbfc0 Wadim Egorov 2016-08-29 697 "0x%x write err\n",
2eedcbfc0 Wadim Egorov 2016-08-29 698 pre_init_reg[i].addr);
2eedcbfc0 Wadim Egorov 2016-08-29 699 return ret;
2eedcbfc0 Wadim Egorov 2016-08-29 700 }
2eedcbfc0 Wadim Egorov 2016-08-29 701 }
f69a7cf74 Chris Zhong 2014-09-03 702
2eedcbfc0 Wadim Egorov 2016-08-29 703 ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
2eedcbfc0 Wadim Egorov 2016-08-29 704 cells, nr_cells, NULL, 0,
d5623161a Laxman Dewangan 2016-04-08 705 regmap_irq_get_domain(rk808->irq_data));
f69a7cf74 Chris Zhong 2014-09-03 706 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 707 dev_err(&client->dev, "failed to add MFD devices %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 708 goto err_irq;
f69a7cf74 Chris Zhong 2014-09-03 709 }
f69a7cf74 Chris Zhong 2014-09-03 710
f69a7cf74 Chris Zhong 2014-09-03 711 pm_off = of_property_read_bool(np,
f69a7cf74 Chris Zhong 2014-09-03 712 "rockchip,system-power-controller");
f69a7cf74 Chris Zhong 2014-09-03 713 if (pm_off && !pm_power_off) {
f69a7cf74 Chris Zhong 2014-09-03 714 rk808_i2c_client = client;
b2e2c8509 Jianhong Chen 2016-10-17 @715 pm_power_off = pm_pwroff_fn;
f69a7cf74 Chris Zhong 2014-09-03 716 }
f69a7cf74 Chris Zhong 2014-09-03 717
f69a7cf74 Chris Zhong 2014-09-03 718 return 0;
f69a7cf74 Chris Zhong 2014-09-03 719
f69a7cf74 Chris Zhong 2014-09-03 720 err_irq:
f69a7cf74 Chris Zhong 2014-09-03 721 regmap_del_irq_chip(client->irq, rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 722 return ret;
f69a7cf74 Chris Zhong 2014-09-03 723 }
f69a7cf74 Chris Zhong 2014-09-03 724
:::::: The code at line 715 was first introduced by commit
:::::: b2e2c85091710159b305735d557f4ef4695f5dff mfd: rk808: RK818 uses DEV_OFF to power off supplies
:::::: TO: Jianhong Chen <chenjh@rock-chips.com>
:::::: CC: Lee Jones <lee.jones@linaro.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54212 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] mfd: rk808: Add RK817 and RK809 support
From: kbuild test robot @ 2018-07-23 21:59 UTC (permalink / raw)
To: Tony Xie
Cc: linux-rtc, a.zummo, alexandre.belloni, tony.xie, huangtao, heiko,
devicetree, sboyd, zhangqing, linux-kernel, xsf, linux-rockchip,
broonie, kbuild-all, lee.jones, linux-clk, linux-arm-kernel,
chenjh
In-Reply-To: <1532315945-1094-2-git-send-email-tony.xie@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 11770 bytes --]
Hi Tony,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.18-rc6 next-20180723]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Tony-Xie/mfd-rk808-Add-RK817-and-RK809-support/20180724-040547
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers//mfd/rk808.c: In function 'rk808_probe':
>> drivers//mfd/rk808.c:715:16: warning: 'pm_pwroff_fn' may be used uninitialized in this function [-Wmaybe-uninitialized]
pm_power_off = pm_pwroff_fn;
~~~~~~~~~~~~~^~~~~~~~~~~~~~
vim +/pm_pwroff_fn +715 drivers//mfd/rk808.c
2eedcbfc0 Wadim Egorov 2016-08-29 581
f69a7cf74 Chris Zhong 2014-09-03 582 static int rk808_probe(struct i2c_client *client,
f69a7cf74 Chris Zhong 2014-09-03 583 const struct i2c_device_id *id)
f69a7cf74 Chris Zhong 2014-09-03 584 {
f69a7cf74 Chris Zhong 2014-09-03 585 struct device_node *np = client->dev.of_node;
f69a7cf74 Chris Zhong 2014-09-03 586 struct rk808 *rk808;
2eedcbfc0 Wadim Egorov 2016-08-29 587 const struct rk808_reg_data *pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 588 const struct mfd_cell *cells;
b2e2c8509 Jianhong Chen 2016-10-17 589 void (*pm_pwroff_fn)(void);
2eedcbfc0 Wadim Egorov 2016-08-29 590 int nr_pre_init_regs;
2eedcbfc0 Wadim Egorov 2016-08-29 591 int nr_cells;
9d6105e19 Elaine Zhang 2017-08-21 592 int pm_off = 0, msb, lsb;
1e99c2e53 Tony Xie 2018-07-23 593 unsigned char pmic_id_msb = RK808_ID_MSB, pmic_id_lsb = RK808_ID_LSB;
f69a7cf74 Chris Zhong 2014-09-03 594 int ret;
f69a7cf74 Chris Zhong 2014-09-03 595 int i;
f69a7cf74 Chris Zhong 2014-09-03 596
f69a7cf74 Chris Zhong 2014-09-03 597 rk808 = devm_kzalloc(&client->dev, sizeof(*rk808), GFP_KERNEL);
f69a7cf74 Chris Zhong 2014-09-03 598 if (!rk808)
f69a7cf74 Chris Zhong 2014-09-03 599 return -ENOMEM;
f69a7cf74 Chris Zhong 2014-09-03 600
1e99c2e53 Tony Xie 2018-07-23 601 if (of_device_is_compatible(np, "rockchip,rk817") ||
1e99c2e53 Tony Xie 2018-07-23 602 of_device_is_compatible(np, "rockchip,rk809")) {
1e99c2e53 Tony Xie 2018-07-23 603 pmic_id_msb = RK817_ID_MSB;
1e99c2e53 Tony Xie 2018-07-23 604 pmic_id_lsb = RK817_ID_LSB;
1e99c2e53 Tony Xie 2018-07-23 605 }
9d6105e19 Elaine Zhang 2017-08-21 606 /* Read chip variant */
1e99c2e53 Tony Xie 2018-07-23 607 msb = i2c_smbus_read_byte_data(client, pmic_id_msb);
9d6105e19 Elaine Zhang 2017-08-21 608 if (msb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 609 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
2eedcbfc0 Wadim Egorov 2016-08-29 610 RK808_ID_MSB);
9d6105e19 Elaine Zhang 2017-08-21 611 return msb;
2eedcbfc0 Wadim Egorov 2016-08-29 612 }
2eedcbfc0 Wadim Egorov 2016-08-29 613
1e99c2e53 Tony Xie 2018-07-23 614 lsb = i2c_smbus_read_byte_data(client, pmic_id_lsb);
9d6105e19 Elaine Zhang 2017-08-21 615 if (lsb < 0) {
9d6105e19 Elaine Zhang 2017-08-21 616 dev_err(&client->dev, "failed to read the chip id at 0x%x\n",
9d6105e19 Elaine Zhang 2017-08-21 617 RK808_ID_LSB);
9d6105e19 Elaine Zhang 2017-08-21 618 return lsb;
9d6105e19 Elaine Zhang 2017-08-21 619 }
9d6105e19 Elaine Zhang 2017-08-21 620
9d6105e19 Elaine Zhang 2017-08-21 621 rk808->variant = ((msb << 8) | lsb) & RK8XX_ID_MSK;
9d6105e19 Elaine Zhang 2017-08-21 622 dev_info(&client->dev, "chip id: 0x%x\n", (unsigned int)rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 623
2eedcbfc0 Wadim Egorov 2016-08-29 624 switch (rk808->variant) {
990f05f6a Elaine Zhang 2017-08-21 625 case RK805_ID:
990f05f6a Elaine Zhang 2017-08-21 626 rk808->regmap_cfg = &rk805_regmap_config;
990f05f6a Elaine Zhang 2017-08-21 627 rk808->regmap_irq_chip = &rk805_irq_chip;
990f05f6a Elaine Zhang 2017-08-21 628 pre_init_reg = rk805_pre_init_reg;
990f05f6a Elaine Zhang 2017-08-21 629 nr_pre_init_regs = ARRAY_SIZE(rk805_pre_init_reg);
990f05f6a Elaine Zhang 2017-08-21 630 cells = rk805s;
990f05f6a Elaine Zhang 2017-08-21 631 nr_cells = ARRAY_SIZE(rk805s);
990f05f6a Elaine Zhang 2017-08-21 632 pm_pwroff_fn = rk805_device_shutdown;
990f05f6a Elaine Zhang 2017-08-21 633 break;
2eedcbfc0 Wadim Egorov 2016-08-29 634 case RK808_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 635 rk808->regmap_cfg = &rk808_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 636 rk808->regmap_irq_chip = &rk808_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 637 pre_init_reg = rk808_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 638 nr_pre_init_regs = ARRAY_SIZE(rk808_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 639 cells = rk808s;
2eedcbfc0 Wadim Egorov 2016-08-29 640 nr_cells = ARRAY_SIZE(rk808s);
b2e2c8509 Jianhong Chen 2016-10-17 641 pm_pwroff_fn = rk808_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 642 break;
2eedcbfc0 Wadim Egorov 2016-08-29 643 case RK818_ID:
2eedcbfc0 Wadim Egorov 2016-08-29 644 rk808->regmap_cfg = &rk818_regmap_config;
2eedcbfc0 Wadim Egorov 2016-08-29 645 rk808->regmap_irq_chip = &rk818_irq_chip;
2eedcbfc0 Wadim Egorov 2016-08-29 646 pre_init_reg = rk818_pre_init_reg;
2eedcbfc0 Wadim Egorov 2016-08-29 647 nr_pre_init_regs = ARRAY_SIZE(rk818_pre_init_reg);
2eedcbfc0 Wadim Egorov 2016-08-29 648 cells = rk818s;
2eedcbfc0 Wadim Egorov 2016-08-29 649 nr_cells = ARRAY_SIZE(rk818s);
b2e2c8509 Jianhong Chen 2016-10-17 650 pm_pwroff_fn = rk818_device_shutdown;
2eedcbfc0 Wadim Egorov 2016-08-29 651 break;
1e99c2e53 Tony Xie 2018-07-23 652 case RK809_ID:
1e99c2e53 Tony Xie 2018-07-23 653 case RK817_ID:
1e99c2e53 Tony Xie 2018-07-23 654 rk808->regmap_cfg = &rk817_regmap_config;
1e99c2e53 Tony Xie 2018-07-23 655 rk808->regmap_irq_chip = &rk817_irq_chip;
1e99c2e53 Tony Xie 2018-07-23 656 pre_init_reg = rk817_pre_init_reg;
1e99c2e53 Tony Xie 2018-07-23 657 nr_pre_init_regs = ARRAY_SIZE(rk817_pre_init_reg);
1e99c2e53 Tony Xie 2018-07-23 658 cells = rk817s;
1e99c2e53 Tony Xie 2018-07-23 659 nr_cells = ARRAY_SIZE(rk817s);
1e99c2e53 Tony Xie 2018-07-23 660 pm_power_off_prepare = rk8xx_device_shutdown_prepare;
1e99c2e53 Tony Xie 2018-07-23 661 break;
2eedcbfc0 Wadim Egorov 2016-08-29 662 default:
2eedcbfc0 Wadim Egorov 2016-08-29 663 dev_err(&client->dev, "Unsupported RK8XX ID %lu\n",
2eedcbfc0 Wadim Egorov 2016-08-29 664 rk808->variant);
2eedcbfc0 Wadim Egorov 2016-08-29 665 return -EINVAL;
2eedcbfc0 Wadim Egorov 2016-08-29 666 }
2eedcbfc0 Wadim Egorov 2016-08-29 667
2eedcbfc0 Wadim Egorov 2016-08-29 668 rk808->i2c = client;
2eedcbfc0 Wadim Egorov 2016-08-29 669 i2c_set_clientdata(client, rk808);
2eedcbfc0 Wadim Egorov 2016-08-29 670
2eedcbfc0 Wadim Egorov 2016-08-29 671 rk808->regmap = devm_regmap_init_i2c(client, rk808->regmap_cfg);
f69a7cf74 Chris Zhong 2014-09-03 672 if (IS_ERR(rk808->regmap)) {
f69a7cf74 Chris Zhong 2014-09-03 673 dev_err(&client->dev, "regmap initialization failed\n");
f69a7cf74 Chris Zhong 2014-09-03 674 return PTR_ERR(rk808->regmap);
f69a7cf74 Chris Zhong 2014-09-03 675 }
f69a7cf74 Chris Zhong 2014-09-03 676
2eedcbfc0 Wadim Egorov 2016-08-29 677 if (!client->irq) {
2eedcbfc0 Wadim Egorov 2016-08-29 678 dev_err(&client->dev, "No interrupt support, no core IRQ\n");
2eedcbfc0 Wadim Egorov 2016-08-29 679 return -EINVAL;
f69a7cf74 Chris Zhong 2014-09-03 680 }
f69a7cf74 Chris Zhong 2014-09-03 681
f69a7cf74 Chris Zhong 2014-09-03 682 ret = regmap_add_irq_chip(rk808->regmap, client->irq,
f69a7cf74 Chris Zhong 2014-09-03 683 IRQF_ONESHOT, -1,
2eedcbfc0 Wadim Egorov 2016-08-29 684 rk808->regmap_irq_chip, &rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 685 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 686 dev_err(&client->dev, "Failed to add irq_chip %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 687 return ret;
f69a7cf74 Chris Zhong 2014-09-03 688 }
f69a7cf74 Chris Zhong 2014-09-03 689
2eedcbfc0 Wadim Egorov 2016-08-29 690 for (i = 0; i < nr_pre_init_regs; i++) {
2eedcbfc0 Wadim Egorov 2016-08-29 691 ret = regmap_update_bits(rk808->regmap,
2eedcbfc0 Wadim Egorov 2016-08-29 692 pre_init_reg[i].addr,
2eedcbfc0 Wadim Egorov 2016-08-29 693 pre_init_reg[i].mask,
2eedcbfc0 Wadim Egorov 2016-08-29 694 pre_init_reg[i].value);
2eedcbfc0 Wadim Egorov 2016-08-29 695 if (ret) {
2eedcbfc0 Wadim Egorov 2016-08-29 696 dev_err(&client->dev,
2eedcbfc0 Wadim Egorov 2016-08-29 697 "0x%x write err\n",
2eedcbfc0 Wadim Egorov 2016-08-29 698 pre_init_reg[i].addr);
2eedcbfc0 Wadim Egorov 2016-08-29 699 return ret;
2eedcbfc0 Wadim Egorov 2016-08-29 700 }
2eedcbfc0 Wadim Egorov 2016-08-29 701 }
f69a7cf74 Chris Zhong 2014-09-03 702
2eedcbfc0 Wadim Egorov 2016-08-29 703 ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_NONE,
2eedcbfc0 Wadim Egorov 2016-08-29 704 cells, nr_cells, NULL, 0,
d5623161a Laxman Dewangan 2016-04-08 705 regmap_irq_get_domain(rk808->irq_data));
f69a7cf74 Chris Zhong 2014-09-03 706 if (ret) {
f69a7cf74 Chris Zhong 2014-09-03 707 dev_err(&client->dev, "failed to add MFD devices %d\n", ret);
f69a7cf74 Chris Zhong 2014-09-03 708 goto err_irq;
f69a7cf74 Chris Zhong 2014-09-03 709 }
f69a7cf74 Chris Zhong 2014-09-03 710
f69a7cf74 Chris Zhong 2014-09-03 711 pm_off = of_property_read_bool(np,
f69a7cf74 Chris Zhong 2014-09-03 712 "rockchip,system-power-controller");
f69a7cf74 Chris Zhong 2014-09-03 713 if (pm_off && !pm_power_off) {
f69a7cf74 Chris Zhong 2014-09-03 714 rk808_i2c_client = client;
b2e2c8509 Jianhong Chen 2016-10-17 @715 pm_power_off = pm_pwroff_fn;
f69a7cf74 Chris Zhong 2014-09-03 716 }
f69a7cf74 Chris Zhong 2014-09-03 717
f69a7cf74 Chris Zhong 2014-09-03 718 return 0;
f69a7cf74 Chris Zhong 2014-09-03 719
f69a7cf74 Chris Zhong 2014-09-03 720 err_irq:
f69a7cf74 Chris Zhong 2014-09-03 721 regmap_del_irq_chip(client->irq, rk808->irq_data);
f69a7cf74 Chris Zhong 2014-09-03 722 return ret;
f69a7cf74 Chris Zhong 2014-09-03 723 }
f69a7cf74 Chris Zhong 2014-09-03 724
:::::: The code at line 715 was first introduced by commit
:::::: b2e2c85091710159b305735d557f4ef4695f5dff mfd: rk808: RK818 uses DEV_OFF to power off supplies
:::::: TO: Jianhong Chen <chenjh@rock-chips.com>
:::::: CC: Lee Jones <lee.jones@linaro.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 54212 bytes --]
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/5] compress/zlib: add ZLIB PMD
From: De Lara Guarch, Pablo @ 2018-07-23 21:58 UTC (permalink / raw)
To: Shally Verma
Cc: dev@dpdk.org, pathreya@caviumnetworks.com,
mchalla@caviumnetworks.com, Ashish Gupta, Sunila Sahu
In-Reply-To: <1532357474-9544-2-git-send-email-shally.verma@caviumnetworks.com>
> -----Original Message-----
> From: Shally Verma [mailto:shally.verma@caviumnetworks.com]
> Sent: Monday, July 23, 2018 3:51 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> mchalla@caviumnetworks.com; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>
> Subject: [PATCH v4 1/5] compress/zlib: add ZLIB PMD
>
> From: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>
> Add initial PMD setup routines in compressdev framework. ZLIB PMD appears as
> virtual compression device. User would need to install zlib prior to enabling this
> PMD.
>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
...
> +++ b/drivers/compress/zlib/zlib_pmd.c
...
> +static int
> +zlib_probe(struct rte_vdev_device *vdev) {
> + struct rte_compressdev_pmd_init_params init_params = {
> + "",
> + rte_socket_id()
> + };
> + const char *name;
> + const char *input_args;
> +
> + name = rte_vdev_device_name(vdev);
> +
> + if (name == NULL)
> + return -EINVAL;
> + input_args = rte_vdev_device_args(vdev);
> + rte_compressdev_pmd_parse_input_args(&init_params, input_args);
Need to check the return value of this function.
^ permalink raw reply
* Re: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
From: Mark Railton @ 2018-07-23 21:58 UTC (permalink / raw)
To: Randy Dunlap; +Cc: boris.ostrovsky, jgross, xen-devel, linux-kernel
In-Reply-To: <e8cab255-eb21-fd08-e62b-3afbbe853b84@infradead.org>
On Mon, Jul 23, 2018 at 02:55:12PM -0700, Randy Dunlap wrote:
> On 07/23/2018 02:48 PM, Mark Railton wrote:
> > On Mon, Jul 23, 2018 at 02:44:28PM -0700, Randy Dunlap wrote:
> >> On 07/23/2018 02:40 PM, Mark Railton wrote:
> >>> On Mon, Jul 23, 2018 at 02:38:20PM -0700, Randy Dunlap wrote:
> >>>> On 07/23/2018 02:34 PM, Mark Railton wrote:
> >>>>> Fixed issue with multi line comment
> >>>>
> >>>> Fix [not Fixed]
> >>>>
> >>>>>
> >>>>> Signed-off-by: Mark Railton <mark@markrailton.com>
> >>>>> ---
> >>>>> drivers/xen/xlate_mmu.c | 5 +++--
> >>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> >>>>> index 23f1387b3ef7..3b03bc1641ed 100644
> >>>>> --- a/drivers/xen/xlate_mmu.c
> >>>>> +++ b/drivers/xen/xlate_mmu.c
> >>>>> @@ -151,8 +151,9 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> >>>>> struct remap_data data;
> >>>>> unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >>>>>
> >>>>> - /* Kept here for the purpose of making sure code doesn't break
> >>>>> - x86 PVOPS */
> >>>>> + /* Kept here for the purpose of making sure code doesn't
> >>>>> + * break x86 PVOPS
> >>>>> + */
> >>>>
> >>>> That is still not the preferred kernel multi-line comment style.
> >>>> Documentation/process/coding-style.rst says:
> >>>>
> >>>> /*
> >>>> * This is the preferred style for multi-line
> >>>> * comments in the Linux kernel source code.
> >>>> * Please use it consistently.
> >>>> *
> >>>> * Description: A column of asterisks on the left side,
> >>>> * with beginning and ending almost-blank lines.
> >>>> */
> >>>>
> >>>> although Networking code has a slightly different preferred style (as in
> >>>> your patch).
> >>>>
> >>>>> BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >>>>>
> >>>>> data.fgfn = gfn;
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> ~Randy
> >>>
> >>> Thank's for the feedback, I'll get that updated now.
> >>>
> >>> I'm still kinda new to this, I assume I need to send the new patch via
> >>> git send-email?
> >>
> >> That is one option. Use whatever works for you.
> >>
> >> There are several email clients that also work well.
> >> See Documentation/process/email-clients.rst.
> >>
> >>
> >> --
> >> ~Randy
> >
> > From 57c8104d2a30020005be16df2ca69ed66f6c4ae9 Mon Sep 17 00:00:00 2001
> > From: Mark Railton <mark@markrailton.com>
> > Date: Mon, 23 Jul 2018 22:28:53 +0100
> > Subject: [PATCH] Drivers: Xen: xlate_mmu.c: Fixed comment layout
> >
> > Fixed issue with multi line comment
> >
> > Signed-off-by: Mark Railton <mark@markrailton.com>
> > ---
> > drivers/xen/xlate_mmu.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/xlate_mmu.c b/drivers/xen/xlate_mmu.c
> > index 23f1387b3ef7..2b77c79f8ce7 100644
> > --- a/drivers/xen/xlate_mmu.c
> > +++ b/drivers/xen/xlate_mmu.c
> > @@ -151,8 +151,10 @@ int xen_xlate_remap_gfn_array(struct vm_area_struct *vma,
> > struct remap_data data;
> > unsigned long range = DIV_ROUND_UP(nr, XEN_PFN_PER_PAGE) << PAGE_SHIFT;
> >
> > - /* Kept here for the purpose of making sure code doesn't break
> > - x86 PVOPS */
> > + /*
> > + * Kept here for the purpose of making sure code doesn't
> > + * break x86 PVOPS
> > + */
> > BUG_ON(!((vma->vm_flags & (VM_PFNMAP | VM_IO)) == (VM_PFNMAP | VM_IO)));
> >
> > data.fgfn = gfn;
> > --
> > 2.17.1
>
>
> Hi,
>
> a. The subject and the patch description should be in present tense, i.e.,
> Fix instead of Fixed.
>
> b. Ideally you start a new email thread for new versions of a patch (but Cc:
> the interested parties).
>
> For the patch itself:
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
>
> Thanks.
>
> --
> ~Randy
Thank you for the feedback, I will make sure to take that on board.
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.