All of lore.kernel.org
 help / color / mirror / Atom feed
* [net-next 06/12] i40e: allow look-up of MAC address from Open Firmware or IDPROM
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Jacob Keller <jacob.e.keller@intel.com>

Look up the MAC address from the eth_get_platform_mac_address() function
first before checking what the firmware provides. We already handle the
case of re-writing the MAC-VLAN filter, so there is no need to add extra
code for this. However, update the comment where we do this to indicate
that it does impact the Open Firmware MAC address case.

Change-ID: I73e59fbe0b0e7e6f3ee9f5170d0bd3a4d5faf4db
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 22831a4a9099..2111f120865a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -9326,10 +9326,15 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
 	if (vsi->type == I40E_VSI_MAIN) {
 		SET_NETDEV_DEV(netdev, &pf->pdev->dev);
 		ether_addr_copy(mac_addr, hw->mac.perm_addr);
-		/* The following steps are necessary to properly keep track of
-		 * MAC-VLAN filters loaded into firmware - first we remove
-		 * filter that is automatically generated by firmware and then
-		 * add new filter both to the driver hash table and firmware.
+		/* The following steps are necessary for two reasons. First,
+		 * some older NVM configurations load a default MAC-VLAN
+		 * filter that will accept any tagged packet, and we want to
+		 * replace this with a normal filter. Additionally, it is
+		 * possible our MAC address was provided by the platform using
+		 * Open Firmware or similar.
+		 *
+		 * Thus, we need to remove the default filter and install one
+		 * specific to the MAC address.
 		 */
 		i40e_rm_default_mac_filter(vsi, mac_addr);
 		spin_lock_bh(&vsi->mac_filter_hash_lock);
@@ -10834,20 +10839,18 @@ static void i40e_print_features(struct i40e_pf *pf)
 
 /**
  * i40e_get_platform_mac_addr - get platform-specific MAC address
- *
  * @pdev: PCI device information struct
  * @pf: board private structure
  *
- * Look up the MAC address in Open Firmware  on systems that support it,
- * and use IDPROM on SPARC if no OF address is found. On return, the
- * I40E_FLAG_PF_MAC will be wset in pf->flags if a platform-specific value
- * has been selected.
+ * Look up the MAC address for the device. First we'll try
+ * eth_platform_get_mac_address, which will check Open Firmware, or arch
+ * specific fallback. Otherwise, we'll default to the stored value in
+ * firmware.
  **/
 static void i40e_get_platform_mac_addr(struct pci_dev *pdev, struct i40e_pf *pf)
 {
-	pf->flags &= ~I40E_FLAG_PF_MAC;
-	if (!eth_platform_get_mac_address(&pdev->dev, pf->hw.mac.addr))
-		pf->flags |= I40E_FLAG_PF_MAC;
+	if (eth_platform_get_mac_address(&pdev->dev, pf->hw.mac.addr))
+		i40e_get_mac_addr(&pf->hw, pf->hw.mac.addr);
 }
 
 /**
@@ -11061,9 +11064,9 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 		i40e_aq_stop_lldp(hw, true, NULL);
 	}
 
-	i40e_get_mac_addr(hw, hw->mac.addr);
 	/* allow a platform config to override the HW addr */
 	i40e_get_platform_mac_addr(pdev, pf);
+
 	if (!is_valid_ether_addr(hw->mac.addr)) {
 		dev_info(&pdev->dev, "invalid MAC address %pM\n", hw->mac.addr);
 		err = -EIO;
-- 
2.12.2

^ permalink raw reply related

* [net-next 05/12] i40e: Simplify i40e_detect_recover_hung_queue logic
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Alan Brady, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Alan Brady <alan.brady@intel.com>

This patch greatly reduces the unneeded complexity in the
i40e_detect_recover_hung_queue code path.  The previous implementation
set a 'hung bit' which would then get cleared while polling.  If the
detection routine was called a second time with the bit already set, we
would issue a software interrupt.  This patch makes it such that if
interrupts are disabled and we have pending TX descriptors, we trigger a
software interrupt since in, the worst case, queues are already clean
and we have an extra interrupt.

Additionally this patch removes the workaround for lost interrupts as
calling napi_reschedule in this context can cause software interrupts to
fire on the wrong CPU.

Change-ID: Iae108582a3ceb6229ed1d22e4ed6e69cf97aad8d
Signed-off-by: Alan Brady <alan.brady@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e.h         |  4 --
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c |  1 -
 drivers/net/ethernet/intel/i40e/i40e_main.c    | 59 +++++---------------------
 drivers/net/ethernet/intel/i40e/i40e_txrx.c    | 12 ++----
 drivers/net/ethernet/intel/i40e/i40e_txrx.h    |  3 +-
 5 files changed, 15 insertions(+), 64 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 686327c031fa..110ef4204306 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -617,7 +617,6 @@ struct i40e_vsi {
 	u32 tx_busy;
 	u64 tx_linearize;
 	u64 tx_force_wb;
-	u64 tx_lost_interrupt;
 	u32 rx_buf_failed;
 	u32 rx_page_failed;
 
@@ -703,9 +702,6 @@ struct i40e_q_vector {
 
 	u8 num_ringpairs;	/* total number of ring pairs in vector */
 
-#define I40E_Q_VECTOR_HUNG_DETECT 0 /* Bit Index for hung detection logic */
-	unsigned long hung_detected; /* Set/Reset for hung_detection logic */
-
 	cpumask_t affinity_mask;
 	struct irq_affinity_notify affinity_notify;
 
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 68c0f204f93e..10325b5a9805 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -89,7 +89,6 @@ static const struct i40e_stats i40e_gstrings_misc_stats[] = {
 	I40E_VSI_STAT("rx_unknown_protocol", eth_stats.rx_unknown_protocol),
 	I40E_VSI_STAT("tx_linearize", tx_linearize),
 	I40E_VSI_STAT("tx_force_wb", tx_force_wb),
-	I40E_VSI_STAT("tx_lost_interrupt", tx_lost_interrupt),
 	I40E_VSI_STAT("rx_alloc_fail", rx_buf_failed),
 	I40E_VSI_STAT("rx_pg_alloc_fail", rx_page_failed),
 };
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 8181647f512e..22831a4a9099 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -737,7 +737,6 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
 	struct i40e_eth_stats *oes;
 	struct i40e_eth_stats *es;     /* device's eth stats */
 	u32 tx_restart, tx_busy;
-	u64 tx_lost_interrupt;
 	struct i40e_ring *p;
 	u32 rx_page, rx_buf;
 	u64 bytes, packets;
@@ -763,7 +762,6 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
 	rx_b = rx_p = 0;
 	tx_b = tx_p = 0;
 	tx_restart = tx_busy = tx_linearize = tx_force_wb = 0;
-	tx_lost_interrupt = 0;
 	rx_page = 0;
 	rx_buf = 0;
 	rcu_read_lock();
@@ -782,7 +780,6 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
 		tx_busy += p->tx_stats.tx_busy;
 		tx_linearize += p->tx_stats.tx_linearize;
 		tx_force_wb += p->tx_stats.tx_force_wb;
-		tx_lost_interrupt += p->tx_stats.tx_lost_interrupt;
 
 		/* Rx queue is part of the same block as Tx queue */
 		p = &p[1];
@@ -801,7 +798,6 @@ static void i40e_update_vsi_stats(struct i40e_vsi *vsi)
 	vsi->tx_busy = tx_busy;
 	vsi->tx_linearize = tx_linearize;
 	vsi->tx_force_wb = tx_force_wb;
-	vsi->tx_lost_interrupt = tx_lost_interrupt;
 	vsi->rx_page_failed = rx_page;
 	vsi->rx_buf_failed = rx_buf;
 
@@ -4508,16 +4504,15 @@ static int i40e_pf_wait_queues_disabled(struct i40e_pf *pf)
  * @vsi: Pointer to VSI struct
  *
  * This function checks specified queue for given VSI. Detects hung condition.
- * Sets hung bit since it is two step process. Before next run of service task
- * if napi_poll runs, it reset 'hung' bit for respective q_vector. If not,
- * hung condition remain unchanged and during subsequent run, this function
- * issues SW interrupt to recover from hung condition.
+ * We proactively detect hung TX queues by checking if interrupts are disabled
+ * but there are pending descriptors.  If it appears hung, attempt to recover
+ * by triggering a SW interrupt.
  **/
 static void i40e_detect_recover_hung_queue(int q_idx, struct i40e_vsi *vsi)
 {
 	struct i40e_ring *tx_ring = NULL;
 	struct i40e_pf	*pf;
-	u32 head, val, tx_pending_hw;
+	u32 val, tx_pending;
 	int i;
 
 	pf = vsi->back;
@@ -4543,47 +4538,15 @@ static void i40e_detect_recover_hung_queue(int q_idx, struct i40e_vsi *vsi)
 	else
 		val = rd32(&pf->hw, I40E_PFINT_DYN_CTL0);
 
-	head = i40e_get_head(tx_ring);
+	tx_pending = i40e_get_tx_pending(tx_ring);
 
-	tx_pending_hw = i40e_get_tx_pending(tx_ring, false);
-
-	/* HW is done executing descriptors, updated HEAD write back,
-	 * but SW hasn't processed those descriptors. If interrupt is
-	 * not generated from this point ON, it could result into
-	 * dev_watchdog detecting timeout on those netdev_queue,
-	 * hence proactively trigger SW interrupt.
+	/* Interrupts are disabled and TX pending is non-zero,
+	 * trigger the SW interrupt (don't wait). Worst case
+	 * there will be one extra interrupt which may result
+	 * into not cleaning any queues because queues are cleaned.
 	 */
-	if (tx_pending_hw && (!(val & I40E_PFINT_DYN_CTLN_INTENA_MASK))) {
-		/* NAPI Poll didn't run and clear since it was set */
-		if (test_and_clear_bit(I40E_Q_VECTOR_HUNG_DETECT,
-				       &tx_ring->q_vector->hung_detected)) {
-			netdev_info(vsi->netdev, "VSI_seid %d, Hung TX queue %d, tx_pending_hw: %d, NTC:0x%x, HWB: 0x%x, NTU: 0x%x, TAIL: 0x%x\n",
-				    vsi->seid, q_idx, tx_pending_hw,
-				    tx_ring->next_to_clean, head,
-				    tx_ring->next_to_use,
-				    readl(tx_ring->tail));
-			netdev_info(vsi->netdev, "VSI_seid %d, Issuing force_wb for TX queue %d, Interrupt Reg: 0x%x\n",
-				    vsi->seid, q_idx, val);
-			i40e_force_wb(vsi, tx_ring->q_vector);
-		} else {
-			/* First Chance - detected possible hung */
-			set_bit(I40E_Q_VECTOR_HUNG_DETECT,
-				&tx_ring->q_vector->hung_detected);
-		}
-	}
-
-	/* This is the case where we have interrupts missing,
-	 * so the tx_pending in HW will most likely be 0, but we
-	 * will have tx_pending in SW since the WB happened but the
-	 * interrupt got lost.
-	 */
-	if ((!tx_pending_hw) && i40e_get_tx_pending(tx_ring, true) &&
-	    (!(val & I40E_PFINT_DYN_CTLN_INTENA_MASK))) {
-		local_bh_disable();
-		if (napi_reschedule(&tx_ring->q_vector->napi))
-			tx_ring->tx_stats.tx_lost_interrupt++;
-		local_bh_enable();
-	}
+	if (tx_pending && (!(val & I40E_PFINT_DYN_CTLN_INTENA_MASK)))
+		i40e_force_wb(vsi, tx_ring->q_vector);
 }
 
 /**
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index a9a97dd2c0a5..e95428c7aba0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -711,19 +711,15 @@ void i40e_free_tx_resources(struct i40e_ring *tx_ring)
 /**
  * i40e_get_tx_pending - how many tx descriptors not processed
  * @tx_ring: the ring of descriptors
- * @in_sw: is tx_pending being checked in SW or HW
  *
  * Since there is no access to the ring head register
  * in XL710, we need to use our local copies
  **/
-u32 i40e_get_tx_pending(struct i40e_ring *ring, bool in_sw)
+u32 i40e_get_tx_pending(struct i40e_ring *ring)
 {
 	u32 head, tail;
 
-	if (!in_sw)
-		head = i40e_get_head(ring);
-	else
-		head = ring->next_to_clean;
+	head = i40e_get_head(ring);
 	tail = readl(ring->tail);
 
 	if (head != tail)
@@ -846,7 +842,7 @@ static bool i40e_clean_tx_irq(struct i40e_vsi *vsi,
 		 * them to be written back in case we stay in NAPI.
 		 * In this mode on X722 we do not enable Interrupt.
 		 */
-		unsigned int j = i40e_get_tx_pending(tx_ring, false);
+		unsigned int j = i40e_get_tx_pending(tx_ring);
 
 		if (budget &&
 		    ((j / WB_STRIDE) == 0) && (j > 0) &&
@@ -2126,8 +2122,6 @@ int i40e_napi_poll(struct napi_struct *napi, int budget)
 		return 0;
 	}
 
-	/* Clear hung_detected bit */
-	clear_bit(I40E_Q_VECTOR_HUNG_DETECT, &q_vector->hung_detected);
 	/* Since the actual Tx work is minimal, we can give the Tx a larger
 	 * budget and be more aggressive about cleaning up the Tx descriptors.
 	 */
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.h b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
index d6609deace57..bc66ec4954d9 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.h
@@ -275,7 +275,6 @@ struct i40e_tx_queue_stats {
 	u64 tx_done_old;
 	u64 tx_linearize;
 	u64 tx_force_wb;
-	u64 tx_lost_interrupt;
 };
 
 struct i40e_rx_queue_stats {
@@ -400,7 +399,7 @@ void i40e_free_tx_resources(struct i40e_ring *tx_ring);
 void i40e_free_rx_resources(struct i40e_ring *rx_ring);
 int i40e_napi_poll(struct napi_struct *napi, int budget);
 void i40e_force_wb(struct i40e_vsi *vsi, struct i40e_q_vector *q_vector);
-u32 i40e_get_tx_pending(struct i40e_ring *ring, bool in_sw);
+u32 i40e_get_tx_pending(struct i40e_ring *ring);
 int __i40e_maybe_stop_tx(struct i40e_ring *tx_ring, int size);
 bool __i40e_chk_linearize(struct sk_buff *skb);
 
-- 
2.12.2

^ permalink raw reply related

* [net-next 04/12] i40e: Decrease the scope of rtnl lock
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Maciej Sosin, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Maciej Sosin <maciej.sosin@intel.com>

Previously rtnl lock was held during whole reset procedure that
was stopping other PFs running their reset procedures. In the result
reset was not handled properly and host reset was the only way
to recover.

Change-ID: I23c0771c0303caaa7bd64badbf0c667e25142954
Signed-off-by: Maciej Sosin <maciej.sosin@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e.h         |   2 +-
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c |   6 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c    | 138 +++++++++++++++++--------
 3 files changed, 101 insertions(+), 45 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e.h b/drivers/net/ethernet/intel/i40e/i40e.h
index 421ea57128d3..686327c031fa 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -837,7 +837,7 @@ void i40e_down(struct i40e_vsi *vsi);
 extern const char i40e_driver_name[];
 extern const char i40e_driver_version_str[];
 void i40e_do_reset_safe(struct i40e_pf *pf, u32 reset_flags);
-void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags);
+void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags, bool lock_acquired);
 int i40e_config_rss(struct i40e_vsi *vsi, u8 *seed, u8 *lut, u16 lut_size);
 int i40e_get_rss(struct i40e_vsi *vsi, u8 *seed, u8 *lut, u16 lut_size);
 void i40e_fill_rss_lut(struct i40e_pf *pf, u8 *lut,
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index c0c1a0cdaa5b..68c0f204f93e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -1852,7 +1852,7 @@ static void i40e_diag_test(struct net_device *netdev,
 			 * link then the following link test would have
 			 * to be moved to before the reset
 			 */
-			i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED));
+			i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED), true);
 
 		if (i40e_link_test(netdev, &data[I40E_ETH_TEST_LINK]))
 			eth_test->flags |= ETH_TEST_FL_FAILED;
@@ -1868,7 +1868,7 @@ static void i40e_diag_test(struct net_device *netdev,
 			eth_test->flags |= ETH_TEST_FL_FAILED;
 
 		clear_bit(__I40E_TESTING, &pf->state);
-		i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED));
+		i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED), true);
 
 		if (if_running)
 			i40e_open(netdev);
@@ -4099,7 +4099,7 @@ static int i40e_set_priv_flags(struct net_device *dev, u32 flags)
 	 */
 	if ((changed_flags & I40E_FLAG_VEB_STATS_ENABLED) ||
 	    ((changed_flags & I40E_FLAG_LEGACY_RX) && netif_running(dev)))
-		i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED));
+		i40e_do_reset(pf, BIT(__I40E_PF_RESET_REQUESTED), true);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 1ee2759c38f7..8181647f512e 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -50,13 +50,16 @@ static const char i40e_copyright[] = "Copyright (c) 2013 - 2014 Intel Corporatio
 
 /* a bit of forward declarations */
 static void i40e_vsi_reinit_locked(struct i40e_vsi *vsi);
-static void i40e_handle_reset_warning(struct i40e_pf *pf);
+static void i40e_handle_reset_warning(struct i40e_pf *pf, bool lock_acquired);
 static int i40e_add_vsi(struct i40e_vsi *vsi);
 static int i40e_add_veb(struct i40e_veb *veb, struct i40e_vsi *vsi);
 static int i40e_setup_pf_switch(struct i40e_pf *pf, bool reinit);
 static int i40e_setup_misc_vector(struct i40e_pf *pf);
 static void i40e_determine_queue_usage(struct i40e_pf *pf);
 static int i40e_setup_pf_filter_control(struct i40e_pf *pf);
+static void i40e_prep_for_reset(struct i40e_pf *pf, bool lock_acquired);
+static int i40e_reset(struct i40e_pf *pf);
+static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired);
 static void i40e_fdir_sb_setup(struct i40e_pf *pf);
 static int i40e_veb_get_bw_info(struct i40e_veb *veb);
 
@@ -5537,6 +5540,8 @@ int i40e_open(struct net_device *netdev)
  * Finish initialization of the VSI.
  *
  * Returns 0 on success, negative value on failure
+ *
+ * Note: expects to be called while under rtnl_lock()
  **/
 int i40e_vsi_open(struct i40e_vsi *vsi)
 {
@@ -5600,7 +5605,7 @@ int i40e_vsi_open(struct i40e_vsi *vsi)
 err_setup_tx:
 	i40e_vsi_free_tx_resources(vsi);
 	if (vsi == pf->vsi[pf->lan_vsi])
-		i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED));
+		i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED), true);
 
 	return err;
 }
@@ -5686,12 +5691,14 @@ int i40e_close(struct net_device *netdev)
  * i40e_do_reset - Start a PF or Core Reset sequence
  * @pf: board private structure
  * @reset_flags: which reset is requested
+ * @lock_acquired: indicates whether or not the lock has been acquired
+ * before this function was called.
  *
  * The essential difference in resets is that the PF Reset
  * doesn't clear the packet buffers, doesn't reset the PE
  * firmware, and doesn't bother the other PFs on the chip.
  **/
-void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags)
+void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags, bool lock_acquired)
 {
 	u32 val;
 
@@ -5737,7 +5744,7 @@ void i40e_do_reset(struct i40e_pf *pf, u32 reset_flags)
 		 * for the Core Reset.
 		 */
 		dev_dbg(&pf->pdev->dev, "PFR requested\n");
-		i40e_handle_reset_warning(pf);
+		i40e_handle_reset_warning(pf, lock_acquired);
 
 	} else if (reset_flags & BIT_ULL(__I40E_REINIT_REQUESTED)) {
 		int v;
@@ -5946,7 +5953,7 @@ static int i40e_handle_lldp_event(struct i40e_pf *pf,
 void i40e_do_reset_safe(struct i40e_pf *pf, u32 reset_flags)
 {
 	rtnl_lock();
-	i40e_do_reset(pf, reset_flags);
+	i40e_do_reset(pf, reset_flags, true);
 	rtnl_unlock();
 }
 
@@ -6348,7 +6355,6 @@ static void i40e_reset_subtask(struct i40e_pf *pf)
 {
 	u32 reset_flags = 0;
 
-	rtnl_lock();
 	if (test_bit(__I40E_REINIT_REQUESTED, &pf->state)) {
 		reset_flags |= BIT(__I40E_REINIT_REQUESTED);
 		clear_bit(__I40E_REINIT_REQUESTED, &pf->state);
@@ -6374,18 +6380,19 @@ static void i40e_reset_subtask(struct i40e_pf *pf)
 	 * precedence before starting a new reset sequence.
 	 */
 	if (test_bit(__I40E_RESET_INTR_RECEIVED, &pf->state)) {
-		i40e_handle_reset_warning(pf);
-		goto unlock;
+		i40e_prep_for_reset(pf, false);
+		i40e_reset(pf);
+		i40e_rebuild(pf, false, false);
 	}
 
 	/* If we're already down or resetting, just bail */
 	if (reset_flags &&
 	    !test_bit(__I40E_DOWN, &pf->state) &&
-	    !test_bit(__I40E_CONFIG_BUSY, &pf->state))
-		i40e_do_reset(pf, reset_flags);
-
-unlock:
-	rtnl_unlock();
+	    !test_bit(__I40E_CONFIG_BUSY, &pf->state)) {
+		rtnl_lock();
+		i40e_do_reset(pf, reset_flags, true);
+		rtnl_unlock();
+	}
 }
 
 /**
@@ -6873,10 +6880,12 @@ static void i40e_fdir_teardown(struct i40e_pf *pf)
 /**
  * i40e_prep_for_reset - prep for the core to reset
  * @pf: board private structure
+ * @lock_acquired: indicates whether or not the lock has been acquired
+ * before this function was called.
  *
  * Close up the VFs and other things in prep for PF Reset.
   **/
-static void i40e_prep_for_reset(struct i40e_pf *pf)
+static void i40e_prep_for_reset(struct i40e_pf *pf, bool lock_acquired)
 {
 	struct i40e_hw *hw = &pf->hw;
 	i40e_status ret = 0;
@@ -6891,7 +6900,12 @@ static void i40e_prep_for_reset(struct i40e_pf *pf)
 	dev_dbg(&pf->pdev->dev, "Tearing down internal switch for reset\n");
 
 	/* quiesce the VSIs and their queues that are not already DOWN */
+	/* pf_quiesce_all_vsi modifies netdev structures -rtnl_lock needed */
+	if (!lock_acquired)
+		rtnl_lock();
 	i40e_pf_quiesce_all_vsi(pf);
+	if (!lock_acquired)
+		rtnl_unlock();
 
 	for (v = 0; v < pf->num_alloc_vsi; v++) {
 		if (pf->vsi[v])
@@ -6926,29 +6940,39 @@ static void i40e_send_version(struct i40e_pf *pf)
 }
 
 /**
- * i40e_reset_and_rebuild - reset and rebuild using a saved config
+ * i40e_reset - wait for core reset to finish reset, reset pf if corer not seen
  * @pf: board private structure
- * @reinit: if the Main VSI needs to re-initialized.
  **/
-static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
+static int i40e_reset(struct i40e_pf *pf)
 {
 	struct i40e_hw *hw = &pf->hw;
-	u8 set_fc_aq_fail = 0;
 	i40e_status ret;
-	u32 val;
-	u32 v;
 
-	/* Now we wait for GRST to settle out.
-	 * We don't have to delete the VEBs or VSIs from the hw switch
-	 * because the reset will make them disappear.
-	 */
 	ret = i40e_pf_reset(hw);
 	if (ret) {
 		dev_info(&pf->pdev->dev, "PF reset failed, %d\n", ret);
 		set_bit(__I40E_RESET_FAILED, &pf->state);
-		goto clear_recovery;
+		clear_bit(__I40E_RESET_RECOVERY_PENDING, &pf->state);
+	} else {
+		pf->pfr_count++;
 	}
-	pf->pfr_count++;
+	return ret;
+}
+
+/**
+ * i40e_rebuild - rebuild using a saved config
+ * @pf: board private structure
+ * @reinit: if the Main VSI needs to re-initialized.
+ * @lock_acquired: indicates whether or not the lock has been acquired
+ * before this function was called.
+ **/
+static void i40e_rebuild(struct i40e_pf *pf, bool reinit, bool lock_acquired)
+{
+	struct i40e_hw *hw = &pf->hw;
+	u8 set_fc_aq_fail = 0;
+	i40e_status ret;
+	u32 val;
+	int v;
 
 	if (test_bit(__I40E_DOWN, &pf->state))
 		goto clear_recovery;
@@ -6993,9 +7017,11 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
 	}
 #endif /* CONFIG_I40E_DCB */
 	/* do basic switch setup */
+	if (!lock_acquired)
+		rtnl_lock();
 	ret = i40e_setup_pf_switch(pf, reinit);
 	if (ret)
-		goto end_core_reset;
+		goto end_unlock;
 
 	/* The driver only wants link up/down and module qualification
 	 * reports from firmware.  Note the negative logic.
@@ -7066,7 +7092,7 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
 		if (ret) {
 			dev_info(&pf->pdev->dev,
 				 "rebuild of Main VSI failed: %d\n", ret);
-			goto end_core_reset;
+			goto end_unlock;
 		}
 	}
 
@@ -7117,6 +7143,9 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
 	/* tell the firmware that we're starting */
 	i40e_send_version(pf);
 
+end_unlock:
+if (!lock_acquired)
+	rtnl_unlock();
 end_core_reset:
 	clear_bit(__I40E_RESET_FAILED, &pf->state);
 clear_recovery:
@@ -7124,16 +7153,38 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
 }
 
 /**
+ * i40e_reset_and_rebuild - reset and rebuild using a saved config
+ * @pf: board private structure
+ * @reinit: if the Main VSI needs to re-initialized.
+ * @lock_acquired: indicates whether or not the lock has been acquired
+ * before this function was called.
+ **/
+static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit,
+				   bool lock_acquired)
+{
+	int ret;
+	/* Now we wait for GRST to settle out.
+	 * We don't have to delete the VEBs or VSIs from the hw switch
+	 * because the reset will make them disappear.
+	 */
+	ret = i40e_reset(pf);
+	if (!ret)
+		i40e_rebuild(pf, reinit, lock_acquired);
+}
+
+/**
  * i40e_handle_reset_warning - prep for the PF to reset, reset and rebuild
  * @pf: board private structure
  *
  * Close up the VFs and other things in prep for a Core Reset,
  * then get ready to rebuild the world.
+ * @lock_acquired: indicates whether or not the lock has been acquired
+ * before this function was called.
  **/
-static void i40e_handle_reset_warning(struct i40e_pf *pf)
+static void i40e_handle_reset_warning(struct i40e_pf *pf, bool lock_acquired)
 {
-	i40e_prep_for_reset(pf);
-	i40e_reset_and_rebuild(pf, false);
+	i40e_prep_for_reset(pf, lock_acquired);
+	i40e_reset_and_rebuild(pf, false, lock_acquired);
 }
 
 /**
@@ -8430,6 +8481,7 @@ static int i40e_pf_config_rss(struct i40e_pf *pf)
  *
  * returns 0 if rss is not enabled, if enabled returns the final rss queue
  * count which may be different from the requested queue count.
+ * Note: expects to be called while under rtnl_lock()
  **/
 int i40e_reconfig_rss_queues(struct i40e_pf *pf, int queue_count)
 {
@@ -8445,11 +8497,11 @@ int i40e_reconfig_rss_queues(struct i40e_pf *pf, int queue_count)
 		u16 qcount;
 
 		vsi->req_queue_pairs = queue_count;
-		i40e_prep_for_reset(pf);
+		i40e_prep_for_reset(pf, true);
 
 		pf->alloc_rss_size = new_rss_size;
 
-		i40e_reset_and_rebuild(pf, true);
+		i40e_reset_and_rebuild(pf, true, true);
 
 		/* Discard the user configured hash keys and lut, if less
 		 * queues are enabled.
@@ -8825,6 +8877,7 @@ static void i40e_clear_rss_lut(struct i40e_vsi *vsi)
  * i40e_set_features - set the netdev feature flags
  * @netdev: ptr to the netdev being adjusted
  * @features: the feature set that the stack is suggesting
+ * Note: expects to be called while under rtnl_lock()
  **/
 static int i40e_set_features(struct net_device *netdev,
 			     netdev_features_t features)
@@ -8848,7 +8901,7 @@ static int i40e_set_features(struct net_device *netdev,
 	need_reset = i40e_set_ntuple(pf, features);
 
 	if (need_reset)
-		i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED));
+		i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED), true);
 
 	return 0;
 }
@@ -9043,6 +9096,8 @@ static int i40e_ndo_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
  * is to change the mode then that requires a PF reset to
  * allow rebuild of the components with required hardware
  * bridge mode enabled.
+ *
+ * Note: expects to be called while under rtnl_lock()
  **/
 static int i40e_ndo_bridge_setlink(struct net_device *dev,
 				   struct nlmsghdr *nlh,
@@ -9098,7 +9153,8 @@ static int i40e_ndo_bridge_setlink(struct net_device *dev,
 				pf->flags |= I40E_FLAG_VEB_MODE_ENABLED;
 			else
 				pf->flags &= ~I40E_FLAG_VEB_MODE_ENABLED;
-			i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED));
+			i40e_do_reset(pf, BIT_ULL(__I40E_PF_RESET_REQUESTED),
+				      true);
 			break;
 		}
 	}
@@ -11501,7 +11557,7 @@ static pci_ers_result_t i40e_pci_error_detected(struct pci_dev *pdev,
 	/* shutdown all operations */
 	if (!test_bit(__I40E_SUSPENDED, &pf->state)) {
 		rtnl_lock();
-		i40e_prep_for_reset(pf);
+		i40e_prep_for_reset(pf, true);
 		rtnl_unlock();
 	}
 
@@ -11570,7 +11626,7 @@ static void i40e_pci_error_resume(struct pci_dev *pdev)
 		return;
 
 	rtnl_lock();
-	i40e_handle_reset_warning(pf);
+	i40e_handle_reset_warning(pf, true);
 	rtnl_unlock();
 }
 
@@ -11633,7 +11689,7 @@ static void i40e_shutdown(struct pci_dev *pdev)
 	set_bit(__I40E_SUSPENDED, &pf->state);
 	set_bit(__I40E_DOWN, &pf->state);
 	rtnl_lock();
-	i40e_prep_for_reset(pf);
+	i40e_prep_for_reset(pf, true);
 	rtnl_unlock();
 
 	wr32(hw, I40E_PFPM_APM, (pf->wol_en ? I40E_PFPM_APM_APME_MASK : 0));
@@ -11652,7 +11708,7 @@ static void i40e_shutdown(struct pci_dev *pdev)
 		i40e_enable_mc_magic_wake(pf);
 
 	rtnl_lock();
-	i40e_prep_for_reset(pf);
+	i40e_prep_for_reset(pf, true);
 	rtnl_unlock();
 
 	wr32(hw, I40E_PFPM_APM,
@@ -11686,7 +11742,7 @@ static int i40e_suspend(struct pci_dev *pdev, pm_message_t state)
 		i40e_enable_mc_magic_wake(pf);
 
 	rtnl_lock();
-	i40e_prep_for_reset(pf);
+	i40e_prep_for_reset(pf, true);
 	rtnl_unlock();
 
 	wr32(hw, I40E_PFPM_APM, (pf->wol_en ? I40E_PFPM_APM_APME_MASK : 0));
@@ -11734,7 +11790,7 @@ static int i40e_resume(struct pci_dev *pdev)
 	if (test_and_clear_bit(__I40E_SUSPENDED, &pf->state)) {
 		clear_bit(__I40E_DOWN, &pf->state);
 		rtnl_lock();
-		i40e_reset_and_rebuild(pf, false);
+		i40e_reset_and_rebuild(pf, false, true);
 		rtnl_unlock();
 	}
 
-- 
2.12.2

^ permalink raw reply related

* [net-next 03/12] i40e: Swap use of pf->flags and pf->hw_disabled_flags for ATR Eviction
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
	Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Alexander Duyck <alexander.h.duyck@intel.com>

This is a minor cleanup so that we are always updating pf->flags when we
make a change to the private flags instead of updating a mix of either
pf->flags and/or pf->hw_disabled_flags.

In addition I went through and cleaned out all the spots where we were
using the X722 define in regards to this flag.

Lastly since we changed the logic I went through and flushed out any
redundancy and cleaned up the handling of the flags in the Tx path.

Change-ID: I79ff95a7272bb2533251ff11ef91e89ccb80b610
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_txrx.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index d45f48c84ff7..a9a97dd2c0a5 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2263,8 +2263,7 @@ static void i40e_atr(struct i40e_ring *tx_ring, struct sk_buff *skb,
 	/* Due to lack of space, no more new filters can be programmed */
 	if (th->syn && (pf->hw_disabled_flags & I40E_FLAG_FD_ATR_ENABLED))
 		return;
-	if ((pf->flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE) &&
-	    (!(pf->hw_disabled_flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE))) {
+	if (pf->flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE) {
 		/* HW ATR eviction will take care of removing filters on FIN
 		 * and RST packets.
 		 */
@@ -2326,8 +2325,7 @@ static void i40e_atr(struct i40e_ring *tx_ring, struct sk_buff *skb,
 			I40E_TXD_FLTR_QW1_CNTINDEX_SHIFT) &
 			I40E_TXD_FLTR_QW1_CNTINDEX_MASK;
 
-	if ((pf->flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE) &&
-	    (!(pf->hw_disabled_flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE)))
+	if (pf->flags & I40E_FLAG_HW_ATR_EVICT_CAPABLE)
 		dtype_cmd |= I40E_TXD_FLTR_QW1_ATR_MASK;
 
 	fdir_desc->qindex_flex_ptype_vsi = cpu_to_le32(flex_ptype);
-- 
2.12.2

^ permalink raw reply related

* [net-next 01/12] i40e: only register client on iWarp-capable devices
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Mitch Williams, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Mitch Williams <mitch.a.williams@intel.com>

The client interface is only intended for use on devices that support
iWarp. Only register with the client if this is the case.

This fixes a panic when loading i40iw on X710 devices.

Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Reported-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_main.c | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index d83430faaa41..1ee2759c38f7 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -11245,10 +11245,12 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 		  round_jiffies(jiffies + pf->service_timer_period));
 
 	/* add this PF to client device list and launch a client service task */
-	err = i40e_lan_add_device(pf);
-	if (err)
-		dev_info(&pdev->dev, "Failed to add PF to client API service list: %d\n",
-			 err);
+	if (pf->flags & I40E_FLAG_IWARP_ENABLED) {
+		err = i40e_lan_add_device(pf);
+		if (err)
+			dev_info(&pdev->dev, "Failed to add PF to client API service list: %d\n",
+				 err);
+	}
 
 #define PCI_SPEED_SIZE 8
 #define PCI_WIDTH_SIZE 8
@@ -11426,10 +11428,11 @@ static void i40e_remove(struct pci_dev *pdev)
 		i40e_vsi_release(pf->vsi[pf->lan_vsi]);
 
 	/* remove attached clients */
-	ret_code = i40e_lan_del_device(pf);
-	if (ret_code) {
-		dev_warn(&pdev->dev, "Failed to delete client device: %d\n",
-			 ret_code);
+	if (pf->flags & I40E_FLAG_IWARP_ENABLED) {
+		ret_code = i40e_lan_del_device(pf);
+		if (ret_code)
+			dev_warn(&pdev->dev, "Failed to delete client device: %d\n",
+				 ret_code);
 	}
 
 	/* shutdown and destroy the HMC */
-- 
2.12.2

^ permalink raw reply related

* [net-next 02/12] i40e: update error message when trying to add invalid filters
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Jacob Keller, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170408095553.78307-1-jeffrey.t.kirsher@intel.com>

From: Jacob Keller <jacob.e.keller@intel.com>

Re-word the error message displayed when adding a filter with an
invalid flow type. Additionally, report a distinct error message when
the IPv4 protocol is at fault.

Change-ID: Iba3d85b87f8d383c97c8bdd180df34a6adf3ee67
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_txrx.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index ebffca0cefac..d45f48c84ff7 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -533,14 +533,15 @@ int i40e_add_del_fdir(struct i40e_vsi *vsi,
 			break;
 		default:
 			/* We cannot support masking based on protocol */
-			goto unsupported_flow;
+			dev_info(&pf->pdev->dev, "Unsupported IPv4 protocol 0x%02x\n",
+				 input->ip4_proto);
+			return -EINVAL;
 		}
 		break;
 	default:
-unsupported_flow:
-		dev_info(&pf->pdev->dev, "Could not specify spec type %d\n",
+		dev_info(&pf->pdev->dev, "Unsupported flow type 0x%02x\n",
 			 input->flow_type);
-		ret = -EINVAL;
+		return -EINVAL;
 	}
 
 	/* The buffer allocated here will be normally be freed by
-- 
2.12.2

^ permalink raw reply related

* [net-next 00/12][pull request] 40GbE Intel Wired LAN Driver Updates 2017-04-08
From: Jeff Kirsher @ 2017-04-08  9:55 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene

This series contains updates to i40e and i40evf only.

Mitch fixes an issue where the client driver (i40iw) was attempting to
load on x710 devices (which do not support iWARP), so only register with
the client if iWARP is supported.

Jake fixes up error messages to better clarify to the user when adding a
invalid flow type.  Updates the driver to look up the MAC address from
eth_get_platform_mac_address() first before checking what the firmware
provides.  Cleans up code so we are not repeating a duplicate loop, by
checking both transmit and receive queues in a single loop.  Also cleans
up flags never used, so remove the definitions.

Alex does cleanup so that we are always updating pf->flags when a change
is made to the private flags.  Adds support for 3K buffers to the receive
path so that we can provide the additional padding needed in the event
of NET_IP_ALIGN being non-zero or a cache line being greater than 64.
Adds support for build_skb() to i40e/i40evf.

Maciej adjusts the scope of the rtnl lock held during reset because it
was stopping other PFs from running their reset procedures.

Alan reduces code complexity in i40e_detect_recover_hung_queue().

The following are changes since commit 3a9024f52c2e92a143195db43d2abbd5d0792c06:
  net: thunderx: Enable TSO and checksum offloads for ipv6
and are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 40GbE

Alan Brady (1):
  i40e: Simplify i40e_detect_recover_hung_queue logic

Alexander Duyck (4):
  i40e: Swap use of pf->flags and pf->hw_disabled_flags for ATR Eviction
  i40e/i40evf: Add support for using order 1 pages with a 3K buffer
  i40e/i40evf: Add support for padding start of frames
  i40e/i40evf: Use build_skb to build frames

Alice Michael (1):
  i40e: remove I40E_FLAG_NEED_LINK_UPDATE

Jacob Keller (4):
  i40e: update error message when trying to add invalid filters
  i40e: allow look-up of MAC address from Open Firmware or IDPROM
  i40e: remove extraneous loop in i40e_vsi_wait_queues_disabled
  i40e: clean up historic deprecated flag definitions

Maciej Sosin (1):
  i40e: Decrease the scope of rtnl lock

Mitch Williams (1):
  i40e: only register client on iWarp-capable devices

 drivers/net/ethernet/intel/i40e/i40e.h          |  10 +-
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c  |   7 +-
 drivers/net/ethernet/intel/i40e/i40e_main.c     | 268 +++++++++++++-----------
 drivers/net/ethernet/intel/i40e/i40e_txrx.c     | 116 +++++++---
 drivers/net/ethernet/intel/i40e/i40e_txrx.h     |  85 +++++++-
 drivers/net/ethernet/intel/i40evf/i40e_txrx.c   |  89 ++++++--
 drivers/net/ethernet/intel/i40evf/i40e_txrx.h   |  82 +++++++-
 drivers/net/ethernet/intel/i40evf/i40evf.h      |   1 -
 drivers/net/ethernet/intel/i40evf/i40evf_main.c |  14 +-
 9 files changed, 486 insertions(+), 186 deletions(-)

-- 
2.12.2

^ permalink raw reply

* Re: [Qemu-devel] [PATCH 08/10] blockjob: introduce block_job_cancel_async
From: Paolo Bonzini @ 2017-04-08  9:54 UTC (permalink / raw)
  To: John Snow, qemu-devel; +Cc: jcody, Kashyap Chamarthy
In-Reply-To: <2f6e20ff-41e8-a931-7a86-abcfcc70d20f@redhat.com>



On 08/04/2017 09:13, John Snow wrote:
> 
> 
> On 03/23/2017 01:39 PM, Paolo Bonzini wrote:
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> 
> What was the bad design that required you to fix the previous test? :)

It was actually patch 9 that had the bug, I'll reorder to match the
commit message.

Paolo

>> ---
>>  blockjob.c | 11 ++++++++---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/blockjob.c b/blockjob.c
>> index c9cb5b1..093962b 100644
>> --- a/blockjob.c
>> +++ b/blockjob.c
>> @@ -373,6 +373,12 @@ static void block_job_completed_single(BlockJob *job)
>>      block_job_unref(job);
>>  }
>>  
>> +static void block_job_cancel_async(BlockJob *job)
>> +{
>> +    job->cancelled = true;
>> +    block_job_iostatus_reset(job);
>> +}
>> +
>>  static void block_job_completed_txn_abort(BlockJob *job)
>>  {
>>      AioContext *ctx;
>> @@ -397,7 +403,7 @@ static void block_job_completed_txn_abort(BlockJob *job)
>>               * them; this job, however, may or may not be cancelled, depending
>>               * on the caller, so leave it. */
>>              if (other_job != job) {
>> -                other_job->cancelled = true;
>> +                block_job_cancel_async(other_job);
> 
> Adds an ioreset here, which I think is probably fine...
> 
>>              }
>>              continue;
>>          }
>> @@ -489,8 +495,7 @@ void block_job_user_resume(BlockJob *job)
>>  void block_job_cancel(BlockJob *job)
>>  {
>>      if (block_job_started(job)) {
>> -        job->cancelled = true;
>> -        block_job_iostatus_reset(job);
>> +        block_job_cancel_async(job);
>>          block_job_enter(job);
>>      } else {
>>          block_job_completed(job, -ECANCELED);
>>
> 
> Reviewed-by: John Snow <jsnow@redhat.com>
> 

^ permalink raw reply

* Re: brcmfmac: don't warn user if requested nvram fails
From: Hans de Goede @ 2017-04-08  9:53 UTC (permalink / raw)
  To: Arend Van Spriel, Luis R. Rodriguez
  Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <577dc508-07ff-c74f-5c90-b6baf4e7694a@broadcom.com>

Hi,

On 07-04-17 23:43, Arend Van Spriel wrote:
>
>
> On 6-4-2017 14:14, Hans de Goede wrote:
>> Hi,
>>
>> I noticed your patch-series on the lwn.net kernel page,
>> and I took a peek :)
>>
>> I don't think that this patch:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/commit/?h=20170329-driver-data-v2-try3&id=3968dd3031d1ff7e7be4acfb810948c70c2d4490
>>
>>
>> Is a good idea, specifically the "do not warn" part,
>> although the brcmfmac driver will indeed try to continue
>> without a nvram file, in my experience it almost all
>> the time will not work properly without the nvram file.
>
> Actually, brcmfmac will only continue without nvram for PCIe devices.
> For SDIO it is a different story, which may be the kind of devices you
> have experienced.

Ah, no I've experience with both now, and the device I've
with a PCIE which needs nvram:

http://www.gpd.hk/gpdwin.asp

Will not work without the nvram file, so I really think
we should at least keep a warning msg here.

>> Arend, should we maybe just make the missing nvram file
>> a fatal error ?
>>
>> ###
>>
>> While on the subject of nvram file loading, I want to make
>> some changes to how brcmfmac does this, for pcie
>> devices I want it to first try:
>>
>> brcmfmac-4xxx-sdio-<pci-subsys-vid>-<pci-subsys-pid>.txt
>> and only if that is not present fallback to
>> brcmfmac-4xxx-sdio.txt, so that we can include the
>> brcmfmac-4xxx-sdio-<pci-subsys-vid>-<pci-subsys-pid>.txt
>> in the linux-firmware repo and have things just work.
>
> You got me confused. I suppose the -sdio- should not be in the filename
> examples above.

Right, sorry. For the pcie device I'm looking at the
name is brcmfmac4356-pcie.txt and I would like to propose
to first check for "brcmfmac4356-<pci-subsys-vid>-<pci-subsys-pid>.txt"

> So who is going to provide these nvram files. We can not
> maintain that as there are too many variants and they are under control
> of the OEM/ODM.

Users / people like me who are interested in using certain
devices with Linux. The idea is to at least make it possible to
have these devices just work. E.g. I would like a user to be
able to insert a USB-stick with a live Fedora 27 and then
have everything just work on the GPD win.

To make this happen I will submit the nvram file from the
Windows install on the GPDwin to linux-firmware as
"brcmfmac4356-<pci-subsys-vid>-<pci-subsys-pid>.txt"
and yes I've checked that there are sensible values in
the subsys ids.

So would you be willing to accept a brcmfmac patch
trying such a post-fixed nvram filename first ?

>> Likewise for sdio devices on devicetree platforms
>> first try brcmfmac-4xxx-sdio-<model>.txt.
>>
>> And for sdio devices on ACPI/x86 systems I want to
>> do something similar too.
>>
>> Luis, do you think it would be a good idea to add
>> .optional_postfix member to driver_data_req_params
>> for this? I believe other sdio based wifi devices
>> may want to do the same, or should this be handled
>> in the driver by doing 2 driver_data_request_async
>> calls (the 2nd when the 1st fails) ?
>
> I think we briefly touched this subject a while ago.

Correct back then I wanted to achieve the same goals
(and I still do) for some ARM boards. What I'm striving
for here is "it just works" user experience when
people use a new enough distro which has all the
bits in place.

 > It would be great
> if the driver_data api could be given a list/array of files which can be
> flagged as required or optional. Just not sure how to deal with drivers
> that request a firmware file and fallback to requesting older ones
> repeatedly thus stop processing upon first successful load. Both
> use-cases seem present in drivers.

Regards,

Hans

^ permalink raw reply

* Re: [Qemu-devel] [PATCH 05/10] blockjob: separate monitor and blockjob APIs
From: Paolo Bonzini @ 2017-04-08  9:52 UTC (permalink / raw)
  To: John Snow, qemu-devel; +Cc: jcody
In-Reply-To: <48253fa9-d5eb-f750-6dfc-e478bfd85277@redhat.com>



On 08/04/2017 08:03, John Snow wrote:
> Looks clean, though it may be useful to do a few more things;
> 
> - Demarcate what you think is the monitor API in this file

It's already there:

+/*
+ * API for block job drivers and the block layer.
+ */
+

where everything before is for the monitor.

> - Organize blockjob.h to match to serve as a useful reference.

Hmm, yes.

Paolo

^ permalink raw reply

* Re: [Qemu-devel] [PATCH 1/4] pam:refactor PAM related code
From: Paolo Bonzini @ 2017-04-08  9:49 UTC (permalink / raw)
  To: Anthony Xu, qemu-devel
In-Reply-To: <1491612336-31066-2-git-send-email-anthony.xu@intel.com>



On 08/04/2017 08:45, Anthony Xu wrote:
> split PAM SMRAM functions in piix.c
> create mch_init_pam in q35.c

Could you further move

    MemoryRegion *ram_memory;
    MemoryRegion *system_memory;
    MemoryRegion *pci_address_space;
    PAMMemoryRegion pam_regions[13];

from the northbridge devices up to PCMachineState, and move the common
code for PIIX and Q35 to hw/pci-host/pam.c?

It looks like you can define a better API than what pam.c currently
provides:

void pc_init_pam(PCMachineState *pc_machine, DeviceState *d);
void pc_update_pam(PCMachineState *pc_machine, uint8_t *pam_config);

or even remove "DeviceState *d" because the owner of the memory regions
can be the PCMachineState.

Thanks,

Paolo

> Signed-off-by: Anthony Xu <anthony.xu@intel.com>
> ---
>  hw/pci-host/piix.c | 58 ++++++++++++++++++++++++++++++++++++++----------------
>  hw/pci-host/q35.c  | 23 +++++++++++++---------
>  2 files changed, 55 insertions(+), 26 deletions(-)
> 
> diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
> index f9218aa..ff4e8b5 100644
> --- a/hw/pci-host/piix.c
> +++ b/hw/pci-host/piix.c
> @@ -138,16 +138,11 @@ static int pci_slot_get_pirq(PCIDevice *pci_dev, int pci_intx)
>      return (pci_intx + slot_addend) & 3;
>  }
>  
> -static void i440fx_update_memory_mappings(PCII440FXState *d)
> +static void i440fx_update_smram(PCII440FXState *d)
>  {
> -    int i;
>      PCIDevice *pd = PCI_DEVICE(d);
>  
>      memory_region_transaction_begin();
> -    for (i = 0; i < 13; i++) {
> -        pam_update(&d->pam_regions[i], i,
> -                   pd->config[I440FX_PAM + ((i + 1) / 2)]);
> -    }
>      memory_region_set_enabled(&d->smram_region,
>                                !(pd->config[I440FX_SMRAM] & SMRAM_D_OPEN));
>      memory_region_set_enabled(&d->smram,
> @@ -155,6 +150,39 @@ static void i440fx_update_memory_mappings(PCII440FXState *d)
>      memory_region_transaction_commit();
>  }
>  
> +static void i440fx_update_pam(PCII440FXState *d)
> +{
> +    int i;
> +    PCIDevice *pd = PCI_DEVICE(d);
> +    memory_region_transaction_begin();
> +    pam_update(&d->pam_regions[0], 0,
> +               pd->config[I440FX_PAM]);
> +    for (i = 1; i < 13; i++) {
> +        pam_update(&d->pam_regions[i], i,
> +                   pd->config[I440FX_PAM + ((i + 1) / 2)]);
> +    }
> +    memory_region_transaction_commit();
> +}
> +
> +static void i440fx_update_memory_mappings(PCII440FXState *d)
> +{
> +    i440fx_update_pam(d);
> +    i440fx_update_smram(d);
> +}
> +
> +
> +static void i440fx_init_pam(PCII440FXState *d)
> +{
> +    int i;
> +    init_pam(DEVICE(d), d->ram_memory, d->system_memory,
> +             d->pci_address_space, &d->pam_regions[0],
> +             PAM_BIOS_BASE,  PAM_BIOS_SIZE);
> +    for (i = 0; i < 12; ++i) {
> +        init_pam(DEVICE(d), d->ram_memory, d->system_memory,
> +                 d->pci_address_space, &d->pam_regions[i + 1],
> +                 PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
> +    }
> +}
>  
>  static void i440fx_write_config(PCIDevice *dev,
>                                  uint32_t address, uint32_t val, int len)
> @@ -163,9 +191,12 @@ static void i440fx_write_config(PCIDevice *dev,
>  
>      /* XXX: implement SMRAM.D_LOCK */
>      pci_default_write_config(dev, address, val, len);
> -    if (ranges_overlap(address, len, I440FX_PAM, I440FX_PAM_SIZE) ||
> -        range_covers_byte(address, len, I440FX_SMRAM)) {
> -        i440fx_update_memory_mappings(d);
> +    if (ranges_overlap(address, len, I440FX_PAM, I440FX_PAM_SIZE)) {
> +        i440fx_update_pam(d);
> +    }
> +
> +    if (range_covers_byte(address, len, I440FX_SMRAM)) {
> +        i440fx_update_smram(d);
>      }
>  }
>  
> @@ -335,7 +366,6 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,
>      PCIHostState *s;
>      PIIX3State *piix3;
>      PCII440FXState *f;
> -    unsigned i;
>      I440FXState *i440fx;
>  
>      dev = qdev_create(NULL, host_type);
> @@ -378,13 +408,7 @@ PCIBus *i440fx_init(const char *host_type, const char *pci_type,
>      object_property_add_const_link(qdev_get_machine(), "smram",
>                                     OBJECT(&f->smram), &error_abort);
>  
> -    init_pam(dev, f->ram_memory, f->system_memory, f->pci_address_space,
> -             &f->pam_regions[0], PAM_BIOS_BASE, PAM_BIOS_SIZE);
> -    for (i = 0; i < 12; ++i) {
> -        init_pam(dev, f->ram_memory, f->system_memory, f->pci_address_space,
> -                 &f->pam_regions[i+1], PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE,
> -                 PAM_EXPAN_SIZE);
> -    }
> +    i440fx_init_pam(f);
>  
>      /* Xen supports additional interrupt routes from the PCI devices to
>       * the IOAPIC: the four pins of each PCI device on the bus are also
> diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
> index 344f77b..8866357 100644
> --- a/hw/pci-host/q35.c
> +++ b/hw/pci-host/q35.c
> @@ -460,9 +460,21 @@ static void mch_reset(DeviceState *qdev)
>      mch_update(mch);
>  }
>  
> -static void mch_realize(PCIDevice *d, Error **errp)
> +static void mch_init_pam(MCHPCIState *mch)
>  {
>      int i;
> +    init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
> +             mch->pci_address_space, &mch->pam_regions[0],
> +             PAM_BIOS_BASE, PAM_BIOS_SIZE);
> +    for (i = 0; i < 12; ++i) {
> +        init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
> +                 mch->pci_address_space, &mch->pam_regions[i + 1],
> +                 PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
> +    }
> +}
> +
> +static void mch_realize(PCIDevice *d, Error **errp)
> +{
>      MCHPCIState *mch = MCH_PCI_DEVICE(d);
>  
>      /* setup pci memory mapping */
> @@ -510,14 +522,7 @@ static void mch_realize(PCIDevice *d, Error **errp)
>      object_property_add_const_link(qdev_get_machine(), "smram",
>                                     OBJECT(&mch->smram), &error_abort);
>  
> -    init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
> -             mch->pci_address_space, &mch->pam_regions[0],
> -             PAM_BIOS_BASE, PAM_BIOS_SIZE);
> -    for (i = 0; i < 12; ++i) {
> -        init_pam(DEVICE(mch), mch->ram_memory, mch->system_memory,
> -                 mch->pci_address_space, &mch->pam_regions[i+1],
> -                 PAM_EXPAN_BASE + i * PAM_EXPAN_SIZE, PAM_EXPAN_SIZE);
> -    }
> +    mch_init_pam(mch);
>  }
>  
>  uint64_t mch_mcfg_base(void)
> 

^ permalink raw reply

* Re: [Qemu-devel] [PATCH 4/4] pam: setup pc.bios
From: Paolo Bonzini @ 2017-04-08  9:49 UTC (permalink / raw)
  To: Anthony Xu, qemu-devel
In-Reply-To: <1491612336-31066-5-git-send-email-anthony.xu@intel.com>



On 08/04/2017 08:45, Anthony Xu wrote:
> -    if (!isapc_ram_fw) {
> -        memory_region_set_readonly(bios, true);
> +    if (PC_MACHINE(current_machine)->pam) {
> +        /* if PAM is disabled, set it as readwrite */
> +        if (!isapc_ram_fw) {
> +            memory_region_set_readonly(bios, true);
> +        }
>      }

I think this is wrong, the high copy should remain read-only or pflash
stops working when you remove PAM.

The comment only explains the "what" but not the "why" and the "why" is
not in the commit message.  See also here:

> +    if (PC_MACHINE(current_machine)->pam) {
> +        memory_region_add_subregion_overlap(rom_memory,
> +                                        0x100000 - isa_bios_size,
> +                                        isa_bios,
> +                                        1);
> +        if (!isapc_ram_fw) {
> +            memory_region_set_readonly(isa_bios, true);
> +        }
> +    } else {
> +        /* if PAM is disabed, add isa-bios to system memory region */
> +        memory_region_add_subregion_overlap(system_memory,
>                                          0x100000 - isa_bios_size,
>                                          isa_bios,
>                                          1);

Thanks,

Paolo

^ permalink raw reply

* Re: [PATCH v7 3/3] read-cache: speed up add_index_entry during checkout
From: Jeff King @ 2017-04-08  9:40 UTC (permalink / raw)
  To: git; +Cc: git, gitster, Jeff Hostetler
In-Reply-To: <20170407212047.64950-4-git@jeffhostetler.com>

On Fri, Apr 07, 2017 at 09:20:47PM +0000, git@jeffhostetler.com wrote:

> This helps performance on very large repositories.
> 
> ================
> Before and after numbers on index with 1M files
> ./p0004-read-tree.sh
> 0004.2: read-tree work1 (1003037)          3.21(2.54+0.62)
> 0004.3: switch base work1 (3038 1003037)   7.49(5.39+1.84)
> 0004.5: switch work1 work2 (1003037)       11.91(8.38+3.00)
> 0004.6: switch commit aliases (1003037)    12.22(8.30+3.06)
> 
> ./p0004-read-tree.sh
> 0004.2: read-tree work1 (1003040)          2.40(1.65+0.73)
> 0004.3: switch base work1 (3041 1003040)   6.07(4.12+1.66)
> 0004.5: switch work1 work2 (1003040)       10.23(6.76+2.92)
> 0004.6: switch commit aliases (1003040)    10.53(6.97+2.83)
> ================

By the way, you may want to try:

  $ cd t/perf
  $ ./run HEAD^ HEAD p0004-read-tree.sh

which gives you the before/after in a nice table, with percentage
changes:

  Test                                       HEAD^             HEAD                  
  -----------------------------------------------------------------------------------
  0004.2: read-tree work1 (1003065)          2.34(1.90+0.42)   1.91(1.51+0.38) -18.4%
  0004.3: switch base work1 (3066 1003065)   5.12(4.14+0.96)   4.45(3.55+0.88) -13.1%
  0004.5: switch work1 work2 (1003065)       8.55(6.63+1.87)   7.78(5.76+2.00) -9.0% 
  0004.6: switch commit aliases (1003065)    8.59(6.75+1.80)   7.64(5.92+1.70) -11.1%

The results are stored for each tested version, so you can re-run just a
single test and then re-output the results with "./aggregate.perl HEAD^
HEAD p0004-read-tree.sh".

The "run" script obviously builds each version behind the scenes, so you
probably also want to set GIT_PERF_MAKE_OPTS as appropriate (at the very
least "-j16" makes it more pleasant).

-Peff

^ permalink raw reply

* [OpenRISC] [PATCH v5 2/4] gdb: provide openrisc target description XML files.
From: Stafford Horne @ 2017-04-08  9:38 UTC (permalink / raw)
  To: openrisc
In-Reply-To: <86mvbv6f1c.fsf@gmail.com>

On Tue, Apr 04, 2017 at 10:25:51PM +0100, Yao Qi wrote:
> Stafford Horne <shorne@gmail.com> writes:
> 
> > diff --git a/gdb/features/or1k.xml b/gdb/features/or1k.xml
> > new file mode 100644
> > index 0000000..688b340
> > --- /dev/null
> > +++ b/gdb/features/or1k.xml
> > @@ -0,0 +1,2274 @@
> > +<?xml version="1.0"?>
> > +<!-- Copyright (C) 2016 Free Software Foundation, Inc.
> > +
> > +     Copying and distribution of this file, with or without modification,
> > +     are permitted in any medium without royalty provided the copyright
> > +     notice and this notice are preserved.  -->
> > +
> > +<!DOCTYPE target SYSTEM "gdb-target.dtd">
> > +<target>
> > +  <architecture>or1k</architecture>
> > +  <feature name="org.gnu.gdb.or1k.group0">
> 
> 11 features are defined, but your patch 1/4 only checks feature group0.
> Does it indicate that only group0 is a required feature?  If so, we need
> to document it here,
> https://sourceware.org/gdb/current/onlinedocs/gdb/Standard-Target-Features.html
> 
> Of course, the debugging stub,like OpenOCD, can provide more features
> than GDB required.  In GDB, we need only to define required features.

I have removed these 11 features and just left the 1.  I think its
better that the targets provide all the extras.

Also, I documented it.  I will send the patches.

> -- 
> Yao (齐尧)

^ permalink raw reply

* [OpenRISC] [PATCH v5 1/4] gdb: Add OpenRISC or1k and or1knd target support
From: Stafford Horne @ 2017-04-08  9:36 UTC (permalink / raw)
  To: openrisc
In-Reply-To: <86wpaz6ffa.fsf@gmail.com>

Hi Yao,

Thanks for reviewing, I had a few of these fixed already, but I havent
had time to send a new series.  I hope I can get around to it and these
in a week or so.

On Tue, Apr 04, 2017 at 10:17:29PM +0100, Yao Qi wrote:
> Stafford Horne <shorne@gmail.com> writes:
> 
> Hi Stafford,
> Have some cycles today, so I can review the patch.
> 
> > +/* The target-dependent structure for gdbarch.  */
> > +
> > +struct gdbarch_tdep
> > +{
> > +  int bytes_per_word;
> > +  int bytes_per_address;
> 
> Don't need these two fields, we can get bfd_arch_info via
> gdbarch_bfd_arch_info (gdbarch), and access its fields to compute
> bytes_per_word and bytes_per_address.

These are computed that way in or1k_gdbarch_init():

  tdep->bytes_per_word = binfo->bits_per_word / binfo->bits_per_byte;
  tdep->bytes_per_address = binfo->bits_per_address / binfo->bits_per_byte;

The idea is that these are used a few times to its better for
readability to not have to compute every time.

I would prefer to keep.

> > +  CGEN_CPU_DESC gdb_cgen_cpu_desc;
> > +};
> > +
> > +/* Support functions for the architecture definition.  */
> > +
> > +/* Get an instruction from memory.  */
> > +
> > +static ULONGEST
> > +or1k_fetch_instruction (struct gdbarch *gdbarch, CORE_ADDR addr)
> > +{
> > +  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > +  gdb_byte buf[OR1K_INSTLEN];
> > +
> > +  if (target_read_memory (addr, buf, OR1K_INSTLEN)) {
> 
> target_read_code, it uses cache, and helps on performance.

OK, thanks

> > +    memory_error (TARGET_XFER_E_IO, addr);
> > +  }
> > +
> > +  return extract_unsigned_integer (buf, OR1K_INSTLEN, byte_order);
> > +}
> > +
> 
> > +
> > +	  /* Check we got something, and if so skip on.  */
> > +	  if (start_ptr == end_ptr)
> > +	    throw_quit ("bitstring \"%s\" at offset %d has no length field.\n",
> > +			format, i);
> 
> s/throw_quit/error/
> multiple instances of this.

OK

> > +/* Analyze a l.addi instruction in form: l.addi  rD,rA,I.  This is used
> > +   to parse add instructions during various prologue analysis routines.  */
> > +
> 
> Document the argument and return value.

OK

> > +static int
> 
> static bool

OK, I guess more instances of this

> > +or1k_analyse_l_addi (uint32_t inst, unsigned int *rd_ptr,
> > +		     unsigned int *ra_ptr, int *simm_ptr)
> > +{
> > +  /* Instruction fields */
> > +  uint32_t rd, ra, i;
> > +
> > +  if (or1k_analyse_inst (inst, "10 0111 %5b %5b %16b", &rd, &ra, &i))
> > +    {
> > +      /* Found it.  Construct the result fields.  */
> > +      *rd_ptr = (unsigned int) rd;
> > +      *ra_ptr = (unsigned int) ra;
> > +      *simm_ptr = (int) (((i & 0x8000) == 0x8000) ? 0xffff0000 | i : i);
> > +
> > +      return 1; /* Success */
> > +    }
> > +  else
> > +    return 0; /* Failure */
> > +}
> > +
> 
> > +/* Functions defining the architecture.  */
> 
> What is this?

Its just a code section comment. i.e. the previous section was

 /* Support functions for the architecture definition.  */

I would prefer to keep.

> > +
> > +/* Implement the return_value gdbarch method.  */
> > +
> > +static enum return_value_convention
> > +or1k_return_value (struct gdbarch *gdbarch, struct value *functype,
> > +		   struct type *valtype, struct regcache *regcache,
> > +		   gdb_byte *readbuf, const gdb_byte *writebuf)
> > +{
> > +  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > +  enum type_code rv_type = TYPE_CODE (valtype);
> > +  unsigned int rv_size = TYPE_LENGTH (valtype);
> > +  int bpw = (gdbarch_tdep (gdbarch))->bytes_per_word;
> > +
> > +  /* Deal with struct/union as addresses.  If an array won't fit in a single
> > +     register it is returned as address.  Anything larger than 2 registers needs
> > +     to also be passed as address (matches gcc default_return_in_memory).  */
> > +  if ((TYPE_CODE_STRUCT == rv_type) || (TYPE_CODE_UNION == rv_type)
> > +      || ((TYPE_CODE_ARRAY == rv_type) && (rv_size > bpw))
> > +      || (rv_size > 2 * bpw))
> 
> If I read the comment and code correctly, register size is
> "bytes_per_word", and bytes_per_address is added in gdbarch_tdep.  Does
> this imply that register size may be different (in bytes) on different
> processors?

It currently will be 4 for 32-bit and the spec doesnt define return
values for 64-bit architectures, but this code does seem to assume that
64-bit architectures would follow the same convention.

> > +    {
> > +      if (readbuf != NULL)
> > +	{
> > +	  ULONGEST tmp;
> > +
> > +	  regcache_cooked_read_unsigned (regcache, OR1K_RV_REGNUM, &tmp);
> > +	  read_memory (tmp, readbuf, rv_size);
> > +	}
> > +      if (writebuf != NULL)
> > +	{
> > +	  ULONGEST tmp;
> > +
> > +	  regcache_cooked_read_unsigned (regcache, OR1K_RV_REGNUM, &tmp);
> > +	  write_memory (tmp, writebuf, rv_size);
> > +	}
> > +
> > +      return RETURN_VALUE_ABI_RETURNS_ADDRESS;
> > +    }
> > +
> > +  if (rv_size <= bpw)
> > +    {
> > +      /* Up to one word scalars are returned in R11.  */
> > +      if (readbuf != NULL)
> > +	{
> > +	  ULONGEST tmp;
> > +
> > +	  regcache_cooked_read_unsigned (regcache, OR1K_RV_REGNUM, &tmp);
> > +	  store_unsigned_integer (readbuf, rv_size, byte_order, tmp);
> > +
> > +	}
> > +      if (writebuf != NULL)
> > +	{
> > +	  gdb_byte buf[4];
> 
> Overflow if bpw is greater than 4?

Good catch, I think we can calloc(1, bpw) and free().

> > +	  memset (buf, 0, sizeof (buf)); /* Zero pad if < bpw bytes.  */
> > +
> > +	  if (BFD_ENDIAN_BIG == byte_order)
> > +	    memcpy (buf + sizeof (buf) - rv_size, writebuf, rv_size);
> > +	  else
> > +	    memcpy (buf, writebuf, rv_size);
> > +
> > +	  regcache_cooked_write (regcache, OR1K_RV_REGNUM, buf);
> > +	}
> > +    }
> > +  else
> > +    {
> > +      /* 2 word scalars are returned in r11/r12 (with the MS word in r11).  */
> 
> 
> > +
> > +/* OR1K always uses a l.trap instruction for breakpoints.  */
> > +
> > +constexpr gdb_byte or1k_break_insn[] = {0x21, 0x00, 0x00, 0x01};
> > +
> > +typedef BP_MANIPULATION (or1k_break_insn) or1k_breakpoint;
> > +
> > +/* Implement the single_step_through_delay gdbarch method.  */
> > +
> > +static int
> > +or1k_single_step_through_delay (struct gdbarch *gdbarch,
> > +				struct frame_info *this_frame)
> > +{
> > +  ULONGEST val;
> > +  CORE_ADDR ppc;
> > +  CORE_ADDR npc;
> > +  CGEN_FIELDS tmp_fields;
> > +  const CGEN_INSN *insn;
> > +  struct regcache *regcache = get_current_regcache ();
> > +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> > +
> > +  /* Get and the previous and current instruction addresses.  If they are not
> 
> This line is too long.

OK

> > +
> > +/* Name for or1k general registers.  */
> > +
> > +static const char *const or1k_reg_names[OR1K_NUM_REGS] = {
> > +  /* general purpose registers */
> > +  "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
> > +  "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
> > +  "r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
> > +  "r24", "r25", "r26", "r27", "r28", "r29", "r30", "r31",
> > +
> > +  /* previous program counter, next program counter and status register */
> > +  "ppc", "npc", "sr"
> > +};
> > +
> > +/* Implement the register_name gdbarch method.  */
> > +
> > +static const char *
> > +or1k_register_name (struct gdbarch *gdbarch, int regnum)
> > +{
> > +  if (0 <= regnum && regnum < OR1K_NUM_REGS)
> > +    return or1k_reg_names[regnum];
> > +  else
> > +    return NULL;
> > +}
> > +
> 
> Register names can be from target description, so we don't need this
> function.

Right, now that I have added target-desc it not needed.

> > +/* Implement the register_type gdbarch method.  */
> > +
> > +static struct type *
> > +or1k_register_type (struct gdbarch *gdbarch, int regnum)
> > +{
> > +  if ((regnum >= 0) && (regnum < OR1K_NUM_REGS))
> > +    {
> > +      switch (regnum)
> > +	{
> > +	case OR1K_PPC_REGNUM:
> > +	case OR1K_NPC_REGNUM:
> > +	  return builtin_type (gdbarch)->builtin_func_ptr; /* Pointer to code */
> > +
> > +	case OR1K_SP_REGNUM:
> > +	case OR1K_FP_REGNUM:
> > +	  return builtin_type (gdbarch)->builtin_data_ptr; /* Pointer to data */
> > +
> > +	default:
> > +	  return builtin_type (gdbarch)->builtin_uint32; /* Data */
> > +	}
> > +    }
> > +
> > +  internal_error (__FILE__, __LINE__,
> > +		  _("or1k_register_type: illegal register number %d"),
> > +		  regnum);
> > +}
> > +
> 
> Likewise.

Yes

> > +/* Implement the register_reggroup_p gdbarch method.  */
> > +
> > +static int
> > +or1k_register_reggroup_p (struct gdbarch *gdbarch,
> > +			  int regnum, struct reggroup *group)
> > +{
> > +  struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
> > +
> > +  /* All register group.  */
> > +  if (group == all_reggroup)
> > +    return ((regnum >= 0)
> > +	    && (regnum < OR1K_NUM_REGS)
> > +	    && (or1k_register_name (gdbarch, regnum)[0] != '\0'));
> > +
> > +  /* For now everything except the PC.  */
> > +  if (group == general_reggroup)
> > +    return ((regnum >= OR1K_ZERO_REGNUM)
> > +	    && (regnum < OR1K_MAX_GPR_REGS)
> > +	    && (regnum != OR1K_PPC_REGNUM) && (regnum != OR1K_NPC_REGNUM));
> > +
> > +  if (group == float_reggroup)
> > +    return 0; /* No float regs */
> > +
> > +  if (group == vector_reggroup)
> > +    return 0; /* No vector regs */
> > +
> > +  /* For any that are not handled above.  */
> > +  return default_register_reggroup_p (gdbarch, regnum, group);
> > +}
> > +
> 
> Likewise.

Yes

> > +static int
> > +or1k_is_arg_reg (unsigned int regnum)
> > +{
> > +  return (OR1K_FIRST_ARG_REGNUM <= regnum)
> > +    && (regnum <= OR1K_LAST_ARG_REGNUM);
> > +}
> > +
> > +static int
> > +or1k_is_callee_saved_reg (unsigned int regnum)
> > +{
> > +  return (OR1K_FIRST_SAVED_REGNUM <= regnum) && (0 == regnum % 2);
> > +}
> > +
> > +/* Implement the skip_prologue gdbarch method.  */
> > +
> > +static CORE_ADDR
> > +or1k_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
> > +{
> > +  CORE_ADDR start_pc;
> > +  CORE_ADDR addr;
> > +  uint32_t inst;
> > +
> > +  unsigned int ra, rb, rd; /* for instruction analysis */
> > +  int simm;
> > +
> > +  int frame_size = 0;
> > +
> > +  /* Try using SAL first if we have symbolic information available.  This only
> > +     works for DWARF 2, not STABS.  */
> > +
> > +  if (find_pc_partial_function (pc, NULL, &start_pc, NULL))
> > +    {
> > +      CORE_ADDR prologue_end = skip_prologue_using_sal (gdbarch, pc);
> > +
> > +      if (0 != prologue_end)
> > +	{
> > +	  struct symtab_and_line prologue_sal = find_pc_line (start_pc, 0);
> > +	  struct compunit_symtab *compunit
> > +	    = SYMTAB_COMPUNIT (prologue_sal.symtab);
> > +	  const char *debug_format = COMPUNIT_DEBUGFORMAT (compunit);
> > +
> > +	  if ((NULL != debug_format)
> > +	      && (strlen ("dwarf") <= strlen (debug_format))
> > +	      && (0 == strncasecmp ("dwarf", debug_format, strlen ("dwarf"))))
> > +	    return (prologue_end > pc) ? prologue_end : pc;
> > +	}
> > +    }
> > +
> > +  /* Look to see if we can find any of the standard prologue sequence.  All
> > +     quite difficult, since any or all of it may be missing.  So this is just a
> 
> This line is too long.

OK

> > +     best guess!  */
> > +
> > +  addr = pc; /* Where we have got to */
> > +  inst = or1k_fetch_instruction (gdbarch, addr);
> > +
> > +  /* Look for the new stack pointer being set up.  */
> > +  if (or1k_analyse_l_addi (inst, &rd, &ra, &simm)
> > +      && (OR1K_SP_REGNUM == rd) && (OR1K_SP_REGNUM == ra)
> > +      && (simm < 0) && (0 == (simm % 4)))
> > +    {
> > +      frame_size = -simm;
> > +      addr += OR1K_INSTLEN;
> > +      inst = or1k_fetch_instruction (gdbarch, addr);
> > +    }
> > +
> > +  /* Look for the frame pointer being manipulated.  */
> > +  if (or1k_analyse_l_sw (inst, &simm, &ra, &rb)
> > +      && (OR1K_SP_REGNUM == ra) && (OR1K_FP_REGNUM == rb)
> > +      && (simm >= 0) && (0 == (simm % 4)))
> > +    {
> > +      addr += OR1K_INSTLEN;
> > +      inst = or1k_fetch_instruction (gdbarch, addr);
> > +
> > +      gdb_assert (or1k_analyse_l_addi (inst, &rd, &ra, &simm)
> > +		  && (OR1K_FP_REGNUM == rd) && (OR1K_SP_REGNUM == ra)
> > +		  && (simm == frame_size));
> > +
> > +      addr += OR1K_INSTLEN;
> > +      inst = or1k_fetch_instruction (gdbarch, addr);
> > +    }
> > +
> > +  /* Look for the link register being saved.  */
> > +  if (or1k_analyse_l_sw (inst, &simm, &ra, &rb)
> > +      && (OR1K_SP_REGNUM == ra) && (OR1K_LR_REGNUM == rb)
> > +      && (simm >= 0) && (0 == (simm % 4)))
> > +    {
> > +      addr += OR1K_INSTLEN;
> > +      inst = or1k_fetch_instruction (gdbarch, addr);
> > +    }
> > +
> > +  /* Look for arguments or callee-saved register being saved.  The register
> > +     must be one of the arguments (r3-r8) or the 10 callee saved registers
> > +     (r10, r12, r14, r16, r18, r20, r22, r24, r26, r28, r30).  The base
> > +     register must be the FP (for the args) or the SP (for the callee_saved
> > +     registers).  */
> > +  while (1)
> 
> Can you give an upper-bound of the loop?  The endless loop looks scary
> to me.

OK, ill look for another way to do it. If not I'll revert with more
comments.

> > +    {
> > +      if (or1k_analyse_l_sw (inst, &simm, &ra, &rb)
> > +	  && (((OR1K_FP_REGNUM == ra) && or1k_is_arg_reg (rb))
> > +	      || ((OR1K_SP_REGNUM == ra) && or1k_is_callee_saved_reg (rb)))
> > +	  && (0 == (simm % 4)))
> > +	{
> > +	  addr += OR1K_INSTLEN;
> > +	  inst = or1k_fetch_instruction (gdbarch, addr);
> > +	}
> > +      else
> > +	{
> > +	  /* Nothing else to look for.  We have found the end of the
> > +	     prologue.  */
> > +	  return addr;
> 
> break the loop and "return addr" at the end of this function.

Right, thats more clean.

> > +
> > +/* Implement the push_dummy_call gdbarch method.  */
> > +
> > +static CORE_ADDR
> > +or1k_push_dummy_call (struct gdbarch *gdbarch, struct value *function,
> > +		      struct regcache *regcache, CORE_ADDR bp_addr,
> > +		      int nargs, struct value **args, CORE_ADDR sp,
> > +		      int struct_return, CORE_ADDR struct_addr)
> > +{
> > +
> > +  int argreg;
> > +  int argnum;
> > +  int first_stack_arg;
> > +  int stack_offset = 0;
> > +  int heap_offset = 0;
> > +  CORE_ADDR heap_sp = sp - 128;
> > +  enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> > +  int bpa = (gdbarch_tdep (gdbarch))->bytes_per_address;
> > +  int bpw = (gdbarch_tdep (gdbarch))->bytes_per_word;
> > +  struct type *func_type = value_type (function);
> > +
> > +  /* Return address */
> > +  regcache_cooked_write_unsigned (regcache, OR1K_LR_REGNUM, bp_addr);
> > +
> > +  /* Register for the next argument.  */
> > +  argreg = OR1K_FIRST_ARG_REGNUM;
> > +
> > +  /* Location for a returned structure.  This is passed as a silent first
> > +     argument.  */
> > +  if (struct_return)
> > +    {
> > +      regcache_cooked_write_unsigned (regcache, OR1K_FIRST_ARG_REGNUM,
> > +				      struct_addr);
> > +      argreg++;
> > +    }
> > +
> > +  /* Put as many args as possible in registers.  */
> > +  for (argnum = 0; argnum < nargs; argnum++)
> > +    {
> > +      const gdb_byte *val;
> > +      gdb_byte valbuf[sizeof (ULONGEST)];
> > +
> > +      struct value *arg = args[argnum];
> > +      struct type *arg_type = check_typedef (value_type (arg));
> > +      int len = arg_type->length;
> > +      enum type_code typecode = arg_type->main_type->code;
> 
> typecode = TYPE_CODE (arg_type);

OK, thanks

> > +
> > +      if (TYPE_VARARGS (func_type) && argnum >= TYPE_NFIELDS (func_type))
> > +	break; /* end or regular args, varargs go to stack.  */
> > +
> > +      /* Extract the value, either a reference or the data.  */
> > +      if ((TYPE_CODE_STRUCT == typecode) || (TYPE_CODE_UNION == typecode)
> > +	  || (len > bpw * 2))
> > +	{
> > +	  CORE_ADDR valaddr = value_address (arg);
> > +
> > +	  /* If the arg is fabricated (i.e. 3*i, instead of i) valaddr is
> > +	     undefined.  */
> > +	  if (valaddr == 0)
> > +	    {
> > +	      /* The argument needs to be copied into the target space.  Since
> > +	         the bottom of the stack is reserved for function arguments
> > +	         we store this at the these at the top growing down.  */
> > +	      heap_offset += align_up (len, bpw);
> > +	      valaddr = heap_sp + heap_offset;
> > +
> > +	      write_memory (valaddr, value_contents (arg), len);
> > +	    }
> > +
> > +	  /* The ABI passes all structures by reference, so get its address.  */
> > +	  store_unsigned_integer (valbuf, bpa, byte_order, valaddr);
> > +	  len = bpa;
> > +	  val = valbuf;
> > +	}
> > +      else
> > +	{
> > +	  /* Everything else, we just get the value.  */
> > +	  val = value_contents (arg);
> > +	}
> > +
> > +      /* Stick the value in a register.  */
> > +      if (len > bpw)
> > +	{
> > +	  /* Big scalars use two registers, but need NOT be pair aligned.  */
> > +
> > +	  if (argreg <= (OR1K_LAST_ARG_REGNUM - 1))
> > +	    {
> > +	      ULONGEST regval =	extract_unsigned_integer (val, len, byte_order);
> > +
> > +	      unsigned int bits_per_word = bpw * 8;
> > +	      ULONGEST mask = (((ULONGEST) 1) << bits_per_word) - 1;
> > +	      ULONGEST lo = regval & mask;
> > +	      ULONGEST hi = regval >> bits_per_word;
> > +
> > +	      regcache_cooked_write_unsigned (regcache, argreg, hi);
> > +	      regcache_cooked_write_unsigned (regcache, argreg + 1, lo);
> > +	      argreg += 2;
> > +	    }
> > +	  else
> > +	    {
> > +	      /* Run out of regs */
> > +	      break;
> > +	    }
> > +	}
> > +      else if (argreg <= OR1K_LAST_ARG_REGNUM)
> > +	{
> > +	  /* Smaller scalars fit in a single register.  */
> > +	  regcache_cooked_write_unsigned
> > +	    (regcache, argreg, extract_unsigned_integer (val, len, byte_order));
> > +	  argreg++;
> > +	}
> > +      else
> > +	{
> > +	  /* Ran out of regs.  */
> > +	  break;
> > +	}
> > +    }
> > +
> > +  first_stack_arg = argnum;
> > +
> > +  /* If we get here with argnum < nargs, then arguments remain to be placed on
> > +     the stack.  This is tricky, since they must be pushed in reverse order and
> 
> These two lines are too long.

OK.

> > +     the stack in the end must be aligned.  The only solution is to do it in
> > +     two stages, the first to compute the stack size, the second to save the
> > +     args.  */
> > +
> > +  for (argnum = first_stack_arg; argnum < nargs; argnum++)
> > +    {
> > +      struct value *arg = args[argnum];
> > +      struct type *arg_type = check_typedef (value_type (arg));
> > +      int len = arg_type->length;
> 
> TYPE_LENGTH (arg_type);

Right, thanks.

> > +      enum type_code typecode = arg_type->main_type->code;
> > +
> 
> TYPE_CODE (arg_type);

Right, thanks

> > +
> > +
> > +/* Support functions for frame handling.  */
> > +
> > +/* Initialize a prologue cache
> > +
> > +   We build a cache, saying where registers of the PREV frame can be found
> > +   from the data so far set up in this THIS.
> > +
> > +   We also compute a unique ID for this frame, based on the function start
> > +   address and the stack pointer (as it will be, even if it has yet to be
> > +   computed.
> > +
> > +   STACK FORMAT
> > +   ============
> > +
> > +   The OR1K has a falling stack frame and a simple prolog.  The Stack pointer
> > +   is R1 and the frame pointer R2.  The frame base is therefore the address
> > +   held in R2 and the stack pointer (R1) is the frame base of the NEXT frame.
> > +
> > +   l.addi  r1,r1,-frame_size	# SP now points to end of new stack frame
> > +
> > +   The stack pointer may not be set up in a frameless function (e.g. a simple
> > +   leaf function).
> > +
> > +   l.sw    fp_loc(r1),r2        # old FP saved in new stack frame
> > +   l.addi  r2,r1,frame_size     # FP now points to base of new stack frame
> > +
> > +   The frame pointer is not necessarily saved right at the end of the stack
> > +   frame - OR1K saves enough space for any args to called functions right at
> > +   the end (this is a difference from the Architecture Manual).
> > +
> > +   l.sw    lr_loc(r1),r9        # Link (return) address
> > +
> > +   The link register is usally saved at fp_loc - 4.  It may not be saved at all
> > +   in a leaf function.
> > +
> > +   l.sw    reg_loc(r1),ry       # Save any callee saved regs
> > +
> > +   The offsets x for the callee saved registers generally (always?) rise in
> > +   increments of 4, starting at fp_loc + 4.  If the frame pointer is omitted
> > +   (an option to GCC), then it may not be saved at all.  There may be no callee
> > +   saved registers.
> > +
> > +   So in summary none of this may be present.  However what is present seems
> > +   always to follow this fixed order, and occur before any substantive code
> > +   (it is possible for GCC to have more flexible scheduling of the prologue,
> > +   but this does not seem to occur for OR1K).
> > +
> > +   ANALYSIS
> > +   ========
> > +
> > +   This prolog is used, even for -O3 with GCC.
> > +
> > +   All this analysis must allow for the possibility that the PC is in the
> > +   middle of the prologue.  Data in the cache should only be set up insofar as
> > +   it has been computed.
> > +
> > +   HOWEVER.  The frame_id must be created with the SP *as it will be* at the
> > +   end of the Prologue.  Otherwise a recursive call, checking the frame with
> > +   the PC at the start address will end up with the same frame_id as the
> > +   caller.
> > +
> > +   A suite of "helper" routines are used, allowing reuse for
> > +   or1k_skip_prologue().
> > +
> > +   Reportedly, this is only valid for frames less than 0x7fff in size.  */
> > +
> > +static struct trad_frame_cache *
> > +or1k_frame_cache (struct frame_info *this_frame, void **prologue_cache)
> > +{
> > +  struct gdbarch *gdbarch;
> > +  struct trad_frame_cache *info;
> > +
> > +  CORE_ADDR this_pc;
> > +  CORE_ADDR this_sp;
> > +  CORE_ADDR this_sp_for_id;
> > +  int frame_size = 0;
> > +
> > +  CORE_ADDR start_addr;
> > +  CORE_ADDR end_addr;
> > +
> > +  if (frame_debug)
> > +    fprintf_unfiltered (gdb_stdlog,
> > +			"or1k_frame_cache, prologue_cache = 0x%p\n",
> > +			*prologue_cache);
> 
> Can you add a new debug flag, like or1k_debug, to control this?  Each
> backend in GDB (amd64-windows-tdep.c) use its own debug flag to control
> the output related to frame unwinding.

OK, adding with add_setshow_boolean_cmd().

> > +  /* Get a new prologue cache and populate it with default values.  */
> > +  info = trad_frame_cache_zalloc (this_frame);
> > +  *prologue_cache = info;
> > +
> > +  /* Find the start address of THIS function (which is a NORMAL frame, even if
> > +     the NEXT frame is the sentinel frame) and the end of its prologue.  */
> 
> Don't need to capitalize THIS, NORMAL, and NEXT.

OK, I think this was done for emphasis, but I guess its not needed.

> > +
> > +  /* The default frame base of THIS frame (for ID purposes only - frame base
> > +     is an overloaded term) is its stack pointer.  For now we use the value of
> > +     the SP register in THIS frame.  However if the PC is in the prologue of
> > +     THIS frame, before the SP has been set up, then the value will actually
> > +     be that of the PREV frame, and we'll need to adjust it later.  */
> > +  trad_frame_set_this_base (info, this_sp);
> > +  this_sp_for_id = this_sp;
> > +
> > +  /* The default is to find the PC of the PREVIOUS frame in the link register
> > +     of this frame.  This may be changed if we find the link register was saved
> > +     on the stack.  */
> > +  trad_frame_set_reg_realreg (info, OR1K_NPC_REGNUM, OR1K_LR_REGNUM);
> > +
> > +  /* We should only examine code that is in the prologue.  This is all code up
> > +     to (but not including) end_addr.  We should only populate the cache while
> > +     the address is up to (but not including) the PC or end_addr, whichever is
> > +     first.  */
> > +  gdbarch = get_frame_arch (this_frame);
> > +  end_addr = or1k_skip_prologue (gdbarch, start_addr);
> > +
> > +  /* All the following analysis only occurs if we are in the prologue and have
> > +     executed the code.  Check we have a sane prologue size, and if zero we
> > +     are frameless and can give up here.  */
> > +  if (end_addr < start_addr)
> 
> How can it be?

Looking at or1k_skip_prologue(), it doesnt look like its possible.

I guess this is just a sanity check.  I can remove if you agree it looks
impossible.

> > +    throw_quit ("end addr 0x%08x is less than start addr 0x%08x\n",
> > +		(unsigned int) end_addr, (unsigned int) start_addr);
> 
> s/throw_quit/error/

OK

> > +
> > +/* Data structures for the normal prologue-analysis-based unwinder.  */
> > +
> > +static const struct frame_unwind or1k_frame_unwind = {
> > +  .type = NORMAL_FRAME,
> > +  .stop_reason = default_frame_unwind_stop_reason,
> > +  .this_id = or1k_frame_this_id,
> > +  .prev_register = or1k_frame_prev_register,
> > +  .unwind_data = NULL,
> > +  .sniffer = default_frame_sniffer,
> > +  .dealloc_cache = NULL,
> > +  .prev_arch = NULL
> > +};
> 
> Write the code this way,
> 
> static const struct frame_unwind or1k_frame_unwind =
> {
>   NORMAL_FRAME,
>   default_frame_unwind_stop_reason,
>   or1k_frame_this_id,
>   or1k_frame_prev_register,
>   NULL,
>   default_frame_sniffer,
>   NULL,
> };

OK, I prefer with the named fields, because its self documenting, but
what you are showing is consistent with other *-tdep.c definitions.

I'll change it.

> > +
> > +/* Architecture initialization for OpenRISC 1000.  */
> > +
> > +static struct gdbarch *
> > +or1k_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> > +{
> ...
> > +  /* Check any target description for validity.  */
> > +  if (tdesc_has_registers (info.target_desc))
> > +    {
> > +      const struct tdesc_feature *feature;
> > +      int valid_p;
> > +
> > +      feature = tdesc_find_feature (info.target_desc, "org.gnu.gdb.or1k.group0");
> 
> This line is too long.  In patch 2/4, you defined 11 features, group0 -
> group 10, but you only find feature group0.  Is group0 a required
> feature?

I have upated this already.  I only define group0 as a required feature
and documented it as well.  The other I removed and leave up to targets
like OpenOCD to define.

> > +      if (feature == NULL)
> > +        return NULL;
> > +
> > +      tdesc_data = tdesc_data_alloc ();
> > +
> > +      valid_p = 1;
> > +
> > +      for (i = 0; i < OR1K_NUM_REGS; i++)
> > +        valid_p &= tdesc_numbered_register (feature, tdesc_data, i,
> > +                                            or1k_reg_names[i]);
> > +
> > +      if (!valid_p)
> > +        {
> > +          tdesc_data_cleanup (tdesc_data);
> > +          return NULL;
> > +        }
> > +    }
> > +
> > +  if (tdesc_data)
> 
> if (tdesc_data != NULL)

OK

> > +    {
> > +      tdesc_use_registers (gdbarch, info.target_desc, tdesc_data);
> > +
> > +      /* Target descriptions may extend into the following groups.  */
> > +      reggroup_add (gdbarch, general_reggroup);
> > +      reggroup_add (gdbarch, system_reggroup);
> > +      reggroup_add (gdbarch, float_reggroup);
> > +      reggroup_add (gdbarch, vector_reggroup);
> > +      reggroup_add (gdbarch, reggroup_new ("immu", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("dmmu", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("icache", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("dcache", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("pic", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("timer", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("power", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("perf", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("mac", USER_REGGROUP));
> > +      reggroup_add (gdbarch, reggroup_new ("debug", USER_REGGROUP));
> > +      reggroup_add (gdbarch, all_reggroup);
> > +      reggroup_add (gdbarch, save_reggroup);
> > +      reggroup_add (gdbarch, restore_reggroup);
> > +    }
> > +
> > +  return gdbarch;
> > +}
> > +
> 
> > +
> > +extern initialize_file_ftype _initialize_or1k_tdep; /* -Wmissing-prototypes */
> > +
> > +void
> > +_initialize_or1k_tdep (void)
> > +{
> > +  /* Register this architecture.  */
> > +  gdbarch_register (bfd_arch_or1k, or1k_gdbarch_init, or1k_dump_tdep);
> > +
> > +  /* Tell remote stub that we support XML target description.  */
> > +  register_remote_support_xml ("or1k");
> 
> Can't remote stub think GDB support xml target description already?

I'll try to remove and see.

> > +}
> > diff --git a/gdb/or1k-tdep.h b/gdb/or1k-tdep.h
> > new file mode 100644
> > index 0000000..edcad88
> > --- /dev/null
> > +++ b/gdb/or1k-tdep.h
> > @@ -0,0 +1,56 @@
> > +/* Definitions to target GDB to OpenRISC 1000 32-bit targets.
> > +   Copyright (C) 2008-2017 Free Software Foundation, Inc.
> > +
> > +   This file is part of GDB.
> > +
> > +   This program is free software; you can redistribute it and/or modify it
> > +   under the terms of the GNU General Public License as published by the Free
> > +   Software Foundation; either version 3 of the License, or (at your option)
> > +   any later version.
> > +
> > +   This program is distributed in the hope that it will be useful, but WITHOUT
> > +   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> > +   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> > +   more details.
> > +
> > +   You should have received a copy of the GNU General Public License along
> > +   With this program.  If not, see <http://www.gnu.org/licenses/>.  */
> > +
> > +
> > +#ifndef OR1K_TDEP__H
> > +#define OR1K_TDEP__H
> > +
> > +#ifndef TARGET_OR1K
> > +#define TARGET_OR1K
> > +#endif
> > +
> > +#include "opcodes/or1k-desc.h"
> > +#include "opcodes/or1k-opc.h"
> > +
> > +/* General Purpose Registers */
> > +#define OR1K_ZERO_REGNUM          0
> > +#define OR1K_SP_REGNUM            1
> > +#define OR1K_FP_REGNUM            2
> > +#define OR1K_FIRST_ARG_REGNUM     3
> > +#define OR1K_LAST_ARG_REGNUM      8
> > +#define OR1K_LR_REGNUM            9
> > +#define OR1K_FIRST_SAVED_REGNUM  10
> > +#define OR1K_RV_REGNUM           11
> > +#define OR1K_PPC_REGNUM          (OR1K_MAX_GPR_REGS + 0)
> > +#define OR1K_NPC_REGNUM          (OR1K_MAX_GPR_REGS + 1)
> > +#define OR1K_SR_REGNUM           (OR1K_MAX_GPR_REGS + 2)
> 
> A general comments on these macros, if they are only used in
> or1k-tdep.c, why don't you move these macros into or1k-tdep.c?

It seems common that other archs put their macros like this in the
*tdep.h file.  I see in nio2 and alpha.

I could change but I rather not if its ok.

> > +
> > +/* Properties of the architecture. GDB mapping of registers is all the GPRs
> > +   and SPRs followed by the PPC, NPC and SR at the end. Red zone is the area
> > +   past the end of the stack reserved for exception handlers etc.  */
> > +
> > +#define OR1K_MAX_GPR_REGS            32
> > +#define OR1K_NUM_PSEUDO_REGS         0
> > +#define OR1K_NUM_REGS               (OR1K_MAX_GPR_REGS + 3)
> > +#define OR1K_STACK_ALIGN             4
> > +#define OR1K_INSTLEN                 4
> > +#define OR1K_INSTBITLEN             (OR1K_INSTLEN * 8)
> > +#define OR1K_NUM_TAP_RECORDS         8
> > +#define OR1K_FRAME_RED_ZONE_SIZE     2536
> > +
> > +#endif /* OR1K_TDEP__H */


Thanks for all the comments.  As mentioned before I will fix up and
send.

> -- 
> Yao (齐尧)

^ permalink raw reply

* [Buildroot] [Patch v4 2/3] cargo-bootstrap: new package
From: Eric Le Bihan @ 2017-04-08  9:34 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1491548799.26127.5.camel@embedded.rocks>

Hi!

On 17-04-07 09:06:39, J?rg Krause wrote:
> Hi Eric,
>
> On Sun, 2017-04-02 at 21:46 +0200, Eric Le Bihan wrote:
> > This new package fetches a binary snapshot of Cargo, suitable for the
> > host, in order to bootstrap the Rust compiler and Cargo, the package
> > manager.
>
> Why not build it from source?

Cargo uses Cargo as its build system, so you need to have a working
version of Cargo on the host system to build a new version from the
source code.

To build the Rust compiler a binary snapshot is enough.

I'll send a patch to add a package for the real Cargo soon.

> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > ---
> > ?DEVELOPERS???????????????????????????????????|??1 +
> > ?package/cargo-bootstrap/cargo-bootstrap.hash |??3 +++
> > ?package/cargo-bootstrap/cargo-bootstrap.mk???| 14 ++++++++++++++
> > ?3 files changed, 18 insertions(+)
> > ?create mode 100644 package/cargo-bootstrap/cargo-bootstrap.hash
> > ?create mode 100644 package/cargo-bootstrap/cargo-bootstrap.mk
> >
> > diff --git a/DEVELOPERS b/DEVELOPERS
> > index 863d5aa..1fed408 100644
> > --- a/DEVELOPERS
> > +++ b/DEVELOPERS
> > @@ -442,6 +442,7 @@ F:	package/xxhash/
> > ?
> > ?N:	Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > ?F:	package/adwaita-icon-theme/
> > +F:	package/cargo-bootstrap
> > ?F:	package/darkhttpd/
> > ?F:	package/eudev/
> > ?F:	package/execline/
> > diff --git a/package/cargo-bootstrap/cargo-bootstrap.hash
> > b/package/cargo-bootstrap/cargo-bootstrap.hash
> > new file mode 100644
> > index 0000000..b193c6f
> > --- /dev/null
> > +++ b/package/cargo-bootstrap/cargo-bootstrap.hash
> > @@ -0,0 +1,3 @@
> > +# Locally generated
> > +sha256
> > 0655713cacab054e8e5a33e742081eebec8531a8c77d28a4294e6496123e8ab1??car
> > go-nightly-x86_64-unknown-linux-gnu.tar.gz
> > +sha256
> > f20adfdcd6fb61c1252034e998998ec349c8a6b05c0320e47a539b0f6d1c76fa??car
> > go-nightly-i686-unknown-linux-gnu.tar.gz
> > diff --git a/package/cargo-bootstrap/cargo-bootstrap.mk
> > b/package/cargo-bootstrap/cargo-bootstrap.mk
> > new file mode 100644
> > index 0000000..8a11e6e
> > --- /dev/null
> > +++ b/package/cargo-bootstrap/cargo-bootstrap.mk
> > @@ -0,0 +1,14 @@
> > +####################################################################
> > ############
> > +#
> > +# cargo-bootstrap
> > +#
> > +####################################################################
> > ############
> > +
> > +CARGO_BOOTSTRAP_VERSION = 6e0c18cccc8b0c06fba8a8d76486f81a792fb420
> > +CARGO_BOOTSTRAP_SITE = https://s3.amazonaws.com/rust-lang-ci/cargo-b
> > uilds/$(CARGO_BOOTSTRAP_VERSION)
> > +CARGO_BOOTSTRAP_SOURCE = cargo-nightly-$(HOSTARCH)-unknown-linux-
> > gnu.tar.gz
> > +CARGO_BOOTSTRAP_LICENSE = Apache-2.0 or MIT
> > +CARGO_BOOTSTRAP_LICENSE_FILES = LICENSE-APACHE LICENSE-MIT
> > +CARGO_BOOTSTRAP_STRIP_COMPONENTS = 1
> > +
> > +$(eval $(host-generic-package))

--
ELB

^ permalink raw reply

* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08  9:33 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Jacek Anaszewski, Rob Herring, Richard Purdie, linux-kernel,
	linux-leds, linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20170407203649.GD15143@minitux>

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Fri 2017-04-07 13:36:49, Bjorn Andersson wrote:
> On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
> 
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> > 
> > Well... I'm not sure if we _want_ to do triggers for
> > patterns. LED triggers change rather quickly (100 times a second?) so
> > doing them in kernel makes sense. Patterns take 10s of seconds, so we
> > do not need to handle them in kernel. 
> > 
> 
> On any current Qualcomm based phone (using the Qualcomm PMIC to drive
> the RGB notification LED) the patterns are hard coded in DeviceTree and
> the option you have in runtime is to enable/disable the usage of the
> configured pattern and a few knobs of how to traverse the configured
> pattern.

Yes... that's easy, but I believe too limiting. Users will want to
configure their own patterns for their own events.

> When you enter e.g. a low-battery scenario you trigger the red LED to
> run its low-battery-pattern and you don't touch it until there's a
> higher prio notification (e.g. someone connects the charger).

Yes, I have something like that, too.

https://gitlab.com/tui/tui/blob/master/ofone/watchdog.py

									Pavel

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Pavel Machek @ 2017-04-08  9:33 UTC (permalink / raw)
  To: Bjorn Andersson
  Cc: Jacek Anaszewski, Rob Herring, Richard Purdie,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-leds-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170407203649.GD15143@minitux>

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Fri 2017-04-07 13:36:49, Bjorn Andersson wrote:
> On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
> 
> > > For the patterns I don't know how a trigger for this would look like,
> > > how would setting the pattern of a trigger be propagated down to the
> > > hardware?
> > 
> > Well... I'm not sure if we _want_ to do triggers for
> > patterns. LED triggers change rather quickly (100 times a second?) so
> > doing them in kernel makes sense. Patterns take 10s of seconds, so we
> > do not need to handle them in kernel. 
> > 
> 
> On any current Qualcomm based phone (using the Qualcomm PMIC to drive
> the RGB notification LED) the patterns are hard coded in DeviceTree and
> the option you have in runtime is to enable/disable the usage of the
> configured pattern and a few knobs of how to traverse the configured
> pattern.

Yes... that's easy, but I believe too limiting. Users will want to
configure their own patterns for their own events.

> When you enter e.g. a low-battery scenario you trigger the red LED to
> run its low-battery-pattern and you don't touch it until there's a
> higher prio notification (e.g. someone connects the charger).

Yes, I have something like that, too.

https://gitlab.com/tui/tui/blob/master/ofone/watchdog.py

									Pavel

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply

* Re: [RFC] Multicast and IPv6 Link Local Addresses
From: Dan Lüdtke @ 2017-04-08  9:39 UTC (permalink / raw)
  To: Jason A. Donenfeld
  Cc: Juliusz Chroboczek, Toke Høiland-Jørgensen,
	Dave Täht, WireGuard mailing list
In-Reply-To: <CAHmME9poZPFbYhitnK8UvDB-32hLRcTFc4vAwaUPwGEz0wY+Yg@mail.gmail.com>

Hi everyone,

I am very excited that we have this discussion, as I am one of those =
IPv6-first/IPv6-only guys who like poking the topic.
I try to keep it short:

- Scalability: I agree with what George said. Broadcast does not scale =
nicely, and IPv6 multicast is intended to help scaling things by =
reaching exactly the node that need to get a copy of a particular =
packet. Downgrading IPv6 multicast to broadcast hurts scalability and I =
for one, would rather not see multicast in WireGuard if it does not =
scale. I am afraid it would be counterproductive to the goal of having a =
widely accepted and used protocol.

- Multicast is not the everyday use case, so if multicast requires an =
extra knob or an extra option, that would be fine I guess. I am in favor =
of intentionally enabling multicast. I am still wrapping my head around =
static vs. dynamic (read: magic) configuration of multicast addresses =
and groups. Will let you know once I end up with something worth =
sharing. In the meantime, I think "solicited node multicast =
addresses/groups" are the one thing that comes with the least amount of =
trouble. Especially if IPv6 LL addressing is also there.

- IPv6 link-local addressing: For me it is a perfect example for "the =
right amount of magic". It would make (at least my) life so much easier. =
Filling the neighbor cache would require WireGuard to provide (simulated =
or real) solicited node multicast addresses routing, right? Or is it =
feasible to fill the neighbor cache based on the peer configuration? The =
last thing sounds wrong to me.

So much for my first thoughts.

Cheers,

Dan=

^ permalink raw reply

* [Intel-wired-lan] [jkirsher-next-queue:dev-queue] BUILD REGRESSION 351268d714a036980895a67fd182a9efe27acba1
From: kbuild test robot @ 2017-04-08  9:33 UTC (permalink / raw)
  To: intel-wired-lan

https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git  dev-queue
351268d714a036980895a67fd182a9efe27acba1  i40e/i40evf: Remove VF Rx csum offload for tunneled packets.

drivers/net/ethernet/intel/i40e/i40e_main.c:11369:15: warning: 'vf' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/intel/i40e/i40e_main.c:11370:3: warning: 'vf' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/intel/i40e/i40e_txrx.c:1346:8: error: 'struct sk_buff' has no member named 'offload_fwd_mark'
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:2171:36: error: 'size' undeclared (first use in this function)

Error ids grouped by kconfigs:

recent_errors
??? arm64-allmodconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? arm-allmodconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? i386-allmodconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? i386-allyesconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? ia64-allmodconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? ??? drivers-net-ethernet-intel-ixgbe-ixgbe_main.c:error:size-undeclared-(first-use-in-this-function)
??? powerpc-defconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? ??? drivers-net-ethernet-intel-i40e-i40e_txrx.c:error:struct-sk_buff-has-no-member-named-offload_fwd_mark
??? powerpc-ppc64_defconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? ??? drivers-net-ethernet-intel-i40e-i40e_txrx.c:error:struct-sk_buff-has-no-member-named-offload_fwd_mark
??? x86_64-allmodconfig
??? ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
??? x86_64-rhel
    ??? drivers-net-ethernet-intel-i40e-i40e_main.c:warning:vf-may-be-used-uninitialized-in-this-function
    ??? drivers-net-ethernet-intel-i40e-i40e_txrx.c:error:struct-sk_buff-has-no-member-named-offload_fwd_mark

elapsed time: 235m

configs tested: 166

alpha                               defconfig
parisc                            allnoconfig
parisc                         b180_defconfig
parisc                        c3000_defconfig
parisc                              defconfig
avr32                        merisc_defconfig
blackfin                BF537-STAMP_defconfig
i386                     randconfig-a0-201714
x86_64                 randconfig-a0-04081425
i386                               tinyconfig
sh                                allnoconfig
sh                          rsk7269_defconfig
sh                  sh7785lcr_32bit_defconfig
sh                            titan_defconfig
i386                   randconfig-c0-04081501
x86_64                           allmodconfig
blackfin                BF526-EZBRD_defconfig
blackfin                BF533-EZKIT_defconfig
blackfin            BF561-EZKIT-SMP_defconfig
blackfin                  TCM-BF537_defconfig
cris                 etrax-100lx_v2_defconfig
x86_64                 randconfig-x010-201714
x86_64                 randconfig-x011-201714
x86_64                 randconfig-x012-201714
x86_64                 randconfig-x013-201714
x86_64                 randconfig-x014-201714
x86_64                 randconfig-x015-201714
x86_64                 randconfig-x016-201714
x86_64                 randconfig-x017-201714
x86_64                 randconfig-x018-201714
x86_64                 randconfig-x019-201714
arm                              allmodconfig
arm                                      arm5
arm                                     arm67
arm                       imx_v6_v7_defconfig
arm                          ixp4xx_defconfig
arm                        mvebu_v7_defconfig
arm                       omap2plus_defconfig
arm                                    sa1100
arm                                   samsung
arm                                        sh
arm                           tegra_defconfig
arm64                            alldefconfig
arm64                            allmodconfig
i386                     randconfig-s0-201714
i386                     randconfig-s1-201714
avr32                      atngw100_defconfig
avr32                     atstk1006_defconfig
frv                                 defconfig
mn10300                     asb2364_defconfig
openrisc                    or1ksim_defconfig
tile                         tilegx_defconfig
um                             i386_defconfig
um                           x86_64_defconfig
i386                             allmodconfig
mips                           32r2_defconfig
mips                         64r6el_defconfig
mips                              allnoconfig
mips                      fuloong2e_defconfig
mips                                   jz4740
mips                      malta_kvm_defconfig
mips                                     txx9
powerpc                           allnoconfig
powerpc                             defconfig
powerpc                       ppc64_defconfig
s390                        default_defconfig
x86_64                   randconfig-i0-201714
microblaze                      mmu_defconfig
microblaze                    nommu_defconfig
i386                     randconfig-i0-201714
i386                     randconfig-i1-201714
i386                             allyesconfig
sparc                               defconfig
sparc64                           allnoconfig
sparc64                             defconfig
c6x                        evmc6678_defconfig
h8300                    h8300h-sim_defconfig
m32r                       m32104ut_defconfig
m32r                     mappi3.smp_defconfig
m32r                         opsput_defconfig
m32r                           usrv_defconfig
nios2                         10m50_defconfig
score                      spct6600_defconfig
xtensa                       common_defconfig
xtensa                          iss_defconfig
arm                      jornada720_defconfig
powerpc                     mpc5200_defconfig
i386                   randconfig-x010-201714
i386                   randconfig-x014-201714
i386                   randconfig-x016-201714
i386                   randconfig-x017-201714
i386                   randconfig-x013-201714
i386                   randconfig-x019-201714
i386                   randconfig-x011-201714
i386                   randconfig-x012-201714
i386                   randconfig-x015-201714
i386                   randconfig-x018-201714
x86_64                                    lkp
x86_64                                   rhel
i386                     randconfig-n0-201714
i386                   randconfig-h0-04081204
i386                   randconfig-h1-04081204
cris                    etrax-100lx_defconfig
mips                       bmips_be_defconfig
powerpc                 mpc8560_ads_defconfig
i386                             alldefconfig
m68k                       m5249evb_defconfig
x86_64                 randconfig-n0-04081645
m68k                       m5475evb_defconfig
m68k                          multi_defconfig
m68k                           sun3_defconfig
ia64                             alldefconfig
ia64                              allnoconfig
ia64                                defconfig
x86_64                                  kexec
x86_64                randconfig-ws0-04081221
arm                               allnoconfig
arm                         at91_dt_defconfig
arm                           efm32_defconfig
arm                          exynos_defconfig
arm                        multi_v5_defconfig
arm                        multi_v7_defconfig
arm                        shmobile_defconfig
arm                           sunxi_defconfig
arm64                             allnoconfig
arm64                               defconfig
i386                   randconfig-x070-201714
i386                   randconfig-x071-201714
i386                   randconfig-x072-201714
i386                   randconfig-x073-201714
i386                   randconfig-x074-201714
i386                   randconfig-x075-201714
i386                   randconfig-x076-201714
i386                   randconfig-x077-201714
i386                   randconfig-x078-201714
i386                   randconfig-x079-201714
i386                              allnoconfig
i386                                defconfig
x86_64                             acpi-redef
x86_64                           allyesdebian
x86_64                                nfsroot
c6x                        evmc6472_defconfig
powerpc                      walnut_defconfig
xtensa                generic_kc705_defconfig
x86_64                 randconfig-x004-201714
x86_64                 randconfig-x009-201714
x86_64                 randconfig-x003-201714
x86_64                 randconfig-x008-201714
x86_64                 randconfig-x002-201714
x86_64                 randconfig-x000-201714
x86_64                 randconfig-x007-201714
x86_64                 randconfig-x005-201714
x86_64                 randconfig-x001-201714
x86_64                 randconfig-x006-201714
i386                     randconfig-r0-201714
i386                   randconfig-x006-201714
i386                   randconfig-x005-201714
i386                   randconfig-x002-201714
i386                   randconfig-x007-201714
i386                   randconfig-x003-201714
i386                   randconfig-x001-201714
i386                   randconfig-x008-201714
i386                   randconfig-x000-201714
i386                   randconfig-x009-201714
i386                   randconfig-x004-201714

Thanks,
Fengguang

^ permalink raw reply

* Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
From: Jeff King @ 2017-04-08  9:31 UTC (permalink / raw)
  To: Jacob Keller; +Cc: Matt McCutchen, git
In-Reply-To: <CA+P7+xrVe7jnqpQFvYBb25ofrNqnRspdk-M6jRuwRi5sUqCCZg@mail.gmail.com>

On Sat, Apr 08, 2017 at 01:25:43AM -0700, Jacob Keller wrote:

> On Fri, Apr 7, 2017 at 7:15 PM, Matt McCutchen <matt@mattmccutchen.net> wrote:
> > When I'm rewriting history, "git push --force-with-lease" is a nice
> > safeguard compared to "git push --force", but it still assumes the
> > remote-tracking ref gives the old state the user wants to overwrite.
> > Tools that do an implicit fetch, assuming it to be a safe operation,
> > may break this assumption.  In the worst case, Visual Studio Code does
> > an automatic fetch every 3 minutes by default [1], making
> > --force-with-lease pretty much reduce to --force.
> >
> 
> Isn't the point of force-with-lease to actually record a "commit" id,
> and not pass it a branch name, but actually the sha1 you intend the
> remote server to be at? Sure if you happen to pass it a branch or
> remote name it will interpret it for yuou, but you should be able to
> do something like
> 
> current=$(git rev-parse origin/branch)
> <verify current is correct and then do your rewind stuff>
> git push --force-with-lease=$current
> 
> and this will work regardless of when if if you fetch in between?

That's definitely the _best way to do it (modulo using "branch:$current"
in the final command). I think Matt's point is just that the default, to
use origin/branch, is unsafe. It's convenient when you don't have extra
fetches, but that convenience may not be worth the potential surprise.

-Peff

^ permalink raw reply

* Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
From: Jeff King @ 2017-04-08  9:29 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Matt McCutchen, git, Junio C Hamano
In-Reply-To: <CACBZZX7MeX-6RHgh2Fa9+YL03mjxs8xmyE86HnVxBxjMYizcig@mail.gmail.com>

On Sat, Apr 08, 2017 at 09:35:04AM +0200, Ævar Arnfjörð Bjarmason wrote:

> Is it correct that you'd essentially want something that works like:
> 
>     git push --force-with-lease=master:master origin master:master

I don't think that would do anything useful. It would reject any push
where the remote "master" is not the same as your own master. And of
course if they _are_ the same, then the push is a noop.

> I haven't used this feature but I'm surprised it works the way it
> does, as you point out just having your remote refs updated isn't a
> strong signal for wanting to clobber whatever that ref points to.

The point of the --force-with-lease feature is that you would mark a
point in time where you started some rewind-y operation (like a rebase),
and at the end you would want to make sure nobody had moved the remote
ref when you push over it (which needs to be a force because of the
rewind).

So the best way to use it is something like:

  git fetch              ;# update 'master' from remote
  git tag base master    ;# mark our base point
  git rebase -i master   ;# rewrite some commits
  git push --force-with-lease=master:base master:master

That final operation will fail if somebody else pushed in the meantime.
But obviously this workflow is a pain, because you have to manually mark
the start of the unsafe operation with a tag.

If you haven't fetched in the meantime, then origin/master is a good
approximation of "base". But if you have fetched, then it is worthless.

It would be nice if we could automatically deduce the real value of
base. I don't think we could do it in a foolproof way, but I wonder if
we could come close in some common circumstances. For instance, imagine
that unsafe operations like rebase would note that "master" has an
upstream of "origin/master", and would record a note saying "we took a
lease for origin/master at sha1 X".

One trouble with that is that you may perform several unsafe operations.
For example, imagine it takes you multiple rebases to achieve your final
state:

  git fetch
  git rebase -i master
  git rebase -i master
  git push --force-with-lease=master

and that --force-with-lease now defaults to whatever lease-marker is
left by rebase. Which marker should it respect? If the second one, then
it's unsafe. But if the first one, then how do we deal with stale
markers?

Perhaps it would be enough to reset the markers whenever the ref is
pushed. I haven't thought it through well enough to know whether that
just hits more corner cases.

-Peff

^ permalink raw reply

* [PATCH nf-next] netfilter: nf_conntrack: make nf_conntrack_max as an unsigned int knob
From: Liping Zhang @ 2017-04-08  9:32 UTC (permalink / raw)
  To: pablo; +Cc: netfilter-devel, Liping Zhang

From: Liping Zhang <zlpnobody@gmail.com>

It doesn't work when we set a large value to the nf_conntrack_max, as
well as the nf_conntrack_expect_max:
  # echo 4294967295 > /proc/sys/net/nf_conntrack_max
  bash: echo: write error: Invalid argument

So convert to use proc_douintvec.

Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
---
 net/netfilter/nf_conntrack_standalone.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c
index 2256147..7f131a3 100644
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -479,9 +479,9 @@ static struct ctl_table nf_ct_sysctl_table[] = {
 	{
 		.procname	= "nf_conntrack_max",
 		.data		= &nf_conntrack_max,
-		.maxlen		= sizeof(int),
+		.maxlen		= sizeof(unsigned int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_douintvec,
 	},
 	{
 		.procname	= "nf_conntrack_count",
@@ -516,9 +516,9 @@ static struct ctl_table nf_ct_sysctl_table[] = {
 	{
 		.procname	= "nf_conntrack_expect_max",
 		.data		= &nf_ct_expect_max,
-		.maxlen		= sizeof(int),
+		.maxlen		= sizeof(unsigned int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_douintvec,
 	},
 	{
 		.procname	= "nf_conntrack_default_on",
@@ -534,9 +534,9 @@ static struct ctl_table nf_ct_netfilter_table[] = {
 	{
 		.procname	= "nf_conntrack_max",
 		.data		= &nf_conntrack_max,
-		.maxlen		= sizeof(int),
+		.maxlen		= sizeof(unsigned int),
 		.mode		= 0644,
-		.proc_handler	= proc_dointvec,
+		.proc_handler	= proc_douintvec,
 	},
 	{ }
 };
-- 
2.5.5



^ permalink raw reply related

* [Buildroot] [Patch v4 1/3] rust-bootstrap: new package
From: Eric Le Bihan @ 2017-04-08  9:23 UTC (permalink / raw)
  To: buildroot
In-Reply-To: <1491548614.26127.3.camel@embedded.rocks>

Hi!

On 17-04-07 09:03:34, J?rg Krause wrote:
> On Sun, 2017-04-02 at 21:46 +0200, Eric Le Bihan wrote:
> > This new package fetches a binary snapshot of the Rust compiler,
> > suitable for the host, in order to bootstrap the Rust compiler.
> >
> > Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr>
> > ---
> > ?DEVELOPERS?????????????????????????????????|??1 +
> > ?package/rust-bootstrap/rust-bootstrap.hash |??5 ++++
> > ?package/rust-bootstrap/rust-bootstrap.mk???| 37
> > ++++++++++++++++++++++++++++++
> > ?3 files changed, 43 insertions(+)
> > ?create mode 100644 package/rust-bootstrap/rust-bootstrap.hash
> > ?create mode 100644 package/rust-bootstrap/rust-bootstrap.mk
> >
> > diff --git a/DEVELOPERS b/DEVELOPERS
> > index c89468b..863d5aa 100644
> > --- a/DEVELOPERS
> > +++ b/DEVELOPERS
> > @@ -448,6 +448,7 @@ F:	package/execline/
> > ?F:	package/hicolor-icon-theme/
> > ?F:	package/jemalloc/
> > ?F:	package/ninja/
> > +F:	package/rust-bootstrap
> > ?F:	package/s6/
> > ?F:	package/s6-dns/
> > ?F:	package/s6-linux-init/
> > diff --git a/package/rust-bootstrap/rust-bootstrap.hash
> > b/package/rust-bootstrap/rust-bootstrap.hash
> > new file mode 100644
> > index 0000000..b418ea0
> > --- /dev/null
> > +++ b/package/rust-bootstrap/rust-bootstrap.hash
> > @@ -0,0 +1,5 @@
> > +# Locally calculated
> > +sha256
> > a833304f99071600c72ecd868c1c7bd5ce49d1102332637a8eb7adb942f349ab??rus
> > tc-1.15.1-i686-unknown-linux-gnu.tar.gz
> > +sha256
> > 33ff44672b731fc71145974ce84194a1a9bafe6da3a74fd1e7543f12467f8894??rus
> > tc-1.15.1-x86_64-unknown-linux-gnu.tar.gz
> > +sha256
> > eff452a54b208a83b35432f226cb7de046d27b5e43edfc31d71ff340af686db0??rus
> > t-std-1.15.1-i686-unknown-linux-gnu.tar.gz
> > +sha256
> > 69b251b478e284dfcaefc1153183f26f41d504ae213a81224f2101d8dbd52bb0??rus
> > t-std-1.15.1-x86_64-unknown-linux-gnu.tar.gz
> > diff --git a/package/rust-bootstrap/rust-bootstrap.mk b/package/rust-
> > bootstrap/rust-bootstrap.mk
> > new file mode 100644
> > index 0000000..1098423
> > --- /dev/null
> > +++ b/package/rust-bootstrap/rust-bootstrap.mk
> > @@ -0,0 +1,37 @@
> > +####################################################################
> > ############
> > +#
> > +# rust-bootstrap
> > +#
> > +####################################################################
> > ############
> > +
> > +RUST_BOOTSTRAP_VERSION = 1.15.1
> > +RUST_BOOTSTRAP_DATE = 2017-02-09
> > +RUST_BOOTSTRAP_TRIPLE = $(RUST_BOOTSTRAP_ARCH)-unknown-linux-gnu
> > +RUST_BOOTSTRAP_LABEL = $(RUST_BOOTSTRAP_VERSION)-
> > $(RUST_BOOTSTRAP_TRIPLE)
> > +
> > +ifeq ($(HOSTARCH),x86_64)
> > +RUST_BOOTSTRAP_ARCH = x86_64
> > +else ifeq ($(HOSTARCH),x86)
> > +RUST_BOOTSTRAP_ARCH = i686
> > +endif
>
> Is there any necessity to limit the bootstrap compiler to those host
> archs only?

I've limited the bootstrap compiler to i686 and x86_64 as these
architectures are listed as tier 1 of the Rust platform support [1].

PowerPC is in tier 2. If some Buildroot users are using pre-2005 Macs,
I can add it.

[1] https://forge.rust-lang.org/platform-support.html
>
> > +RUST_BOOTSTRAP_SITE = https://static.rust-
> > lang.org/dist/$(RUST_BOOTSTRAP_DATE)
>
> Why use a date and not https://static.rust-lang.org/dist solely. Since
> I can fetch https://static.rust-lang.org/dist/rust-1.15.1-x86_64-unknow
> n-linux-gnu.tar.gz.

Good catch! This part is a leftover from the early versions of this
patch series when Rust compiler version N could not be bootstrapped from
version N-1 but an obscure nightly one. I'll change this.

>
> > +RUST_BOOTSTRAP_SOURCE = rustc-$(RUST_BOOTSTRAP_LABEL).tar.gz
> > +RUST_BOOTSTRAP_LICENSE = Apache-2.0 or MIT
> > +RUST_BOOTSTRAP_LICENSE_FILES = LICENSE-APACHE LICENSE-MIT
> > +RUST_BOOTSTRAP_LIBSTD_SOURCE= rust-std-
> > $(RUST_BOOTSTRAP_LABEL).tar.gz
> > +RUST_BOOTSTRAP_LIBSTD_ROOT = rust-std-$(RUST_BOOTSTRAP_LABEL)/rust-
> > std-$(RUST_BOOTSTRAP_TRIPLE)
>
> Why not make a seperate package?

I though about making it a separate package to clarify the Makefile, but
the library on its own is useless, so why expose it? This is just an
internal build dependency, like perl-cross in package/perl/perl.mk.

> > +RUST_BOOTSTRAP_EXTRA_DOWNLOADS =
> > $(RUST_BOOTSTRAP_SITE)/$(RUST_BOOTSTRAP_LIBSTD_SOURCE)
> > +
> > +define RUST_BOOTSTRAP_LIBSTD_EXTRACT
> > +	$(call suitable-extractor,$(RUST_BOOTSTRAP_LIBSTD_SOURCE)) \
> > +		$(DL_DIR)/$(RUST_BOOTSTRAP_LIBSTD_SOURCE) | \
> > +		$(TAR) --strip-components=2 -C $(@D)/rustc
> > $(TAR_OPTIONS) - \
> > +			$(RUST_BOOTSTRAP_LIBSTD_ROOT)/lib
> > +endef
> > +
> > +HOST_RUST_BOOTSTRAP_EXTRA_DOWNLOADS =
> > $(RUST_BOOTSTRAP_EXTRA_DOWNLOADS)
> > +HOST_RUST_BOOTSTRAP_POST_EXTRACT_HOOKS +=
> > RUST_BOOTSTRAP_LIBSTD_EXTRACT
> > +
> > +$(eval $(host-generic-package))
>
> J?rg

--
ELB

^ permalink raw reply

* [Bug 100593] corruption in total war warhammer when using mesa 17.1 - git
From: bugzilla-daemon @ 2017-04-08  9:19 UTC (permalink / raw)
  To: dri-devel
In-Reply-To: <bug-100593-502@http.bugs.freedesktop.org/>


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

https://bugs.freedesktop.org/show_bug.cgi?id=100593

tarpoon@gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #130714|0                           |1
        is obsolete|                            |

--- Comment #3 from tarpoon@gmx.de ---
Created attachment 130754
  --> https://bugs.freedesktop.org/attachment.cgi?id=130754&action=edit
Warhammer glitch padoka ppa after update on 2017-04-08

The padoka ppa was updated today

Changes:
mesa    1:17.1~git170407201100.c05cf9c~x~padoka0        Paulo Dias (9 hours
ago)
mesa    1:17.1~git170407201100.c05cf9c~y~padoka0        Paulo Dias (9 hours
ago)
libdrm  2.4.78+git1704072009.047aba1~x~padoka0  Paulo Dias (9 hours ago)
libdrm  2.4.78+git1704072009.047aba1~y~padoka0  Paulo Dias (9 hours ago) 

Now both padoka and oibaf show the same error.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2483 bytes --]

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

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

^ permalink raw reply


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.