linux-kernel - Re: [PATCH] regmap: permit to set reg_update

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:   Mon, 18 Jul 2022 22:37:34 +0200
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, rafael@...nel.org,
        gregkh@...uxfoundation.org
Subject: Re: [PATCH] regmap: permit to set reg_update_bits with bulk
 implementation

On Mon, Jul 18, 2022 at 04:44:23PM +0200, Christian Marangi wrote:
> On Mon, Jul 18, 2022 at 03:42:06PM +0100, Mark Brown wrote:
> > On Mon, Jul 18, 2022 at 03:48:52PM +0200, Christian Marangi wrote:
> > 
> > > thanks, assuming everything went smooth with the merge to linux-next and
> > > no problems arise, can you provide a signed tag?
> > 
> > > This is needed for a net-next series that is currently in RFC state as
> > > it does depends on this.
> > 
> > > (I had this problem before and it was said that in this kind of
> > > situation I had to ask for a signed tag to merge the related patch in
> > > net-next branch)
> > 
> > Oh, it would have been good to know about this when reviewing the patch
> > rather than after the fact - since this hadn't been mentioned it's now
> > applied on the main development branch with everything that's going into
> > the next release rather than on a separate branch for easy merging
> > elsewhere.  How urgent is this, given that the merge window is likely to
> > open at the weekend so this'll get sent to Linus at that point - is the
> > driver otherwise near merging?
> 
> Ohh sorry, I was too generic in the patch comments and didn't mention it
> was an actual dependency.
> 
> It's not too urgent, (I assume) but it was said that it was preferrable
> to have the changes done in 2 weeks window (the one in net-next about
> the working driver). Will ask on net-next and give you news ASAP.
> 

Hi Mark,
sorry for the delay, I pointed out this problem with net-next and we
decided to adopt a workaround so this is not urgent anymore and we can
wait the merge window to have this change in net-next.

The required code will be updated later when this change is merged.

-- 
	Ansuel