From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F2E1C3713C for ; Mon, 21 Jan 2019 22:33:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 032DE20870 for ; Mon, 21 Jan 2019 22:33:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="v5xANY24" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727803AbfAUWdt (ORCPT ); Mon, 21 Jan 2019 17:33:49 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:50986 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727153AbfAUWds (ORCPT ); Mon, 21 Jan 2019 17:33:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=W92yPzynIzOntPRJ8bjFbqcKd3NCMhbp3icl5lb+u9E=; b=v5xANY240aMk5Mik/F5DCQJo1H2fRHgGpy+G3VnLuzx1tJJoRBt+WXHR+VseTghe5QUOEOohD7U6sXrwFfC7nz+PZtNlbSRT8vUzrsQeMVfrO1ApWsqykFI/qm6YFGwvhnz1VjnYKCnvOXc2/QDmywghIFznAs0qCCJZO4QQYOY=; Received: from andrew by vps0.lunn.ch with local (Exim 4.84_2) (envelope-from ) id 1gli8X-00068m-OB; Mon, 21 Jan 2019 23:33:45 +0100 Date: Mon, 21 Jan 2019 23:33:45 +0100 From: Andrew Lunn To: Bryan.Whitehead@microchip.com Cc: davem@davemloft.net, netdev@vger.kernel.org, UNGLinuxDriver@microchip.com Subject: Re: [PATCH v1 net-next] lan743x: Provide Read/Write Access to on chip OTP Message-ID: <20190121223345.GA23208@lunn.ch> References: <1547848493-16985-1-git-send-email-Bryan.Whitehead@microchip.com> <20190121182630.GB16212@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > 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. Andrew