On Thu, Jun 14, 2018 at 09:46:36AM +0200, Arnd Bergmann wrote: > On Thu, Jun 14, 2018 at 2:40 AM, Don Bollinger <d...@thebollingers.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 <d...@thebollingers.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
