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]
Date:   Wed, 2 Feb 2022 16:10:05 -0600
From:   Corey Minyard <minyard@....org>
To:     "Verdun, Jean-Marie" <verdun@....com>
Cc:     "Hawkins, Nick" <nick.hawkins@....com>,
        Mark Rutland <mark.rutland@....com>,
        Wang Kefeng <wangkefeng.wang@...wei.com>,
        Vignesh Raghavendra <vigneshr@...com>,
        Sam Ravnborg <sam@...nborg.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Linus Walleij <linus.walleij@...aro.org>,
        Amit Kucheria <amitk@...nel.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Stanislav Jakubek <stano.jakubek@...il.com>,
        Hao Fang <fanghao11@...wei.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Richard Weinberger <richard@....at>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Russell King <linux@...linux.org.uk>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>,
        "openipmi-developer@...ts.sourceforge.net" 
        <openipmi-developer@...ts.sourceforge.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Guenter Roeck <linux@...ck-us.net>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-watchdog@...r.kernel.org" <linux-watchdog@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Anshuman Khandual <anshuman.khandual@....com>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "soc@...nel.org" <soc@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        Mark Brown <broonie@...nel.org>,
        Daniel Vetter <daniel@...ll.ch>, Marc Zyngier <maz@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [Openipmi-developer] [PATCH] HPE BMC GXP SUPPORT

On Wed, Feb 02, 2022 at 06:14:57PM +0000, Verdun, Jean-Marie wrote:
> > This is far too big for a single patch.  It needs to be broken into
> > functional chunks that can be reviewed individually.  Each driver and
> > each device tree change along with it's accompanying code need to be
> > done in individual patches.  The way it is it can't be reviewed in any
> > sane manner.
> 
> > -corey
> 
> Thanks for your feedback. We are getting a little bit lost here, as our plan was to submit initial
> 
> - bindings
> - dts for SoC and 1 board
> - initial platform init code
> 
> Then drivers code avoiding to send many dts updates which might complexify the review. We wanted to send all drivers code to relevant reviewers by tomorrow.
> 
> So, what you are asking ( do not worry I am not trying to negotiate, I just want to avoid English misunderstandings as I am French) is to send per driver
> 
> - binding
> - dts update
> - driver code
> 
> For each driver through different submission (with each of them containing the 3 associated parts) ?

Arnd gave an excellent explaination for this.

To be clear, you need to split out changes to individual subsystems and
submit those to the maintainers for that subsystem and not send them to
everyone.  That way you reduce sending emails to people who don't need
to see them.

Once you have a set of patches for a subsystem, you can submit them as one
set.  That is generally preferred.  The "git send-email" or "git
format-patch" tools are generally what we use, they let you compose a
header message where you can give an overall explaination, then it sends
the individual changes as followup messages to the header message.

-corey

> 
> What shall be the initial one in our case as we are introducing a platform ? An empty dts infrastructure and then we make it grow one step at a time ?
> 
> vejmarie
> 
> 
>  
> 
> 
> _______________________________________________
> Openipmi-developer mailing list
> Openipmi-developer@...ts.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ