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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181018221048.GA6364@amd>
Date:   Fri, 19 Oct 2018 00:10:48 +0200
From:   Pavel Machek <pavel@....cz>
To:     Dan Murphy <dmurphy@...com>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Rob Herring <robh@...nel.org>,
        Lee Jones <lee.jones@...aro.org>,
        Tony Lindgren <tony@...mide.com>, devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>
Subject: Re: [PATCH v3 2/9] dt-bindings: ti-lmu: Remove LM3697

Hi!

> >>>> Given this one seems to have not really been finished, it's probably
> >>>> okay to make changes in this case. Still, it would be good to see
> >>>> patches structured so that it's obvious we're breaking things. But how
> >>>> the patches are structured doesn't matter until there's some agreement
> >>>> on the end result.
> >>>
> >>> OK, so if I'm getting it right, the correct patch structure in this case
> >>> means that changes removing bindings from MFD and moving them along
> >>> with the modifications to the LED subsystem should be placed in a single
> >>> patch.
> >>>
> >>> Dan, could you please arrange the next patch set version accordingly?
> >>
> >> Yes I can squash the DT bindings patches and call it a "move and modify"
> > 
> > You can do move without problems. But if you plan to modify them,
> > please try to change as little as possible, make it separate patch and
> > explain why new version is better than old one.
> > 
> 
> I have been thinking of how to do this.  Since the 2 devices are part of the current
> binding there really is not a way to move them.  Since there are still MFD capable
> devices available.
> 
> I would still need to remove the current active binding and create a new binding in the LED
> bindings directory.
> 
> I would have to remove and create in the same patch.

Yeah, and this all is a sign that you should just keep the current
binding, and make your code use it, see?

You are free to use Sebastian's updated binding. It has "suggested by:
Rob" or something like that on it, so it should be fine.

You can add note to bindings/leds pointing to mfd binding.

Now... this is what I've suggested before. If you don't agree, you may
want to contact Tony Lindgren, IIRC he works for TI, too, and might be
willing to help.

Thank you,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ