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

[Jonathan Cameron <Jonathan.Cameron@Huawei.com>]

On Thu, 24 Oct 2024 20:39:57 +0200
Javier Carrasco <javier.carrasco.cruz@gmail.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@gmail.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