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

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

[Jonathan Cameron]

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

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

[Javier Carrasco]

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.

Best regards,
Javier Carrasco

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

[Jonathan Cameron]

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