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] [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

Powered by Openwall GNU/*/Linux Powered by OpenVZ