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