[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <228f2d97-4816-bb37-f834-f9a2db59054a@linaro.org>
Date: Mon, 26 Sep 2022 23:33:01 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Nathan Chancellor <nathan@...nel.org>
Cc: rafael@...nel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, rui.zhang@...el.com,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Amit Kucheria <amitk@...nel.org>,
Antoine Tenart <atenart@...nel.org>
Subject: Re: [PATCH v5 29/30] thermal/intel/int340x: Replace parameter to
simplify
Hi Nathan,
On 26/09/2022 19:05, Nathan Chancellor wrote:
[ ... ]
>> + int34x_thermal_zone->ops = kmemdup(&int340x_thermal_zone_ops,
>> + sizeof(int340x_thermal_zone_ops), GFP_KERNEL);
>> + if (!int34x_thermal_zone->ops)
>> + goto err_ops_alloc;
>
> I assume I was cc'd on this change due to my fix up patch:
> https://lore.kernel.org/20220923152009.1721739-1-nathan@kernel.org/
Yes, right, thanks for sending the fix.
> However, I don't see that applied here. I don't mind it being squashed
> in to keep the build as clean as possible through bisects.
Ok, that makes sense, I will merge with the change it fixes
> Additionally, I did a diff of v4 to v5 to apply on top of next-20220923
> and I noticed there were a significant number of places where there was
> whitespace added where it probably should not have been.
Yeah, my git configuration does always trim the extra whitespaces when
applying so I usually don't pay attention to that, but thanks for
letting me know. I've probably something wrong with my emacs indentation
setup
> Other than
> that, v5 works on all the machines that had issues so thank you for the
> quick fix!
Thanks for testing
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists