On Wed, Jul 1, 2020 at 2:56 PM Daniel Lezcano <daniel.lezc...@linaro.org> wrote: > > On 30/06/2020 13:47, Amit Kucheria wrote: > > On Thu, Jun 25, 2020 at 8:15 PM Daniel Lezcano > > <daniel.lezc...@linaro.org> wrote: > >> > >> In order to set the scene for the new generic netlink thermal > >> management and notifications, let remove the old dead code remaining > > > > s/management/management api/ > > > > s/let/let's/ > > > >> in the uapi headers. > >> > >> Signed-off-by: Daniel Lezcano <daniel.lezc...@linaro.org> > >> --- > >> include/linux/thermal.h | 5 ----- > >> include/uapi/linux/thermal.h | 12 +----------- > >> 2 files changed, 1 insertion(+), 16 deletions(-) > >> > >> diff --git a/include/linux/thermal.h b/include/linux/thermal.h > >> index faf7ad031e42..fc93a6348082 100644 > >> --- a/include/linux/thermal.h > >> +++ b/include/linux/thermal.h > >> @@ -302,11 +302,6 @@ struct thermal_zone_params { > >> int offset; > >> }; > >> > >> -struct thermal_genl_event { > >> - u32 orig; > >> - enum events event; > >> -}; > >> - > >> /** > >> * struct thermal_zone_of_device_ops - scallbacks for handling DT based > >> zones > >> * > >> diff --git a/include/uapi/linux/thermal.h b/include/uapi/linux/thermal.h > >> index 96218378dda8..22df67ed9e9c 100644 > >> --- a/include/uapi/linux/thermal.h > >> +++ b/include/uapi/linux/thermal.h > >> @@ -6,21 +6,12 @@ > >> > >> /* Adding event notification support elements */ > >> #define THERMAL_GENL_FAMILY_NAME "thermal_event" > >> -#define THERMAL_GENL_VERSION 0x01 > >> +#define THERMAL_GENL_VERSION 0x02 > > > > This hunk should be removed since you set version back to 1 in the > > next patch and we don't actually intend to bump the version yet. > > Well, I've been very strict here for git-bisecting. > > I move to V2 because of the removal, but when adding the new genetlink > code, the family name changed, so we returned back to the V1 as it is a > new genetlink thermal brand.
I don't understand the move to v2 for an empty skeleton UAPI. For the purposes of bisection, couldn't you just remove all the v1 UAPI (w/o bumping to v2) and then add a new UAPI in the next patch? > The name is change because it is no longer event based but also sampling > and commands. In this case, just to avoid any confusion, the new UAPI could be v2 making the transition clear in case of bisection. I'm afraid the v1->v2->v1 is a bit more confusing. /Amit