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: <CH2PR12MB38951B9B8F189E1B991A7950D7769@CH2PR12MB3895.namprd12.prod.outlook.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ