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] [thread-next>] [day] [month] [year] [list]
Message-ID: <8737brn83n.fsf@intel.com>
Date:   Fri, 26 May 2017 14:57:48 +0300
From:   Jani Nikula <jani.nikula@...ux.intel.com>
To:     Wolfram Sang <wsa@...-dreams.de>, linux-i2c@...r.kernel.org
Cc:     Jean Delvare <jdelvare@...e.de>, linux-acpi@...r.kernel.org,
        Wolfram Sang <wsa@...-dreams.de>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org
Subject: Re: [PATCH 0/8] i2c: refactor core and break out blocks

On Fri, 26 May 2017, Wolfram Sang <wsa@...-dreams.de> wrote:
> Yes, I wanted to do this for years now... The I2C core became a huge monolithic
> blob getting harder and harder to maintain. This series breaks out some
> functional parts into seperate files. This makes the code easier to handle
> because of the smaller chunks. It reduces ifdeffery because we can now handle
> compilation at the Makefile level. And it helps to spread responsibility, e.g.
> the ACPI maintainers do now have a dedicated file listed in MAINTAINERS.
>
> This series was tested with a Renesas Lager board (R-Car H2 SoC). It booted
> normally and all device drivers for I2C clients seem to work normally. I wired
> two I2C busses together and used i2c-slave-eeprom to let one I2C IP core read
> out data from the other. That all worked fine. Buildbot is also happy, it found
> two issues of the first (non public) iteration. Thanks!
>
> I did not test ACPI and hope for some assistance here :) I'd also be happy if
> people could check the includes of the newly created files, there might be
> missing some.

If you don't mind sending the whole series to the intel-gfx list (Cc'd),
our CI will run a bunch of tests on it, exercising our use of the I2C
adapter interfaces for display data channel and I2C over Display Port
native aux.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ