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  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]
Date:   Wed, 8 Aug 2018 18:27:25 +0200
From:   Bartosz Golaszewski <>
To:     Wolfram Sang <>
Cc:     Bartosz Golaszewski <>,
        Jonathan Corbet <>, Sekhar Nori <>,
        Kevin Hilman <>,
        Russell King <>,
        Arnd Bergmann <>,
        Greg Kroah-Hartman <>,
        David Woodhouse <>,
        Brian Norris <>,
        Boris Brezillon <>,
        Marek Vasut <>,
        Richard Weinberger <>,
        Grygorii Strashko <>,
        "David S . Miller" <>,
        Srinivas Kandagatla <>,
        Naren <>,
        Mauro Carvalho Chehab <>,
        Andrew Morton <>,
        Lukas Wunner <>,
        Dan Carpenter <>,
        Florian Fainelli <>,
        Ivan Khoronzhuk <>,
        Sven Van Asbroeck <>,
        Paolo Abeni <>, Alban Bedel <>,
        Rob Herring <>,
        David Lechner <>,
        Andrew Lunn <>,
        linux-doc <>,
        LKML <>,
        arm-soc <>,
        linux-i2c <>,,
        Linux-OMAP <>,
Subject: Re: [PATCH 00/28] at24: remove at24_platform_data

2018-08-08 17:55 GMT+02:00 Wolfram Sang <>:
> On Wed, Aug 08, 2018 at 05:31:22PM +0200, Bartosz Golaszewski wrote:
>> From: Bartosz Golaszewski <>
>> This is a follow-up to the previously rejected series[1] which partially
>> removed the at24_platform_data structure. After further development and
>> taking reviews into account, this series finally removes that struct
>> completely but not without touching many different parts of the code
>> base.
>> Since I took over maintainership of the at24 driver I've been working
>> towards removing at24_platform_data in favor for device properties.
> Wooha, nice work. I can't really comment on it but wondered how you want
> to upstream it (after reviews)? Pull request of an immutable branch for
> nvmem-tree sounds best to me. Then I could also pull it in if i2c needs
> it. Probably same situation for arm-soc...

I initially wanted to merge small parts of it starting with v4.18, but
there were some voices against merging APIs without users. I'm not
sure how it should go in. There'll be a need for multiple immutable
branches most probably...


Powered by blists - more mailing lists