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

[Don Bollinger]

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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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