[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <184c95fc476146939b240557e54ee2c9@AUSX13MPC105.AMER.DELL.COM>
Date: Tue, 1 Oct 2019 17:05:09 +0000
From: <Mario.Limonciello@...l.com>
To: <mika.westerberg@...ux.intel.com>, <linux-usb@...r.kernel.org>
CC: <andreas.noever@...il.com>, <michael.jamet@...el.com>,
<YehezkelShB@...il.com>, <rajmohan.mani@...el.com>,
<nicholas.johnson-opensource@...look.com.au>, <lukas@...ner.de>,
<gregkh@...uxfoundation.org>, <stern@...land.harvard.edu>,
<anthony.wong@...onical.com>, <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 17/22] thunderbolt: Add initial support for USB4
> @@ -322,9 +398,21 @@ static int tb_switch_nvm_add(struct tb_switch *sw)
> u32 val;
> int ret;
>
> - if (!sw->dma_port)
> + if (!nvm_readable(sw))
> return 0;
>
> + /*
> + * The NVM format of non-Intel hardware is not known so
> + * currently restrict NVM upgrade for Intel hardware. We may
> + * relax this in the future when we learn other NVM formats.
> + */
> + if (sw->config.vendor_id != PCI_VENDOR_ID_INTEL) {
> + dev_info(&sw->dev,
> + "NVM format of vendor %#x is not known, disabling NVM
> upgrade\n",
> + sw->config.vendor_id);
> + return 0;
> + }
> +
Don't you actually have an attribute you can use here for this exact purpose that you
could be setting rather than returning immediately?
sw->no_nvm_upgrade
Then potentially you can at least let users "dump out" the nvm on !Intel but don't let
it be written until ready to relax further.
> nvm = kzalloc(sizeof(*nvm), GFP_KERNEL);
> if (!nvm)
> return -ENOMEM;
Powered by blists - more mailing lists