[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5a57cad-7311-4075-8b6e-04f22ed510f7@gmail.com>
Date: Thu, 24 Oct 2024 20:39:57 +0200
From: Javier Carrasco <javier.carrasco.cruz@...il.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Greg KH <greg@...ah.com>,
Arnd Bergmann <arnd@...db.de>, Jonathan Cameron
<Jonathan.Cameron@...wei.com>,
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 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.
Best regards,
Javier Carrasco
Powered by blists - more mailing lists