[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxSOXFfVxL45egIr@black.fi.intel.com>
Date: Sun, 4 Sep 2022 14:39:08 +0300
From: Mika Westerberg <mika.westerberg@...ux.intel.com>
To: "Limonciello, Mario" <mario.limonciello@....com>
Cc: Szuying Chen <chensiying21@...il.com>, gregkh@...uxfoundation.org,
andreas.noever@...il.com, michael.jamet@...el.com,
YehezkelShB@...il.com, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, Yd_Tseng@...edia.com.tw,
Chloe_Chen@...edia.com.tw, Richard_Hsu@...edia.com.tw
Subject: Re: [PATCH v8 3/3] thunderbolt: To extend ASMedia NVM formats.
Hi Mario,
On Fri, Sep 02, 2022 at 08:32:41AM -0500, Limonciello, Mario wrote:
> On 9/2/2022 04:40, Szuying Chen wrote:
> > From: Szuying Chen <Chloe_Chen@...edia.com.tw>
> >
> > The patch add ASMedia NVM formats.
> >
> > Signed-off-by: Szuying Chen <Chloe_Chen@...edia.com.tw>
> > ---
> > v7->v8: Fix the no_nvm_upgrade bit setting on suggestion by Mika.
> >
> > drivers/thunderbolt/nvm.c | 40 +++++++++++++++++++++++++++++++++++++++
> > drivers/thunderbolt/tb.c | 2 +-
> > 2 files changed, 41 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thunderbolt/nvm.c b/drivers/thunderbolt/nvm.c
> > index 878d705bd0cb..8393d82dd108 100644
> > --- a/drivers/thunderbolt/nvm.c
> > +++ b/drivers/thunderbolt/nvm.c
> > @@ -12,9 +12,16 @@
> >
> > #include "tb.h"
> >
> > +/* ID of Router */
> > +#define ROUTER_VENDOR_ID_ASMEDIA 0x174c
> > +
> > /* Switch NVM support */
> > #define NVM_CSS 0x10
> >
> > +/* ASMedia specific NVM offsets */
> > +#define ASMEDIA_NVM_DATE 0x1c
> > +#define ASMEDIA_NVM_VERSION 0x28
> > +
> > static DEFINE_IDA(nvm_ida);
> >
> > /**
> > @@ -120,11 +127,43 @@ static int intel_nvm_validate(struct tb_switch *sw)
> > return 0;
> > }
> >
> > +static int asmedia_nvm_version(struct tb_switch *sw)
> > +{
> > + struct tb_nvm *nvm = sw->nvm;
> > + u32 val;
> > + int ret;
> > +
> > + /* ASMedia get version and date format is xxxxxx.xxxxxx */
> > + ret = nvm_read(sw, ASMEDIA_NVM_VERSION, &val, sizeof(val));
> > + if (ret)
> > + return ret;
> > +
> > + nvm->major = (((u8)val) << 0x10 | ((u8)(val >> 0x8)) << 0x8 | (u8)(val >> 0x10));
> > +
> > + ret = nvm_read(sw, ASMEDIA_NVM_DATE, &val, sizeof(val));
> > + if (ret)
> > + return ret;
> > +
> > + nvm->minor = (((u8)val) << 0x10 | ((u8)(val >> 0x8)) << 0x8 | (u8)(val >> 0x10));
> > +
> > + /*
> > + * Asmedia NVM size fixed on 512K. We currently have no plan
> > + * to increase size in the future.
> > + */
> > + nvm->nvm_size = SZ_512K;
>
> Any chance this can also be gleamed from your NVM? It would future proof
> the kernel code if you did come up with a need to change it in the future
> some day rather than hardcoding.
>
> > +
> > + return 0;
> > +}
> > +
> > static const struct tb_nvm_vendor_ops intel_switch_nvm_ops = {
> > .read_version = intel_nvm_version,
> > .validate = intel_nvm_validate,
> > };
> >
> > +static const struct tb_nvm_vendor_ops asmedia_switch_nvm_ops = {
> > + .read_version = asmedia_nvm_version,
>
> I recall an earlier version of your patch series was reading the customer ID
> as well. Would it make sense to have an `asmedia_nvm_validate` that checks
> this matches?
It seems the customer ID was the same 0x28 offset than the
ASMEDIA_NVM_VERSION so I guess it was just renamed.
>
> Or any other safety validation that the image is good the kernel might want
> to do? Checksum or signature or anything?
>
> Even if the hardware does all these verifications it's much easier to debug
> problems if the kernel can do a first line verification to tell you what is
> wrong with the image instead of trying to trace an error code from the
> hardware.
I agree.
Powered by blists - more mailing lists