linux-kernel - Re: linux-next: manual merge of the char-misc tree with the iio-fixes tree

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]

Message-ID: <20241025170855.00001f0a@Huawei.com>
Date: Fri, 25 Oct 2024 17:08:55 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>
CC: Jonathan Cameron <jic23@...nel.org>, Stephen Rothwell
	<sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>, Arnd Bergmann
	<arnd@...db.de>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>,
	<linux-iio@...r.kernel.org>
Subject: Re: linux-next: manual merge of the char-misc tree with the
 iio-fixes tree

On Thu, 24 Oct 2024 20:39:57 +0200
Javier Carrasco <javier.carrasco.cruz@...il.com> wrote:

> On 24/10/2024 19:41, Jonathan Cameron wrote:
> > On Wed, 23 Oct 2024 20:17:30 +0200
> > Javier Carrasco <javier.carrasco.cruz@...il.com> wrote:
> >   
> >> On 23/10/2024 05:10, Stephen Rothwell wrote:  
> >>> Hi all,
> >>>
> >>> Today's linux-next merge of the char-misc tree got a conflict in:
> >>>
> >>>   drivers/iio/light/veml6030.c
> >>>
> >>> between commit:
> >>>
> >>>   de9981636774 ("iio: light: veml6030: fix microlux value calculation")
> >>>
> >>> from the iio-fixes tree and commit:
> >>>
> >>>   ed59fc90f38a ("iio: light: veml6030: drop processed info for white channel")
> >>>
> >>> from the char-misc tree.
> >>>
> >>> I fixed it up (the latter removed the line updated by the former) and
> >>> can carry the fix as necessary. This is now fixed as far as linux-next
> >>> is concerned, but any non trivial conflicts should be mentioned to your
> >>> upstream maintainer when your tree is submitted for merging.  You may
> >>> also want to consider cooperating with the maintainer of the conflicting
> >>> tree to minimise any particularly complex conflicts.
> >>>     
> >>
> >>
> >> Hi Stephen,
> >>
> >> I doubled checked the status of the driver in linux-next, and everything
> >> looks as it should: the first commit applied as a single chunk, as its
> >> second chunk affects lines that the second commit removed.
> >>
> >> Thank you for fixing it up.  
> > 
> > Not quite. This was a lucky merge issue as it highlighted something I'd
> > messed up.
> > 
> > A rare case of a fuzzy application of a patch picking the wrong block but still
> > giving a very plausible looking diff that fooled me.
> > 
> > I picked up the fix via a different tree from where you expected.
> > In char-misc-next / iio/togreg there is only one instance of this code block because
> > the larger driver rework removed one of the two that was in the tree that
> > iio-fixes is based on (effectively mainline).
> > 
> > The fix got applied to the one that is going away (which is going away because
> > the scale makes no sense on the intensity channel) not the illuminance / IIO_LIGHT
> > channel that was intended.
> > 
> > I've move it to the right block with the side effect that the merge conflict
> > should go away.  Javier, please check iio.git/fixes-togreg to be 100% sure
> > I haven't messed it up again.
> > 
> > Thanks Stephen for your hard work on linux-next!
> > 
> > Jonathan
> >   
> >>
> >> Best regards,
> >> Javier Carrasco  
> >   
> 
> What I see in iio.git/fixes-togreg is right in the sense that the fix
> fro the processed value (commit 63dd163cd61dd) is only applied to the
> processed value of the IIO_LIGHT channel, and not to IIO_INTENSITY.
> 
> The processed value of the IIO_INTENSITY channel should be then dropped
> at some point with the other patch, as it has already been done in
> linux-next/master.
> 
Yes. We may want to separately chase back dropping the processed
IIO_INTENSITY later given the issues that are left there.
Once the change is upstream, I'd be fine with that as a backported
fix.

Jonathan

> Best regards,
> Javier Carrasco