All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thymo van Beers <thymovanbeers@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] docs: kernel-parameters.txt: Fix whitespace
Date: Wed, 18 Apr 2018 20:16:37 +0200	[thread overview]
Message-ID: <20180418181635.GA24031@thinkpad> (raw)
In-Reply-To: <31612fbd-6624-140a-ed92-04b8f0bd5f64@infradead.org>

On Mon, Apr 16, 2018 at 03:03:47PM -0700, Randy Dunlap wrote:
> On 04/16/18 14:49, Thymo van Beers wrote:
> > Some lines used spaces instead of tabs at line start.
> > This can cause mangled lines in editors due to inconsistency.
> > 
> > Replace spaces for tabs where appropriate.
> > 
> > Signed-off-by: Thymo van Beers <thymovanbeers@gmail.com>
> > ---
> > Changes in v2:
> >   - Rebase against docs-next
> >   - Fix indentation modifications
> > 
> >  Documentation/admin-guide/kernel-parameters.txt | 136 ++++++++++++------------
> >  1 file changed, 68 insertions(+), 68 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 3487be79847c..f625f65c286f 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> 
> Most of the patch is OK IMO, but not the intel_pstate part:
> The 2-space extra indents work fine here, while the extra tab makes a lot of the
> lines go beyond the 80-column mark.
> 
> > @@ -1650,39 +1650,39 @@
> >  			0	disables intel_idle and fall back on acpi_idle.
> >  			1 to 9	specify maximum depth of C-state.
> >  
> > -	intel_pstate=  [X86]
> > -		       disable
> > -		         Do not enable intel_pstate as the default
> > -		         scaling driver for the supported processors
> > -		       passive
> > -			 Use intel_pstate as a scaling driver, but configure it
> > -			 to work with generic cpufreq governors (instead of
> > -			 enabling its internal governor).  This mode cannot be
> > -			 used along with the hardware-managed P-states (HWP)
> > -			 feature.
> > -		       force
> > -			 Enable intel_pstate on systems that prohibit it by default
> > -			 in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > -			 instead of acpi-cpufreq may disable platform features, such
> > -			 as thermal controls and power capping, that rely on ACPI
> > -			 P-States information being indicated to OSPM and therefore
> > -			 should be used with caution. This option does not work with
> > -			 processors that aren't supported by the intel_pstate driver
> > -			 or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > -		       no_hwp
> > -		         Do not enable hardware P state control (HWP)
> > -			 if available.
> > -		hwp_only
> > -			Only load intel_pstate on systems which support
> > -			hardware P state control (HWP) if available.
> > -		support_acpi_ppc
> > -			Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > -			Description Table, specifies preferred power management
> > -			profile as "Enterprise Server" or "Performance Server",
> > -			then this feature is turned on by default.
> > -		per_cpu_perf_limits
> > -			Allow per-logical-CPU P-State performance control limits using
> > -			cpufreq sysfs interface
> > +	intel_pstate=	[X86]
> > +			disable
> > +				Do not enable intel_pstate as the default
> > +				scaling driver for the supported processors
> > +			passive
> > +				Use intel_pstate as a scaling driver, but configure it
> > +				to work with generic cpufreq governors (instead of
> > +				enabling its internal governor).  This mode cannot be
> > +				used along with the hardware-managed P-states (HWP)
> > +				feature.
> > +			force
> > +				Enable intel_pstate on systems that prohibit it by default
> > +				in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > +				instead of acpi-cpufreq may disable platform features, such
> > +				as thermal controls and power capping, that rely on ACPI
> > +				P-States information being indicated to OSPM and therefore
> > +				should be used with caution. This option does not work with
> > +				processors that aren't supported by the intel_pstate driver
> > +				or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > +			no_hwp
> > +				Do not enable hardware P state control (HWP)
> > +				if available.
> > +			hwp_only
> > +				Only load intel_pstate on systems which support
> > +				hardware P state control (HWP) if available.
> > +			support_acpi_ppc
> > +				Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > +				Description Table, specifies preferred power management
> > +				profile as "Enterprise Server" or "Performance Server",
> > +				then this feature is turned on by default.
> > +			per_cpu_perf_limits
> > +				Allow per-logical-CPU P-State performance control limits using
> > +				cpufreq sysfs interface
> >  
> >  	intremap=	[X86-64, Intel-IOMMU]
> >  			on	enable Interrupt Remapping (default)
> > @@ -2027,7 +2027,7 @@
> >  			* [no]ncqtrim: Turn off queued DSM TRIM.
> >  
> >  			* nohrst, nosrst, norst: suppress hard, soft
> > -                          and both resets.
> > +			and both resets.
> 
> I would leave that line above indented like the one after "rstonce" below.
> 
> >  
> >  			* rstonce: only attempt one reset during
> >  			  hot-unplug link recovery
> 
> 
> -- 
> ~Randy

Okay, thanks for your feedback.

I reindented intel_pstate as you said and I can still see the whole
description for the 'advanced' option is going past the 80-column mark.

I'll leave it indented with two spaces for this patch.
If you wish I can make a separate patch that addresses 80-column overrun
for intel_pstate.

I'll indent the nohrst,... section like rstonce.

Does that sound good to you?

-Thymo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Thymo van Beers <thymovanbeers@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] docs: kernel-parameters.txt: Fix whitespace
Date: Wed, 18 Apr 2018 20:16:37 +0200	[thread overview]
Message-ID: <20180418181635.GA24031@thinkpad> (raw)
In-Reply-To: <31612fbd-6624-140a-ed92-04b8f0bd5f64@infradead.org>

On Mon, Apr 16, 2018 at 03:03:47PM -0700, Randy Dunlap wrote:
> On 04/16/18 14:49, Thymo van Beers wrote:
> > Some lines used spaces instead of tabs at line start.
> > This can cause mangled lines in editors due to inconsistency.
> > 
> > Replace spaces for tabs where appropriate.
> > 
> > Signed-off-by: Thymo van Beers <thymovanbeers@gmail.com>
> > ---
> > Changes in v2:
> >   - Rebase against docs-next
> >   - Fix indentation modifications
> > 
> >  Documentation/admin-guide/kernel-parameters.txt | 136 ++++++++++++------------
> >  1 file changed, 68 insertions(+), 68 deletions(-)
> > 
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 3487be79847c..f625f65c286f 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> 
> Most of the patch is OK IMO, but not the intel_pstate part:
> The 2-space extra indents work fine here, while the extra tab makes a lot of the
> lines go beyond the 80-column mark.
> 
> > @@ -1650,39 +1650,39 @@
> >  			0	disables intel_idle and fall back on acpi_idle.
> >  			1 to 9	specify maximum depth of C-state.
> >  
> > -	intel_pstate=  [X86]
> > -		       disable
> > -		         Do not enable intel_pstate as the default
> > -		         scaling driver for the supported processors
> > -		       passive
> > -			 Use intel_pstate as a scaling driver, but configure it
> > -			 to work with generic cpufreq governors (instead of
> > -			 enabling its internal governor).  This mode cannot be
> > -			 used along with the hardware-managed P-states (HWP)
> > -			 feature.
> > -		       force
> > -			 Enable intel_pstate on systems that prohibit it by default
> > -			 in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > -			 instead of acpi-cpufreq may disable platform features, such
> > -			 as thermal controls and power capping, that rely on ACPI
> > -			 P-States information being indicated to OSPM and therefore
> > -			 should be used with caution. This option does not work with
> > -			 processors that aren't supported by the intel_pstate driver
> > -			 or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > -		       no_hwp
> > -		         Do not enable hardware P state control (HWP)
> > -			 if available.
> > -		hwp_only
> > -			Only load intel_pstate on systems which support
> > -			hardware P state control (HWP) if available.
> > -		support_acpi_ppc
> > -			Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > -			Description Table, specifies preferred power management
> > -			profile as "Enterprise Server" or "Performance Server",
> > -			then this feature is turned on by default.
> > -		per_cpu_perf_limits
> > -			Allow per-logical-CPU P-State performance control limits using
> > -			cpufreq sysfs interface
> > +	intel_pstate=	[X86]
> > +			disable
> > +				Do not enable intel_pstate as the default
> > +				scaling driver for the supported processors
> > +			passive
> > +				Use intel_pstate as a scaling driver, but configure it
> > +				to work with generic cpufreq governors (instead of
> > +				enabling its internal governor).  This mode cannot be
> > +				used along with the hardware-managed P-states (HWP)
> > +				feature.
> > +			force
> > +				Enable intel_pstate on systems that prohibit it by default
> > +				in favor of acpi-cpufreq. Forcing the intel_pstate driver
> > +				instead of acpi-cpufreq may disable platform features, such
> > +				as thermal controls and power capping, that rely on ACPI
> > +				P-States information being indicated to OSPM and therefore
> > +				should be used with caution. This option does not work with
> > +				processors that aren't supported by the intel_pstate driver
> > +				or on platforms that use pcc-cpufreq instead of acpi-cpufreq.
> > +			no_hwp
> > +				Do not enable hardware P state control (HWP)
> > +				if available.
> > +			hwp_only
> > +				Only load intel_pstate on systems which support
> > +				hardware P state control (HWP) if available.
> > +			support_acpi_ppc
> > +				Enforce ACPI _PPC performance limits. If the Fixed ACPI
> > +				Description Table, specifies preferred power management
> > +				profile as "Enterprise Server" or "Performance Server",
> > +				then this feature is turned on by default.
> > +			per_cpu_perf_limits
> > +				Allow per-logical-CPU P-State performance control limits using
> > +				cpufreq sysfs interface
> >  
> >  	intremap=	[X86-64, Intel-IOMMU]
> >  			on	enable Interrupt Remapping (default)
> > @@ -2027,7 +2027,7 @@
> >  			* [no]ncqtrim: Turn off queued DSM TRIM.
> >  
> >  			* nohrst, nosrst, norst: suppress hard, soft
> > -                          and both resets.
> > +			and both resets.
> 
> I would leave that line above indented like the one after "rstonce" below.
> 
> >  
> >  			* rstonce: only attempt one reset during
> >  			  hot-unplug link recovery
> 
> 
> -- 
> ~Randy

Okay, thanks for your feedback.

I reindented intel_pstate as you said and I can still see the whole
description for the 'advanced' option is going past the 80-column mark.

I'll leave it indented with two spaces for this patch.
If you wish I can make a separate patch that addresses 80-column overrun
for intel_pstate.

I'll indent the nohrst,... section like rstonce.

Does that sound good to you?

-Thymo

  reply	other threads:[~2018-04-18 18:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16 21:49 [PATCH v2] docs: kernel-parameters.txt: Fix whitespace Thymo van Beers
2018-04-16 21:49 ` Thymo van Beers
2018-04-16 22:03 ` Randy Dunlap
2018-04-16 22:03   ` Randy Dunlap
2018-04-18 18:16   ` Thymo van Beers [this message]
2018-04-18 18:16     ` Thymo van Beers
2018-04-18 18:32     ` Randy Dunlap
2018-04-18 18:32       ` Randy Dunlap

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180418181635.GA24031@thinkpad \
    --to=thymovanbeers@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.