linux-kernel - RE: [PATCH v2 0/9] i2c-mlxbf.c: bug fixes and new feature support

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]

Date:   Mon, 29 Aug 2022 20:46:05 +0000
From:   Asmaa Mnebhi <asmaa@...dia.com>
To:     Wolfram Sang <wsa+renesas@...g-engineering.com>
CC:     "robh@...nel.org" <robh@...nel.org>,
        "linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 0/9] i2c-mlxbf.c: bug fixes and new feature support

> This is a series of patches fixing several bugs and implementing new 
> features.

What did change since v1 and where did Khalil's Rev-by tags go?

Khalil told me to remove the rev-by : ) since it is supposed to be reserved for the reviewers. I will add it back and describe what has changed in my next set of patches. As a note , this is what changed from v1->v2:
1) moved all the bug fixes to the top commits and left the features for last 
2) split the BlueField-3 SoC patch into 2 to address Rob's comment: one for the driver code and another patch for the device tree binding yaml documentation file
3) addressed  Rob's comment regarding keeping the device tree/acpi tables backward compatible. So add the new resources at the end of the enum.
4) update the license in a separate patch

> Bug fixes:
> 1) Fix the frequency calculation
> 2) remove unnecessary IRQF_ONESHOT flag

Is this really a bugfix?

This is not a bug fix. We removed it because it is no longer needed.

> 3) Fix incorrect base address passed during io write
> 4) prevent stack overflow in mlxbf_i2c_smbus_start_transaction()
> 5) Support lock mechanism

Here, I am also not sure if this is a bugfix.

I think this is a bug fix because we have an i2c driver also in UEFI so we need this lock mechanism to avoid race conditions over acquiring the i2c bus. Not using this lock resulted in unexpected behavior.

Thanks for the update,

   Wolfram