Breno Leitao <lei...@debian.org> writes: > On Sat, Oct 21, 2017 at 11:58:47AM +1100, Michael Neuling wrote: >> On Fri, 2017-10-20 at 09:45 -0200, Breno Leitao wrote: >> > On Thu, Oct 12, 2017 at 09:17:16PM +1100, Michael Ellerman wrote: >> > > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c >> > > index f83056297441..d9bd6555f980 100644 >> > > --- a/arch/powerpc/kernel/prom.c >> > > +++ b/arch/powerpc/kernel/prom.c >> > > @@ -658,6 +658,35 @@ static void __init early_reserve_mem(void) >> > > #endif >> > > } >> > > >> > > +#ifdef CONFIG_PPC_TRANSACTIONAL_MEM >> > > +static bool tm_disabled __initdata; >> > >> > I think the name 'tm_disabled' might cause more confusion on the TM >> > code. Mainly because we already have tm_enable() and tm_enabled() >> > functions which are related to the MSR register and TM bit, and, with >> > your new variable, tm_enabled() and tm_disabled are not going to be >> > exclusionary. Neither tm_enable() with be able to toggle the tm_disabled >> > value.
I've merged it with that name, but I'm happy to take an incremental patch to give it a better name. >> Got a proposal for better names? > > That is the hardest part, but I thought about something as: > > * tm_disabled_on_boot Maybe. > * tm_off Nah. > * tm_explicit_disabled Maybe. > * tm_feature_disabled No that's not quite accurate. > * tm_enablement_disabled I refuse to use "enablement" ;) > I think these names, although a bit longer, might avoid the confusion > with tm_enable/tm_enabled nomenclature. tm_cmdline_disabled would be OK. Or tm_force_disable, or ... cheers
