linux-kernel - Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

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:   Fri, 01 Jun 2018 09:33:49 +1000
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Eddie James <eajames@...ux.vnet.ibm.com>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Wolfram Sang <wsa@...-dreams.de>,
        Rob Herring <robh+dt@...nel.org>,
        Joel Stanley <joel@....id.au>,
        Mark Rutland <mark.rutland@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v8 0/7] i2c: Add FSI-attached I2C master algorithm

On Thu, 2018-05-31 at 09:29 +0300, Andy Shevchenko wrote:
> > If you have specific issues with how this is done, please express them
> > clearly. It's quite possible that there's some better way to do what
> > Eddie is doing here, but without *construtive* feedback this is
> > pointless.
> 
> It feels like you duplicate approach which is done in OF generic case.
> That is my concern. Though, if Wolfram is telling that is OK, I have
> no objections.

THe OF generic case is about discovering slaves underneath a port, not
ports inside of a mulit-port master.

I am not aware of a generic mechanism for the latter. We *could* make
the ports sub-devices but it gets messy then to arbitrate the
communication and deal with the common part. I've seen (and written)
multi-port masters in the past that use a similar approach to what
Eddie's doing and it works fine.

> > I'm disappointed here because we have an example of somebody rather new
> > producing what is overall pretty damn good code,
> 
> That is true. His code much better than many I have seen before

Thanks. Also thanks for taking the time to review.

> > despite a few corner
> > issues, and being (again) treated like crap.
> 
> Sorry for that, life is harsh.
> 
> > This isn't the right way to operate, and I believe this has been made
> > clear many times before.
> 
> Yes.


Cheers,
Ben.