[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAErSpo5-LAfmoddxT0W_TLryytbKpR694W9dv096=mKGJrL8rw@mail.gmail.com>
Date: Thu, 7 Feb 2019 11:29:59 -0600
From: Bjorn Helgaas <bhelgaas@...gle.com>
To: "Shah, Nehal-bakulchandra" <Nehal-bakulchandra.Shah@....com>
Cc: Wolfram Sang <wsa@...-dreams.de>,
Elie Morisse <syniurge@...il.com>,
linux-i2c <linux-i2c@...r.kernel.org>,
"S-k, Shyam-sundar" <Shyam-sundar.S-k@....com>,
"Singh, Sandeep" <Sandeep.Singh@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kai-Heng Feng <kai.heng.feng@...onical.com>,
Bjorn Helgaas <helgaas@...nel.org>
Subject: Re: [PATCH v15] i2c: Add drivers for the AMD PCIe MP2 I2C controller
On Thu, Feb 7, 2019 at 10:47 AM Shah, Nehal-bakulchandra
<Nehal-bakulchandra.Shah@....com> wrote:
>
>
> Hi Bjorn and Wolfram,
> On 2/7/2019 9:23 PM, Wolfram Sang wrote:
> > Hi Bjorn,
> >
> > thanks a lot for your additional information!
> >
> >> IMHO the split into two drivers is a bit of a mess and doesn't really
> >> correspond with the hardware, as I mentioned at [1]. The PCI device
> >> is the real hardware and the driver should claim that. AFAICT the
> >> ACPI device exists only to pass some config information to the PCI
> >> driver. I think the natural approach would be for the PCI driver to
> >> directly search the ACPI namespace for that config information.
> >
> > AFAIR the AMD folks insisted on the two driver setup because they need
> > it in the future? Maybe they can explain again here?
> >
> >> The fact that driver_find_device() is essentially unused except for a
> >> few very special cases is a good clue that there's probably a better
> >> way.
> >
> > Excactly this thinking made me recommend something else, too. Let's see
> > what we can come up with.
>
> First of really thanks for your valuable review. It may seem to be illogical to have two separate drivers, however as explained
> in past we are working on another solution for some upcoming thing. In that case we need MP2-PCI communication driver which will be reused.
> At this point of time i can't talk much about that but once solution is ready, we will be pushing that as well. Hence i sincerely requesting
> to have two separate driver.
This is not my area and my opinion is by no means definitive. But
FWIW, I don't think the argument that "a secret project will someday
require the ungainly design currently proposed" is worth very much.
Until we've seen the upcoming project, it's impossible to say whether
this two-driver design is the best approach for it. I'd say it's
quite likely that people might have alternate proposals.
Bjorn
Powered by blists - more mailing lists