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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 F2EA6C433C1 for ; Sat, 27 Mar 2021 12:41:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C6E58619E4 for ; Sat, 27 Mar 2021 12:41:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230259AbhC0MlB (ORCPT ); Sat, 27 Mar 2021 08:41:01 -0400 Received: from mail.kernel.org ([198.145.29.99]:57108 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229582AbhC0Mk7 (ORCPT ); Sat, 27 Mar 2021 08:40:59 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2E64A619C9; Sat, 27 Mar 2021 12:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1616848836; bh=3VV+CnI+qYEN6es0BwNT6G0L+Q81CDeO0DCIN1lsJoY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p8JnJotcN5reSX3u3jwu39BrFYw6UC2hIqpEx0c11GihYdHOV08mPJ/ouMPpYi8zV 31KiI4TjfmtaeILHLYgmewx7jvkMkelguau719vwaj6+y/ubZsmEhMgfpZfotoIT44 6csfU4qR2FgsJKzG6cp4gisl+S1zjiaIKt666YqI= Date: Sat, 27 Mar 2021 13:40:34 +0100 From: Greg KH To: Don Bollinger Cc: 'Andrew Lunn' , 'Jakub Kicinski' , arndb@arndb.de, linux-kernel@vger.kernel.org, brandon_chuang@edge-core.com, wally_wang@accton.com, aken_liu@edge-core.com, gulv@microsoft.com, jolevequ@microsoft.com, xinxliu@microsoft.com, 'netdev' , 'Moshe Shemesh' Subject: Re: [PATCH v2] eeprom/optoe: driver to read/write SFP/QSFP/CMIS EEPROMS Message-ID: References: <20210315103950.65fedf2c@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <001201d719c6$6ac826c0$40587440$@thebollingers.org> <009601d72023$b73dbde0$25b939a0$@thebollingers.org> <011301d7226f$dc2426f0$946c74d0$@thebollingers.org> <011901d7227c$e00015b0$a0004110$@thebollingers.org> <011c01d72284$544c8f50$fce5adf0$@thebollingers.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011c01d72284$544c8f50$fce5adf0$@thebollingers.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 26, 2021 at 02:09:36PM -0700, Don Bollinger wrote: > > You keep missing the point. I always refer to the KAPI. The driver we can > > rework and rework, throw away and reimplement, as much as we want. > > The KAPI cannot be changed, it is ABI. It is pretty much frozen the day > the > > code is first committed. > > Maybe I don't understand what you mean by KAPI. The KAPI that optoe exposes > is in two parts. > > First, it makes the EEPROM accessible via the nvmem() interface, an existing > KAPI that I call from optoe. at24 implemented it, I made use of it. This > interface exposes EEPROM data to user space through a defined sysfs() file. > I didn't invent this, nor am I proposing it, it already exists. Again, a "raw" interface to a device that is just memory-mapping all of the device information directly is no sort of a real KABI at all. It is no different from trying to use /dev/mem/ to write a networking driver, just because you can mmap in the device's configuration space to userspace. That is not a real api, it is only using the kernel as a "pass-through" which works fine for one-off devices, and other oddities, but is not a unified user/kernel api for a class of device types at all. thanks, greg k-h