netdev - RE: [PATCH v1 net-next] lan743x: Provide Read/Write Access to on chip OTP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 22 Jan 2019 19:21:13 +0000
From:   <Bryan.Whitehead@...rochip.com>
To:     <andrew@...n.ch>
CC:     <davem@...emloft.net>, <netdev@...r.kernel.org>,
        <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH v1 net-next] lan743x: Provide Read/Write Access to on chip
 OTP

> > > This is breaking backwards compatibility. I think you need to
> > > respect the magic value, independent of how adapter->flags.
> >
> > Is backwards compatibility a requirement?
> 
> Hi Bryan
> 
> You should not change the ABI. And this is an ABI. So yes, backwards
> compatibility should be maintained. Maybe there is a manufacturer out there
> that has a script in their factory programming MAC addresses into their
> devices using the current API. This change is going to break their system. You
> really should be trying to avoid that.
> 
> > If so, this only breaks OTP backward compatibility, which was
> > extremely restrictive and ultimately not very useful.
> 
> Was it sufficiently useful to actually program something into the OTP to make
> the hardware work? If yes, somebody is probably using it. Or is there some
> other way you expect a manufacturer to be programming the OTP? Do you
> tell them the current API is horribly broken, don't use it, always use JTAG?
> 
> You also need to think about the new ABI you are putting into place. Is it
> really what you want? You cannot change it afterwards. You need to support
> this forever.
> 
Hi Andrew,

Maybe it will help to provide you a little more background on our reasons for
doing this change.
First this product is very new. It only just went into production last December (2018).
And we recently received a support request regarding how to program the OTP. 
Unfortunately our interface was too restrictive for their needs. Which is why
we need to change it. 
So at this stage, before demand ramps up, we believe this change to the ABI is
worth it, since most customers who try to use OTP as is, will likely generate
more support requests, which we would naturally like to avoid.
I've spoken with the architect on the project and he agrees this new ABI is the
one we want going forward.
We apologize for needing to change the ABI, but we are prepared to support
the few early customers in their transition to the new ABI.
We hope you understand.

Regards,
Bryan