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

Powered by Openwall GNU/*/Linux Powered by OpenVZ