linux-kernel - Re: [PATCH v4] i2c: i2c-qcom-geni: Parse Error correctly in i2c GSI mode

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: <Zh__kAdzU8a2DHLH@matsya>
Date: Wed, 17 Apr 2024 22:27:52 +0530
From: Vinod Koul <vkoul@...nel.org>
To: Andi Shyti <andi.shyti@...nel.org>
Cc: konrad.dybcio@...aro.org, andersson@...nel.org, wsa@...nel.org,
	linux-arm-msm@...r.kernel.org, dmaengine@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-i2c@...r.kernel.org,
	Mukesh Kumar Savaliya <quic_msavaliy@...cinc.com>,
	quic_vdadhani@...cinc.com,
	Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Subject: Re: [PATCH v4] i2c: i2c-qcom-geni: Parse Error correctly in i2c GSI
 mode

On 16-04-24, 17:05, Andi Shyti wrote:

> > > Anyway, the changes are in -next. What do we do now? Do I revert
> > > it? Mukesh, can you please agree with Vinod?
> > 
> > I dont apply patches to other subsystem without the ack. Either way you
> > can ask always! 
> 
> Yes, you are totally right; but please, keep in mind that this
> patch has some history and I would have loved to hear from you
> earlier. Anyway...

There was merge window, I dont look up during that. Then I had some
family stuff and travel to take care... Things happen.

When in doubt pls ask, a gentle reminder goes long way!

> 
> > I will leave it upto you...
> 
> ... Mukesh, I'm sorry, but I'm going to revert this patch again
> until we address all the last minute issues from Vinod. The
> silence on this thread is worrying me more than reverting it.
> 
> I hope this will be the last time I revert this patch.
> 
> Moreover, in order to avoid maintainers' rumble (:)), please
> let's try to split patches that are touching more than one
> subsystems keeping the logical meainings intact.

That is best. Very rarely we have a situation where we add
changes which break bisect and it has to be clubbed together. But for
other cases, it should always be split!

> I hope this is fine with you, Vinod.

Thank you for understanding

-- 
~Vinod