linux-kernel - Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180615024138.oervj67t4zgt6icm@thebollingers.org>
Date:   Thu, 14 Jun 2018 19:41:38 -0700
From:   Don Bollinger <don@...bollingers.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        brandon_chuang@...e-core.com, wally_wang@...ton.com,
        roy_lee@...e-core.com, rick_burchett@...e-core.com,
        quentin.chang@...ntatw.com, jonathan.tsai@...ntatw.com,
        steven.noble@...switch.com, jeffrey.townsend@...switch.com,
        scotte@...ulusnetworks.com, roopa@...ulusnetworks.com,
        David Ahern <dsa@...ulusnetworks.com>,
        luke.williams@...onical.com, Guohan Lu <gulv@...rosoft.com>,
        Xin Liu <xinxliu@...rosoft.com>, steve.joiner@...isar.com
Subject: Re: [PATCH] optoe: driver to read/write SFP/QSFP EEPROMs

On Thu, Jun 14, 2018 at 09:46:36AM +0200, Arnd Bergmann wrote:
> On Thu, Jun 14, 2018 at 2:40 AM, Don Bollinger <don@...bollingers.org> wrote:
> > On Mon, Jun 11, 2018 at 03:43:02PM +0200, Arnd Bergmann wrote:
> >> On Mon, Jun 11, 2018 at 6:25 AM, Don Bollinger <don@...bollingers.org> wrote:
> 
> >>
> >> I don't understand this part: I see some older patches introducing an
> >> EEPROM_CLASS, but nothing ever seems to have made it into the
> >> mainline kernel.
> >>
> >> If that class isn't there, this code shouldn't be either. You can always
> >> add it back in case we decide to introduce that class later, but then
> >> I wouldn't make it a compile-time option but just a hard dependency
> >> instead.
> >
> > Thanks for the feedback.
> >
> > Some background will explain how optoe got here...
> 
> Ok, I see. For the upstream submission of course, none of the forked
> kernel code bases matter at all, what we want is a driver that makes
> sense by itself, and none of it should depend on any third party code.

Got it.

> For traditional devices, we would use a header in
> include/linux/platform_data/, but a more modern way of doing this
> would be to use named device properties that are either put
> in the devicetree file (on embedded machines) or added through
> the .properties field when statically declaring an i2c device from
> a PCI device parent.
> 
>       Arnd

Thanks for the guidance.  It turns out that getting into mainline makes
it easier for my partners to consume a header in
include/linux/platform_data.  I'll restore that file and remove all of the
unnecessary items, which should address the concerns you have raised.  

Rev 2 coming soon.

Don