From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752385AbdE0QDd (ORCPT <rfc822;w@1wt.eu>);
        Sat, 27 May 2017 12:03:33 -0400
Received: from mail-qk0-f180.google.com ([209.85.220.180]:36594 "EHLO
        mail-qk0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752294AbdE0QDb (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 27 May 2017 12:03:31 -0400
MIME-Version: 1.0
In-Reply-To: <20170526160936.54265-22-mika.westerberg@linux.intel.com>
References: <20170526160936.54265-1-mika.westerberg@linux.intel.com> <20170526160936.54265-22-mika.westerberg@linux.intel.com>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sat, 27 May 2017 19:03:30 +0300
Message-ID: <CAHp75Veby_6j=XjrQTkHyuPcqA4qUyaucq5jAcCQAXTbau90Sg@mail.gmail.com>
Subject: Re: [PATCH v2 21/27] thunderbolt: Store Thunderbolt generation in the
 switch structure
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Andreas Noever <andreas.noever@gmail.com>,
        Michael Jamet <michael.jamet@intel.com>,
        Yehezkel Bernat <yehezkel.bernat@intel.com>,
        Lukas Wunner <lukas@wunner.de>, Amir Levy <amir.jer.levy@intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Mario Limonciello <Mario.Limonciello@dell.com>,
        Jared.Dominguez@dell.com,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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