I submitted a new set of patches as directed by Hans in which the variable name 'int_value' was kept. Thank you for replying back to me. Regards, Jorge Lopez On Tue, Aug 1, 2023 at 12:54 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > On Mon, Jul 31, 2023 at 11:35:35AM -0500, Jorge Lopez wrote: > > On Mon, Jul 31, 2023 at 11:16 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > > > On Mon, Jul 31, 2023 at 11:03:42AM -0500, Jorge Lopez wrote: > > > > On Thu, Jul 27, 2023 at 1:21 AM Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote: > > > > > 134 int value_len = 0; > > > > > 135 int ret; > > > > > 136 u32 size; > > > > > 137 u32 int_value = 0; > > > > > > > > > > It confused me that it's called int_value when it's not an int. Just > > > > > call it "u32 value = 0;". > > > > > > > > The variable is named int_value when it is not an int because it > > > > stores the value reported by ACPI_TYPE_INTEGER package. > > > > The variable will be renamed to type_int_value; > > > > > > Eep! That's even worse! Just leave it as-is then. > > > > Oops! just send a new patch using type_int_value. Should I change it back? > > In order of preference for me, it's "value", "int_value", and > "type_int_value". But it doesn't really matter. I feel there were a > couple bugs like the size vs value_len and re-using the iterator. You > have addressed the real problems so lets not worry about variable names. > Whatever you pick is fine. > > regards, > dan carpenter >
