Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1651498 > unrolled thread

[PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure

Started byMika Westerberg <mika.westerberg@linux.intel.com>
First post2017-05-26 18:20 +0200
Last post2017-05-27 18:10 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure Mika Westerberg <mika.westerberg@linux.intel.com> - 2017-05-26 18:20 +0200
    Re: [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the  switch structure Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-05-27 18:10 +0200

#1651498 — [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure

FromMika Westerberg <mika.westerberg@linux.intel.com>
Date2017-05-26 18:20 +0200
Subject[PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure
Message-ID<tLq84-87A-75@gated-at.bofh.it>
In some cases it is useful to know what is the Thunderbolt generation
the switch supports. This introduces a new field to struct switch that
stores the generation of the switch based on the device ID. Unknown
switches (there should be none) are assumed to be first generation to be
on the safe side.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Yehezkel Bernat <yehezkel.bernat@intel.com>
Reviewed-by: Michael Jamet <michael.jamet@intel.com>
---
 drivers/thunderbolt/switch.c | 50 +++++++++++++++++++++++++++++---------------
 drivers/thunderbolt/tb.h     |  2 ++
 2 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/drivers/thunderbolt/switch.c b/drivers/thunderbolt/switch.c
index 73e4752580f6..79afa1eb5f4a 100644
--- a/drivers/thunderbolt/switch.c
+++ b/drivers/thunderbolt/switch.c
@@ -390,6 +390,37 @@ struct device_type tb_switch_type = {
 	.release = tb_switch_release,
 };
 
+static int tb_switch_get_generation(struct tb_switch *sw)
+{
+	switch (sw->config.device_id) {
+	default:
+		tb_sw_warn(sw, "unsupported switch device id %#x\n",
+			   sw->config.device_id);
+		/* Fall through */
+	case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
+	case PCI_DEVICE_ID_INTEL_EAGLE_RIDGE:
+	case PCI_DEVICE_ID_INTEL_LIGHT_PEAK:
+	case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_2C:
+	case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
+	case PCI_DEVICE_ID_INTEL_PORT_RIDGE:
+	case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_2C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_4C_BRIDGE:
+		return 1;
+
+	case PCI_DEVICE_ID_INTEL_WIN_RIDGE_2C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE:
+		return 2;
+
+	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_LP_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_2C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_2C_BRIDGE:
+	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_4C_BRIDGE:
+		return 3;
+	}
+}
+
 /**
  * tb_switch_alloc() - allocate a switch
  * @tb: Pointer to the owning domain
@@ -443,6 +474,8 @@ struct tb_switch *tb_switch_alloc(struct tb *tb, struct device *parent,
 		sw->ports[i].port = i;
 	}
 
+	sw->generation = tb_switch_get_generation(sw);
+
 	cap = tb_switch_find_vsec_cap(sw, TB_VSEC_CAP_PLUG_EVENTS);
 	if (cap < 0) {
 		tb_sw_warn(sw, "cannot find TB_VSEC_CAP_PLUG_EVENTS aborting\n");
@@ -491,23 +524,6 @@ int tb_switch_configure(struct tb_switch *sw)
 		tb_sw_warn(sw, "unknown switch vendor id %#x\n",
 			   sw->config.vendor_id);
 
-	switch (sw->config.device_id) {
-	case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
-	case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
-	case PCI_DEVICE_ID_INTEL_PORT_RIDGE:
-	case PCI_DEVICE_ID_INTEL_FALCON_RIDGE_2C_BRIDGE:
-	case PCI_DEVICE_ID_INTEL_FALCON_RIDGE_4C_BRIDGE:
-	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_2C_BRIDGE:
-	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_4C_BRIDGE:
-	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_2C_BRIDGE:
-	case PCI_DEVICE_ID_INTEL_ALPINE_RIDGE_C_4C_BRIDGE:
-		break;
-
-	default:
-		tb_sw_warn(sw, "unsupported switch device id %#x\n",
-			   sw->config.device_id);
-	}
-
 	sw->config.enabled = 1;
 
 	/* upload configuration */
diff --git a/drivers/thunderbolt/tb.h b/drivers/thunderbolt/tb.h
index 0be989069941..b3cda7605619 100644
--- a/drivers/thunderbolt/tb.h
+++ b/drivers/thunderbolt/tb.h
@@ -25,6 +25,7 @@
  * @device: Device ID of the switch
  * @vendor_name: Name of the vendor (or %NULL if not known)
  * @device_name: Name of the device (or %NULL if not known)
+ * @generation: Switch Thunderbolt generation
  * @cap_plug_events: Offset to the plug events capability (%0 if not found)
  * @is_unplugged: The switch is going away
  * @drom: DROM of the switch (%NULL if not found)
@@ -40,6 +41,7 @@ struct tb_switch {
 	u16 device;
 	const char *vendor_name;
 	const char *device_name;
+	unsigned int generation;
 	int cap_plug_events;
 	bool is_unplugged;
 	u8 *drom;
-- 
2.11.0

[toc] | [next] | [standalone]


#1651911 — Re: [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-05-27 18:10 +0200
SubjectRe: [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the switch structure
Message-ID<tLMrU-6fP-39@gated-at.bofh.it>
In reply to#1651498
On Fri, May 26, 2017 at 7:09 PM, Mika Westerberg
<mika.westerberg@linux.intel.com> wrote:
> In some cases it is useful to know what is the Thunderbolt generation
> the switch supports. This introduces a new field to struct switch that
> stores the generation of the switch based on the device ID. Unknown
> switches (there should be none) are assumed to be first generation to be
> on the safe side.

> +       default:
> +               tb_sw_warn(sw, "unsupported switch device id %#x\n",
> +                          sw->config.device_id);

> +               /* Fall through */

I would rather be explicit here. And perhaps even mention in the
message we are falling back to 1.

> +       case PCI_DEVICE_ID_INTEL_LIGHT_RIDGE:
> +       case PCI_DEVICE_ID_INTEL_EAGLE_RIDGE:
> +       case PCI_DEVICE_ID_INTEL_LIGHT_PEAK:
> +       case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_2C:
> +       case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
> +       case PCI_DEVICE_ID_INTEL_PORT_RIDGE:
> +       case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_2C_BRIDGE:
> +       case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_4C_BRIDGE:
> +               return 1;

Other than that
FWIW:
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web